Interface Builder: Pros, Cons and Our Thoughts

Xcode’s Interface Builder got some fine tuning at the last WWDC event. “Who cares?”, some might say. Well, Ben Sandofsky has reasons to believe that now is the time for using IB. Our co-workers discussed about it and we decided to put all that into a nice blogpost, to explain a little why Interface Builder can be good (or not).

It’s important to understand the debate: what’s all about the fuss on IB? Well, the Interface Builder is a part of the Xcode developing tool and since its implementation, it has picked up some fans and haters along the way. There’s a lot of good reasons for both, so let’s break it down into some sections, shall we?

Performance during Development

The visual contents of Interface Builder can hinder development if they’re not well-planned since the beginning. Even in fairly new computers, they might run a little choppy, like Dominik Hauser’s MacBook Air, bought in early 2015 – here he’s changing from the code editor to the Interface Builder and it took this long:

 

 

Another slowdown happens when he selects a view with many constraints:

 

 

It takes about 2 seconds to show every constraint in this view. It may looks bearable at first, but in the end of the day, you’ll certainly want to throw your computer out of your window. Speaking of windows, there’s also some problems with the monitor size when using IB: with a big storyboard, it’s nearly impossible to visualize all views at the same time, especially with a small screen.

Runtime Performance (in the actual device)

If it’s slow for editing, obviously it’s slow in the actual performance too…right?

Well, not really. It is pratically the same speed. Matt Gallagher benchmarked this comparison, with a gain of 10-15% of speed on cells made in code compared with ones made in IB. It’s worthy of note that this test was made 5 years ago in an iPhone 3G. Today, the difference is even more negligible between both approaches.

 

Versioning

Incrementing your project via Interface Builder is still risky, even with the tweaks that Apple made. Sharing your project with others (at GitHub or even in-house) increases greatly the odds of merge conflicting, because of their XML complex structure. That doesn’t happen in code, as it’s easier to control it. Besides, asking for help for posting your code is far more simple than with a screenshot of your storyboard.

A good future upgrade would be the possibility of editing the XML as Android enables it. The developer would brush up the unnecessary parts, previewing its work instead of building the app in the simulator again and again.

 

Integration with Designers

The developer is good at coding, not at designing interfaces. Changing contexts all day long is tiresome and, even if you get used to, the desired look can take as long as if you did it on the code editor. From the designer’s point of view, the IB isn’t a friendly tool like Photoshop or other visual editors but it’s still better than writing code. It gives the designer autonomy to make changes without the need of a developer.

Refactoring

 

Usually, when things go wrong at IB, the entire project was crammed in the main.Storyboard. While a good practice in IB is about creating modules – small .xib files with specific functions – since the beginning of the work, refactoring things later can be really time-consuming. In code, this is simpler, even with poor syntax or other technical mishaps. But, in the last WWDC, Apple presented the new iOS 9, which brought a great addition for IB: you’re now able to reference multiple storyboards. This is bound to bring lots of coders, at least, to make a retry in the tool.

What Our Guys Said

@Bruno Guerios – “Many senior developers are defending Interface Builder. I’ve gotten used to code, but there’s so many people saying good things about it, maybe I’ll spend some time to lose that bad feeling.”

@Felipe Docil – “There were many good updates on IB at the WWDC, but I don’t know, I have more control when I’m coding… The greatest disavantage on IB is having to monitor changes in code too, in classes, constraints or other properties. We should keep an eye on the IB, as Apple Watch uses only this for interface.”

@Lucas Oceano – “I’m with Felipe, I believe IB is good for more specific situations, in simpler, less complex apps. But let’s be aware of the news about it, to decide if using IB is better (or not) for the project you’re working on.”

Conclusion

The Interface Builder is great for watching some concepts faster than in code, such as colors, layout restraints and custom fonts. With the IB, it’s better to understand the layout and see what you’re doing, but coders don’t want to design that way, as their context isn’t visual. Being a designer who also code – or vice-versa – is a plus for using both tools with ease, even though the preset boundaries for each professional are enough for shipping nice apps. And like Felipe said, you can’t code your way into a Apple Watch app’s interface. You’re forced to use the Interface Builder. So, maybe you won’t have a choice, sooner than you think.