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

In theory, you should check in the Pods directory. In practice, it is not always going to work. Many pods well exceed the size limit of github files so if you are using github you are going to have issues checking in the Pods directory.

Answer 2

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.

Answer 3

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: https://github.com/github/gitignore/blob/master/Objective-C.gitignore

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.

Answer 4

.gitignore file

No answer actually offers a .gitignore, so here are two flavors.

---

Checking in the Pods directory (Benefits)

Xcode/iOS friendly git ignore, skipping Mac OS system files, Xcode, builds, other repositories and backups.

.gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

---

Ignoring the Pods directory (Benefits)

.gitignore: (append to previous list)

# Cocoapods
Pods/

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

If Pods are not checked-in, your Podfile should probably request explicit version numbers for each Cocoapod. Cocoapods.org discussion here.

Answer 5

It depends, personally:

Why pods should be part of the repo (under source control) and should not be ignored

• The source is identical
• You can build it right away as is (even without the cocoapods)
• Even if a pod is deleted, we still have its copy (Yes, this can happen and it did. In an old project where you want just a small change you would need to implement a new library to be able to even build).
• pods.xcodeproj settings are part of the source control as well. This means e.g. if you have the project in swift 4, but some pods must be in swift 3.2 because they are not updated yet, these settings will be saved. Otherwise the one who cloned the repo would end up with errors.
• You can always delete pods from the project and run pod install, the opposite can not be done.
• Even the authors of the Cocoapods recommend it.

Some cons: larger repository, confusing diffs (mainly for team members), potentially more conflicts.

Answer 6

TL;DR: when you track the Pods/ folder, the project is easier to pick up from. When you don't track it, it's easier to improve on when you work in a team.

Although the Cocoapods organization encourage us to track the Pods/ directory, they say it's up to the devs to decide whether or not to do it based on these pros and cons: http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control

Personally, I usually track the Pods/ folder just for projects that I won’t be working on anymore for a while. That way any developer can quickly pick up from it and continue the work using the proper version of the cocoapods.

On the other hand, I think the commit history gets cleaner and its easier to merge the code and review another person's code when you are not tracking the Pods/ folder. I usually set the cocoapod library's version when I install it to make sure anyone can install the project using the same versions as I.

Also, when the Pods/ directory is being tracked all the devs have to use the same version of Cocoapods to prevent it from changing dozens of files every time we run pod install to add/remove a pod.

Bottom line: when you track the Pods/ folder, the project is easier to pick up from. When you don't track it, it's easier to improve on.