[kevingibbon]

Utilizing storyboards and xibs is one of the best way to decrease development time. Stop the coding madness!!!!

The only people I still know that avoid heavy utilization of these do not understand how to properly use them. Go learn!

[jsankey]

I started out using XIBs, but also found myself moving a lot of my controllers away from them as soon as things got non-trivial. The biggest problem I found was weak layout support, so if you had a lot of dynamic content in a screen, it was easier to make a flexible layout in code.

I also agree that the lack of "diffability" for XIBs, despite them being XML, is a pain.

Maybe I was missing something, but my experience matches the OP.

[robterrell]

Perhaps you're missing something. XIBs are arguably among the most powerful features of Cocoa. I built an app with a really complex, dynamic layout using them (look up "Panna" in the App Store). Working with an evolving design and changing team, with layout elements often changing and getting tweaked in tiny ways... Well, if I did the entire layout in code, I would have needed a full-time developer just for the ongoing GUI changes. I agree that dynamic layout support was weak pre-constraints, but it was still a much better development experience, and now you can do really complicated things without any code at all.

If you're just talking about some buttons in a toolbar, go nuts, but otherwise it's worth the time investment to learn.

[andrewroycarter]

100% agree. IB makes for faster development time, easier maintenance, and it's way better for auto layout if you're targeting iOS 6.0

[ravenger00]

I think there's a case to be made though, that using IB when starting out doesn't make you fully understand how UIViews work. So starting out I'd probably recommend you make your own views programmatically to know what you're hooking into.

That said once you get that base level of understanding, nibs and storyboards are huge time savers, and are the way to go.

[MaxGabriel]

While using storyboards definitely meant that I didn't understand things like how my root view controller got set up, I don't think it abstracts too much. Most importantly, using Interface Builder allowed me to explore the properties of views and get immediate feedback on how they're made. I still go back to a Storyboard when I need to figure out what combination of UIControl content settings I need.

[jsankey]

My experience is all pre-autolayout, which is very new. It sounds like I definitely need to take another look for future work.

[reidmain]

I'm 100% with you. I used nibs a lot when I started out but now I've slowly drifted away from them. The only thing I use them for is setting the frame so I can get a general idea of the layout of the view. Sometimes I'll set a few properties like text color and font size but I'll then move those lines into viewDidLoad: so I know exactly what my view will be like when it is loaded.

I've dealt with far too many bugs involving Interface Builder and it's random changes and "upgrading" the second I touch a nib that it's more of a liability now.

People who say it's less "code" are just delusional. Setting the font in IB versus a single line in viewDidLoad: doesn't save you anything. At some point in time that line of code is getting executed and you will at some point have to maintain it.

[cageface]

Agreed. If iOS actually had a sane declarative language like Android's xml layouts then I'd do everything in code but since layouts coded in Obj-C are excruciatingly painful to read and edit you're better off with a WYSIWYG tool, even if (IMO) WYSIWYG is fundamentally the wrong approach for UI development.

I actually consider this a big liability for Apple going forward. The explosion of "phablets" and other form factors spells the end of their pixel-perfect design approach and their tools and APIs for managing dynamic, variable layouts are stone age compared to Android's.

[Zev]

Cocoa Auto Layouts are what you're looking for: https://developer.apple.com/library/mac/#documentation/UserE...

[cageface]

They're better than nothing but compared to the html-esque layouts in Android they're much harder to write, read and debug.

[weiran]

I would beg to differ. I much prefer to work with AutoLayout constraints rather than some custom XML layout like with Android or WP.

[cageface]

YMMV but when the presenter of the WWDC AutoLayout track had to dig into Instruments to find out why his layout was throwing exceptions I felt like I was watching some kind of really nerdy April fools joke.

[jkubicek]

Totally agree. It's well worth working closely with your designer to make your interface work with nibs, not against them. Little things like putting button icons on the left side of the button and putting a 20px gutter between elements add up fast.

[protomyth]

That's actually a good way to see if your designer knows how to create a design within the conventions of the platform. Violating too many of a NIBs conventions tends to mean either a game (not really going to use NIBs) or something that will be hard on the users.

[pjmlp]

As someone with experience in several RAD tools, I never understood the design UI in code mentality.

Sure, you can control all your code, but there is so much time that is lost until the UI is finally ready, and than the marketing department wants it redone in one day.

[melling]

How do I set up view containment in iOS5 with Storyboards so I can have multiple segues in a dashboard view? This is something that I was just looking into last night.