I totally agree. I wanted to expand a little on basic vs advanced screens, and suitability for IB.

At work we had two teams who had very different opinions of IB's usefulness. In our case, it was based on the nature of each application. IB does not provide much value when the majority of the screen is dynamically determined: different elements based on user preferences, locale, document contents, etc. The team that disliked IB, their app was almost all dynamic (and lists/tables, whose cells were also fairly dynamic).

Our team, on the other hand, had a very static UI. It had very little runtime customization (other than the contents of labels, images, etc). We loved IB.

And then child ViewControllers came along, and made it easier to mix static/dynamic content on the same screen.

I haven't used UIStackView yet, but I suspect it also will help with screens that contain dynamic content.

This is a good point. I've been dealing almost exclusively with highly dynamic UIs, and that's almost certainly skewed my perception of IB's usefulness.

We built our designs on a modular approach where each element is contained in a tableview cell, so that part is done by code. The cells themselves make use of Auto Layout though.

While I absolutely hated AL at first (and the IB just plain sucks) I do find it very time-saving once it clicked.

How do you code review?

For small to medium changes, by reading the XML. Everything is named sanely, and the XML hierarchy matches the view hierarchy. Constraints can be a little hard to understand, because they use opaque identifiers, but it's possible. I'll occasionally have to open the storyboard/NIB in Interface Builder to confirm/disprove something.

For large changes, it can be unmanageable. But large changes are hard to code review anyway, so we try to avoid those.