In IB one can instantiate controllers, build up references to UI elements, and define action targets. It is also possible to do that programmatically. I wonder what (most) seasoned Cocoa developers prefer?
In many other environments, I would not bother too long with interface builders (lower case), but the Apple tools are clearly a class of their own. Still, do they carry further, or are they beginners’ tools? And why?
I think it is clear that they are the right choice for assembling and laying out the UI. But what about associating the UI elements and controller objects?
Experienced Cocoa developers use Interface Builder extensively. It’s the inexperienced ones who tend to distrust it, because the UI builders for other environments usually suck, so they assume Interface Builder is like that. It’s not. Cocoa and Interface Builder are intimately connected. It’s hard to develop an app without using Interface Builder — to the point where if you look through the Cocoa-Dev mailing list archives, you’ll see a lot of frustrated developers new to Cocoa asking how they can avoid using IB. The answer both from Apple employees and from veteran Cocoa devs is the same: Just use it.
Think I’m full of crap? Open any professionally done Cocoa app. Seriously — any Apple app, any third-party Cocoa app. Now go to the Resources folder. Poke around and you will see nibs everywhere.
As for how much IB is too much — there is a point where connections will be set up by code. In general, hooking up UI elements and controllers is usually done in IB, and even controller-to-controller connections often are as well, though that’s more iffy. It essentially comes down to which is less work to set up and maintain. The big exception to IB’s dominance, ironically, is custom views. When you have a custom view that is only used once, it just isn’t worth the time to create an IBPlugin for it. In that case, usually the controller is hooked up to the view in IB and then the controller hooks up the view to anything else it needs.