Comment by SeoxyS | Hacker News Reader

Comment by SeoxyS | Hacker News Reader

Parent Full thread

I've been a Cocoa developer for close to a decade now, and I've gone back and forth on this many times, but by now I've settled 100% in the nibs-are-evil camps. There are several reasons for that:

- Nibs are a nightmare when working with version control and merge tools. Now, at least, they are XML instead of a proprietary binary format, but it's still a joke…

- Auto-layout in IB is provably the worst GUI I have ever used. It's completely impossible to make it do what you actually indent. I was one of the guys cheering and wooing in the audience when it was announced at WWDC 2011, but it's proven to be a huge flop.

- I have a similar experience with storyboards.

- Having classes that may be instantiated both from code or from NIB deserialization adds a layer of complexity and messiness to your app.

- Ultimately laying out your views in code doing some simple arithmetic is easier to reason about and more likely to do what you expect. (People have no problem doing it to lay out websites with CSS–it's not that complicated.)

At the end of the day, nibs make it a little easier to get started (like using Ruby on Rails, and the Active* set of libraries), but it does not belong in a serious project, as it would add a prohibitive amount of technical debt.

Since you seem to be catching some flak for your post, I'll elaborate a bit further.

AutoLayout is a constraint solver, and as such it's very easy to either over-specify or under-specify your constraints in a way where it no longer evaluates.

On top of this, AutoLayout also has a priority for each constraint such that if/when such a conflict occurs AutoLayout has some ordering as to which constraints get abandoned first.

When you run into cases where AutoLayout breaks, debugging is a chore. You have to go through your entire view hierarchy and query each view for its hasAmbiguousLayout flag, which will give you some pointers as to what views are breaking your whole layout.

Interface Builder makes this somewhat worse because it doesn't give you an easily understood 1:1 match between what you do in the UI vs. the code that gets generated out of the other end. The opacity makes it hard to triage AutoLayout failures.

We use AutoLayout in small parts of the app, and we've found that doing it in code has been preferable - for a system that is as easy to break as AutoLayout you really don't want to be poking buttons on the top of a black box in the hopes that whatever comes out the bottom is sane. If there was a more transparent mapping of Interface Builder -> NSLayoutConstraint this would be less of an issue.

Also, yes, XIB merges are one of the Prime Evils of Hell, second only to pbxproj merges.

It's hard for me to believe that Storyboards or AutoLayout were designed by someone that actually builds non-trivial apps for a living. They're the kind of technologies that look good in a one-hour conference demo but quickly fall apart in real world use. After nearly throwing my laptop across the room on my latest project I ripped AutoLayout out of my project entirely and went back to springs & struts + frame math.

What this means though is that a layout I can build in five minutes in Android with <GridLayout> takes hours in iOS and is utterly opaque to version control. This is a cost I have to pass on to my clients.

You need to learn AutoLayout putting the blame on it won't help you.

I understand it. The problem is that not only is it a fundamentally flawed concept but the tools are inadequate. Moving a control by as much as one pixel in IB can completely scramble your constraints, including deleting user constraints attached to properties.

The API is ridiculously verbose and the visual language is underpowered and cryptic. It's sad but going back to manual frame calculations actually saved me a lot of time.

I think a lot of iOS devs don't realize how crap it is because they haven't taken the time to learn how other platforms solve these problems in a much more logical & developer friendly way.

I agree that the IB implementation is crap.

The API, on the other hand, is very nice. Although constraints can be slightly verbose, they are ages better than having to manually re-layout views after every single change of the superview's bounds. Spring and struts are nice, but cannot replace all of the CGGeometry math which is equally as, if not more, verbose than adding constraints. Autolayout is add-and-forget. The only downside is that it is iOS6+ only.

Have you done any Android dev? I find the various layout containers there far, far more intuitive and explicit and semantically clear. Let's face it, 95% of UI is nested grid layouts. Plus, having instant visual feedback for layout tweaks is a big time saver.

Just let it be, cageface is on a mission.

I tried using Auto-layout on an app when it was first released, but for anything beyond simple cases it's incredibly buggy and unpredictable. It's now the first thing I turn off in any nib.

I don't think that Auto-layout is buggy at all. It is, however, not very intuitive and requires using it the right way for it to work!

Not any of those points is justified, "a nightmare", "the worst". You need to provide something to support all those affirmations.

It's called an opinion. This isn't a peer reviewed paper we're talking about. And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Hardly.

>It's called an opinion.

Which are like noses. Everybody has one.

>And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion?

Does he needs to elaborate more in order to justify it?

Of course.

Well allow me to elaborate - have you ever merged two nib files? With today's variant you merge XML. With yesterday's variant you simply don't do it because it's not possible. So you're merging an obtuse XML file at best. In my mind that's painful versus merging clean .h and .m files where we know what's going on. So he's using colorful language to describe such situations - A "nightmare".

Try merging a .nib. You'll see first-hand how hard it is.

Why merge it?

Merging isn't even funny with regular code.

How about having a process for who works on what or when?

Either than or let a single person be responsible for the UI.

We're a two person development team who sits in the same 5 foot radius and we've had to merge xibs semi-frequently. It's not overly viable to ask the person next to you what files they plan to work on in the hour, because that can be difficult to determine in advance. Additionally once I upgraded Xcode before my partner, and suddenly our xibs were out of sync. In terms of one person working on the UI, even if that's the case, the other person might change an outlet, or create a non-UI object in the xib. It's complicated to coordinate changes because the breadth of features (as they appear in the codebase) is unpredictable.

these things work well-enough in very small development teams.

If you say "provably" you really do need to... prove it. What studies are you citing when you say IB auto-layout is "provably the worst GUI?"

He might have meant "probably".

This is one of those quintessentially Hacker News exchanges that I have begun calling "Hacker News moments".

I did :). I wrote the comment on the bus this morning on my iPhone, and the autocorrect failed me! I wish I could still edit it to add a little more substance, though – hard to be thorough on an iPhone screen.

Do you use Auto Layout in code?

Reply on news.ycombinator.com