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

Pros of not checking in Pods/ to version control (in subjective order of importance):

1. Much easier to merge commits, and review code diffs. Merging is a common source of issues in a code base, and this allows you to focus only on things that are pertinent.
2. It's impossible for some random contributor to edit the dependencies themselves and check the changes in, which they should never do (and again would be hard to identify if the diff is massive). Editing dependencies is very bad practice because a future pod install could occlude the changes.
3. Discrepancies between the Podfile and the Pods/ directory are found quicker among teammates. If you check in Pods/ and, for example, update a version in the Podfile, but forget to run pod install or check in the changes to Pods/, you will have a much harder time noticing the source of the discrepancy. If Pods/ isn't checked in, you always need to run pod install anyway.
4. Smaller repo size. Having a smaller byte-footprint is nice, but that doesn't matter much in the grand scheme. More importantly: having more things in the repo also increases your cognitive load. There is no reason to have things in the repo that you shouldn't be looking at. Refer to documentation (the abstraction) to know how something works, not at code (the implementation).
5. Easier to discern how much someone contributes (since their lines of code contributed won't include dependencies they didn't write)
6. JAR files, .venv/ (virtual environments), and node_modules/ are never included in version control. If we were completely agnostic about the question, not checking in Pods would be the default based on precedent.

Cons of not checking in the Pods/

1. You must run pod install when switching branches, or reverting commits.
2. You can't run a project just by cloning the repository. You must install the pod tool, then run pod install.
3. You must have an internet connection to run pod install, and the source of the pods must be available.
4. If the owner of a dependency removes their package, you are in trouble.

In summary, not including the Pods directory is a guardrail against more bad practices. Including the Pods directory makes running the project easier. I prefer the former over the latter. You won't need to debrief every new person on a project about "what not to do" if there is not a possibility for making certain mistakes in the first place. I also like the idea of having a separate version control for the Pods which alleviates the Cons.