I disagree with the blanket statement that for anything non-trivial, IB is more of a hindrance. I've worked on a number of large iOS projects over the last fou

I disagree with the blanket statement that for anything non-trivial, IB is more of a hindrance. I've worked on a number of large iOS projects over the last four years — I tend to select whether or not to use IB on a per-project basis. About 60% of our projects end up using IB for the majority of their UI layout. Recently we built a very large educational app for teachers. IB was great — we had a number of key storyboards, most of the design happened very fast. We developed strict standards by which we developed further styling in code (for things that IB couldn't handle like pattern images, and stretchable images). Merging Storyboards was a bit of a pain — which was exacerbated by the fact that it's much easier for multiple developers to touch a single storyboard than to touch a single xib. But using DiffMerge as our default git mergetool makes things better. There are definitely times when IB is not suitable — especially if you want to develop reusable dynamic layouts or controls. But when you have strict specs, designers working on the project in advance, and clients signing off on particular designs, IB is great.