Simplifying Auto Layout in iOS with MarkupKit

Auto layout is an iOS feature that allows developers to create “responsive” user interfaces; i.e., applications that automatically adapt to device size, orientation, or content changes. An application built using auto layout generally has no hard-coded view positioning logic, but instead dynamically arranges user interface elements based on their preferred or “intrinsic” content sizes.

Auto layout in iOS is implemented primarily via layout constraints, which, while powerful, are not particularly convenient to work with. This article provides an overview of how constraints are typically managed in an iOS application, and then discusses some alternatives that can significantly simplify the task of working with auto layout.

Storyboards

The structure of an iOS user interface is commonly represented by XIB files or storyboards created using Xcode’s Interface Builder utility. This tool allows developers to lay out an application’s user interface visually using a drag and drop metaphor.

For example, the following is a storyboard representing a simple view. The view contains two subviews whose positions will be automatically determined at runtime based on layout constraints. The constraints pin the subviews to the edges of the parent view as well as to each other, with a 16-pixel gap in between:

Running the application in portrait mode on an iPhone 8 produces the following results:

In landscape, the application looks like this:

While storyboards are undoubtedly the most common way to create auto layout constraints in iOS, they are not necessarily the most efficient. Using Interface Builder to visually establish every relationship can be awkward, especially when working with large or complex view hierarchies. Further, storyboards are not stored in a human-readable text format, which makes it difficult to identify changes across revisions.

Programmatically Defined Constraints

In addition to storyboards, constraints can also be managed programmatically. For example, the following Swift code produces the same results as the previous example:

// Red view
let redView = UIView()

redView.translatesAutoresizingMaskIntoConstraints = false
redView.backgroundColor = UIColor(red: 202.0 / 255.0, green: 53.0 / 255.0, blue: 56.0 / 255.0, alpha: 1.0)

view.addSubview(redView)

// Blue view
let blueView = UIView()

blueView.translatesAutoresizingMaskIntoConstraints = false
blueView.backgroundColor = UIColor(red: 59.0 / 255.0, green: 85.0 / 255.0, blue: 162.0 / 255.0, alpha: 1.0)

view.addSubview(blueView)

// Constraints
NSLayoutConstraint.activate([
    NSLayoutConstraint(item: redView, attribute: .top, relatedBy: .equal,
        toItem: topLayoutGuide, attribute: .bottom,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: redView, attribute: .bottom, relatedBy: .equal,
        toItem: bottomLayoutGuide, attribute: .top,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: redView, attribute: .leading, relatedBy: .equal,
        toItem: view, attribute: .leadingMargin,
        multiplier: 1.0, constant: 0.0),

    NSLayoutConstraint(item: blueView, attribute: .top, relatedBy: .equal,
        toItem: topLayoutGuide, attribute: .bottom,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: blueView, attribute: .bottom, relatedBy: .equal,
        toItem: bottomLayoutGuide, attribute: .top,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: blueView, attribute: .leading, relatedBy: .equal,
        toItem: redView, attribute: .trailing,
        multiplier: 1.0, constant: 16.0),
    NSLayoutConstraint(item: blueView, attribute: .trailing, relatedBy: .equal,
        toItem: view, attribute: .trailingMargin,
        multiplier: 1.0, constant: 0.0),

    NSLayoutConstraint(item: redView, attribute: .width, relatedBy: .equal,
        toItem: blueView, attribute: .width,
        multiplier: 1.0, constant: 0.0),
])

Because the constraints are established in code, it is easy to identify changes between revisions. Unfortunately, managing constraints programmatically is not particularly convenient. This simple layout required the definition of eight individual constraints. More complex layouts could quickly become untenable.

Stack Views

The UIStackView class, introduced in iOS 9, provides an alternative to managing constraints directly. Stack views automatically arrange their subviews in a vertical or horizontal line, and can be nested to create sophisticated layouts.

For example, the following code uses a stack view to produce results identical to the first two examples:

let view = UIStackView()

view.isLayoutMarginsRelativeArrangement = true
view.spacing = 16

// Red view
let redView = UIView()

redView.backgroundColor = UIColor(red: 202.0 / 255.0, green: 53.0 / 255.0, blue: 56.0 / 255.0, alpha: 1.0)

view.addArrangedSubview(redView)

// Blue view
let blueView = UIView()

blueView.backgroundColor = UIColor(red: 59.0 / 255.0, green: 85.0 / 255.0, blue: 162.0 / 255.0, alpha: 1.0)

view.addArrangedSubview(blueView)

// Width constraint
NSLayoutConstraint.activate([
    NSLayoutConstraint(item: redView, attribute: .width, relatedBy: .equal,
        toItem: blueView, attribute: .width,
        multiplier: 1.0, constant: 0.0),
])

While it is arguably more readable than the previous version, this example is still somewhat verbose. It also still requires the explicit creation of a layout constraint to manage the width relationship, which is not ideal.

Introducing MarkupKit

MarkupKit is an open-source framework for simplifying development of native iOS and tvOS applications. Among other things, it provides a collection of UIView subclasses whose sole responsibility is managing the size and position of their respective subviews:

  • LMRowView – arranges subviews in a horizontal line
  • LMColumnView – arranges subviews in a vertical line
  • LMAnchorView – optionally anchors subviews to one or more edges

These classes use layout constraints internally, allowing developers to easily take advantage of auto layout while eliminating the need to manage constraints directly.

For example, the following code uses an instance of LMRowView to replicate the results produced by the previous examples. The weight property is used to ensure that the views are the same width. This property, which is added to UIView by MarkupKit, specifies the amount of excess space the view would like to be given within its parent view, relative to all other weights. Since both views are assigned a weight of 1, they will each be given 1 / (1 + 1), or one-half, of the available space:

let view = LMRowView()

view.spacing = 16

// Red view
let redView = UIView()

redView.backgroundColor = LMViewBuilder.colorValue("#CA3538")
redView.weight = 1.0

view.addArrangedSubview(redView)

// Blue view
let blueView = UIView()

blueView.backgroundColor = LMViewBuilder.colorValue("#3B55A2")
blueView.weight = 1.0

view.addArrangedSubview(blueView)

Like stack views, layout views are easy to work with programmatically. However, unlike stack views, no manual constraint is manipulation required; MarkupKit uses the weight values to automatically establish the width relationship.

Additionally, the colorValue(_:) method of MarkupKit’s LMViewBuilder class is used to simplify color assignment. The logic is still a bit verbose though, and could become difficult to manage as view complexity increases.

Markup

MarkupKit’s namesake feature is its support for declarative view construction. Using markup, the view hiearchy created in the previous example can be represented entirely as follows:

<LMRowView spacing="16">
    <UIView backgroundColor="#ca3538" weight="1"/>
    <UIView backgroundColor="#3b55a2" weight="1"/>
</LMRowView>

The markup is loaded using the view(withName:owner:root:) method of LMViewBuilder. This method is similar to the loadNibNamed(_:owner:options:) method of the NSBundle class, and returns the root element of the view hiearchy declared in the document:

view = LMViewBuilder.view(withName: "ViewController", owner: self, root: nil)

Unlike all of the preceding examples, this version is extremely concise. It is also much more readable: the element hierarchy declared in the document parallels the resulting view hiearchy, making it easy to understand the relationships between views.

For example, the periodic table shown below was constructed using a combination of MarkupKit’s layout views and UILabel instances:

Creating this view in Interface Builder would be an arduous task. Creating it programmatically would be even more difficult. However, in markup it is almost trivial. The complete source code for this example can be found here.

Summary

This article provided an overview of how layout constraints are typically managed in an iOS application and introduced MarkupKit, an open-source framework that can significantly simplify the task of working with auto layout in iOS.

For more information and additional examples, see the MarkupKit README.