4 ms·

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.

by SeoxyS 14y ago

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.

pc86 14y ago
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?"
- spac 14y ago
  He might have meant "probably".
  - mratzloff 14y ago
    This is one of those quintessentially Hacker News exchanges that I have begun calling "Hacker News moments".
  - SeoxyS 14y ago
    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.
rbritton 14y ago
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.
- goyalpulkit 14y ago
  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!
pablasso 14y ago
Not any of those points is justified, "a nightmare", "the worst". You need to provide something to support all those affirmations.
- ianstallings 14y ago
  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.
  - coldtea 14y ago
    >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.
    - ianstallings 14y ago
      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".
- coherentpony 14y ago
  Try merging a .nib. You'll see first-hand how hard it is.
  - coldtea 14y ago
    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.
bridgeyman 14y ago
Do you use Auto Layout in code?
potatolicious 14y ago
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.
- deleted 14y ago
  [deleted]
cageface 14y ago
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.
- seivan 14y ago
  You need to learn AutoLayout putting the blame on it won't help you.
  - cageface 14y ago
    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.
    - conradev 14y ago
      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.

by SeoxyS 14y ago

pc86 14y ago

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?"

spac 14y ago
He might have meant "probably".
- mratzloff 14y ago
  This is one of those quintessentially Hacker News exchanges that I have begun calling "Hacker News moments".
- SeoxyS 14y ago
  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.

rbritton 14y ago

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.

goyalpulkit 14y ago
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!

pablasso 14y ago

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

ianstallings 14y ago
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.
- coldtea 14y ago
  >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.
  - ianstallings 14y ago
    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".
coherentpony 14y ago
Try merging a .nib. You'll see first-hand how hard it is.
- coldtea 14y ago
  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.

bridgeyman 14y ago

Do you use Auto Layout in code?

potatolicious 14y ago

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.

deleted 14y ago
[deleted]

cageface 14y ago

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.

seivan 14y ago
You need to learn AutoLayout putting the blame on it won't help you.
- cageface 14y ago
  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.
  - conradev 14y ago
    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.