Designing Adaptive Layouts for iPhone 6 (2024)

Storyboards

In Xcode, storyboards are a feature that allow you to layout app screens² by dragging and dropping native objects (like buttons, images, textfields and labels) onto a screen, and defining how those screens are connected with each other.

In Xcode terminology, user interface items that people can see, touch, or otherwise interact with (buttons, images, textfields, labels etc…) are called views.

The screens that contain and manage all those views are called view controllers³. I tend to use these terms interchangeably.

When we add a view controller to a storyboard it’s aspect ratio doesn’t match any particular device. In fact it’s a perfect square 600pt wide and 600pt high:

This is to remind us that a storyboard screen doesn’t represent a screen on specific hardware, but instead it’s an abstract representation of screens for any iOS device.

Simulated Sizes

You might be comfortable working with the 600×600pt canvas, but it will probably help to work with an actual size.

We can easily change this in Xcode by changing the view controllers simulated size and orientation⁴:

The easiest way to introduce constraints is to show you them in action.

Start with a simple storyboard that contains one screen (simulated to the size of an 4-inch iPhone) and add two squares⁵ positioned next to each other.

When we run the app the squares are laid out exactly where we positioned them in portrait. When we switch the orientation to landscape they remain loyal to their x,y coordinates:

And when we run the project with the iPhone 6 simulator, we see again that our layout hasn’t adapted to these different screen sizes and extra space is visible on the right side of the screen.

That’s because without constraints, the objects remain positioned at the x,y coordinates and dimensions that we laid them out with on our storyboard.

So let’s start adding constants and see the effect they have.

Leading and trailing space

Add a leading space constraint of 10pt to the image and a trailing space constraint of 10pt to the red square.

When we run the project now, the constants fix the blue square to the left edge of the screen and the red square to the right.

Horizontal space constraint

Add horizontal gap constraint of 10pt between the squares. Like the previous constraints this ensures that there will always be a fixed space between the objects.

When we run the project we see a slightly unexpected result: All of our constraints are satisfied, but to do so one of the squares has been stretched to satisfy the constraint.

It seems that unless told otherwise, iOS will try and keep the ‘natural’ size of as many objects as possible.

Equal widths constraint

Override that behavior by adding an equal widths constraint.

Running the project now we see that the widths of both squares are increased equally with the additional space.

Aspect ratio constraint

Finally, add an aspect ratio constraint to both of the squares.

This constraint ensures that the ratio of width to height always remains the same.

Running the app now we see that as well as the width of each square increasing, the height also increases proportionality because of our aspect ratio constraint.

Running the project with the iPhone 6 simulator, and overlaying the result from before constraints we added, you can also see how the size of the squares have scaled up to take advantage of the extra space that’s available.

Managing constraints

Now you’ve seen some of the ways that constraints can be used, here’s how to actually add them in to your storyboard layouts.

Tip: Try to use a few constraints as possible

A good approach when adding constraints is to try and challenge yourself to use as few constraints as possible to achieve an effect.

I don’t think there is a noticeable performance impact in iOS for the number of constraints that are entered, but the fewer constraints you have the easier your layout will be to maintain.

Adding constraints

There are three ways to add constraints to a storyboard⁶:

1. Constraint popovers

Probably the easiest way to get started is to select one or more objects on the screen and then add a constraint from one of the popovers. I think these are a good way to start since they are the clearest way to see the range of constraints that exist.

If a constraint is disabled it likely means that you need to have two or more objects selected for the constraint to make sense.

2. Control-drag

You can hold down the control key and drag onto an object (either a neighboring object, the parent object, or onto itself) a pop up will show you possible constraint that can be added.

This is my preferred way to add constraints since it’s faster than moving your mouse down to the bottom of the storyboard and back to the object.

3. Menu / keybindings

You can also add constraints by selecting one or more objects and choosing a constraint from the editor —> pin menu. This is the least efficient way to add constraints, but if you’re finding yourself repeating a constraint over and over again it might make sense to add a keybinding to one or more options.

Reviewing & editing existing constraints

The easiest way to review constraints that are applied to a view is to select the view and toggle into the Size inspector panel.

Or toggle the constants open in the document outline hierarchy panel.

From either method, selecting a constraint allows you to directly update the constraint.

Removing constraints

Likewise, constraints can be deleted by highlighting and hitting the delete key.

To remove all constraints associated with a view, or all constraints in the screen a shortcut is available in the layout issues popover:

Layout issues & conflicts

As we add constraints to a storyboard Xcode will often give warnings and errors about the constraints that have been added.

Sometimes the issues are innocent, but more often they hint at a problem that needs to be resolved.

Constraint warnings and errors are best viewed in the document outline panel. Each view controller will have an red or yellow icon to indicate if there are any layout issues:

Misplaced views warning

A common warning is the misplaced view warning which will occur anytime there’s a mismatch between where constraints say a view should be, and where it is currently shown.

These happen all the time when you switch between simulated sizes, or just accidentally moving a view with your mouse.

Clicking on an object with a misplaced view shows an dotted outline on the screen where the constraints say the view should be positioned.

Selecting the warning presents a popover with a few options. You can either ask Xcode to update the constraints to match what’s shown in the storyboard, or (most likely) you can ask Xcode to Update Frame which will move or resize views as needed to pop them back into the state that their constraints expect them to be.

Missing constraint error

Let’s go back to our earlier example with the red and blue squares. We never added a constraint that specified the the Y-position of the squares. When we ran the app it was okay because iOS just assumed the y-location of where we placed the objects on the storyboard, but to avoid unexpected behavior it would have been better for us to specify exactly what we want.

Adding a top space to top layout guide constraint to each of the squares removes ambiguity of the constraints and removes the error⁷.

To take advantage of constraints on anything more than the most basic layouts you’ll need to pair them with size classes.

Size classes are a type of trait that give information about the physical device width and height⁸.

When we add an object or constraint to a screen on our storyboard, that object will only be shown, or the constraint will only be applied for devices that meet the current with and height traits.

This is an extremely powerful approach, and allows us to define variations in layouts for different devices and orientations⁹.

Width & height traits

Using a mixture of compact, any, and regular for width and height allows us to target a range of device layouts.

Not every variation is covered¹⁰ (for instance there’s no way to target the iPhone 6 Plus in portrait, or to distinguish orientation in iPads) but a good range of options are covered¹¹.

Again, the easiest way to introduce size classes is to show them in action so let’s look at a real life example.

Our goal…

As an example, we’ll experiment with making a simplified version of the Instagram detail screen adapt to larger screens, and both orientations.

Our aim is to create a layout that scales sensibly to the larger iPhone 6 device sizes (by sensibly I mean only the photo scaling, and other elements like the profile photo remaining a constant size), and an landscape layout where the image and metadata are presented size-by-side rather than stacked on top of each other:

Add constraints for generic size class

This time let’s not use the simulated size metrics like we did in earlier examples, but instead use the abstract square layout of the generic size class to remind us that any views and constraints added for this size class should only be those that apply for any screen size and both orientations.

This includes these constraints:

As well as the spacing, gap, and aspect ratio constraints that you saw earlier, some of these objects are also positioned by aligning their top or bottom edges.

Add those views and constraints to your storyboard. Here’s an example of what my storyboard looks like after this step:

Note that it’s got all the key items needed for both orientations, but I’ve not bothered with trying to layout this generic layout to look like either of the orientations. That comes next!

Add constraints for iPhone portrait layout

Now switch size classes to compact width and regular height. This combination of size traits apply to any iPhone device when in portrait.

To switch size classes click on the size class label at the center-bottom of your storyboard and select the combination you want to view.

Notice that when you switch size class the size of the view controller updates to reflect the new abstract layout.

Finally, now you can reposition and resize the views and add constraints for a portrait layout. Here are the constraints that I added to the portrait layout:

Here’s what my storyboard looks like after this step:

At this stage you should be able to run the project with any of the iPhone simulators (3.5, 4, 4.7 or 5.5 inch screens) and see a layout that makes sense in portrait, although switching over to landscape will still be a mess.

Notice that we never defined the width of the image, instead we simply pinned the left and right edge of the image to the sides of the screen. As the screen size increases on the iPhone 6 the image width will be stretched out, and because we have a constraint that fixes the aspect ratio of the image width and height, the height also increases.

Add constraints for iPhone landscape layout

Switch size classes to any width and compact height. This combination of size traits apply to any iPhone device when in landscape and update the layout to match our goal for the landscape view.

This time the top, right and bottom edges of the image are all pinned to the edge of the parent view.

The only other interesting part of this layout is that trailing space constraint added to the comments label.

While the constraints on the image are scaling the image up, the constraints on this label are squeezing it to become narrower. To accommodate the text in this view, the height has to increase to show two lines¹² - which it does!

Here’s what my storyboard looks like after this step. Notice that in the document outline some constraints are slightly faded out. These are the constraints that we added for the portrait view. They still exist, but with the current width and height traits selected, they no longer apply.

Also notice that when you switch between width and height traits the storyboard updates to show the constraints that you’ve added for those traits. Neat!

Running the project now, finally we’ll see a layout that works for both portrait and landscape, and a nice transition between the two when the orientation changes.

I’ve slowed this transition down so you can see the details. Notice that the layering of views in the hierarchy is maintained in the transition. Because of this, we need to start thinking about how views are layered even for views that don’t overlap in their normal layouts…

Assistant Editor: Device Preview

Another nice addition in Xcode 6 is the device preview assistant. Instead of running your project multiple times to check if your layouts are correct, you can use the assistant editor storyboard preview and choose as many devices and orientations as you want.

It’s not perfect (for instance the navigation bar color is lost on the preview in this example) but it was a great option to switch from your language to a Double Length Pseudolanguage which repeats any text in your storyboard.

Here’s the assistant preview for my storyboard showing the 3.5 inch iPhone in landscape and the 4 inch iPhone in portrait. You can see from my storyboard that I’ve still got some work to do to accommodate longer labels… -_-

Add constraints for iPad layout

Now switch size classes to regular width and regular height. These are the traits for an iPad in both landscape and portrait.

As before, reposition and resize the views in the screen.For the iPad layout I’m deciding to go with a fixed size image (so it won’t change size between landscape and portrait like on the iPhone) and the metadata all underneath the image.

Here’s my storyboard after rearranging the views and adding constraints:

So far we’ve added constraints for a particular set of size class traits, but now we’re going to do something different.

With the extra space on the iPad, let’s not just rearrange views, but also add extra content. For the purpose of this example, add two more image views (perhaps to represent the images taken directly before and after the main image).

Here’s my storyboard after these updates:

I could have chosen to enter the width and height of these secondary images manually but instead defined their size relative to the main image¹³.

The nice benefit of this is that if we decide to change the size of the main image, the rest of the layout updates automatically without us having to manually calculate and update the width and height of the secondary images.

Here’s a screen capture of me changing the value of the main image width constraint and seeing the waterfall of updates cascade onto the other views.

I don’t have the screen resolution to capture the project running in an iPad simulator, but here are some screenshots of the resulting layout in landscape and portrait:

With the types of constraints that are currently available in Xcode there are some common layout scenarios that need a little help to achieve¹⁴.

Layout view example

It’s easy to align the edge of a view with the edge of the parent view, or to align a view exactly to the center of it’s parent view, but I've not found a simple way to pin a view to a fixed distance from the center.

Thanks to Jeff Nouwen for pointing out that after pinning a view to the center, you can change it’s constant value from the default of 0 to offset it by any amount you want .

Conceptually, what we need is a hypothetical ‘center alignment guide’ that would allow us to pin the edges of any view to the horizontal or vertical center of the parent view:

To achieve this with the constraints that are available to us today we could embed our views in a wrapper view —a view with a clear background and only exists to help achieve our layout — which can then be aligned to the center of the parent view.

With this approach your constraints might look something like this:

Right now I prefer to keep my layout hierarchy as flat as possible. Another approach that avoids the use of a wrapper view is to use what I call a layout view.

For this approach I like to add a view to the storyboard that has a bold color but then set it’s hidden property to true. You’ll still see it in the storyboard layout (although slightly faded) but it won’t appear when you run the simulator.

Now you can add align center to center constraints between your views and the layout view.

Spacer view example

Earlier we looked at how we can pin the gap from the edge of a view to its parent view so that when the parent view scales up the gap constraints pull on the view to increase it’s size.

But if we want the size of the views to remain the same, and intend have the extra screen space used by increasing the size of the gaps between the views?

Conceptually, we want something like the equal widths constraint that we apply to views, but to be able to apply it to a constraint¹⁵.

Instead we need to add spacer views which again are views that we’ll add to the storyboard to help with our layout, but because we don’t want to see them in the running app we’ll set their hidden property to true.

The general approach with this technique is to add a spacer view for every gap you want to grow proportionally, pin all the edges of the views with your spacer views, and then add an equal widths constraint to all the spacer views.

Hopefully by now you’re confidant enough to start exploring layouts defined with constraints.

Don’t expect instant success. Xcode is a complex tool with a lot of features that extend beyond storyboards and constraints so parts at first may seem mysterious and confusing. Like any complex tool it will take a while before you get familiar with it’s quirks, but I’d recommend that you start getting familiar with it sooner rather than later as I predict (or at least I hope) that the next generation of designers will spend more time using tools like Xcode than Photoshop.

If you’re a designer who creates design specs for iOS developers to follow build from you should start thinking about the best way to communicate what you want to your design team. Maybe you will create a visual language that describes the constraints you want applied.

Personally I’m excited about the idea of designers taking more responsibility for the creation of their work and instead of having a front-end developer recreate the designers intention, the designer simply manages the storyboard file themselves.

If you found any part of this tutorial difficult to understand, or if there’s something I completely missing please let me know and I’ll try my best to make an update.

If you found this tutorial interesting you might also like my series on posts looking at creating animations in Swift.

Notes