Hacker News Reader

Comment by jbish | Hacker News Reader

Are there many designers that know their way around Interface Builder?

I always felt that Interface Builder is _for_ designers who want to visualize and use something (only somewhat) closer to photoshop. A developer might more likely come at it from the other direction, not even touching IB and doing it all in code, then maybe adding modular IB elements when the layouts start to make the code unmanageable.

Interesting. I've worked with a few designers who had Xcode _installed_, but they were mostly using it for the Simulator. Using IB wasn't something they were comfortable with. I'd be really impressed with somebody who's a Sketch/Photoshop wiz coming over to IB and being productive.

On the flip side why would a non-developer bother to install Xcode and learn IB when they can export their ideas directly from Sketch/Photoshop into clickable "prototypes"?

If you're not using interface builder as a developer, you're wasting a huge amount of time. Doing advanced screens (mostly) through code makes sense, but often it's a lot faster to use IB for putting together / building the more basic parts of an app.

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.

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.

Back when IB was a separate tool, I'd agree with you. I'm not going to look for old docs, but I'm pretty sure I ran across something from six or seven years ago that mostly said, "IB can be used by non-programmers to make a UI, and then dev can create the code to hook to the IBActions.", or something like that.

Whether it was written down or not, it seems like a good idea in theory. The old, stand-alone IB wasn't all that hard to figure out (though struts and springs might bring the death of your sanity). Get the UI all prettied up, and hook up an implementation behind it. Not that I've ever seen that in practice, however.

Reply on news.ycombinator.com