NIB Files and Storyboards vs. Pure Code: What it means for iOS 8

The debate between using NIB Files vs laying out screens in pure code has been raging on since the birth of Apple’s Interface Builder. In one camp are the visual developers that love being able to see their screen in Interface Builder and laying all views out visually. In the other camp are code purist developers that worship code and detest any tools that do “magic and wonders” behind the scenes but with little to no understanding of the magic. The battle is symbolic of the ongoing rivalry between the two biggest mobile companies in Silicon Valley: Google and Apple. Google has banned the use of NIB/XIB files several years ago in their iOS projects – while Apple has made it clear that NIB’s are the preferred way to go.

I am NOT here to fight for either camp. I will only say that developers should be able to work in whichever way they prefer – what is good for me may NOT be the best for another developer. So long as everyone is happy – I don’t care what is your sexual orientation, ethnicity, nationality, religion … or your coding habits (that is so long as you deliver quality work).

That being said, with the release of iOS 8 and the larger screen sizes introduced with the iPhone 6 and iPhone 6 Plus, developers in the pure code camp may be in for some trouble! Several years ago Apple has introduced a new technology and screen layout methodology known as Autolayout. What exactly is Autolayout? From Apple: “Auto Layout is a system that lets you lay out your app’s user interface by creating a mathematical description of the relationships between the elements. You define these relationships in terms of constraints either on individual elements, or between sets of elements. Using Auto Layout, you can create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization.”

For anyone that has tried massing around with Autolayout using Interface Builder – you’ll soon realize that it doesn’t take long to learn the ropes and get moving quickly with it. For anyone that has tried getting Autolayout to work in code – good luck! It’s a real pain in the butt. A single view rendered in code using Autolayout requires some 20 lines of code – and NOT only in Objective-c – but in a whole new language called Visual Format Language (VFL). As if learning Objective-c wasn’t hard enough to learn …

The alternative to Autolayout (and its predecessor) is simply setting the frame of the view in code using an old and favorite function known as CGRectMake. If the view has to be dynamically resized for any reason – no problem! All one has to do is set the automask property of its subviews to resize along with their superview.

The issue with this old and trusted approach is that the new phones released last month have a larger point resolution than the 320 point width of the older iPhone 3/4/5. You may ask yourself, why didn’t Apple simply make the iPhone 6 and iPhone 6+ have a 320 point width so that existing apps wouldn’t have to be re-written? There are many answers to this – but my guess is that Apple expects everyone to migrate to Autolayout along with Interface Builder – and if you don’t … well, you’re on your own.

Initially, I decided to throw in the towel and become another lamb in the Apple clan – but then I remembered why I became an iOS freelance app developer in the first place – I have a brain and I like to use it for myself! I stared thinking about how I can continue to set view frames in code without reverting to Interface Builder or spending 100’s of hours writing Autolayout in code. I soon came up with two solutions to this problem – and both are working like charms for me. If anyone is interested to learn more – simply contact me and I’ll share the two solutions (it’s simpler than you may think).

Leave a Reply