[gte910h]

I am a full time iOS dev: I cannot imagine professionals who completely avoid interface builder.

For some screens, it is certainly faster and easier to programmatically build them up, but for the vast majority of screens, your comment seems to tell more about a willingness to learn than a desire to make good apps.

Perhaps you stopped trying to use it during the Xcode3 days? Now, almost any hairs it did have got shaved off in the Xcode3->4 transition.

I'm not saying use it for all adjustments to views, sometimes those go faster in code, but it is by far the better way to do almost every view.

[coreycollins]

I admit I did stop using it during XCode3. I got so use to it I haven't yet used it in XCode4. I meant it more as a better way to understand the iOS view hierarchy, not necessarily the faster way to build apps. But building faster apps doesn't make them better.

[gte910h]

If you do the exact same amount of functionality in a shorter period of time, it frees up that time to then go make another part better. More features. More testing. Faster Release. More documentation. Accessibility features.

If you prefer to boil each grain of rice separately for a pilaf, and it tastes the same at the end, you just wasted a lot of time in the kitchen for no good reason other than you've not stopped and learned how to boil them all at once.

Try the new Xcode4 book: http://www.amazon.com/Xcode-Developer-Reference-Richard-Went...

It goes into IB's newest incarnation. IB is also fantastic when adding assecessability functions to your app. Another reason to add accessability functions to your app (beyond being a good human being who lets not-fully sighted people use your app) is that it allows kif to work: http://corner.squareup.com/2011/07/ios-integration-testing.h... (play the video).

I'm not a IB Zealot, I make views manually when it makes more sense to or IB is just not doing it's job with any speed, but "0" is not the amount anyone should be using it who makes non-game apps.

[coreycollins]

Your analogy doesn't really apply since you still have set the properties in Interface Builder. It's more like i'm just using a different stove. It does some, but not all. And most of the steps it does do are default for the class anyway. I like the finer grained control. If you're used to it the time difference is negligible.

[gte910h]

>It's more like i'm just using a different stove.

Sure: http://www.goodtimestove.com/

Modern constraints(http://developer.apple.com/library/mac/#recipes/xcode_help-i...), for instance, are insane to edit manually with no visualization on any complicated screen.

Perhaps you're just building tons and tons of tableview cells or something else automatically laid out for you, so you're not really feeling it (or are too strident a believer of your position to learn then judge, rather than judge first). But if you do any manual layout at all, there are huge wins within days of starting to learn the tool.

It feels like I'm discussing with someone contending that zip files are as good as source control here.

[coreycollins]

Were talking about iOS and the Interface Builder, not MacOS. I do not develop apps for the Mac, but I agree using Interface Builder would make sense for "larger" screens with more ui elements. To be clear I used Interface Builder for over a year until I decided it was better for ME to programmatically add ui elements.

[gte910h]

http://developer.apple.com/library/ios/#recipes/xcode_help-i...

Is the iOS link to the same article. I just hit the wrong one in google.

>The one thing I would recommend people do is not use Interface Designer. It bloats your code base and adds more complexity to the view hierarchy. It might be good to quickly mock-up a prototype, but not much else.

Is the issue. If you yourself wish to do things a different way, that's fine, but it should be clear to people that this is a you thing, not a thing that's really accepted by anyone much who does this. Have fun not using it, it's fine, I'm not working with you in particular.