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.
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.
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.
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.
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.
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.
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.
How does it add more complexity to your view hierarchy exactly?
Most people are getting away from doing their UI's in code and moving back to their proper place in IB.
This is done almost entirely in IB:
http://www.youtube.com/watch?v=Tk8HCkqZsNU
As is this:
I'd still be typing if I did it in code.
Weird.
It's unfortunate that the Default.png is a photo when the UI doesn't seem to vary enough to exclude the standard preview shot.
In the adjustments view, "Finish" should be "Done". And tapping it should not trigger a flip animation-- it's too distracting.
Also, the music is extremely loud.
Not sure what you mean by the standard preview shot?
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.
Care to be more specific?