I'm using cocoapods in xcode for few frameworks (Firebase extensions, fabric, facebook sdk etc). The moment I generated the workspace, it take too long to compile and makes it very difficult to work on the project.
I'm looking for a solution where I can temporarily disable the frameworks that are added through pod.
I have been trying few ideas but all of them have their drawbacks.
1) Remove the pods and update the repo (but it has to download all the pods again)
2) Make a backup of pod folder and create a temporary pod file with very limited frameworks (Pod always try to download the selected frameworks even if they're present in the folder)
3) Remove the frameworks from dependencies (This still compile the frameworks as they're added as a separate project in the workspace)
Related
I have a 3rd party framework I'm linking to my iOS folder, not a plugin, which I manually have to add back into the iOS project after I run pod install.
Is there any way I can persist the framework reference?
I thought I would need to create a podspec file for the framework, however, I have no idea how to tie the back into the podfile in the root of the iOS directory.
The project folder looks like this:
- MyFlutterApp
- ios
- OtherCompany.xcframework
Then in XCode, I add this to Pods->Frameworks manually; however, every time I need to run pod install, it removes the reference in XCode
I just added Cocoapods to my xcode project. I followed all of the instructions, and all of my frameworks were installed perfectly. However, now I have duplicates. I have frameworks in my Pods directory, and these same frameworks are still in my project's Frameworks group.
What would be the proper way to go about removing these duplicates? Should I remove them from the Frameworks group? Should I remove the Frameworks group altogether?
If I do remove them, how can I properly link to the new ones in the Pods directory so that the compiler knows where their new location is?
Also, if I do remove the duplicates, will this create conflicts when trying to commit these changes to my project's GitHub repo?
I have recently been working with Cocoapods on my own projects, and would like to incorporate a couple of pods into a project at work. The problem is that our code consists of close to 20 projects stored inside a large workspace, sorted into folders. The structure of the projects is
Workspace
Apps (Folder)
Project 1
Project 2
etc...
Modules
More Projects
etc
Base Components
Even More Projects
etc
I am unsure how to write a podfile that would link a pod (RETableView in this case) against an app without disturbing the existing structure of the workspace? Is this even possible? If it isn't possible to incorporate cocoapods without changing the existing workspace, is it possible to set up cocoapods to compile pods as standalone libraries that I could incorporate into our project?
With CocoaPods 1.x you can use :integrate_targets => false in your Podfile like this:
install! :integrate_targets => false
You can find the documentation for this here
Previously (for older CocoaPods versions):
After creating your Podfile use pod install --no-integrate documented here. This will create the Pods project that you can then include in your workspace. Please make sure everything in your project is checked into your version control system first just in case anything goes wrong.
We are working on many projects having common basic functionality, so we decided to put the common functionality in a framework and use it as git submodule, All well and good.
Now, I want to control Pods from framework as well, so I tried to put the Podfile into framework.
As Podfile and .xcodeproj are not in same directory, so to link the xcodeproj I tried to put
xcodeproj '../XYZ.xcodeproj'
As XYZ is different for every project, so want to use something like this.
xcodeproj '../*.xcodeproj'
Is there any way I can do it?
BTW it may be possible if I create a Private Pod and then use the Pods as dependencies of it, But in my case above solution will be handy.
I've setup cocoapods for my project and I've been doing development for quite some time without any issues. Recently I added a new Configuration for it called "Beta", duplicating the "Release" configuration. At the same time, I added a Scheme that would build targets using this configuration.
This new scheme would build everything without issues, but linking would fail with the (quite known it seems) message:
ld: library not found for -lPods
I know that issues that makes this error message come up have been discussed widely around the web, with different causes and conditions:
library not found for -lPods
https://github.com/CocoaPods/CocoaPods/issues/155
None of these fixes seem to apply here. What I can see by looking into the workspace folder, is that Cocoapods build products are put in Build/Products/Release-iphonesimulator instead of in Build/Products/Beta-iphonesimulator, even though the app itself is built rightly so into the latter. Moving all the *.a files into Build/Products/Beta-iphonesimulator makes running in the simulator work properly, but the next build is still put in the wrong location.
Edit
After some further investigations, the environment variable $BUILT_PRODUCTS_DIR is set correctly in the build phase for the app itself, but not when building cocoapods products.
What causes this and how can I fix this?
Ruled out issues
pod install has been run, multiple times
I'm working in the workspace, not in the project
The cocoapods configuration file in the new configuration is properly set
Build locations in the preferences seem fine
For the record, the issue has been solved. So, as I said, I use cocoapods, but my current setup is that a single podfile, and workspace is used for 3 projects that share some common libraries. As explained in this issue, cocoapods will only consider one project out of all those that are specified in the podfile, and it turns the one project (out of three) that it was using, didn't have the beta configuration, so it didn't feel the need to prepare for it. So when it was time to build the project with the beta configuration, cocoapods would be built for the release configuration, and put in some folder specific to release, so the beta project wouldn't be able to find it.
Fixing was a matter of creating the beta configuration for all projects present in the workspace, forcing cocoapods to prepare accordingly. Then, Xcode would be able to wire up everything appropriately.