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][1] library for dependency management.

I tried it out on a personal project: added a dependency to [Kiwi][2] 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?

[1]:

[To see links please register here]

[2]:

[To see links please register here]

I generally work on app’s of clients. In that case I add the Pods directory to the repo as well, to ensure that at any given time any developer could do a checkout and build and run.

If it were an app of our own, I would probably exclude the Pods directory until I won’t be working on it for a while.

Actually, I must conclude I might not be the best person to answer your question, versus views of pure users :) I’ll tweet about this question from

[To see links please register here]

.

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 check in everything. (`Pods/` and `Podfile.lock`.)

I want to be able to clone the repository and know that everything will just work as it did last time I used the app.

I'd rather vendor things in than risk having different results that could be caused by a different version of the gem, or someone rewriting history in the Pod's repository, etc.

I recommend to use the [GitHub’s Objective-C gitignore](

[To see links please register here]

).
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](

[To see links please register here]

).

_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.

I'm in the camp of developers who do not check in libraries, assuming we have a good copy available in another location. So, in my .gitignore I include the following lines specific to CocoaPods:

Pods/
#Podfile.lock # changed my mind on Podfile.lock

Then I make sure that we have a copy of the libraries in a safe location. Rather than (mis-)use a project's code repository to store dependencies (compiled or not) I think the best way to do this is to archive builds. If you use a CI server for your builds (such as Jenkins) you can permanently archive any builds that are important to you. If you do all your production builds in your local Xcode, make a habit of taking an archive of your project for any builds you need to keep. Something like:
1. Product --> Archive

2. Distribute... Submit to the iOS App Store / Save for Enterprise or Ad-hoc Deployment / what have you

3. Reveal your project folder in Finder

4. Right click and Compress "WhateverProject"

This provides an as-built image of the entire project, including the complete project and workspace settings used to build the app as well as binary distributions (such as Sparkle, proprietary SDKs such as TestFlight, etc.) whether or not they use CocoaPods.

**Update:** I've changed my mind on this and now do commit the `Podfile.lock` to source control. However, I still believe that the pods themselves are build artifacts and should be managed as such outside of source control, through another method such as your CI server or an archive process like I describe above.

Seems like a good way to structure this really would be to have the "Pods" directory as a git submodule / separate project, here's why.

- Having pods in your project repo, when working with several developers, can cause VERY LARGE diffs in pull requests where it's nearly impossible to see the actual work that was changed by people (think several hundreds to thousands of files changed for libraries, and only a few changed in the actual project).

- I see the issue of not committing anything to git, as the person owning the library could take it down at any time and you're essentially SOL, this also solves that.

To me, the biggest concern is future proofing your source. If you plan to have your project last for a while and CocoaPods ever goes away or the source of one of the pods goes down, you're completely out of luck if trying to build fresh from an archive.

This could be mitigated with periodic full source archivals.

I prefer committing `Pods` directory along with `Podfile` and `Podfile.lock` to make sure anyone in my team can checkout the source anytime and they don't have to worry about anything or do additional stuff to make it work.

This also helps in a scenario where you have fixed a bug inside one of the pods or modified some behaviour as per your needs but these changes will not be available on other machines if not committed.

And to ignore unnecessary directories:

xcuserdata/

I must say, I am a fan of committing Pods to the repository. Following a link already mentioned will give you a good .gitignore file to get up your Xcode projects for iOS to allow for Pods but also for you to easily exclude them if you so wish:

[To see links please register here]

My reasoning for being a fan of adding Pods to the repository is for one fundamental reason which no one seems to be picking up on, what happens if a library which our project is so dependant upon is suddenly removed from the web?

- Maybe the host decides they no longer want to keep their GitHub
account open What happens if the library is say several years old
(like older than 5 years for example) there is a high risk the
project may no longer be available at source
- Also another point, what happens if the URL to the repository
changes? Lets say the person serving the Pod from their GitHub
account, decides to represent themselves under a different handle -
your Pods URLs are going to break.
- Finally another point. Say if you're a developer like me who does a lot
of coding when on a flight between countries. I do a quick pull on
the 'master' branch, do a pod install on that branch, while sitting
in the airport and have myself all set for the upcoming 8 hour
flight. I get 3 hours into my flight, and realise I need to switch to
another branch.... 'DOH' - missing Pod information which is only available on the 'master' branch.

***NB... please note the 'master' branch for development is just for examples, obviously 'master' branches in version control systems, should be kept clean and deployable/buildable at any time***

I think from these, snapshots in your code repositories are certainly better than being strict on repository size. And as already mentioned, the podfile.lock file - while version controlled will give you a good history of your Pod versions.

At the end of the day, if you have a pressing deadline, a tight budget, time is of the essence - we need to be as resourceful as possible and not waste time on strict ideologies, and instead harness a set of tools to work together - to make our lives easier more efficient.