A short (beginners) guide to choosing third party libraries
Open source libraries are a blessing for us developers and that’s not big news. If chosen wisely, they save us time and energy. We don’t have to care too much about implementation details, maintanence and features. Instead, we are served an easy consumable API that gets us where we want with less effort. I never had to write a QR code scanner of my own, and I sure as hell won’t ever write a networking library again.
However, there are many considerations when it comes to choosing a library for your project. Picking one that is not well maintained will backfire sooner or later. For now let’s assume you want to implement a library and you found one that can be customized to your needs.
Let’s head over to Github and navigate to the library of your choice.
Here are a few things I look out for when choosing an open source library.
Does the library support dependency managers?
Dependency managers have made our life much easier, and I can’t even remember how coding was before they were around. On iOs, my favorite is Cocoapods, but Carthage has gained significant traction as well. Not to forget Apples own Swift Package Manager, which will definitely be a thing in the near future. I won’t go into detail here and explain how they work, but you should use them, trust me. They handle the nitty-gritty for you, like integrating dependencies in your app, making them easy to update, just to name a few.
So make sure the dependency manager of your choice is supported.
When was the last commit to this repo?
A repo that has not been updated in a while might not be your first choice. Usually, commits older than 6 months make me suspicious, commits older than 1 or more years effectively disqualify this repo. That is even more important with iOS these days, as Swift is evolving quickly and comes with new breaking API changes on a regular basis. Chances are the library is not well maintained, and it will be up to you to keep it up to date. In the end, you might be better off looking for an alternative or writing it yourself.
Having said that: it is always a good idea to check out other branches in the repo, besides the master. Many devs prepare their libraries for compatability with upcoming SDK versions on separate branches. These will be merged once the new version was released and can be used explicitly in your project until then.
How many stars does the library have?
If a repo has a considerable amount of stars (and forks), that’s usually a good indicator that there is a big community behind it. It’s hard to tell what “a considerable amount” might be, but for now I’d say roughly 600+. Let me stress that I am not saying that a library with less stars might not be the perfect fit! All I am saying is that many hundreds or even thousands of stars are almost a guarantee that this lib does a great job and that there are people out there who care. People who discover bugs quickly and contribute by fixing them. People who are interested in keeping this library up-to-date as it lives in their very own projects. So, as a rule of thumb: the more stars, the more future-proof your decision will be.
How many issues does the library have?
The Github issue tracker is a handy thing. It gives you a good unterstanding of how the owner and the community contribute to the library. Let’s check out the issue tracker of Alamofire, the elegant networking library in Swift.
Issues usually come in three flavors: bug, question or feature request. Lets focus on bugs and questions:
Is there a long list of unresolved bugs, some of them dating back months or even years? Check out the detail view: do these bugs seem valid to you? Are there any responses of project members? If not, I would decide against using this library.
Are there many issues labeled question? Even though it seems they are about very basic things? This could be a hint that this lib is not well documented or complicated to use. However, if questions are answered quickly and frequently, you can expect help when opening an issue as well, in case documentation alone does not solve your problem.
This also leads to the next question:
Is the library well documented?
The readme is the landing page for every Github repository, the first impression. What do you think? Does it give you a good overview on what the library is and how it can be used? Was it made “with love”?
Does it feature API documentation and examples? These are things that should be easy to discover. If there is no inline documentation, there should be a link to it. More complex libraries might have an extra documentation folder, some also feature a wiki page and/or a website. The better the documentation is, the less you will find yourself searching for answers.
What does the code look like?
Let’s go to the folder where the source code of the library of your choice lives. If it is a complex thing: are there many files and classes with single responsibilites? Good! Choose a class. Is it well structured, not 10.000 lines of overwhelming code? Is it commented well? Do you understand what it is supposed to do, regardless what the implementation details are? Perfect, that looks like a well written library!
What does the UI look like?
Ok, that might just be me. And mostly for libraries that feature UI related stuff, but — I need screenshots! Does it look good? Does it fit the style of my app? Can I customize it so it doesn’t feel wrong in my app? Is there motion design involved? Show me a video! It’s not a biggie showcasing your app with screenshots or gifs right in the readme to give you an idea of the look and feel. I have never, I repeat, never even tried a UI library that does not have screenshots.
Last thing here: make sure that all libraries support the oldest iOS version your app is supposed to run on. Don’t use a iOS 9+ only library when your app needs to support iOS 8… Just sayin’ ;)
Bonus tips
Follow your favorite devs on Github and you will see their repository likes in your timeline. I have found many cool libraries this way, believe me ;)
Additionally, I would encourage you to check out trending repos on Github once in a while. You can filter by language and time-period. Another way to find cool stuff and inspiration.
In general: Follow, read and listen. That’s how the community works :)
These are just my two cents, I bet other developers have opinions, too. I would be more than happy if you shared your thoughts here. Thanks!
