Hacker News Reader

Comment by niggler | Hacker News Reader

> if you are using IB

For anything nontrivial, IB is more of a hindrance than an aid. You probably are constructing the view programmatically.

View on HN

I'm so tired of all the IB hate. IB is a tool, and it should be used when appropriate. Sure you can't do everything in it, but for 80% of even "complex" views, things can be done significantly faster in IB. Doing all UI creation and layout isn't faster and more "hardcore", it's ignoring a tool that has been around longer than OS X and iOS that was literally made for the job! Have fun maintaining that mess of UI layout code!

Definitely. And Super Debugger can be used just as well for IB projects too (some things you can't test out with IB, like a corner radius).

And of course, this tool isn't just for UI tweaking. It's for any kind of messages you might want to send to objects. It's an object spelunker.

I'm looking forward to giving this a go at work tomorrow!

Isn't it fair to hate it just due to the clunky interface?

Many times I find it difficult to select a subview under another subview. Or, when adding a subview, it is too eager to be the subview of a subview. Those are the tip of my list of grievances.

I use it! Sometimes it's simpler and faster to go with IB instead of code, and you are definitely right about maintainability. But I sure wish there was something as convenient that wasn't awful to use. That's actually how I feel about all of Xcode. (Yes, I've tried AppCode, I liked it even less.)

You can select a specific view under others with ctrl-shift-click. I don't know anything to help with its over-eagerness to add subviews, though.

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.

One of the biggest detriments to interface builder is the lack of code review. If you're a solo developer, you can maybe get by without this... but for a team that actively follows a code review process, nib files are black boxes with no searchable history.

Out of curiosity, have you maintained any of your large projects over a long period of time? Did you have any issues with nib files (i.e lots of duplicated bugs? re-introduced bugs? etc?) Personally I've avoided nib files like the plague because of this, but I'm curious as to how others deal with them.

"Trivial" views are the rule though. And with autolayout, IB is much more important since it's the only way to effectively test the behavior of your constraints interactively. (By setting the screen size to "free form" and dragging the control handle, like a web browser window.)

What are some nontrivial examples? I've only been an iOS developer as my day job for about a year now, and I don't know everything - but rarely do I need to resort to code to do my interfaces.

That said, merging xib's is a pain in the ass. I wish they were more like Android's human readable layouts.

Reply on news.ycombinator.com