Think twice before using a third-party library

First of all, a short introductory advise: I am an indie developer, my projects are small if compared with those led by comercial brands or software consultancies, and my resources are limited. Developing apps is not my main source of income, and I don’t have to follow tight project plans or aggressive delivery dates when coding.

Being said this, the following post is my personal experience using third-party libraries in my apps. There are many good articles discussing this topic (Avoiding Third-Party UI Libraries, by Arek Holko is one of the last I’ve read), but I have not seen anyone showcasing real life examples. I think I can add my little contribution if I describe why and how I used third-party code, what I got in the long term and which was the final result. If you are thinking about including that fancy library from Cocoa Controls in your project, keep reading…

Wow, these libraries rock!

I started coding my first IOS app, Do Not Eat That!, about 5 years ago. Swift didn’t exist yet at that time, and my development abilities were not so impressive. Being confronted with many app design challenges, I searched for third-party libraries that could rescue me from the hard bits of some cocoa frameworks, such as CoreData or StoreKit. Sometimes I was just trying to save time in writing common (and boring) chunks of code. This was the case of my settings view. Instead of using a standard approach for it (a table view with dynamic cell prototypes) I tried the XLForm library, that allows the creation of form UI elements quickly, just assigning configuration properties to predefined form objects.

The time I spent learning the quirks of XLForm was considerably higher than expected. Making a fully featured settings view with it required the use of many of its hidden features, and there were hours just dedicated to explore and learn the caveats of the library.

The final result was, however, quite good. It looked fine and professional (well, at least, professional to the eyes of an indie developer). At that time I confess I was fully convinced that using this library (and many others) had been a good decision.

The euphoria of the initial success

Considering the theoretical success of using XLForm in Do Not Eat That!, my second app, Next Song Player, ended up having external libraries from many contributors. One of them was DZNSegmentedControl, a replacement for UISegmentedControl that adds a text field to show a counter in every segment.

The extra work needed to include this control into my app was not too high. However, things started to get complicated when I realized that I needed a second row of segments. DZNSegmentedControl was not designed to build a matrix of segments, and modifying it to achieve this design pattern would be very complicated without knowing the internals of the code. I finally decided to create a new instance of the same control, which obliged me to add many extra lines of code to handle simple actions, like selecting and deselecting a segment. Not too good.

Playlist selection using DZNSegmentedControl in Next Song Player

I decided also to keep on using XLForm for my settings view, and considered it a good fit for the playlists filter options. The view for the filter options had complex requirements, if compared with the settings form. I had to create custom subclasses of the predefined form cells shipped with the library, as I wanted the filter view to display counters for the number of songs that resulted after applying a filter. Before having a working UI I spent between 8 to 10 hours crafting the XLForm code and embedding it into my app. Things had started to get complicated.

Filter options using XLForm in Next Song Player

Maintaining and evolving my apps

My apps were born as Objective-C projects. As the swift usage started to gain traction among the IOS development community, many of the libraries I was using were no longer maintained in their Objective-C versions. In the beginning I considered this a minor setback. Later on I realized that IOS is a fast paced technology that evolves quickly: with each new version, Apple adds more and more capabilities, while at the same time, flags legacy frameworks as deprecated. Obviously, the third party libraries I was using were not taking advantage of these improvements.

Furthermore, Xcode started to display warnings to highlight the use of deprecated classes and methods in my third party components. For example, after updating the development target from IOS 8 to IOS 9, Xcode threw into my screen more than 20 warnings about the use of the deprecated UIAlertView class in the XLForm library.

Suddenly, the time I was spending in reviewing all the third party code embedded in my apps to fix deprecation warnings and errors had become really unbearable. And this was time diverted from exploring and learning new things.

Lessons learned

The use of third-party libraries finally has revealed to be a very bad strategic decision for me. It caused three major issues to my projects:

  • Issue #1, unnecessary complexity: adapting my design to libraries that were built to meet other needs was not an easy task and caused my code to be complex and hard to maintain.
  • Issue #2, code lock-in: some of the libraries were abandoned by the original developers, causing my code to be stuck in the past, not taking advantage of new additions or improvements.
  • Issue #3, misled efforts: I spent hours doing the integration and adaptation of third-party libraries instead of learning how to do the same things using the capabilities provided be the core framework.

The cost of developing the same functionality by my own

The question now is how much effort does it take to abandon the use of third-party libraries in an app. The short answer: it depends on how deeply coupled the library is with your code. This is a summary of the time it took me to replace XLForm and DZNSegmentedControl from Next Song Player.

I recoded my settings and filter options views in about 8 hours. It was just a matter of designing the cell prototypes and wiring the things up reusing the existing application logic. The exercise revealed that using XLForm was not needed for my particular purpose, as coding the exact same interface is extremely simple with the Interface Builder.

Settings veiw using dynamic cell prototypes

Removing the DZNSegmentedControl was not that easy, as the code was really a mess. I decided to use an approach based on container views, moving the UI of the segments and the associated presentation logic to a separate UIViewController. It took me about 16 hours. The resulting code is much more simple and clearer. But the big benefit of this refactoring is the fact that I really know how this UI is implemented, so I can evolve it, and keep on adding new features, if needed.

New UI for the playlist segments, custom developed

Final thoughts

My own experience using third party libraries may not apply to your particular situation, or to the problem you are trying to address. Each app development project is different. Before deciding the right path to follow, many variables must be considered, and using third party code is sometimes a good option.

I want also to remark that XLForm and DZNSegmentedControl are very good libraries that serve their specific purpose very well. I want to thank their creators for open-sourcing them, and for taking the effort of giving such a great support to the community of app developers.