If you are an iOS developer, you for sure should know that there are many ways of setting up the layout of UI in applications. While every approach has both upsides and downsides, and I assume that there is no “best way” of doing it since your choice would depend on the situation or project you are involved in. Since the advent of the Interface Builder or Storyboards in iOS 5, there has been a heated debate in the Swift community regarding it. In this article, I want to discuss the different approaches, and which I prefer.
There currently exist 2 main ways of creating iOS screens:
2.Using Interface Builder (Storyboards)
“A storyboard is a visual representation of the user interface of an iOS application, showing screens of content and the connections between those screens. A storyboard is composed of a sequence of scenes, each of which represents a view controller and its views; scenes are connected by segue objects, which represent a transition between two view controllers.” — Apple documentation
Storyboards are a visual tool for laying out multiple views and transitions between them. Every newly created project has by default one Storyboard file called Main. Storyboard, which is a blank view.
Suppose you want to add a button to your ViewController. Storyboards made the process as easy as it can be. You simply find the UI component you need, then drag and drop it to your view. That’s it!
Furthermore, you can add extra parameters you want your view to have, such as the background color, text on it, and so on. The cool thing about it is that you can see everything in front of you. You do not have to compile and run the project every time to see if the width of your image is wide enough or not.
Besides that, the name of the storyboard tells itself that it is supposed to tell the “story”, where comes the second benefit of storyboards is that you can see the whole flow of your application in one file.
However, as soon as projects get bigger and more complicated, the storyboard can become a huge pain for the team. Since Storyboard is a complicated human nonreadable XML file, it would be hard to collaboration between 2 or more developers working on the same project
Besides the collaboration issues, Storyboard’s load time depends directly on the number of Storyboards in a project.
So far cons and pros of the storyboard:
In the programmatic approach, you create all UI elements and their constraints by coding them. If in Storyboards you could just select the button and drag it to the position you wanted it to be, in the programmatic approach you need to create the button, add the parameters to it, such as the color, target, then add it to the view, and constraint the layout of it all using code.
It may sound a little complicated, but this is the best approach for the environments that have many developers working on the same project at one time. So, if you are planning to work in a big tech company, most likely you will face a programmatic approach in setting the UI layout.
Personally, programmatic approach, even if it looks boring and complicated to understand, gives the developer freedom and full responsibility on creating the UIViews as the developer wants, and refactor them in a future way faster. For instance, if some other developer needs to move the button, changing 1–4 lines of code is required only!
Besides the collaboration, I assume that the coding approach gives you an idea of how the UI works under the hood. You start to understand the deeper differences between the components, and how they should work.
So far the cons and pros of the code approach:
As I mentioned before, the heated discussion between IOS developers still takes its place, and I believe there is no “best way” of building the UI. Sometimes it is more efficient and easier to do the drag and drop approach, sometimes it is recommended to do it programmatically. It all depends on what your project is.
However, it wouldn’t be unnecessary to know both of them. Each company has its own rules.
Engineering leaders around the world are constantly looking for ways to bridge the talent gap and scale up their engineering team. At Decagon we are solving this problem by recruiting the top 0.5% of engineering talent and transforming them into exceptional software engineers equipped with world class technical and soft skills that fits perfectly into your engineering needs. Click here to get started