Johan Sørensen

Nibs vs. code, a journeyman's perspective (or lack thereof)

Saturday August 06, 2011

Like all languages and frameworks, Cocoa has some topics that will polarize its programmers. This one isn’t about dot-notation, for once, but laying out user interface in nibs/xibs (interface builder files) versus building it in plain old Objective-C code. With nibs (even though their modern extension is .xib) you layout the user interface ín a graphical UI and connect it with your code. With code you allocate, initialize and place the UI element(s) entirely in code, most likely within your controller.

First things first, at its core programming is a discipline of balance. Balance with performance and implementation time. Balance between readability and understandability. Balance between implementation time and understanding it in one, two, twelve months from now ad infinium.
Some times it’s faster to add some UI elements in code, sometimes it’s faster with nibs. That’s the diplomatic aspect, let’s try and look at in what situations you might prefer one over the other, enumerated as a list since my editor let it slip through;

• I like nibs when I have to layout UI elements from a mockup or “final” design.
• I like nibs when I got the feeling my designer will change his mind and he can edit the nibs himself, or sit next to me dictating where the elements should be.
• I like nibs when there’s lots of graphical elements to layout; writing code, compiling, running, editing, recompiling running is slower than seeing it WYSIWYG-ish in interface builder.
• I like code when there’s dynamic “things” involved, except when it’s combined with one of the above, then it’s faster to just hook it up with an outlet.
• I like code when I have to place elements relative to other elements (and I can’t use auto layout), as long as I cannot make it work with autoresizingMask’s in the nib.
• I like nibs when it means there’s less -layoutSubviews or -initWithFrame: boilerplate code to scroll past.

The last one is probably the most important to me. A lot of programmers seem to take a Conan the Barbarian approach to code; “if you do not like code, then TO HELL WITH YOU” and forgetting that when they look at the code in six months from now they’ll wasting time scrolling past code that may be important layout logic or just simple layout logic or worst of all, they’ll waste lots of time compile-run cycles trying to get their CGRect’s to align properly.

Code is craft, crafting is balance between getting your message across and getting your message out there. And sometimes there’s not a single right answer. That’s what makes this profession a craft, the hard part is often crafting it together in a team.