Apple has a huge device palette. There’s iPhones and iPads in various sizes reaching from small to oversized and those devices can be used in Portrait or Landscape mode. Some of the devices, especially iPads even have a split view mode where you can use Apps side by side or you can use them as sidebars on iPads.
All of those variations were introduced by apple to create a seamless experience when using those apps. They wanted users to enjoy using the devices and that was only possible if the user didn’t get held back by lack of functionality. This was definitely a smart move and certainly it did make a lot of our experiences with apples ecosystem enjoyable because we can use the apps the way we want to.
The Thing is this made it much harder to develop apps because we now have to account for all the different screen sizes and size configurations.
So let’s just look at this example I’ve created. We have a login view of a fictional app right here. While on the iPhone 5 it looks fantastic, as soon as we switch to iPhone 6 or 7, the login view just gets mashed up. The view doesn’t adapt to the screen size and therefore the login screen looks terrible on anything else than an iPhone 5.
Now how can we change that? Well, its not that straightforward by hand. Let’s just take this example of the login view to think about the problems we have. We could just check for the screen size in code every time the app gets launched and adjust the layout in code. And then every time the screen is rotated. And then every time the app is used in a sidebar view. And every time the app is used in split view mode, and so on. We could just go through all the different cases, create complex math functions that calculate the positions of the views and make the layout adapt every time some change occurs. This would cost us a lot of time to develop and would probably be really inefficient.
But there already is a much more elegant solution. The solution is Auto-Layout.
The Solution – Adapting Layouts
Think of a layout that knows how to behave. That can adapt to screen sizes without you having to write complex functions and calculating where a certain view should go.
Apple has implemented such a system into Xcode and all of the operating systems of the devices that unifies the system that makes up the layout and this is what we call Auto-Layout. Auto-Layout is similar across iOS and macOS and In fact, since you’re just using Xcode to develop for all those devices, there is no difference at all for you. The tools and menus look and work exactly the same on every project for every device and the rest is handled by the device itself.
Now, Auto-Layout unfortunately doesn’t work like that magically on its own. There is some work we need to do. We have to tell the auto-layout system how a layout should behave if changes occur, so it can react accordingly.
The thing we use to make this happen is called:
Now, I have good and bad news. Bad news first: Even though Auto-Layout is convenient and it works really well, we haven’t gotten rid of the complex math yet. That’s because Auto-Layout makes use of mathematical functions, called constraints, to determine the layout. So there still is quite a lot of math involved in determining the layout. Fortunately though, Auto-Layout is a system that is fully implemented by Apple, so we don’t even notice that 90% of the time.
So the good news is, even though we need to use complex math to make Auto-Layout possible, we don’t need to worry about it at all. We don’T need to know how to calculate the anchor points so that a view appears to be centered. We don’t need to implement interactions between to different wies to make them create margin around them. The Auto-Layout system takes care of that for us, so that we don’t have to, so we can take our time and energy and apply it to the things we are good at, like designing interfaces or building apps.
So, let’s take a quick look at how the constraints work.
Like I mentioned before, Auto-Layout uses mathematical equations to determine the size and position of the different views. Now to make this possible, each of those equations, each of those math equations describes certain aspects of the view – like for example the position, the height, the width etc.) and in order to work properly, the equations need to be structured in a way that those equations, when solved, have one and only one possible solution. They can’t be different solutions of that set of constraints. For example this means that there can’t ever be 2 constraints setting the X position of the view to two different positions. Or the height or the width. You can’t say this view is 30 points wide as well as 20 points wide. it’s obvious that this can’t work. If this would happen, auto-layout doesn’t know how to resolve the information and we get an error. Usually Xcode would tell us that or if it doesn’t, the app will just crash.
Because we have those mathematical equations, Auto-Layout can now determine how the layout should behave, when changes on the superviews size occur. That means, Auto-Layout can help us adapt the UI of apps to different screen sizes, make adjustments once the device is rotated or the app gets pushed into a sidebar. On Mac it would mean that we can react properly to window size changes. All of this is stuff that happens on a frequent basis. You shouldn’t ever have an app that can’t adapt to size changes or important elements of your layout could get pushed outside of the screen.
Lastly, because constraints are just math equations, we can easily use those to connect them to code. That is especially useful, when we want to make use of the constraints to reposition objects while the application runs for example. Constraints come in very handy when we get into animations for our apps. For example: We can make use of the X position constraints to create an animation, where the view moves across the apps screen or the Y-Position to make a view fly into a launch screen from the top. This is for example something I have used for an onboarding for an app I did a couple of weeks back.