One of my favorite talks at @tryswiftconf (ok, every talk was my favorite!) was when @helenvholmes talked about how to get designers into code. One of the big things to do is very obvious – use Storyboards! Immediately, this comment was a bit controversial among developers.
Honestly, I don’t see the whole controversy. Does Interface Builder have a few issues? Sure! But in my experience, the benefits far outweigh the issues. And it’s not just about getting designers into the codebase. It’s about getting anyone into the codebase. It’s about making your big code base readable!
As a developer first introduced into another codebase, it’s so nice to go to the Storyboard, identify the View Controller I’m seeing on screen, and start working from there.
That said, Storyboards are a tool. And just like any tool, when used in the wrong way, it becomes useless and even worse, harmful. So I wanted to list a few tips on how to use Interface Builder effectively:
The biggest issue with Storyboards that I’ve seen is that developers start their project in Main.storyboard and start adding EVERYTHING in there! Soon, the storyboard becomes huge, a spiderweb that touches everything in the project. And as more developers are added to the project, no changes can be made because everything will conflict in a merge.
I think of Storyboards as pieces of code. Keep them small and isolated! I like to have a Storyboard for every part of my app that has it’s own single user-flow. For example, the sign-in / sign-up user flow can be completely isolated from the rest of the app. Or the Settings screen with all the settings options / flows. If my app has tabs at the bottom, each Tab would be it’s own Storyboard.
Sometimes I have Storyboards with only a two-screen isolated flow. But I’m ok with that. I know that in the future, it’ll be easy to add to it as the project grows.
Using this system, I haven’t had that many issues with merge conflicts. I can work on the Settings feature for example, while another developer works on fixing the Sign Up. Our stories are isolated and do not conflict. If we are working on the same user-flow within the same isolated Storyboard, we most likely need to collaborate anyway to make sure we’re not working on conflicting things.
Now with Storyboard References, it’s even easier to maintain multiple Storyboards.
I especially love Storyboards for laying out the flow of the application. It’s an easy way to see how each screen relates to each other, and what the options are for each screen. Again, this is a level of readability that is hard to replicate with one glance in code. That is the most powerful part of Storyboards. Putting every single view / design is not what Storyboards should be primarily used for.
Most of our apps have re-usable views and Table View Cells. If you add the same view in the same or different Storyboards, isolate that view into a Nib! Again, your Storyboard / Nib “code” should be re-usable and isolated if possible.
Since I like to re-use views as much as possible, sometimes my Storyboards look like this:
I’m completely ok with keeping most of my views in Nibs (or code if it makes sense!). To me, an empty-looking storyboard like this is still useful for glancing and seeing the flow of the user story. I can easily click into each View Controller to find out more.
IBInspectable / IBDesignable
Another big issue I’ve had with Storyboards / Nibs is that I might need to make a small design tweak to my view that’s not possible to do in the Storyboard, so the the view in the Storyboard looks different than it does when I run the app.
Well, now with IBInspectables / IBDesignables, we can add those extra design fields to the storyboard. Oh, and we can see how that changes the look of the screen right there in the Storyboard / Nib!
Autolayout / Stack Views
Doing Autolayout is hard enough without having to try to do in code with no visuals. I love that Storyboards / Nibs tell me right away when I’m missing a constraint and I can fix it until there are no warning signs. Same goes for Stack Views – it’s nice to see the views click in place and adjust from there!
As an iOS developer, I really enjoy using Interface Builder and really don’t see why some developers are so against them. Of course if you use these tools in the wrong way, they will have consequences. But as long as you keep your IB files modular and isolated, just like any good piece of code, there are a lot of benefits to readability for everyone involved in the project.