×

Rotterdam

Benjamin Franklinstraat 513
3029 AC Rotterdam

Designing for all iOS devices

May 12th, 2016

In a world with an increasing differentiation of screen sizes, it’s important to think about adaptivity right from the design process. However, not all designers keep this in mind. If this is the case, design choices for different screen sizes are not visible to the designer and might not be made. In most cases, it’s up to the interpretation of the developer to choose a correct solution, although these decisions should've been made by the designers themselves.

This blog is meant for designers to solve the problem above by describing a layout in layout constraints, instead of just using absolute pixels.

Layout Constraints

When describing a layout using natural language instead of pixel information, you will almost always get an adaptive layout that’s usable for different screen sizes. For example, the Apple Weather app. The interface of this app can easily be described by the following rules:

Each rule in the list above represents a layout constraint.

Constraint Anatomy

In the example of the Weather app, layout constraints let you center and pin elements, but there are more things. To explain what a constraint should describe, let’s take the following constraint:

Pin the temperature label’s bottom, to the center-Y of the window.

And let’s decompose it into functional blocks:

Pin the temperature label’s bottom, to the center-Y of the window.

As you can see, a constraint should contain a subject, the attribute of the subject, a relative object and the attribute of the relative object. There’s one exception to this rule: describing the width or height of a subject. As this kind of constraint does not refer to another object, but just to itself. In addition to relative positioning, an iOS layout constraint can also describe a relationship, offset constant or multiplication:

The temperature label’s center-Y, should be greater than the window’s center-Y times 0.5, plus 20 points.

As this constraint looks a bit complex, this syntax can describe all possible layout properties. A simple centering constraint for example would look like this:

The temperature label’s center-X, should be equal to the window’s center-X times 1, plus 0 points.

A constraint that describes a width or height would only have a subject, attribute, multiplication and a constant.

Constraint Attributes

A constraint can define a relative position from the following attributes of a subject:

On top of these positions, a constraint can also be described relative to a predefined margin from the object. This is possible for left, right, top, bottom, leading, trailing, center-X and center-Y.

Ambiguity

It’s possible to define multiple layout constraints for a single view. This means that it’s possible to define constraints that contradict each other. This is called ambiguity.

Constraint Priority

To explain ambiguity, let’s look at the following constraints:

By default, each element gets the dimensions of its content, unless there are constraints that define other dimensions. This content size is called the intrinsic content size. This won’t cause any problem as the label is small. However, when the content starts to grow (which might be the case when the app is being localized in a language that uses longer or more words), problems arise. The label begins to grow beyond the 50 points at its trailing. It won’t be possible to either center the label horizontally, or have a trailing space of at least 50 points. The iOS layout system will give a warning and will remove a random constraint from the conflicting constraint. This might cause unexpected layout behaviour. To solve the problem in this case, we can lower the centering constraint priority, so that the label shifts to the left whenever the label becomes bigger.

Content Hugging Priority

Let’s say we have a text compose view with a send button next to a text field. The horizontal constraints would look like this:

There’s a problem with these constraints. How does the layout system know how big the textfield or the button is? As mentioned, the layout system uses the intrinsic content size of elements, but we have two elements with an intrinsic content size next to each other. In this situation, there’s an ambiguity and the system needs to choose between blowing up either the textfield’s width, or the button’s width. To fix this, we can define a content hugging priority on all views. A content hugging priority describes the need for a view to “hug” its edges while blowing up its window.

A content hugging priority describes the need of the view to “hug” its edges while blowing up its window.

In this case, we would give the button a higher content hugging priority than the textfield.

Content Compression Resistance

Let’s say we still have a text compose view as shown in the last paragraph’s example. The view in that example was bigger than both intrinsic content sizes. But what if we have such a small view that the subviews would be compressed instead of blown up? This is what the content compression resistance is about. The content compression resistance describes the need for a view to keep to its intrinsic content size while compressing it.

The content compression resistance describes the need for a view to keep to its intrinsic content size while compressing its window.

Trait Collections

Layout constraints are really powerful in describing the layout, so that it can be laid out for all kinds of screen sizes. It works very well for interfaces that can be blown up or compressed. However, sometimes we have a different kind of design for different kind of devices. The Apple Settings app for example has a sidebar at the left on the iPad, where the iPhone app does not have this. This is possible by conditionally defining layout constraints, based on a collection of device properties. Such a collection is called a “Trait Collection”.

Size Classes

A size class describes whether a screen’s axis is either “Compact” or “Regular”. A few use case examples:

Layout constraints that are defined in Xcode’s Interface Builder can be conditionally set based on a screen’s horizontal or vertical size classes. When the size class changes (for example by rotating, or changing the app window size on the iPad), iOS will automatically change the current used layout constraints. This is an overview of the used size classes on different iOS devices:

Other Properties

In code, layout constraints can be based on more variables than just the horizontal and vertical size class:

More Information

Every iOS app designer should think in different size classes. This makes the experience great for every iOS device (including the iPhone 6 plus). For more information about trait collections and iOS design, see the iOS Human Interface Guidelines by Apple.