Avoiding Third-Party UI Libraries

There’s been some discussion recently in the iOS community about pros and cons (OK, mostly cons) of using third-party dependencies. Many arguments I saw were rather generic — grouping all third-party libraries into one basket. As with most things, though, it’s not that simple. So, let’s try to focus on a single case today: should we avoid using third-party UI libraries?

Reasons to consider third-party libraries

There seem to be two main reasons developers consider using a third party library:

Lack of skill or knowledge. Let’s say, you’re working on a photo sharing app. You don’t start by rolling your own crypto. Lack of time or interest to build something. Unless you have an unlimited amount of time (which no human has yet) you have to prioritize.

Most UI libraries (not all!) tend to fall into the second category. This stuff is no rocket science, but it takes time to build it right.

What to “outsource”

So, how do we actually decide what code to write ourselves and what to delegate to a third-party component? The famous Joel’s advice applies really well here:

If it’s a core business function — do it yourself, no matter what.

A (possibly hard) truth is that most iOS apps are skewed towards being frontend- rather than backend-heavy. The look matters. It follows that we should consider doing as much UI development as possible in-house. One could argue that it’s just one person’s opinion, so let’s go through specific reasons you should rethink your usage of third-party UI libraries.

Problems with UI libraries

Generic vs. specific

There are pretty much two types of controls/views:

Generic, allowing you to use them in many different contexts not even thought of by their creators, e.g. UICollectionView from UIKit. Specific, designed for a single use-case, e.g. UIPickerView .

Most third-party libraries tend to fall into the second category. What’s more, they’re often extracted from an existing codebase for which they were optimized.

As an example, that cool-looking pull to refresh control you saw last month? Yeah, it probably won’t fit your app’s design or use cases, like view controller containment or contentInset value being modified.

Inheritance as a way to personalize

As far as OOP goes, there’s an industry-wide move from subclassing to composition. Make sure you’re not going against the flow when choosing a library. In most cases you let someone else do the composition for you, leaving you with only subclassing or direct code modification at your disposal.

(Delegate pattern is one of the approaches to composition.)

Too customized look

This may seem counterintuitive but the less visible UI there is in a library, the better. The problem with highly customized controls/views is that it’s not possible to specify their requirements in a way that will fit all use cases.

If there’s a lot of custom UI, you may not be able to contribute back to the upstream, because your ideas about the look or feel may be different than those of the maintainer. You’ll have to either maintain a fork or use some ugly hacks on the app’s side just to remove that one shadow.

On the other end of the spectrum are libraries that operate on the UI level but don’t provide any or almost any look by themselves, think SDWebImage or my SloppySwiper. These have a higher chance of not needing to be modified just to fit into your project.

Unknown early assumptions

Many teams do code reviews of their internal code but may be taking third-party source code’s quality for granted. It’s worth spending a bit of time just browsing a library’s code. You may end up being surprised to see some red flags, e.g. swizzling used where it’s not needed.

Try to get a glimpse of the architecture. Will you be able to adjust the library to your future needs or will you have to rewrite it after your MVP ships?

You should assess the general health of the project too. How many commits, pull requests and issues have there been lately? Are there any unit or UI tests? Ignore the GitHub stars, though – they’re mostly meaningless.

Idea > code?

I like open-source because it allows me to see how other people think and design their solutions. Often learning the idea is more beneficial than obtaining the resulting code itself. If a library touches UI and is small, it’s often better to get inspired by its code and develop a component yourself to suit your needs perfectly.

Can’t hide it

Because of the way UIKit is designed you most probably won’t be able to hide the third-party UI library, e.g. behind an adapter. A library will intertwine with your UI code becoming a de-facto first-class citizen of your project.

Future time cost

UIKit changes with each iOS release. Things will break. Your third-party dependency won’t be as maintenance-free as you may expect.

Conclusion

As it’s often the case in programming, it’s hard to provide general rules. We have to consider every chunk of code we add to our codebase on a piece-by-piece basis. From my personal experience, most uses of third-party UI code boil down to exchanging smaller flexibility for some time gain.

We leverage ready-made code to ship our current release faster. Sooner or later, though, we hit the limits of the library and stand before a hard decision: what to do next?