How Much, or How Little, I Use Interface Builder These Days

I used to like IB, but moving all dev tools into Xcode 4 basically killed my desire to do Cocoa programming as a hobby after 10 years of it. In what world did it make sense to take a complicated program (IB) and wedge it into another complicated program (Xcode)? Intermingling the two interfaces has made the process of switching from codenib tedious at best, and confusing at worst due to all the unrelated UI around it. Now IB and Xcode have to proceed at the same development pace, as changes in one will affect the other.

The bugs in xib generation are inexcusable. Sadly, even things like swapping views out of a window is better done in code, regardless of any claims about tabless tab views. Dealing with nested splitviews or any moderately complex view hierarchy in IB just doesn't work.

I still use IB a lot. I agree localization is a pain; localizing nibs/xibs is the wrong approach. I have some code that given a couple IB root objects will visit everything in the hierarchy and localize objects using regular .strings files, plus some code to adjust the layout when text takes more space (with some limitations). Works great really. Apple seems to be moving in the same direction with auto-layout and .strings-based localization.

. When you write "I hope to phase out IB as I transition to using auto layout.", do you mean creating all the UI in code (including outlet, action, delegate connections)?

. In his post, Brent wrote: "Navigating back and forth between code and a xib file is a pain, even on my big screen."

Well, that's one the stupid consequences of the stupid idea to merge Xcode and IB.

. I've always been surprised to read that people would rather localized through code and .strings instead of localizing the xib/nibs. I think Delicious Library was one of the first well known applications to do that. Side effect, there are way too many duplicated strings in the .strings file of Delicious Library. Other side effect: if you give a set of .strings files to localize, either you have to provide screenshots to give the context where these strings will appear or you have to add the boring comments when calling NSLocalizedStringXXX or write them directly in the .strings files.

. Now, at the same time, Apple is doing its best to ruin the life of the guys localizing applications. From the non editable nib files to the .strings files saved in binary plist format, someone in Cupertino is targeting obscurity as a new standard.

@stephane I’m going to give it a try creating as much as possible in code. I already do much of the wiring that way, since it was easier and less fragile.

I didn’t go the Delicious Library route because I saw that it had lots of truncation bugs and extra padding. However, in theory auto-layout would solve those problems.

Rather than use the “comments” approach with NSLocalizedString, I give each string a “symbolic” name and only put the localized string in the English .strings file. This makes it easier to sort and organize the strings, etc.

Apple killed part of the utility of IB when they dropped the ability to create IB palettes with fully-functional custom widgets. Granted, creating them was kind of a pain, and it was a hassle when you tried to open a nib that used a palette that IB couldn't find. Still, it was useful to be able to create or buy custom widgets that were just as functional as the standard widgets, including during 'test run mode'.

Come to think of it, does the current IB even have 'run mode'? (Checks...) Not for iOS apps, only for Mac apps, it seems.

Back in the NeXT days, there was a 3rd party 3270 emulator palette. Just in case you needed to drop an IBM terminal emulator into your app in IB. (Always struck me as an odd thing to need in a palette, but whatever.)

I think IB was probably a bigger win back when computers were slower and had less RAM, where you could build, tweak, and test large portions of a UI, using 'live' standard and custom widgets, without going through a full compile/run cycle.

@Jon Hendry Yeah, I thought the loss of custom palettes was just temporary, but since Xcode is now at 4.6.1 it no longer seems like they’ll be coming back. I agree with the commenters that Interface Builder was less of a pain before it was merged into Xcode.

@Adam: +1 for Xcode is increasingly horrid. The Xcode devs clearly bunked Coupling & Cohesion 101 and wouldn't know HCI if it bit them. Couldn't believe what a PITA Xcode 4 was the first time I needed to look up some framework header files. Found them eventually, entombed over a dozen levels down in the Xcode.app bundle. Never thought the day would come I'd prefer using CLI to GUI, but there you are - all hail 'man find'!

For my next product, I'm now intending to write my desktop UI in HTML+JS and limit Xcode/Cocoa use to wrapping a minimal .app shell around that and the existing Python core. It's a vertical market (print industry) solution, so fortunately AppStore rejections won't be a problem. Just hope the vertical markets don't all defect to Windows before I get done. :p

As for Brent's post, that can be largely summarized as "code weenies make visual editing suck, declare code editing victorious". Color me unsurprised.

[…] How Much, or How Little, I Use Interface Builder These Days, Stopped Using NIBs Thanks to Auto Layout, Decoding Old Nibs: a Sad Tale of Vendor Lock-in and […]