FAQ

Do you really all wear wooden shoes in the Netherlands?

Good first question. As a matter of fact we do.

What are CocoaPods’s goals?

1. Make working with dependencies simple.
2. Improve library discoverability and engagement by providing an ecosystem that facilitates this.

Can I donate to the project?

Please refer to the dedicated page on this topic: Why we do not accept donations, but do accept sponsorship.

Can I install the bleeding edge version of a Pod?

Definitely. There are several ways to do this. See the documentation and an example Podfile for more info.

Can I workaround ‘Duplicate Symbol’ errors with static libraries?

This usually occurs when you’re using a closed-source third-party library that includes a common dependency of your application. One brute-force workaround is to remove the dependency from the static library, as described here

However, in general, the vendor should really prefix any dependencies it includes, so you don’t need to deal with it. When this happens, please contact the vendor and ask them to fix it on their side and use the above method as a temporary workaround.

I like to be able to browse the Pods' source files in Xcode, why hide them outside of my project?

Well, they are indeed kept outside of your application project, but these projects are combined in ‘workspaces’, a new feature that was introduced in Xcode 4. A workspace allows you to combine multiple projects and use it as if it were one.

A simple advantage example is that the dependencies won’t get your application’s prefix header and/or pre-processor definitions, which could potentially break the build. See this article by Mike Nachbaur for more information.

Here’s an example of what it looks like, for your viewing pleasure:

Or try it yourself. This particular screenshot is taken from the ‘AFNetworking Mac Example’, which you can find in the examples directory.

Finally, I have already heard from some people that this fits their company’s M.O., as they like to distribute their private libraries to their clients in the form of static libraries.

Wouldn’t it be great if there were a website where I could go and, like, search for Pods?

Bien sûr! Here it is!

Great! But wouldn't it be great too if pod specs were distributed through this website, instead of through Git?

Instead of starting out with a more complex server and client architecture, we want to keep things as simple as possible, for as long as possible. This is a good thing, because it allows us to move forward and focus on the more pressing issues first.

Unlike the Ruby community, the Objective-C community has a much longer commercial culture, with which comes lots of private libraries and/or forks. Trying to get people to adopt a new way to deal with their dependencies is a lot easier if it caters to them. Want to set up a private spec repo (or just separated from the CocoaPods one)?

$ cd ~/.cocoapods/repos
$ mkdir my-spec-repo
$ cd my-spec-repo
$ git init

Done.

If the repo is shared, you only have to do:

$ cd ~/.cocoapods/repos
$ git clone our-spec-repo

Finally, once many people use it and we start to clearly see the way in which this could be improved (or maybe not at all), then we can easily add it because of our lean basis.

I hear ARC is all the rage, but that mixing code can be tricky. So can I use ARC and non-ARC apps and libraries together?

Sure thing! First of all, because the Pods are in a separate project, it does not matter whether your application uses ARC. Second, the Pods project does not enable ARC by default, but any Pod that specifies that it needs ARC in its podspec will get an extra compile option on its source files: -fobjc-arc. This will compile that specific file only with ARC support.

I’m a developer, and I want to make my library available through CocoaPods. What do I do?

1. Create a podspec. CocoaPods can create a stub for you.

     $ pod spec create MyPod
     $ edit MyPod.podspec
     $ pod spec lint MyPod.podspec
   

2. Once you've verified that the spec produces a usable result by testing it out with a Podfile in your (example) application, create a ticket and upload the Pod. If you're familiar with Git, you can also fork the CocoaPods specs repository and send a pull request. We really love contributions and we’ll give you push access to push new releases at your own leisure.

3. Pop the champagne.

And if I want to contribute to CocoaPods in general?

Right on!

All CocoaPods development happens on GitHub, there is a repository for CocoaPods and one for the CocoaPods specs. Contributing patches or Pods is really easy and gratifying.

You can find a guide to setting up a development environment here on this very wiki.