No matter the platforms you develop on, any sane developer knows it’s prudent to use a source code repository and check in their commits when progress is made. This is just common sense among us. But what about your dependencies?
Should you also check in your dependencies? In the iOS world, that means CocoaPods or Carthage.
The short answer is yes. You should always check them in.
For the longer answer, …
If you don’t check them in, the next time you or a new developer needs to check out the project, you need to run pod install. Wifi has become so prevalent that this is no longer a problem. Virtually everywhere you go has free wifi. The latest MacBook Pro models don’t even have an Ethernet port anymore. Even if you know you’re going to a place without Internet access, you can easily check out your project before you leave the house. Nobody complains about not being able to use a web app nowadays.
You can even make your Podfile specify the exact versions for all your dependencies. When you run pod install, it’ll pull down those pods you want.
By not checking in your dependencies, especially if you use a lot of them, you also save a lot of space and make your repository small in size. You also save a lot of time when checking out a large project.
However, …
No modern repository host charge by size or bandwidth. Most charge by the number of projects, the number of users, and/or whether you can create private projects. So the space and time arguments go out of the window.
Modern download speeds are plenty fast that it doesn’t take too long to download the dependencies. Especially when they are mostly text files.
So those advantages disappear.
If you check them in, all you need to do is to check out the project. It may take a little longer. But there’s no need to run pod install to fetch the dependencies separately. This has some advantages,
Pods usually aren’t specified by the exact versions. Rather, you specify newer than or equal to a particular version. This means another developer may pull in a slightly newer version than what you want and expect 3 months later. There could be changes that break your app in subtle ways. Unless you know all your dependencies in and out, you aren’t signing up for a lot of headaches down the road. Let’s face it, the fact that you’re using these pods is because you want to delegate these tasks and not worry about them. But now you do.
Even worse, what if the pod version your app needs no longer exists? Hey, it’s open source software. The author doesn’t have any obligation to maintain it for you forever. New changes in iOS may also make it incompatible or even obsolete. Download it while you can.
Most of the time, installing the pods isn’t the time consuming part. Setting them up properly for your projects can turn many hairs grey. There may be dependencies between the dependencies. There may be a config or plist file that you need to edit first. A missing import or bridging header? You name it.
If you don’t want your app suddenly breaks for some unknown reasons, and you have to cut your day short, check everything in. Because you know what – you can always decide to remove them later if you want to upgrade your dependencies.
Also, read about why you want to organize your source code files by intent.
