tl;dr - I check in dependencies in my projects. It allows me to work faster and easily re-create old builds
There is a war going on in the iOS development community. Lines have been drawn in the sand. The two sides are well armed and deep in conflict. Their problem?
Checking in dependencies.
Washington Crossing the Delaware, Emmanuel Leutze, 1 January 1851
One faction holds strong to the idea that you should check in most everything to build your app; the other faction is fundamentally opposed: they believe you should keep your projects lightweight and pull in your dependencies at build time.
In this post I’ll describe the pros and cons of both choices and describe why I’ve chosen to check in dependencies in my projects.
Not checking in your pods
- Smaller project size. If you don’t commit AFNetworking and SVPullToRefresh and all your other pods to your project then it will by definition, be smaller. Is this really a big deal? Most of the projects I have worked on are hosted internally so they check out pretty fast. Even if they aren’t then how often do you have to check out your project? If you’re worried about long build server checkout times take a look at my other post on speeding up builds which describes how you can do a shallow clone for your build server.
- I don’t know why else? From an iOS / CocoaPods perspective this seems to be it. If you don’t check in your pods, then you have a smaller project.
- You don’t have your dependencies! :) While it’s fine to think that CocoaPods will always be around, what happens if it goes the way of SourceForge and becomes less dependable over time? This becomes a big deal if you’re in the habit of building old projects for regressions etc (having worked in a couple of banks this can be a big deal).
- Slow builds on build server if you’re running a clean build each time.
- Mayhem if you are actively switching between branches which have different dependency graphs. I’ve been in the situation where a release branch was different to
pod install10x a day anyone?
- Having to email everyone in your team and tell them “the pods were updated, please run a pod install” each time you update the Podfile.
[Additional unrelated War of Independence image:] The Siege and Relief of Gibraltar, John Singleton Copley, 13 September 1782
Checking in your pods
- Fast builds! You don’t need to grab stuff from CocoaPods if you’re on a build server all the time.
- Easily reproducible builds! If you have an ancient app with three20 in it (it happens - I’ve had to use the Wayback machine not that long ago to read the three20 documentation for a job) you can build it without having to worry about whether the Podspecs are correct.
- No having to email everyone to “install the pods” (and no colleagues pulling their hair out wondering why they can’t build the project).
- You have a bigger project. Is this really a con though? I get it if you’re running a Facebook style enormous repo but in my experience for most commercial size applications, this isn’t a huge issue.
- Git “noise” generated by committing the pods (thanks to the astute Andy Skinner for pointing this one out). Each time you update a Pod there will be a large number of file changes in your git repo. This isn’t a big deal if you separate your commits judiciously (ie: don’t do a commit which updates your pods AND makes some change to core auth logic - as this would be confusing to someone reading your git history 😃) but I can understand why it might put some people off on first appearance.
So there you have it. The ups and downs of this strangely divisive choice. I’m all for checking in my pods. All of the pros outlined above - and then some - have been realised on large commercial iOS projects. In the past I’ve made the switch for applications built with large teams and colleagues have been quite enthusiastic about the benefits. I think you might too! Please leave comments below 😃