Johan Sørensen

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

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;

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.