Wrap Up

Tomorrow you’ll unwrap your present, but today we wrap up The iOS Advent Calendar 🎁.

Sorry, I couldn’t resist the pun.

Thank You

I would like to start by saying thank you all for going through this journey with me. I made a lot of typos, and sent out some emails with the wrong links, but you have always been patient and gave me positive feedbacks.

Writing one post per day for 24 days straight has been quite a challenge for me, but thanks to your support I made it. I am very grateful for that.

Open Source Libraries

These 23 posts have showcased a variety of libraries, from big frameworks like Alamofire and Eureka, to small sharp focused libraries like Regex and AnimatedGIFImageSerialization. We’ve seen libraries that improve testability like Quick and OHHTTPStubs, and other that provide delightful UX like AMScrollingNavbar and BubbleTransition.

When trying to implement some piece of functionality, if you spend enough time between GitHub, Google, and StackOverflow there is a high chance you’ll find a library that does that for you. Or more than one.

It can be tempting to pull in as many libraries as possible, and just write code that makes them interact together. But we need to be careful. Each library comes with both advantages and disadvantages.

The advantage of libraries

A well written library will help you in your development, either by saving you the time of implementing some user interface component or complex logic, think of SDWebImage, or by simplifying existing APIs, think of SugarRecord.

Libraries can let you focus on your domain logic, without having to worry or spend time on mundane coding tasks.

Libraries and frameworks are great. Using them we can stand on the shoulder of giants and achieve great results with minimum effort.

The danger of libraries

Seasoned software engineers are aware of the fact that the more code is in a project, the harder that becomes to maintain. Each library we pull in adds code that we will somehow need to maintain.

Are you sure you understand everything that is going on in the internals of the library? What if there are undocumented side effects? Or worst, bugs?!

What happens if there is a bug in one of our libraries? We have now added a bug to our project that would not have been there. How is going to fix that? The library maintainers or us with a fork? If so, will we ever have time to submit a PR with the fix?

And what if the maintainers stop working on the library. It’s free open source we are talking about, they are all working on it in their spare time, and more often than not life can get in the way.

This is a great post that goes deeper in the pros and cons of third party libraries.

How to choose

When evaluating whether or not to use a library you should ask yourself these questions:

• Do I really need a library, or could I write that myself? If so, how long would it take me?
• Is the library well documented? How does the internal code look like? Does it have unit tests?
• Is it still maintained? When was the last commit? And the last release?
• Does the library have a community of users? Are there open issues, tutorials, StackOverflow questions?
• Is it going to be easy to use, or just another tool to fight?

Writing your own libraries

One advantage of libraries that I haven’t yet mentioned is that a good library does only one thing, and does it well. This means that the library’s code has one single concern.

This is a very powerful concept. Separation of concerns and single responsibility principle are best practices that can help you write code that is both easy to understand and to maintain.

Justin Spahr-Summers, author of ReactiveCocoa and many more libraries, gave a great talk entitled Library Oriented Programming, in which he suggests that we could try to architect our projects as a collection of our own little domain specific libraries. The Clojure community is very keen on building small libraries too.

Structuring your code in a single responsibility library oriented way is a recipe for good code, and can also lead to discovering libraries that can be shared across different projects.

Going open source

When extracting code into its own library to share it across projects something you might want to consider is making it open source.

In my opinion you should consider going open source by default. Unless the code as special competitive advantages for you or your business you should open source it.

The advantages of open source code are many, and huge. First and foremost you are helping other developers like you, and this is very important. On top of that you will get free code reviews and possibly free bug fixes. It is a great opportunity to grow as a developer.

Maintaining an open source projects and its community is also a useful skill to develop, as it is more related with managing people and project management than coding itself. You can read more about it on this NSHipster post.

Finally, by publishing open source libraries you get the chance to be featured on The iOS Times. 😎

Once again, thank you, thank you so much for reading along these posts. I hope you enjoyed them and found them useful. If you want to get in touch send me a tweet @mokagio.

Let me know if you’d like The iOS Advent Calendar to return next year, in the meantime you can keep up to date on the latest and greatest open source libraries by subscribing to The iOS Times.