[skue]

I wish this article spent more time discussing how autolayout is implemented in the real-life example, and less time talking about absurd situations such as using autolayout with a thousand subviews.

We are given no info about what constraints were used and whether the view was created in code or IB. For all we know, maybe all they needed was an extra constraint or two they to speed things up. Diving into how changing individual constraints affects overall performance would be interesting. It would be nice if Instruments had a template for inspecting autolayout performance (or does it? I haven't looked and not by my desktop).

Also, the numbers without autolayout still aren't great (hopefully that was tested on low end hardware?). I wonder why the OP didn't just pre-render the next view in the background, since he has the luxury of knowing that users will page through views in a linear fashion.

[the_french]

I don't know much about how autolayout works, but wouldn't it be possible to solve some of the constraints at compile time? e.g when you compile your app for iphone it could try and solve as much as possible considering the known screen size, etc..

[gdubs]

The idea is that it accounts for variations in things like string length for labels, image sizes and proportions -- things not always known at compile time.

But, for layouts where that's not the case, a compile time constraint builder would indeed be nice.