I 🌀 Storyboards & Nibs

Yesterday, NatashaTheRobot published a super insightful post about her love of storyboards, listing a multitude of reasons why storyboards and nibs are great.

I agree with most of the arguments — storyboard references make life easier, keeping things small and modular helps avoid many of the downfalls and IBDesignable/IBInspectable is seriously cool.

However, it’s still hard for me to 💖 storyboards & nibs, my feelings are a lot more 🌀 (i.e. mixed). Here’s why:

Can’t handle our scale

Earlier this month, I attended mobile@scale at Facebook’s HQ in London. It was a fascinating day of presentations from Facebook, Google, Twitter, Spotify and Soundcloud. They shared many of their experiences and best practices when working on apps at scale. Here’s a note I made:

The main reason was build times and merge conflicts.

Facebook and Google might be special cases, with thousands of classes and hundreds of engineers sharing the same codebase and yes, by keeping your storyboards small and modular, merge conflicts are a lot less likely in a small team.

However, if you are working for a start-up with significant scaling ambitions, relying heavily on storyboards is the same as placing a major technical debt on the company and forcing a significant future rewrite when the team grows.

Application flow

Storyboards are great for laying out the flow of the application but they force a very linear idea of what that flow is. Implementing more modern navigation concepts and deep linking is significantly harder with storyboards and can easily result in the much feared “storyboard spiderweb”.

Also, it severely restricts your ability to build non-generic gesture-driven user interfaces — think Snapchat or Facebook’s Paper.

Data Flow

You may lay out the flow of your application in the storyboard but what about the data flow?

Apple’s solution for this, a big if statement inside prepareForSegue:sender, is very error prone and restrictive. Custom initialisers simply don’t work with storyboard segues.

One of the Twitter replies to Natasha’s post suggested using dependency injection as an alternative, which seems like a novel approach and something worth looking into.

Chchchchanges

Storyboards are not built for resuability and Natasha recommended using nibs for reusable views. Still though, designing views in nibs makes app-wide changes much harder.

Let’s take fonts and colours for example. In my current codebase, I have categories on UIColor and UIFont that reflect the current colour and typeface schemes for the app. For labels and views created in code, any change the designer makes can be applied by changing a few lines in the categories. For labels and views designed entirely in interface builder, these changes can be a huge pain to apply.

Conclusion

Storyboards are way way better than they used to be. They are fantastic tools for simpler apps or quick prototypes and they also make life a lot easier for anyone beginning iOS development.

However, the question of when to use them is still not an easy one to answer. It honestly depends on the needs and ambitions of the app you are creating and should be decided on a case-by-case basis. For now, I remain 🌀.