I’ll answer a question about the future of Storyboards by going through a personal experience of my last 4 years in iOS development.

Even before the introduction of SwiftUI, there was a question that every iOS developer would ask himself at some point in life — Storyboards or No Storyboards? The real question was WHEN? It actually depends on what kind of project the developer is working on — short term app or long term product.

In this article, I am going to take you through my journey in iOS development to the point where I asked myself… Storyboards or No Storyboards?

Prior to developing iOS apps, I was an Android developer (I still am 😄). Shifting to iOS, Storyboards were the first thing that grabbed my interest. In Android, I hardly ever used the drag and drop tool to design UI. It was always me and the XML playing together. So looking at storyboard and seeing all those options at once was a bit overwhelming, but once I got a hang of it, there was no looking back. I started developing UIs faster than I ever developed in Android. Everything was so cool. I quickly started designing UIs, creating prototypes and developing apps.

At this point, I was the sole iOS developer and these were small to medium sized apps.

First Taste…

With time the app size started to increase, new features started to pour in and the number of view controllers eventually increased.

My Storyboard grew in size and this had a direct effect on the performance of loading Storyboards. Which was obvious since the storyboard is nothing but xml code behind the scene. The more lines of code, the more time it’ll take to load. Also, to scroll through such a huge storyboard to find and fix a small thing had become a headache now. The thing which I liked was now the pain point. At this point, I started designing view cells and other views in separate nib files. This took off some load from storyboards and kept its size in check. Still, this wasn’t a good solution.

The Saviour.

I came across an article — “Clean Code for Multiple Storyboards”.

Our apps usually have different modules or different user flows. We can group these view controllers either as per ‘User Flows’ or ‘Modules’ and create separate storyboards for each user flow / module. It was now much easier to navigate through the Storyboards. Also, it kept the sizes of Storyboard files in check thus reducing its load time.

Saviour? Not for long.

Soon, multiple developers joined me on the app and whoever has worked on GIT with storyboards would know this… It Just Doesn’t work! The Merge conflicts here just cannot be resolved. The way Xcode displays the merge conflicts for Storyboards is another story in itself. After going through a lot of merge conflicts, my fellow colleagues were now scared hearing the word ‘Merge’.

Plan your development

Thankfully I was able to resolve this by planing the development in such a way that each developer had his own module to work on. Hence Say Developer-1 was working on Module-1 which had its own Storyboard-1. I was working on another module which had its own storyboard. This reduced merge conflicts in storyboards to a great extent since no two developers were working on the same storyboard at the same time.

Phew, life was sorted over here.

Unless…

iOS had different plans for me. Now came the point wherein we were tasked to develop features which would be available in some releases while absent in others. Obviously, we could not keep on copy-pasting these features whenever required and remove whenever not required. To solve this problem, Feature branches came to the rescue. We started to develop these additional features or change requests in their own branches. Now theoretically everything was fine until… we had to merge our feature branches into our development branch. Merge Conflicts came back saying “Missed me?”

Finally, the time arrived…

Now this was the time when I had to ask myself…. Storyboards or No Storyboards? With all due respect to the benefits that storyboard gives, It just fails to go hand in hand with Git. This was the biggest drawback for our team which was currently working on a large product with tons of features and multiple developers. So we started to develop new UIs, especially in feature branches programmatically without using Storyboards.

Trust me it will be difficult at the start, especially if you had never designed UIs programatically, but it becomes a lot easier. And with the long term benefits that it gives, its definitely a better option. To summarise, here are Pros and Cons of using Storyboards: