Stop Using Storyboards and Interface Builder

Storyboards. Beginner-friendly, drag-and-drop, and very visual — Great!

For anyone who learned Swift using UIKit, you most certainly have some experience with Storyboards and Interface Builder. It makes sense. You get to design your view before compiling.

Storyboards are a great teaching resource. Although, as you start developing larger applications, you will soon encounter its set of nuisances and limitations.

I used Storyboards in the past. Fortunately, I was able to transition away from them rather early, and I couldn’t be happier.

Despite that, I got hired as an iOS Developer a few months back to work on a large iOS application that had been over 2 years in development, and guess what? To my surprise, they used Storyboards!

I was reminded of everything I did not miss about them, which inspired me to write this article.

Storyboards — Why not?

With some experience with both, Interface Builder and the programmatic approach, I would like to state some points of why I do not use Storyboards and Interface Builder and show you a better alternative for your future projects.

Slow Build Times

Every time you build your application, the compiler needs to link your storyboard files, find the references for its respective ViewController, reference its views through the IBOutlets, and calculate the different screen sizes for its margins, padding, constraints, and spacings.

Build times will get lengthy as they are directly correlated with the storyboard size. As the storyboard grows, the compile time increases.

Slow Development Time

If the build time was not slow enough, prepare to lengthen your project’s development time by the development itself.

There is so much clicking, dragging, and moving around. Every time you add a new view and need to reference it in your ViewController you need to:

1. Open the Storyboard file
2. Create and drag a view into the Storyboard
3. Set the view’s constraints and properties by clicking on the Inspector
4. Split your editor into two, and go through a bunch of clicking to show the ViewController on one editor and the Storyboard on the other.
5. Hold CTRL and drag it into your ViewController to create a new IBOutlet

So many menus, so much dragging, so much clicking. Click, click, click. — Jesus, I would rather be playing Cookie Clicker at this point.

So much moving from file to file. Your hands go from the keyboard to the mouse like 100 times.

Creating reusable components (or subviews) is laborious, or in some cases impossible.

It’s also very strict. Imagine you want constant 6-point padding throughout your application just to realize later that 8-point padding looks better. Good luck refactoring that! You’ll need to set that new value for each view individually.

Complicated

As your application grows, your once nice and tidy Storyboard will become a behemoth; A conglomeration of nodes connecting to other nodes. Views that are halfway understandable visually as they are dynamically filled on run-time. There is no escape.

Projects become large and exhausting to navigate. Every component is connected to a different file.

Trying to find the IBOutlets is a chore. If you are just starting you might mistakenly erase its references and get confused (I certainly did).

Refactoring is a pain. Anything can disconnect your IBOutlets, so anytime you change an outlet name be sure to go back to your Storyboard and update the name referencing it as they are “connected” through literal strings!

Working in a Team is Hell

Prepare for merge conflicts that look like hieroglyphs.

Photo by Jeremy Bezanger on Unsplash

Storyboards are essentially just XML files that are hidden behind the Interface Builder, so you don’t have to deal with the XML code and can focus solely on the nice drag-and-drop workflow.

I find counter-intuitive the fact that Storyboards are targeted towards beginners and efficiency when behind the scenes you have to deal with this monstrous XML file.

Do you want to see what the view looks like for the previous XML code?

I just dragged a UIButton and a UILabel and created a monstrosity of an XML file. Now, imagine working on a big project with complex Storyboard layouts and other developers.

Merge conflicts will occur and they will be a pain to fix.

The Programmatic Approach

Now, it would be inconsiderate to have rambled about Storyboards and IB without showing you a better alternative. I present to you, the programmatic approach to creating views!

The Programmatic Approach

I couldn’t come up with a better example to demonstrate the programmatic approach, so I decided to just make a CookieClicker app.

Just click (or touch) the cookie to make the counter go up.

Our objective is to completely get rid of Storyboards and learn how to build the view using only Swift code.

Let’s get to it.

Create a new iOS Application named CookieClicker, for the Interface choose Storyboard (we are not going to use them, but is the only way to create an application that is based on the UIKit framework)

Now that we have our project, get rid of that Storyboard

We’ve deleted the file, but our project will still try to access the Storyboard when building the application. We just need to delete its last reference remains located in the Project Info.

Go over to the Project Info and delete the Main storyboard file base name and Storyboard Name keys.

Finally, we need to inform the SceneDelegate to use our ViewController class as our main window when starting the application.

Go over to SceneDelegate.swift and replace the scene method with this code.

You can now run the app and be greeted with a beautiful black screen; this is our ViewController working by itself.

Creating the View

I’m not trying to make a CookieClicker tutorial, so I’ll just summarize the structure of the ViewController.swift

We no longer have Storyboards so we need to create the view ourselves.

I found the best and most organized way to approach this is by structuring the ViewController.swift file this way. Here are the marked divisions.

• PROPERTIES: all the properties you might need for that particular ViewController
• SUBVIEWS: declaration of all the subviews that we are going to use in our view as computed properties. Inside we set all the properties (font size, color, text, etc.).
• LIFECYCLE: the lifecycle methods such as viewDidLoad, viewDidAppear, viewWillDisappear, etc.
• SETUP: all the necessary setup for the view to be ready for use. We add the subviews (declared on top), set up the constraints, assign delegates, customize the navigation bar, etc.
• ACTIONS: all the actions that can be performed in the view such as button presses, swipe gestures, etc.

Here’s the finished code:

You can find the repo here.

Those are the building blocks of creating views programmatically. As you build from this foundation, you’ll soon find the numerous benefits this approach has over using Storyboards.

Cleaner projects, easy encapsulation of subviews, simple dynamic views, effortless merges, straightforward code, fast build times, reusable view code; the list goes on.

Wrap up

This was my opinion based on my experience developing with both workflows. Feel free to comment your thoughts! Maybe I’m missing something on Interface Builder I’ve overseen. Thanks for reading and hope you the best in whichever decision you make for your future projects!

If you enjoyed this article make sure to follow me so I can keep creating more content like this. :)

Sign up for our Free Weekly Newsletter. Fresh content from developers all over the world, fresh and direct from the field! Don’t forget to follow our publication The Dev Project.