The Swift Blog: Third-Party Libraries vs. your own solutions

Everyone, at some point, has come to a point in which he/she needs to implement a feature that requires a lot of work, or involves unknown APIs. One option that often comes to mind then is to use a third-party library. CocoaPods and Carthage make this extremely easy, so why not? In this post I want to talk about why this isn’t always the best way to go though.

What is a third-party library?

To answer the question whether you should consider using a library let’s first talk about what those libraries are. In short they’re ready-to-use implementations of features your app might need. This can be a camera view you like better than the built-in UIImagePickerController, or a calendar view you don’t need to code and design yourselves. Another example would be a networking layer like Alamofire which takes away the burden of setting up your own URLSessions and gives you an easy to use interface with which you can then download your data and forget about it. So, with this out of the way let’s dive into the pros and cons of third-party code.

Pros

The biggest pro on our list would be that we don’t need to think about how to code the library we’re using. Simply fetch it using pod install or carthage update and you’re good to go. You also don’t have to maintain the code for the library. Since it’s written by someone else and distributed via CocoaPods and/or Carthage, a simple command in Terminal will fetch the latest release and you’re good to go once again.

Cons

The biggest con in our list is also the biggest pro, and that is that you don’t have to maintain the code you’re using. Confused? Let me explain: Imagine that you thought of a feature you absolutely need in your app, and imagine now that you’re lucky and someone already wrote the code for exactly that feature. It’s a pod so you spin up Terminal, create a Podfile, run pod install and open up Xcode just to see a bunch of build warnings and errors stating that the code can’t be compiled because it’s written in an unsupported Swift language. Yes, this happens and it happens a lot. People deploy a library via CocoaPods and/or Carthage, maintain the code for a couple of months or even years, but then all of a sudden they don’t anymore. The project becomes stale, but they also don’t remove it from GitHub or add a note that the library isn’t being maintained anymore. So you start searching for an alternative, maybe you can find one quickly, maybe you need to search a little longer, and also maybe you need to start writing the code yourself. In any case, the time you spend looking for and installing various versions of your dream feature could also have been spent implementing it yourself. You would not only have saved yourself a lot of time, you would maybe even have learned something new, a simple win-win situation. Which brings us to the second biggest issue with third-party code and that is changes and the resulting lack of documentation. Most third-party libraries you can find on GitHub have a very short summary of what the framework can and can’t do, but only very few are fully documented. Now imagine what happens when the author decides to change a function or class name but doesn’t update the docs. The worst case scenario would be that your entire project stops working and you need to figure out why, completely on your own. The last thing to consider is what you will learn from using third-party code. I often find myself not even considering taking a look at the underlying code, so basically with using other people’s code you’ll learn nothing. For some people this might not sound like the worst thing since your app will still work and can be deployed to the App Store nonetheless, but then again we need to think about the issues I stated above and the risks we take. When the library you’re using stops working you will eventually have to think about implementing it yourself.

Conclusion

Using third-party libraries can be quite easy and convenient, but I like to think long-term. Will the library be maintained in the near future? Will I be able to implement this feature myself in a reasonable amount of time should things go south? Will I learn something valuable for the future if I at least try to write this piece of code myself? If you ask me for advice if you should go ahead and give CocoaPods and Carthage a try, then I would say “Yes, definitely”. But please also bear in mind that you’re relying on other people here and you need an escape plan if something doesn’t work out as planned.