What goes into your .gitignore if you're using CocoaPods?

I've been doing iOS development for a couple of months now and just learned of the promising CocoaPods library for dependency management.

I tried it out on a personal project: added a dependency to Kiwi to my Podfile, ran pod install CocoaPodsTest.xcodeproj, and voila, it worked great.

The only thing I'm left wondering is: what do I check in, and what do I ignore for version control? It seems obvious that I want to check in the Podfile itself, and probably the .xcworkspace file as well; but do I ignore the Pods/ directory? Are there other files that will be generated down the road (when I add other dependencies) that I should also add to my .gitignore?

I commit my Pods directory. I don't agree that the Pods directory is a build artefact. In fact I'd say it most definitely isn't. It's part of your application source: it won't build without it!

It's easier to think of CocoaPods as a developer tool rather than a build tool. It doesn't build your project, it simply clones and installs your dependencies for you. It shouldn't be necessary to have CocoaPods installed to be able to simply build your project.

By making CocoaPods a dependency of your build, you now need to make sure it's available everywhere you might need to build your project...a team admin needs it, your CI server needs it. You should, as a rule, always be able to clone your source repository and build without any further effort.

Not committing your Pods directory also creates a massive headache if you frequently switch branches. Now you need to run pod install every time you switch branches to make sure your dependencies are correct. This might be less hassle as your dependencies stabilise but early in a project this is a massive time sink.

So, what do I ignore? Nothing. Podfile, the lock file and the Pods directory all get committed. Trust me, it will save you a lot of hassle. What are the cons? A slightly bigger repo? Not the end of the world.

Personally I do not check in the Pods directory & contents. I can't say I spent long ages considering the implications but my reasoning is something like:

The Podfile refers to a specific tag or or commit of each dependency so the Pods themselves can be generated from the podfile, ergo they are more like an intermediate build product than a source and, hence, don't need version control in my project.

I recommend to use the GitHub’s Objective-C gitignore. In detail, the best practices are:

• The Podfile must always be under source control.
• The Podfile.lock must always be under source control.
• The Workspace generated by CocoaPods should be kept under source control.
• Any Pod referenced with the :path option should be kept under source control.
• The ./Pods folder can be kept under source control.

For more information you can refer to the official guide.

source: I’m a member of the CocoaPods core team, like @alloy

Although the Pods folder is a build artifact there are reasons that you might consider while deciding wether to keep it under source control:

• CocoaPods is not a package manager so the original source of the library could be removed in future by the author.
• If the Pods folder is included in source control, it is not necessary to install CocoaPods to run the project as the checkout would suffice.
• CocoaPods is still work in progress and there are options which don’t always lead to the same result (for example the :head and the :git options currently are not using the commits stored in the Podfile.lock).
• There are less points of failure if you might resume work on a project after a medium/long amount of time.