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.
Related
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)
I have a iOS framework for which I don't have the source and the authors have not provided a podspec for it. I'm already using CocoaPods for multiple other libs and would love to keep this one along with them.
Is it possible to create a podspec file that will simply reuse the existing framework binary?
I have:
xxx.embeddedframework/
xxx.framework
Resources/
yyyy.momd
I know all the details like what system frameworks it depends on.
I suspect vendored_frameworks may be an answer, but I'm not sure how to write one. For example, s.source is mandatory parameter and I don't have any source files so pod spec lint fails.
Note: I can see this question has been asked once before here: Right way to extend or customize cocoapods
but I am unsatisfied with the answer. Some more specifics would be great in the case where rather than simply adding new methods, etc., you wish to fundamentally alter the nature of the pod, and don't really have the time to submit a patch to the original pod owner (nor would they necessarily want to pull your app-specific changes to their generalized project).
Right now I am working on a project that makes significant use of Cocoapods, but currently the project's Pods directory is more or less frozen due to customizations of multiple pods to suit the needs of the app.
Since the customizations were done directly in the pods classes, the Pods project needs to be frozen from new installs/updates because it doesn't seem to be possible to add or update single pods without doing them all at the same time. Doing this naturally results in errors when the customizations get wiped out by the update.
I know that a feature to update individual pods was introduced in a recent version of Cocoapods, but that new version seems to introduce new issues where "Analyzing dependencies" will often error out with incorrect circular dependencies between a single pod and itself.
And as far as I know, there is no way to add a single pod without updating the others at the same time.
So then, what are people's strategies for customizing pods without getting into this kind of situation? Do you subclass in your main project while leaving the pods directory untouched?
At the end of the day, are pods really that much better than git submodules?
Thanks for advice as to how to make use of them while still customizing freely and not wind up in this kind of situation.
Right now my perspective is that pods which will be used without alteration can be imported to the Pods project as usual, but pods that are heavily customized should be added to the main project and separated from the pod add/update process completely.
You should never make changes to any Pod directly.
What you should do, if you really must change the behavior of the dependency (i.e., you can't solve the problem with any other alternative such as composition or even categories), you should create a fork and then make the changes there.
Then, on your Podfile you should add the link to your fork:
pod 'MyLib', :git => 'https://github.com/someuser/MyLib.git'
Also, none of your Pods should ever make reference to your app code. A dependency should be self-contained.
All of these problems you're having is not CocoaPods' (or any other tool) fault. They're happening because you (and your team) misused it.
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.