Every time you add a Pod, an angel loses its wings

This article uses Cocoapods as an example, but the idea applies to any dependency system on any platform.

Third-party libraries are just great. By simply adding a line to your Podfile, you can bask in the glow of someone else’s hard work making your app that little bit more fantastic. But how can you improve as a developer this way? And what risks do you expose your app to?

Take a look at most large projects and their Podfile will be big. Third-party dependencies are now a common sight in apps, because they make development so much easier. Need a stack of cards in your iOS app? There’s a pod for that. Don’t like the API of constraints on iOS? There’s about a million pods for that. You could write these things yourself, but if someone else has done it for you, that’s probably better right?

Easier dependencies aren’t always better

A few years ago, before Cocoapods and Carthage existed, adding dependencies to an iOS project was a bit of a nightmare. It involved downloading, dragging and dropping, and hoping that the .framework wouldn’t get messed up when you added it to Git. Thankfully, such dependency systems blow away this friction and makes it a lot easier to add an external dependency to your project.

Reducing friction is great, but also reduces the perceived cost of an action, meaning you’re more likely to do it (this applies to a lot of things). Making adding external dependencies easier means that you’ll likely add more of them. Conversely, the more difficult something is, the more you think about whether it is actually beneficial. When adding a dependency is so easy, it becomes a case of “add the dependency, ask questions later”, which can prove problematic.

Your schedule vs. their schedule

There are two big sticking points with third-party dependencies. The first is that you’re tying yourself down to be dependent on someone else’s work, time, and effort. This is great if a library is well maintained, with a responsive owner and clear prioritisation of upcoming features. However such a case is quite rare — a lot of projects are abandoned, buggy, or generally ill-prepared to be used externally.

The feedback loop for a change, be it a new feature or a critical bug fix, is far larger for a project you don’t own vs code that you do. It’s riskier. Waiting weeks for a fix is not ideal for a product owner. Even worse, many a time I’ve used a library, only to find that it doesn’t quite have the level of customisation the design needs; in the end, we had to throw it away and write it ourselves anyway. If we’d properly looked at the library before, and weighed up the decision, we’d have realised that it didn’t do what we needed, and that it would be far quicker to write it ourselves than go through the process of adding it to the library.

Your learnings vs. their learnings

The second sticking point is one people don’t often think about. Most libraries exist to solve a single problem. How can I make JSON parsing easier in Swift? How can I make my UI layout code more obvious? Whilst libraries are there because someone has already solved the problem… why not try and solve it yourself too? You might come up with a better solution, or a worse one; but either way you’ve learnt something, and learning is the only way to become a better developer.

Learning is the only way to become a better developer.

DIY

I have nothing at all against Cocoapods. In fact, some of my best friends are Pods. But the whole mobile development ecosystem tends towards using other people’s work rather than your own. This is great if you need to put something together quickly, but you lose the ability to try your skill at something new, and may open yourself up to a problem later down the line. Solving a problem in your own way also gives you a warm, fuzzy, feeling inside, and your solution will fit better with the product you’re writing. It’s not easy recognising when you should use an external dependency and when you shouldn’t, but it is a skill worth having.

Try removing a single dependency from your build soon, solving that problem yourself and bringing it into your project. Then bask in your warm, fuzzy, glow, instead of someone else’s!