I'm developing a Pod that have a external dependency, which shows a lot of warnings in Xcode when using my Pod in an App.
What I want to do is remove all those warnings since it could quite annoying to see for those who use my Pod.
Is there a way to solve this? I'm trying several parameters in the subspec.xcconfig setting but I'm not able to find a solution.
Related
I'm using Pods in different iOS projects, now I would like to somehow get notified when a new version is released for one of the pods - no matter if via mail, rss feed or whatever. Does such a possibility exist?
A Podfile will generally semantically constrain the allowed versions of a pod (see semantic versioning):
pod 'Bolts', '~> 1.7'
This example would accept versions from 1.7 up to 2.0 excluded.
So the only way to know if there is a new version that fits your project is to run specifically for your repo:
pod outdated
Knowing that, you can script a Jenkins job to check it periodically.
Try https://www.versioneye.com/ . Not sure how well it works though.
I am building a cocoapod and wanted to add a dependency for Alamofire because my pod will be making some requests.
After trying to integrate my cocoapod (with the Alamofire dependency) into our main app, I got a version conflict because we are also using Alamofire in our app, but a different version.
Seeing this error, it made us wonder.. why havn't we seen a version conflict message like this one before? We have a handful of third-party cocoapods installed. After inspecting a few of our third-party pod spec files, we found that none of them have dependencies defined.
Is this common practice when releasing cocoapods, to have no dependencies?
(..asked by a Node.js developer)
Remember Alamofire now is on version 4.0(there is even a branch for swift 3), so, if you updated your pods, it automatically installed the new version, if this what you want take a look to the migration guide.
Other case, you have to specify the version you wanna wortk with in your pod file
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.
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.