Checking in 3rd-party dependencies.

In the CocoaPods documentation, the recommendation is made to check your dependencies into SCM. I often find myself discussing this with other developers, so I thought I’d write-up some of my arguments, in no specific order.

It’s part of your app.

At runtime, whether or not code is specific to the app or lives inside a 3rd-part dependency is irrelavent to me. If you decide to pull in a dependency, be it explicit or implicit, then, in my book, you’re on the hook for maintaining it.

Checking the sources of 3rd-party dependencies into SCM makes for a great way to review the sources we’re pulling in and to be aware of the sizes thereof.

Don’t trust the internet.

If you’re trusting that sources you depend on can be hosted elsewhere out of your control, then sooner or later you will suffer. Sources will go down temporarily or even indefinitely.

Checking in sources is akin to backups. Backups are good. I know this, you know this, even if we don’t make any backups of our personal data.

Simplify bootstrapping.

Not every contributor will need to manage dependencies, especially not when first checking out your project. Minimizing bootstrapping steps will make them happier and more productive. Imagine if those contributors aren’t even developers, but for instance designers… ugh, that must suck for them.

Checking in the sources you depend on and setting up the project to be able to run without the dependency manager even being installed is the best experience you can give your new contributors.

But checking in dependency sources adds noise to my project sources.

One popular solution among believers of checking in your dependency sources is to have a dedicated external SCM module for these. Then the diff of your project will simply show that the external dependency module changed, so you’ll still be able to connect dependency changes to project changes.

At Artsy we have an external repo for our CocoaPods dependencies.