It seems like every day I have a new problem with Apple. I’m not going to touch on their corporate evil (which has, in no uncertain terms, surpassed every other operating system developer) or their gross hubris (if you want to talk about Jobs’s “Thoughts on Flash” with me, make sure it’s not among polite society). I’m fighting my battles where I can fight most effectively - in the tech field.

Interface Builder is broken. It’s not broken in a small, subtle way that you might miss. It’s broken in a rather large, ugly way.

It has no concept of Build Targets.

For those uninitiated, most IDEs - including XCode - have a notion of a Build Target, where each target specifies what is going to be built and how. The part you really want to focus on is “what is going to be built.”

I’ll take a common example: iPhone versus iPad. Assuming you have 2 different SKUs here and aren’t using a Universal app (that idea still makes me a little nauseous), you have a different set of assets per target. To ease coding and interface setup, it’s a perfectly natural thing to name those assets the same and rely on build targets to sort out which asset to use.

Except, as I just stated three paragraphs ago, Interface Builder doesn’t have the build target metaphor. So what does it do? It just picks one of the assets to show during interface setup. Which asset it shows is rather arbitrary; usually it’ll show the iPhone assets while setting up the iPad interface. Which makes it pretty much useless for actually setting up the iPad interface.

You can get around this, of course, by either (a) naming your iPad assets differently and hooking up your entire interface again, or (b) temporarily deleting your iPhone assets from the project and restoring them after the iPad interface is finalized. Both of these solutions aren’t solutions so much as they are dirty, error-prone hacks.

Let’s take it a step further though - the problem also exists with localization. You have a bunch of assets, and those assets are localized among a bunch of different languages. When you’re in Interface Builder editing a certain language’s interface, it’s natural to believe that IB would be showing you the appropriately localized images.

That belief is rational and wrong. What image will be shown to you? I don’t know, but you can rest assured there’s a good chance it will be wrong. Sometimes you’ll get a mix of the correct images and incorrect images. In short, you’re never really sure what your interface is going to look like until you run the application, and if that’s the case you’ve lost any benefit of having a visual editor.

These are not minor problems. They are real workflow-shattering problems. They are problems that make developing large systems unreasonably difficult, and “developing large systems” is precisely where you want as many things as possible to be not difficult.

With all this said, I’ll admit I don’t know how other tools do it. I’ve never had to setup a multiplatform localized interface in WPF. I know how Interface Builder does it, though, and I know Interface Builder does it poorly.


Ice Cream Social = Success+!