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

Question

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 person

Answer 1

At the end is up to you the approach you take.

This is what Cocoapods team thinks about it:

Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you.

Personally I'd like to keep Pods out, as node_modules if I were using Node or bower_components if I were using Bower. This apply for almost any Dependency Manager out there, and is the philosophy behind git submodules aswell.

However there are sometimes that you might want to be really sure about the state-of-art of a certain dependency, that way you are carry own the dependency within your project. Of-course there are several drawbacks that apply if you do that, but concerns do not only apply to Cocoapods, those applies to any Dependency Manager out there.

Below there is a good pros/cons list made by Cocoapods team, and the full text of the quote mentioned previously.

Cocoapods team: Should I check the Pods directory into source control?

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

The answer for this is given directly in Cocoapod docs. You may look at "http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control"

Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you:

Benefits of checking in the Pods directory

• After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no need to run pod install, and no Internet connection is necessary.
• The Pod artifacts (code/libraries) are always available, even if the source of a Pod (e.g. GitHub) were to go down.
• The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo.

Benefits of ignoring the Pods directory

• The source control repo will be smaller and take up less space.

• As long as the sources (e.g. GitHub) for all Pods are available, CocoaPods is generally able to recreate the same installation. (Technically there is no guarantee that running pod install will fetch and recreate identical artifacts when not using a commit SHA in the Podfile. This is especially true when using zip files in the Podfile.)

• There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod versions.

Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control.

Answer 6

Check in the Pods.

I think this should be a tenet of software development

• All builds must be reproducible
• The only way to ensure builds are reproducible is to be in control of all dependencies; checking in all dependencies is therefore a must.
• A new developer starting from scratch shall be able to check out your project and start working.

Why?

CocoaPods or any other external libraries might change which might break things. Or they might move, or be renamed, or be removed altogether. You can't rely on the internet to store things for you. Your laptop might have died and there is a critical bug in production that needs to be fixed. The main developer might get hit by a bus and his replacement has to start up in a hurry. And I wish that last one was a theoretical example but it actually happened at a startup I was with. RIP.

Now, realistically, you can't really check in ALL dependencies. You can't check in an image of the machine you used to create builds; you can't check in the exact version of the compiler. And so on. There are realistic limits. But check in all you can - not doing so just makes your life harder. And we don't want that.

Final word: Pods are not build artifacts. Build artifacts are what gets generated from your builds. Your build uses Pods, not generate them. I'm not even sure why this has to be debated.