Why does it feel like Interface Builder just gets in my way?

Question

I'm very new to Cocoa for MacOSX, but I can't help but feel like I'm constantly fighting Interface Builder.

My current situation is that I'm building an app that will have several custom controls and views. I started building the app in Interface Builder because it was initially very easy to drag things around and get them into the correct spots with the proper colors and the correct autosizing rules. However the time has come to start building my custom controls and views - which I can't nicely represent in Interface Builder without going through the work of building an IBPlugin! The only other option I know of it is to have an Interface Builder document that includes a bunch of "Custom Views" all over the place with only their class changed. It suddenly seems pointless to even bother with IB - especially in light of that fact that these controls and views will have properties such as color that need to be set - just like the other views and controls already in the IB document. So now I've got visualization properties being set in two disconnected places and seems to counter one of the potential advantages of IB which is making it relatively easy to tweak the UI of the app without digging into code.

I'm also faced with a situation where a few controls change properties (such as colors) based on data or current selections. So now I have initial default colors of the control specified in Interface Builder, but I have to specify the data-driven colors in code? Once again Interface Builder seems to cause me to have to split some presentation settings between it's world and the code. I suppose it's possible to solve this somewhat with a complex plugin that knows about my data or states or whatever, but it seems like I'd end up maintaing a ton of support code that exists just so the Interface Builder experience remains "right."

Something else that I often see mentioned is how easily IB allows you to define bindings between components. "You can do it without writing any code!" Again, I may be missing something, but binding one property to another is a single line of code as far as I can tell. Is setting a couple properties in a box in IB really better than writing that one single line of code? And why is it better to put what amounts to application logic in the presentation layer's specification?

Like I said at the open, I'm pretty new to this Cocoa stuff, but I feel like either I'm missing something very important about how to use Interface Builder, or it's designed primarily for trivial demo applications with a high "wow" factor.

Answer 1

My first iPhone program, available for sale, as well as my second one under development do not use Interface Builder. I like having it all in the code so I can understand what is happening and so that I can use version tracking to track all changes.

So far as I know it comes down to a matter of preference. There are Cocoa books out there which use both styles (IB and no IB).

Answer 2

I find that Interface Builder is excellent for getting the generic layout of an app. It's also wonderful for things like bindings (on the Mac). However, there's no way you're going to create Delicious Library using Interface Builder. The more complex your interface, the more code you'll have to write.

Answer 3

Jeff LaMarche (of iPhone development fame) wrote an excellent article about why IB is a good choice to use, even if it doesn't 'seem' the right route once you get past basic tutorials. I had given up on IB for similar reasons to you, but the article inspired me to keep working with it, and it really does end up being the right solution, even though it goes against the geek tendency to not allow too leaky abstractions.

Answer 4

Interface Builder can take a little getting used to. But, as has been previously stated, the more you use it, the better it is. Sure, custom views can be done in code, but IB is a standard for a reason. Mac apps are held to certain standards of UI quality by the community, which are much higher than the UI standards for other platforms. IB makes it much easier to conform to those standards than doing everything in code, with no visual reference.

And you don't have to do everything in code to have your UI in version control. All of my Cocoa projects live in their own git repository with includes nib/xib files.

So give IB a chance. It only gets easier the more you use it.