How much do experienced Cocoa programmers rely on Interface Builder for wiring up their apps?

Question

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?

Answer 1

Like apple's documentation says, the less code you write the less you have to maintain, and I think that it is a very good point.

You associate controllers with UI elements at all times, this is what is called the MVC schema.

Answer 2

It mostly depends on their background as a developer and what you could consider "experienced".

I've seen people refuse to even open IB.

My opinion is that to make an app that doesn't look like every tutorial app from the iPhone 3G era, you have to use IB, and to eschew it and try to build a good looking sophisticated app completely in code is a waste of time and can make your code hard to read unless its done perfectly.

Answer 3

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.

Answer 4

Any experienced Mac or iPhone developer will use IB for almost all of their interface wiring, and as an "inversion of control" object creation manager. By putting your wiring in NIB instead of code, it's not loaded until requested, and is easier to manage.