NSStackView

10.9 gained a new class, NSStackView, which is a great idea in principle. It's roughly like CSS's flexbox, except less powerful and not as intuitive. Or like one of Java's LayoutManagers, in the sense that all it does is lay out other views.

It would be neat if you could manage 90% of your layouts this way, and that's how they demo it. Unfortunately, it's not the easiest class to work with.

• Are your edgeInsets being ignored? This says they're only used when the stack's huggingPriority (not contentHuggingPriority, which doesn't do anything) is at least 500. Then again, I've run into this problem even when I've set huggingPriority all the way up to .required, so I think there's something else going on. That trick has helped me in at least one case, though.
  • Empirically, 500 doesn't actually seem to be the threshold. Any value >251 produces the same result (on 10.15).
  • (I honestly can't tell if this is a bug or not. Apple's documentation doesn't say anything about it.)
• Are you getting errors about unsatisfiable constraints? This says you might need to explicitly set translatesAutoresizingMaskIntoConstraints = false on your subviews, due to an OS bug.
• UIKit has a similarly-named "UIStackView" class, but it's not the same. It doesn't support "gravity" at all, for example. NSHipster suggests that feature is "unnecessary complexity for most use cases", but it's the default distribution for NSStackView and probably the most common one I use, so I'm not sure what they mean by that. In any event, don't assume that just because you used NSStackViews that you're one Swift typealias away from running that layout on UIKit.

See also: NSGridView