[irskep]

I see you're getting downvoted (wrongly, because you're discussing in good faith), but I agree with the sentiment. 5% is a bit harsh, but having been on multiple iOS teams where AutoLayout is essential, it has always been a challenge to get people to understand what's going on, do the correct thing, and write code that doesn't barf constraint conflict warnings to the console. Seasoned iOS engineers have learned to do the right thing, but it's easy for one person to introduce a new conflict that nobody notices until months later when it's tedious to debug.

A shorter way of saying this is that the ergonomics of the most broadly-deployed constraint solving UI layout system—AutoLayout for iOS—still cause pain. It's not better pain than the massive complexity of CSS, it's just different pain. And it's also not sufficient; Apple themselves introduced collection views and stack views, each of which has its own special behavior. Their new framework, SwiftUI, does not use AutoLayout. Even the maintainers don't consider AutoLayout "superior" enough to adopt in a fresh UI framework.

It's a shame, because there is elegance in having a layout system you can explain in one or two pages, with enough power to almost support an entire OS and ecosystem of apps. It's just not quite across the finish line for developer experience and education.