Is there a better approach to layouts than auto-layout?

The Age old question: How to calculate a layout.

Look. I get it. Developing nice layouts is hard. Companies usually have got dedicated people designing beautiful UIs for their apps to make the user experience as seamless and smooth as possible. Those people studied human psychology, their perception, and behaviors, to create good looking apps that are easy to use. The result usually is a well designed, yet static mockup of what the app should look like in a hypothetical scenario.

Now, what happens when those static designs come to us developers? The designers before us have poured their heart and soul into the designs and it’s now on us to turn these static mockups into dynamic content, that can be interacted with. We basically bring it to life. (This is the part that makes me feel superhuman! ???? )

We’ve got dedicated tools for making that happen. After all, we’re not the first ones to face this problem of trying to turn a mockup into an app. This is where the importance of auto-layout comes in. But it’s hard to convey how important it actually is. After all, the auto-layout system looks like a crutch at first, because it’s hard to understand at first, so many people shy away from ever touching it. But I believe that’s wrong.

Auto-Layout is actually really easy to handle and to understand. Much easier than to look for some library that does the same or even to implement such a solution from the ground up. It’s just nuts to think that that would be necessary. Apple implemented this nice and effective feature for us so we don’t need to think about the calculation, memory usage, energy efficiency, and performance. This saves us: So. Much. Time. The only thing we need to do is set things up so that the behavior is well defined.

But how comes that people shy away from the setup task? It’s not the implementation, it’s the setup that people fear. And it’s easy to say why: The education about the system is poor. That’s why most people are left with half-baked knowledge, and this usually leads to errors, then frustration and finally rejection. I’m here to fix this for you, once and for all.

I’ve spent months preparing to teach auto-layout and after the preparation, I can confidently say: Auto-Layout is one of the true golden nuggets of Apples implementations. The speed and efficiency of the system are incredible. You just need to know what you’re doing and it’ll serve you on every single project. Except CLI, but that’s a different topic. ????

Varying applications, varying behaviors.

The first thing I want to note at this point is something I briefly touched on already. Auto-Layout needs setup work to define the behavior of the views it is applied to. That’s the number one thing why creating a fully functional layout, is one of the more time-consuming tasks. Since there are so many different ways to create designs and define their behaviors, plus Auto-Layout needs to be able to cover them all, there is a lot left to chance. On the other hand, Auto-Layout needs to be able to solve the layout correctly every time. That’s where the many errors come from. Versatility and reliability. Those two are not easy to get under one hat.

Most of the time when we’re working on a single device size in the Interface builder, everything works out. We test on the same simulator and we’re good to go, right?

But our users don’t do that. They have a variety of different devices. iPhone 4, 5, 6, 6 Plus and so on. And then come the iPads.

We need to be able to handle the complexity of the layouts. Without auto-layout, this would be a pain to implement efficiently. But luckily we can test the constraints in the interface builder and we can check if everything works like intended.

But that’s not the only thing that auto-layout helps us deal with. What we also have to think about, is that a universal layout system needs to take into account that there’s a variety of different methods to show information to the user. There’s main views, sidebars, search bars and tab views. There are splash screens, popup dialogs and notifications. The list goes on, but what I’m trying to get to is that all of those things need to be positioned on the screen and also need to respect the space that we have on our devices. We usually don’t want a sidebar to take up the whole screen of an iPad Pro. That would just be confusing. Luckily auto-layout has got solutions for that too.

I could ramble on about what we can all achieve with this magic system, but I think you got it by now. You might say:

„Yeah, Ferdi I get it. You’re a fanboy. Now cut to the chase!“

Well all right then. Let’s do as you say.

Why Constraints?

The thing that makes Interface Builder newbies cringe and even makes some intermediate programmers shiver, is called constraints.

If you’re here you probably heard the term here and there but let me shed a little light on the matter, just to make sure we’re all on the same page.

Constraints sound like something from outer space I admit, but ultimately „to constrain“ is just some fancy word for saying you want to restrict or limit something.

If we look at it from that perspective, by setting constraints to views, we’re just limiting the possibility of them floating around anywhere on the screen, to a well-defined place and size. We’re just taking ownership of the views and we bring them into place by telling auto-layout where to position and how to size things.

But we’re also doing more. We’re defining a behavior for the views on how to behave if there are any changes made to the space available. Sounds vague, I know, but it’s actually is quite simple.

For that to be possible, we need to create a valid set of constraints. That means we need to set constraints – which, under the hood, are just math equations – in a way that they’re solvable. We know from our math teachers that there are equations that can be solved and there are some that just can’t. For example, if you take the equation

X * 5 = X * 3

with X = 1 you’re going to have a hard time solving that.

Same with constraints. If you set constraints that conflict each other (e.g. Adding a width constraint of 250 to a view, then adding another width constraint of 230 to the same view) Auto-Layout is just straight up going to tell you: „Nope“.

But why is that? How does it know how and when a layout is solvable?

A Glimpse Under The Hood

As I said, under the hood, constraints are just math equations. That means that there are numbers, relations, and operators involved. What’s different from a normal math equation we know from school, is the fact that we usually have 2 views involved in the whole process. Auto-Layout takes different attributes of those 2 views and adjusts them according to the equations.

Think of an equation without views:

X = 1 * 16

The solution is pretty clear there. X = 16.

Now let’s introduce the first view with its attributes into the equation. For that, we’ll replace X with a view and attribute, and on the other side, we’ll leave everything as it is. Like that:

View1.Width = 1 * 16

That’s our way of setting the width of a View to 16. This is a special case because, in this, there’s just one view involved in creating the constraint. However in most cases (since we’re usually defining interactions between multiple views) we need to introduce the second view.

View1.Width = 1* View2.Width - 16

If we solve this, it’s pretty obvious what will happen. We’ll take the width of View2 (View2.Width) and multiply it by 1, which leaves us with the same value. Now we subtract 16 from the width. The result of this equation is the new width of View1. We have successfully solved a constraint.

In this example, we are taking the width of a fictional View2 and define the width of our View1 using this information. That’s how we deal with constraints and as you can imagine since we have 2 view objects we can chain as many different views together if we want to. This system is dynamically extendable. For example, we could now set the width of a third view, based on the width of the first view, which is based on the second one and so on.

Oh the possibilities!

Standing on the shoulders of the people before us.

So let’s get back to the initial question of this post:

Is there a better approach to layouts than auto-layout?

It’s pretty obvious now. Of course, this is not a black or white question. There’s personal preference, there are different use-cases and many more factors that come in to play when we’re trying to answer this question. However, what I can say with confidence, is that Apple has created a Framework that is powerful, efficient, graceful and intuitive (if you understand it).

I know the feeling that some of you might still have about this. Some people – including me – love to take control of everything and believe that they can produce great quality software frameworks. But more importantly, I sometimes think that I could solve something better than the people that came before me. Most of the time this usually comes from not knowing how to properly use something and getting frustrated with it. I tend to think that I should redo something similar from scratch because it might be better, or faster, or easier to maintain.

The truth, however, is, in some cases that might be the case and even the best solution. However, when it comes to layouts, I choose to leave things up to the auto-layout system. The concept is great and I am super impressed by the versatility and speed that the auto-layout framework offers. Plus it lets you animate stuff if you’re into that. I’ve come to appreciate the immense time saving I’ve been able to get, by using auto-layout and not having to position and size everything myself. I encourage you to look into auto-layout deeper and find out what makes it tick. It’s a real golden nugget.

Ask Anything!

Do you have any questions? Ask them! I'll answer via Email as soon as I read it.

Not readable? Change text. captcha txt
0