Interface builder is great. Storyboards are not.

I really like using Interface Builder. It helps me to reduce a lot of code that otherwise would be in my view layer. But using storyboards brings a lot of problems. Here I will explain why isolated xibs work way better for me than storyboards.

Note: this is my opinion. This works very well for me, but you can have a different opinion in this topic and it’s fine. I’d be glad to read that. Discussing about this in friendly terms is the best way to grow as developers.

What are storyboards actually?

Storyboards can be seen as visual representations of the application flow. That’s really great. If you come to a new project that was developed using storyboards, and the team was organized, then you will have a complete panorama of the whole application flow, and the visual hierarchy of every screen. You will understand the project in a fraction of time.

Although it’s clear that storyboards can bring a lot of advantages, they come at a price: git merge conflicts, mutable variables, coupled view controllers.

Git merge conflicts

Imagine that you are working on the login screen. Another developer from your team is working in a remote place on the register screen. At the end of the day, both of you try to push your code to your remote git repository and BOOM! Everything is broken. Git conflicts everywhere.

Depending on how big is your project and how it’s broken in several storyboards (storyboard references 🎉), you will have more or less git merge conflicts, but surely this will be an issue that will make you have a lot of headaches.

Mutable variables

When using storyboards, you can’t create custom inits, so you have a serious problem when you try to pass data from one screen to another.

Passing data when using storyboards is normally achieved by overriding prepareForSegue in ViewControllerA to set the value of an implicitly unwrapped variable declared in ViewControllerB. The problem with this approach is that nothing stops you to perform the segue without setting that variable.

Not setting the value of an implicitly unwrapped optional variable that was supposed to be set before performing the segue is a very common cause of crashes in applications that use storyboards.

Coupled view controllers

When you use a storyboard, you define segues between the view controllers. If ViewControllerA has a segue to ViewControllerB, they will be coupled together. ViewControllerA knows that ViewControllerB will be displayed after it, and that will be the truth while the segue continues to exist.

View controllers shouldn’t be that coupled. A view controller shouldn’t know about the next view controller in the navigation flow, so it could be replaced at any time. A popular solution to this problem is using navigation coordinators, and delegate the navigation flow execution to a new object that acts as a mediator and performs the required transitions.

Using Xibs

Create a view controller with its own xib is as simple as creating a new class

And then creating a new UIViewController subclass selecting “Also create XIB file”.

The resulting view controller can be implemented with a code like this:

Note that you can create custom initializers so you can’t forget passing data from a view controller to the other.

Modifying AppDelegate

AppDelegate needs to be modified to allow starting the app without using storyboards. A code like this is needed:

First, we instantiate the UIWindow. Then, we instantiate the root view controller using a custom initializer. Finally, that view controller is designed to be the root view controller of the window and the window is made key and visible to start the flow.

How are isolated xibs different

Using isolated xibs (a xib per view controller) is better than storyboards by several reasons:

1. They help to avoid git merge conflicts. You will continue to have merge conflicts if you are working in the same view controller as the other developer, but that is far less common than working in the same storyboard.
2. They allow us to have immutable variables. When you instantiate the view controller, it’s created with all its dependencies set, so you can’t make silly mistakes about passing data.
3. View controllers can be decoupled by using navigation coordinators. View controllers can be isolated from the rest of the application, making them completely replaceable.

When to use storyboards anyway

Xibs and storyboards are just tools, resources that us, as developers can use when it’s convenient. Xibs are not the solution to everything. There are some scenarios where using storyboards may be the best choice. Lets explore some:

1. The app is being developed by a single developer: In this case, merge conflicts aren’t a problem.
2. The app has a very well defined flow where the view controllers are fixed: In this case, a storyboard will show the flow without major problems.
3. Small apps: In small apps, using xibs may be overkill.

Conclusion

Here, I discuss some differences between using xibs and storyboards to build the user interface of an iOS application. In general, I prefer using xibs instead of storyboards. They are much easier to maintain than a storyboard. But there are some scenarios where storyboards are better, specially when the app is small and the developer is the only developer working on the app.