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.
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.
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.
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.
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.
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.
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.
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.
Would you care to qualify that. In my experience it has been the exact opposite -- setting up your UI in Interface Builder has always reduced the amount of code necessary and has allowed quite complex view hierarchies to appear pretty much flat in code. And I'm taking about iOS UIs, for which a bunch of the code saving goodies of AppKit Interface Builder are not available -- things like Cocoa bindings and the new auto layout machinery in Lion.
I find that added generated NIB files just dirty the code base. Of course this is just my preference. However, when I was a beginner, beginning to create more advanced views, I found it easier to programmably add them then to use Interface Builder. I like to be in control of my views and it helps me better visualize the view hierarchy. One example, was trying to create a UITabController with UINavigationController's for each tab. It can be done with Interface Builder, but it takes a lot of steps.
I still don't understand how a bunch of stored-to-file object graphs "dirty the code base" but I guess you are right -- it is a preference thing. Believe me, I have weirder quirks than that when it comes to coding.
Your example, however, is probably amongst the worst to support the argument you are making. Here are the steps to create a tab bar view with four tabs, each containing a navigation view, and those containing alternating table views and plain views:
- drag out a UITabBarController
- remove the two default UIViewControllers instantiated with it
- drag out to the tab bar four UINavigationControllers
- select each tab and drag out to the center area of the view a UITableViewController or UIViewController
- customize to your heart's content
- there is no step six…
In my guestimate this will take at least 20 lines of boilerplate code, even with the minimal amount of customization. And you’d be missing out on all the rest of the benefits of NIBs, like the ability to see (and to some degree test) your UI without having to build and run your application or the ability to send it off for localization to a collaborator.
I think during XCode3 I just really started to hate NIB's haha. They seemed slow to initiate and load. I admit that i haven't yet used Interface Builder in XCode4 and it apparently has fixed a lot of those "weird" bugs.
For example, instead of drawing a table programmatically, I can drag it into my view from Interface Builder's default list of objects. I can edit the table's properties quickly and easily.
And that's just one tiny example. Suppose you have a complex interface with loads of different buttons, sliders etc, custom backgrounds - you would have to set everything in code (e.g. button background images, button type, x and y co-ordinates on the view). In my admittedly limited experience that adds massively to the amount of code you have to write. It's crazy not to use IB in my opinion, but each to their own.
> It bloats your code base and adds more complexity to the view hierarchy.
How so?
All Interface Builder really does is serializes the objects, much like you would any other object supporting NSCoding. The net result is that an instantiated view from IB should be identical to one you created manually.
IB certainly isn't the right tool for all situations, but its design is pretty clever with tight integration with the rest of the system. I can't see any reason not to use it, when it is appropriate.
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.