How an App Launches

Your app’s root view controller is the link between your app’s UIWindow and the interface that it contains. The initial view controller is instantiated, and that instance is assigned to the window’s rootViewController property. It is now the app’s root view controller, and its view henceforth occupies the entirety of the window. The root view controller itself will be the top of the view controller hierarchy, of which I’ll have much more to say in Chapter 6.

But how does your app, at launch time, come to have a main window in the first place, and how does that window come to be populated and displayed? If your app uses a main storyboard, it all happens automatically. Your app consists, ultimately, of a single call to the UIApplicationMain function. (Unlike an Objective-C project, a typical Swift project doesn’t make this call explicitly, in code; it is called for you, behind the scenes.) Here are some of the first things this call does:

1. UIApplicationMain instantiates UIApplication and retains this instance, to serve as the shared application instance, which your code can later refer to as UIApplication.shared. It then instantiates the app delegate class. (It knows which class is the app delegate because it is marked @UIApplicationMain.) It retains the app delegate instance, thus ensuring that it will persist for the lifetime of the app, and assigns it as the application instance’s delegate.

2. UIApplicationMain looks to see whether your app uses a main storyboard. It knows whether you are using a main storyboard, and what its name is, by looking at the Info.plist key “Main storyboard file base name” (UIMainStoryboardFile). You can easily edit this key, if necessary, by editing the target and, in the General pane, changing the Main Interface value in the Deployment Info section. By default, a new iOS project has a main storyboard called Main.storyboard, and the Main Interface value is Main.

3. If your app uses a main storyboard, UIApplicationMain instantiates UIWindow and assigns the window instance to the app delegate’s window property, which retains it, thus ensuring that the window will persist for the lifetime of the app. It also sizes the window so that it will initially fill the device’s screen. This is ensured by setting the window’s frame to the screen’s bounds. (I’ll explain later in this chapter what “frame” and “bounds” are.)

4. If your app uses a main storyboard, UIApplicationMain instantiates that storyboard’s initial view controller. (I’ll talk more about that in Chapter 6.) It then assigns this view controller instance to the window’s rootViewController property, which retains it. When a view controller becomes the main window’s rootViewController, its main view (its view) is made the one and only immediate subview of your main window — the main window’s root view. All other views in your main window will be subviews of the root view.

   Thus, the root view is the highest object in the view hierarchy that the user will usually see. There might be just a chance, under certain circumstances, that the user will catch a glimpse of the window, behind the root view; for this reason, you may want to assign the main window a reasonable backgroundColor. In general you’ll have no reason to change anything else about the window itself.

5. UIApplicationMain calls the app delegate’s application(_:didFinishLaunchingWithOptions:).

6. Your app’s interface is not visible until the window, which contains it, is made the app’s key window. Therefore, if your app uses a main storyboard, UIApplicationMain calls the window’s instance method makeKeyAndVisible.

It is also possible to write an app that lacks a main storyboard, or that has a main storyboard but, under certain circumstances, effectively ignores it at launch time by overriding some or all of the automatic UIApplicationMain behavior. Such an app simply does in code — typically, in application(_:didFinishLaunchingWithOptions:) — everything that UIApplicationMain does automatically if the app has a main storyboard (see Appendix B for a full implementation):

1. Instantiate UIWindow and assign it as the app delegate’s window property. With a little clever coding, we can avoid doing this if UIApplicationMain did it already:

   self.window = self.window ?? UIWindow()

2. Instantiate a view controller, configure it as needed, and assign it as the window’s rootViewController property. If UIApplicationMain has already assigned a root view controller, this view controller replaces it.

3. Call makeKeyAndVisible on the window, to show it. This does no harm even if there is a main storyboard, as UIApplicationMain will not subsequently repeat this call.

An app with no main storyboard is not common nowadays, but a hybrid app that sometimes overrides some of the automatic UIApplicationMain behavior is. A frequent scenario is that our app has something like a login or registration screen that appears at launch if the user has not logged in, but doesn’t appear on subsequent launches once the user has logged in.

To enforce this, we implement step 2 only, leaving UIApplicationMain to perform the other steps. In step 2, we look in UserDefaults (or some similar storage) to see if the user has logged in:

• If so, we skip past the storyboard’s initial view controller to the next view controller in the storyboard.

• If not, we do nothing, leaving UIApplicationMain to instantiate the storyboard’s initial view controller and make it the window’s rootViewController.

Here’s the general idea (this code will make much more sense to you after reading Chapter 6):

func application(_ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions:
    [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        if let rvc = self.window?.rootViewController {
            let ud = UserDefaults.standard
            if ud.string(forKey: "username") != nil { // user has logged in
                let vc = rvc.storyboard!.instantiateViewController(
                    withIdentifier: "userHasLoggedIn")
                self.window!.rootViewController = vc
            }
        }
        return true
}

Subclassing UIWindow

A possible variation is to subclass UIWindow. That is uncommon nowadays, though it can be a way of intervening in hit-testing (Chapter 5) or the target–action mechanism (Chapter 12). To use an instance of your UIWindow subclass as your app’s main window, you would need to prevent UIApplicationMain from assigning a plain vanilla UIWindow instance as your app delegate’s window. The rule is that, after UIApplicationMain has instantiated the app delegate, it asks the app delegate instance for the value of its window property:

• If that value is nil, UIApplicationMain instantiates UIWindow and assigns that instance to the app delegate’s window property.

• If that value is not nil, UIApplicationMain leaves it alone.

Therefore, to make your app’s main window be an instance of your UIWindow subclass, all you have to do is assign that instance as the default value for the app delegate’s window property:

@UIApplicationMain
class AppDelegate : UIResponder, UIApplicationDelegate {
    var window : UIWindow? = MyWindow()
    // ...
}

Referring to the Window

Once the app is running, there are various ways for your code to refer to the window:

• If a UIView is in the interface, it automatically has a reference to the window through its own window property. Your code will probably be running in a view controller with a main view, so self.view.window is usually the best way to refer to the window.

  You can also use a UIView’s window property as a way of asking whether it is ultimately embedded in the window; if it isn’t, its window property is nil. A UIView whose window property is nil cannot be visible to the user.

• The app delegate instance maintains a reference to the window through its window property. You can get a reference to the app delegate from elsewhere through the shared application’s delegate property, and through it you can refer to the window:

  let w = UIApplication.shared.delegate!.window!!

  If you prefer something less generic (and requiring less extreme unwrapping of Optionals), cast the delegate explicitly to your app delegate class:

  let w = (UIApplication.shared.delegate as! AppDelegate).window!

• The shared application maintains a reference to the window through its keyWindow property:

  let w = UIApplication.shared.keyWindow!

  That reference, however, is slightly volatile, because the system can create temporary windows and interpose them as the application’s key window.

Window Coordinates and Screen Coordinates

The device screen has no frame, but it has bounds. The main window has no superview, but its frame is set with respect to the screen’s bounds:

let w = UIWindow(frame: UIScreen.main.bounds)

You can omit the frame parameter, as a shortcut; the effect is exactly the same:

let w = UIWindow()

The window thus starts out life filling the screen, and generally continues to fill the screen, and so, for the most part, window coordinates are screen coordinates. (I’ll discuss a possible exception in Chapter 9.)

In iOS 7 and before, the screen’s coordinates were invariant. The transform property lay at the heart of an iOS app’s ability to rotate its interface: the window’s frame and bounds were locked to the screen, and an app’s interface rotated to compensate for a change in device orientation by applying a rotation transform to the root view, so that its origin moved to what the user now saw as the top left of the view.

But iOS 8 introduced a major change: when the app rotates to compensate for the rotation of the device, the screen (and with it, the window) is what rotates. None of the views in the story — neither the window, nor the root view, nor any of its subviews — receives a rotation transform when the app’s interface rotates. Instead, there is a transposition of the dimensions of the screen’s bounds (and a corresponding transposition of the dimensions of the window’s bounds and its root view’s bounds): in portrait orientation, the size is taller than wide, but in landscape orientation, the size is wider than tall.

Therefore, there are actually two sets of screen coordinates. Each is reported through a UICoordinateSpace, a protocol (also adopted by UIView) that provides a bounds property:

UIScreen’s coordinateSpace property

This coordinate space rotates. Its bounds height and width are transposed when the app rotates to compensate for a change in the orientation of the device; its origin is at the top left of the app.

UIScreen’s fixedCoordinateSpace property

This coordinate space is invariant. Its bounds origin stays at the top left of the physical device, remaining always in the same relationship to the device’s hardware buttons regardless of how the device itself is held.

To help you convert between coordinate spaces, UICoordinateSpace provides methods parallel to the coordinate-conversion methods I listed in the previous section:

• convert(_:from:)

• convert(_:to:)

The first parameter is either a CGPoint or a CGRect. The second parameter is a UICoordinateSpace, which might be a UIView or the UIScreen; so is the recipient.

So, for example, suppose we have a UIView v in our interface, and we wish to learn its position in fixed device coordinates. We could do it like this:

let screen = UIScreen.main.fixedCoordinateSpace
let r = v.superview!.convert(v.frame, to: screen)

Imagine that we have a subview of our main view, at the exact top left corner of the main view. When the device and the app are in portrait orientation, the subview’s top left is at (0.0,0.0) in window coordinates and in screen fixedCoordinateSpace coordinates. When the device is rotated left into landscape orientation, and if the app rotates to compensate, the window rotates, so the subview is still at the top left from the user’s point of view, and is still at the top left in window coordinates. But in screen fixedCoordinateSpace coordinates, the subview’s top left x-coordinate will have a large positive value, because the origin is now at the lower left and its x grows positively upward.

Occasions where you need such information, however, will be rare. Indeed, my experience is that it is rare even to worry about window coordinates. All of your app’s visible action takes place within your root view controller’s main view, and the bounds of that view, which are adjusted for you automatically when the app rotates to compensate for a change in device orientation, are probably the highest coordinate system that will interest you.

Trait Collections and Size Classes

The salient fact about app rotation and the like is not the rotation per se but the change in the app’s dimensional proportions. Consider, for example, a subview of the root view, located at the bottom right of the screen when the device is in portrait orientation. If the root view’s bounds width and bounds height are effectively transposed, then that poor old subview will now be outside the bounds height, and therefore off the screen — unless your app responds in some way to this change to reposition it. (Such a response is called layout, a subject that will occupy most of the rest of this chapter.)

The dimensional characteristics of the environment are embodied in a set of size classes which are vended by a view’s traitCollection property. Every view in the interface, from the window on down, as well as any view controller whose view is part of the interface, inherits from the environment the value of its traitCollection property, which it has by virtue of implementing the UITraitEnvironment protocol.

The traitCollection is a UITraitCollection, a value class. UITraitCollection was introduced in iOS 8; it has grown since then, and is now freighted with a considerable number of properties describing the environment. In addition to its displayScale (the screen resolution) and userInterfaceIdiom (the general device type, iPhone or iPad), a trait collection now also reports such things as the device’s force touch capability and display gamut. But just two properties in particular concern us with regard to views in general:

horizontalSizeClass

verticalSizeClass

A UIUserInterfaceSizeClass value, either .regular or .compact.

These are the size classes. In combination, they have the following meanings when, as will usually be the case, your app occupies the entire screen:

Both the horizontal and vertical size classes are .regular

We’re running on an iPad.

The horizontal size class is .compact and the vertical size class is .regular

We’re running on an iPhone with the app in portrait orientation.

The horizontal size class is .regular and the vertical size class is .compact

We’re running on an iPhone 6/7/8 Plus, iPhone XR, or iPhone XS Max (the “big” iPhones) with the app in landscape orientation.

Both the horizontal and vertical size classes are .compact

We’re running on an iPhone (other than a big iPhone) with the app in landscape orientation.

(I’ll explain in Chapter 9 how your app might not occupy the entire screen due to iPad multitasking.)

The size class trait collection properties can change while the app is running. In particular, the size classes on an iPhone reflect the orientation of the app — which can change as the app rotates in response to a change in the orientation of the device. Therefore, both at app launch time and if the trait collection changes while the app is running, the traitCollectionDidChange(_:) message is propagated down the hierarchy of UITraitEnvironments (meaning primarily, for our purposes, view controllers and views); the old trait collection (if any) is provided as the parameter, and the new trait collection can be retrieved as self.traitCollection.

It is possible to construct a trait collection yourself. (In the next chapter, I’ll give an example of why that might be useful.) Oddly, though, you can’t set any trait collection properties directly; instead, you form a trait collection through an initializer that determines just one property, and if you want to add further property settings, you have to combine trait collections by calling init(traitsFrom:) with an array of trait collections. For example:

let tcdisp = UITraitCollection(displayScale: UIScreen.main.scale)
let tcphone = UITraitCollection(userInterfaceIdiom: .phone)
let tcreg = UITraitCollection(verticalSizeClass: .regular)
let tc1 = UITraitCollection(traitsFrom: [tcdisp, tcphone, tcreg])

The init(traitsFrom:) array works like inheritance: an ordered intersection is performed. If two trait collections are combined, and they both set the same property, the winner is the trait collection that appears later in the array or further down the inheritance hierarchy. If one sets a property and the other doesn’t, the one that sets the property wins. Thus, if you create a trait collection, the value for any unspecified property will be inherited if the trait collection finds itself in the inheritance hierarchy.

To compare trait collections, call containsTraits(in:). This returns true if the value of every specified property of the parameter trait collection matches that of this trait collection.

Autoresizing

Autoresizing is a matter of conceptually assigning a subview “springs and struts.” A spring can stretch; a strut can’t. Springs and struts can be assigned internally or externally, horizontally or vertically. Thus you can specify (using internal springs and struts) whether and how the view can be resized, and (using external springs and struts) whether and how the view can be repositioned. For example:

• Imagine a subview that is centered in its superview and is to stay centered, but is to resize itself as the superview is resized. It would have struts externally and springs internally.

• Imagine a subview that is centered in its superview and is to stay centered, and is not to resize itself as the superview is resized. It would have springs externally and struts internally.

• Imagine an OK button that is to stay in the lower right of its superview. It would have struts internally, struts externally to its right and bottom, and springs externally to its top and left.

• Imagine a text field that is to stay at the top of its superview. It is to widen as the superview widens. It would have struts externally, but a spring to its bottom; internally it would have a vertical strut and a horizontal spring.

In code, a combination of springs and struts is set through a view’s autoresizingMask property, which is a bitmask (UIView.AutoresizingMask) so that you can combine options. The options represent springs; whatever isn’t specified is a strut. The default is the empty set, apparently meaning all struts — but of course it can’t really be all struts, because if the superview is resized, something needs to change, so in reality an empty autoresizingMask is the same as .flexibleRightMargin together with .flexibleBottomMargin.

To demonstrate autoresizing, I’ll start with a view and two subviews, one stretched across the top, the other confined to the lower right (Figure 1-12):

let v1 = UIView(frame:CGRect(100, 111, 132, 194))
v1.backgroundColor = UIColor(red: 1, green: 0.4, blue: 1, alpha: 1)
let v2 = UIView(frame:CGRect(0, 0, 132, 10))
v2.backgroundColor = UIColor(red: 0.5, green: 1, blue: 0, alpha: 1)
let v1b = v1.bounds
let v3 = UIView(frame:CGRect(v1b.width-20, v1b.height-20, 20, 20))
v3.backgroundColor = UIColor(red: 1, green: 0, blue: 0, alpha: 1)
self.view.addSubview(v1)
v1.addSubview(v2)
v1.addSubview(v3)

Figure 1-12. Before autoresizing

To that example, I’ll add code applying springs and struts to the two subviews to make them behave like the text field and the OK button I was hypothesizing earlier:

v2.autoresizingMask = .flexibleWidth
v3.autoresizingMask = [.flexibleTopMargin, .flexibleLeftMargin]

Now I’ll resize the superview, thus bringing autoresizing into play; as you can see (Figure 1-13), the subviews remain pinned in their correct relative positions:

v1.bounds.size.width += 40
v1.bounds.size.height -= 50

Figure 1-13. After autoresizing

If autoresizing isn’t sophisticated enough to achieve what you want, you have two choices:

• Combine it with manual layout in layoutSubviews. Autoresizing happens before layoutSubviews is called, so your layoutSubviews code is free to come marching in and tidy up whatever autoresizing didn’t get quite right.

• Use autolayout. This is actually the same solution, because autolayout is in fact a way of injecting functionality into layoutSubviews. But using autolayout is a lot easier than writing your own layoutSubviews code!

Autolayout and Constraints

Autolayout is an opt-in technology, at the level of each individual view. You can use autoresizing and autolayout in different areas of the same interface — even for different subviews of the same view. One sibling view can use autolayout while another sibling view does not, and a superview can use autolayout while some or all of its subviews do not.

However, autolayout is implemented through the superview chain, so if a view uses autolayout, then automatically so do all its superviews; and if (as will almost certainly be the case) one of those views is the main view of a view controller, that view controller receives autolayout-related events.

But how does a view opt in to using autolayout? Simply by becoming involved with a constraint. Constraints are your way of telling the autolayout engine that you want it to perform layout on this view, as well as how you want the view laid out.

An autolayout constraint, or simply constraint, is an NSLayoutConstraint instance, and describes either the absolute width or height of a view, or else a relationship between an attribute of one view and an attribute of another view. In the latter case, the attributes don’t have to be the same attribute, and the two views don’t have to be siblings (subviews of the same superview) or parent and child (superview and subview) — the only requirement is that they share a common ancestor (a superview somewhere up the view hierarchy).

Here are the chief properties of an NSLayoutConstraint:

firstItem, firstAttribute, secondItem, secondAttribute

The two views and their respective attributes (NSLayoutConstraint.Attribute) involved in this constraint. If the constraint is describing a view’s absolute height or width, the second view will be nil and the second attribute will be .notAnAttribute. Aside from that, the possible attribute values are:

• .width, .height

• .top, .bottom

• .left, .right, .leading, .trailing

• .centerX, .centerY

• .firstBaseline, .lastBaseline

.firstBaseline applies primarily to multiline labels, and is some distance down from the top of the label (Chapter 10); .lastBaseline is some distance up from the bottom of the label.

The meanings of the other attributes are intuitively obvious, except that you might wonder what .leading and .trailing mean: they are the international equivalent of .left and .right, automatically reversing their meaning on systems for which your app is localized and whose language is written right-to-left. The entire interface is automatically reversed on such systems — but that will work properly only if you’ve used .leading and .trailing constraints throughout the interface.

multiplier, constant

These numbers will be applied to the second attribute’s value to determine the first attribute’s value. The multiplier is multiplied by the second attribute’s value; the constant is added to that product. The first attribute is set to the result. (The name constant is a very poor choice, as this value isn’t constant; have the Apple folks never heard the term addend?) Basically, you’re writing an equation a₁ = ma₂ + c, where a₁ and a₂ are the two attributes, and m and c are the multiplier and the constant. Thus, in the degenerate case where the first attribute’s value is to equal the second attribute’s value, the multiplier will be 1 and the constant will be 0. If you’re describing a view’s width or height absolutely, the multiplier will be 1 and the constant will be the width or height value.

relation

How the two attribute values are to be related to one another, as modified by the multiplier and the constant. This is the operator that goes in the spot where I put the equal sign in the equation in the preceding paragraph. Possible values are (NSLayoutConstraint.Relation):

• .equal

• .lessThanOrEqual

• .greaterThanOrEqual

priority

Priority values range from 1000 (required) down to 1, and certain standard behaviors have standard priorities. Constraints can have different priorities, determining the order in which they are applied. Starting in iOS 11, a priority is not a number but a UILayoutPriority struct wrapping the numeric value as its rawValue, initializable with init(rawValue:).

A constraint belongs to a view. A view can have many constraints: a UIView has a constraints property, along with these instance methods:

• addConstraint(_:), addConstraints(_:)

• removeConstraint(_:), removeConstraints(_:)

The question then is which view a given constraint should belong to. The answer is: the view that is closest up the view hierarchy from both views involved in the constraint. If possible, it should be one of those views. Thus, for example, if the constraint dictates a view’s absolute width, it belongs to that view; if it sets the top of a view in relation to the top of its superview, it belongs to that superview; if it aligns the tops of two sibling views, it belongs to their common superview.

However, you’ll probably never call any of those methods! Starting in iOS 8, instead of adding a constraint to a particular view explicitly, you can activate the constraint using the NSLayoutConstraint class method activate(_:), which takes an array of constraints. The activated constraints are added to the correct view automatically, relieving you from having to determine what view that would be. There is also a method deactivate(_:), which removes constraints from their view. Also, a constraint has an isActive property; you can set it to activate or deactivate a single constraint, plus it tells you whether a given constraint is part of the interface at this moment.

NSLayoutConstraint properties are read-only, except for priority, constant, and isActive. If you want to change anything else about an existing constraint, you must remove the constraint and add a new one.

Implicit Autoresizing Constraints

The mechanism whereby individual views can opt in to autolayout can suddenly involve other views in autolayout, even though those other views were not using autolayout previously. Therefore, there needs to be a way, when such a view becomes involved in autolayout, to generate constraints for it — constraints that will determine that view’s position and size identically to how its frame and autoresizingMask were determining them. The autolayout engine takes care of this for you: it reads the view’s frame and autoresizingMask settings and translates them into implicit constraints (of class NSAutoresizingMaskLayoutConstraint). The autolayout engine treats a view in this special way only if it has its translatesAutoresizingMaskIntoConstraints property set to true — which happens to be the default.

To demonstrate, I’ll construct an example in two stages. In the first stage, I add to my interface, in code, a UILabel that doesn’t use autolayout. I’ll decide that this view’s position is to be somewhere near the top right of the screen. To keep it in position near the top right, its autoresizingMask will be [.flexibleLeftMargin, .flexibleBottomMargin]:

let lab1 = UILabel(frame:CGRect(270,20,42,22))
lab1.autoresizingMask = [.flexibleLeftMargin, .flexibleBottomMargin]
lab1.text = "Hello"
self.view.addSubview(lab1)

If we now rotate the device (or Simulator window), and the app rotates to compensate, the label stays correctly positioned near the top right corner by autoresizing.

Now, however, I’ll add a second label that does use autolayout — and in particular, I’ll attach it by a constraint to the first label (the meaning of this code will be made clear in subsequent sections; just accept it for now):

let lab2 = UILabel()
lab2.translatesAutoresizingMaskIntoConstraints = false
lab2.text = "Howdy"
self.view.addSubview(lab2)
NSLayoutConstraint.activate([
    lab2.topAnchor.constraint(
        equalTo: lab1.bottomAnchor, constant: 20),
    lab2.trailingAnchor.constraint(
        equalTo: self.view.trailingAnchor, constant: -20)
])

This causes the first label to be involved in autolayout. Therefore, the first label magically acquires four automatically generated implicit constraints of class NSAutoresizingMaskLayoutConstraint, such as to give the label the same size and position, and the same behavior when its superview is resized, that it had when it was configured by its frame and autoresizingMask:

<NSAutoresizingMaskLayoutConstraint:0x6000002818b0 h=&-- v=--&
    UILabel:0x7f9d3820bf80'Hello'.midX == UIView:0x7f9d383079d0.width-29>
<NSAutoresizingMaskLayoutConstraint:0x60000009fe50 h=&-- v=--&
    UILabel:0x7f9d3820bf80'Hello'.midY == 31>
<NSAutoresizingMaskLayoutConstraint:0x60000009fef0 h=&-- v=--&
    UILabel:0x7f9d3820bf80'Hello'.width == 42>
<NSAutoresizingMaskLayoutConstraint:0x6000002821c0 h=&-- v=--&
    UILabel:0x7f9d3820bf80'Hello'.height == 22>

But within this helpful automatic behavior lurks a trap. Suppose a view has acquired automatically generated implicit constraints, and suppose you then proceed to attach further constraints to this view, explicitly setting its position or size. There will then almost certainly be a conflict between your explicit constraints and the implicit constraints. The solution is to set the view’s translatesAutoresizingMaskIntoConstraints property to false, so that the implicit constraints are not generated, and the view’s only constraints are your explicit constraints.

In a nib with “Use Auto Layout” checked, there is no difficulty in this regard. The nib editor itself will switch a view’s translatesAutoresizingMaskIntoConstraints property to false as soon as you add constraints that would cause a problem. The trouble is most likely to arise when you create a view in code and then position or size that view with constraints, forgetting that you also need to set its translatesAutoresizingMaskIntoConstraints property to false. If that happens, you’ll get a conflict between constraints. (To be honest, I usually do forget, and am reminded only when I do get a conflict between constraints.)

Creating Constraints in Code

We are now ready to write some code that creates constraints! I’ll start by using the NSLayoutConstraint initializer:

• init(item:attribute:relatedBy:toItem:attribute:multiplier:constant:)

This initializer sets every property of the constraint, as I described them a moment ago — except the priority, which defaults to .required (1000) and can be set later if necessary.

I’ll generate the same views and subviews and layout behavior as in Figures 1-12 and 1-13, but using constraints. First, I’ll create the views and add them to the interface. Observe that I don’t bother to assign the subviews v2 and v3 explicit frames as I create them, because constraints will take care of positioning them. Also, I remember (for once) to set their translatesAutoresizingMaskIntoConstraints properties to false, so that they won’t sprout additional implicit NSAutoresizingMaskLayoutConstraints:

let v1 = UIView(frame:CGRect(100, 111, 132, 194))
v1.backgroundColor = UIColor(red: 1, green: 0.4, blue: 1, alpha: 1)
let v2 = UIView()
v2.backgroundColor = UIColor(red: 0.5, green: 1, blue: 0, alpha: 1)
let v3 = UIView()
v3.backgroundColor = UIColor(red: 1, green: 0, blue: 0, alpha: 1)
self.view.addSubview(v1)
v1.addSubview(v2)
v1.addSubview(v3)
v2.translatesAutoresizingMaskIntoConstraints = false
v3.translatesAutoresizingMaskIntoConstraints = false

Now here come the constraints:

v1.addConstraint(
    NSLayoutConstraint(item: v2,
        attribute: .leading,
        relatedBy: .equal,
        toItem: v1,
        attribute: .leading,
        multiplier: 1, constant: 0)
)
v1.addConstraint(
    NSLayoutConstraint(item: v2,
        attribute: .trailing,
        relatedBy: .equal,
        toItem: v1,
        attribute: .trailing,
        multiplier: 1, constant: 0)
)
v1.addConstraint(
    NSLayoutConstraint(item: v2,
        attribute: .top,
        relatedBy: .equal,
        toItem: v1,
        attribute: .top,
        multiplier: 1, constant: 0)
)
v2.addConstraint(
    NSLayoutConstraint(item: v2,
        attribute: .height,
        relatedBy: .equal,
        toItem: nil,
        attribute: .notAnAttribute,
        multiplier: 1, constant: 10)
)
v3.addConstraint(
    NSLayoutConstraint(item: v3,
        attribute: .width,
        relatedBy: .equal,
        toItem: nil,
        attribute: .notAnAttribute,
        multiplier: 1, constant: 20)
)
v3.addConstraint(
    NSLayoutConstraint(item: v3,
        attribute: .height,
        relatedBy: .equal,
        toItem: nil,
        attribute: .notAnAttribute,
        multiplier: 1, constant: 20)
)
v1.addConstraint(
    NSLayoutConstraint(item: v3,
        attribute: .trailing,
        relatedBy: .equal,
        toItem: v1,
        attribute: .trailing,
        multiplier: 1, constant: 0)
)
v1.addConstraint(
    NSLayoutConstraint(item: v3,
        attribute: .bottom,
        relatedBy: .equal,
        toItem: v1,
        attribute: .bottom,
        multiplier: 1, constant: 0)
)

Now, I know what you’re thinking. You’re thinking: “What are you, nuts? That is a boatload of code!” (Except that you probably used another four-letter word instead of “boat.”) But that’s something of an illusion. I’d argue that what we’re doing here is actually simpler than the code with which we created Figure 1-12 using explicit frames and autoresizing.

After all, we merely create eight constraints in eight simple commands. (I’ve broken each command into multiple lines, but that’s mere formatting.) They’re verbose, but they are the same command repeated with different parameters, so creating them is simple. Moreover, our eight constraints determine the position, size, and layout behavior of our two subviews, so we’re getting a lot of bang for our buck.

Even more telling, these constraints are a far clearer expression of what’s supposed to happen than setting a frame and autoresizingMask. The position of our subviews is described once and for all, both as they will initially appear and as they will appear if their superview is resized. And we don’t have to use arbitrary math. Recall what we had to say before:

let v1b = v1.bounds
let v3 = UIView(frame:CGRect(v1b.width-20, v1b.height-20, 20, 20))

That business of subtracting the view’s height and width from its superview’s bounds height and width in order to position the view is confusing and error-prone. With constraints, we can speak the truth directly; our constraints say, plainly and simply, “v3 is 20 points wide and 20 points high and flush with the bottom-right corner of v1.”

In addition, constraints can express things that autoresizing can’t. For example, instead of applying an absolute height to v2, we could require that its height be exactly one-tenth of v1’s height, regardless of how v1 is resized. To do that without autolayout, you’d have to implement layoutSubviews and enforce it manually, in code.

NSLayoutConstraint.activate([
    v2.leadingAnchor.constraint(equalTo:v1.leadingAnchor),
    v2.trailingAnchor.constraint(equalTo:v1.trailingAnchor),
    v2.topAnchor.constraint(equalTo:v1.topAnchor),
    v2.heightAnchor.constraint(equalToConstant:10),
    v3.widthAnchor.constraint(equalToConstant:20),
    v3.heightAnchor.constraint(equalToConstant:20),
    v3.trailingAnchor.constraint(equalTo:v1.trailingAnchor),
    v3.bottomAnchor.constraint(equalTo:v1.bottomAnchor)
])

"V:|[v2(10)]"

let d = ["v2":v2,"v3":v3]
NSLayoutConstraint.activate([
    NSLayoutConstraint.constraints(withVisualFormat:
        "H:|[v2]|", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "V:|[v2(10)]", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "H:[v3(20)]|", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "V:[v3(20)]|", metrics: nil, views: d)
].flatMap{$0})

Constraints as Objects

The examples so far have involved creating constraints and adding them directly to the interface — and then forgetting about them. But it is frequently useful to form constraints and keep them on hand for future use, typically in a property. A common use case is where you intend, at some future time, to change the interface in some radical way, such as by inserting or removing a view; you’ll probably find it convenient to keep multiple sets of constraints on hand, each set being appropriate to a particular configuration of the interface. It is then trivial to swap constraints out of and into the interface along with views that they affect.

In this example, we create within our main view (self.view) three views, v1, v2, and v3, which are red, yellow, and blue rectangles respectively. For some reason, we will later want to remove the yellow view (v2) dynamically as the app runs, moving the blue view to where the yellow view was; and then, still later, we will want to insert the yellow view once again (Figure 1-14). So we have two alternating view configurations.

To prepare for this, we create two sets of constraints, one describing the positions of v1, v2, and v3 when all three are present, the other describing the positions of v1 and v3 when v2 is absent. For purposes of maintaining these sets of constraints, we have already prepared two properties, constraintsWith and constraintsWithout, initialized as empty arrays of NSLayoutConstraint. We will also need a strong reference to v2, so that it doesn’t vanish when we remove it from the interface:

var v2 : UIView!
var constraintsWith = [NSLayoutConstraint]()
var constraintsWithout = [NSLayoutConstraint]()

Here’s the code for creating the views:

let v1 = UIView()
v1.backgroundColor = .red
v1.translatesAutoresizingMaskIntoConstraints = false
let v2 = UIView()
v2.backgroundColor = .yellow
v2.translatesAutoresizingMaskIntoConstraints = false
let v3 = UIView()
v3.backgroundColor = .blue
v3.translatesAutoresizingMaskIntoConstraints = false
self.view.addSubview(v1)
self.view.addSubview(v2)
self.view.addSubview(v3)
self.v2 = v2 // retain

Now we create the constraints. In what follows, c1, c3, and c4 are in common to both situations (v2 is present or v2 is absent), so we simply activate them once and for all. The remaining constraints we store in two groups, one for each of the two situations:

// construct constraints
let c1 = NSLayoutConstraint.constraints(withVisualFormat:
    "H:|-(20)-[v(100)]", metrics: nil, views: ["v":v1])
let c2 = NSLayoutConstraint.constraints(withVisualFormat:
    "H:|-(20)-[v(100)]", metrics: nil, views: ["v":v2])
let c3 = NSLayoutConstraint.constraints(withVisualFormat:
    "H:|-(20)-[v(100)]", metrics: nil, views: ["v":v3])
let c4 = NSLayoutConstraint.constraints(withVisualFormat:
    "V:|-(100)-[v(20)]", metrics: nil, views: ["v":v1])
let c5with = NSLayoutConstraint.constraints(withVisualFormat:
    "V:[v1]-(20)-[v2(20)]-(20)-[v3(20)]", metrics: nil,
    views: ["v1":v1, "v2":v2, "v3":v3])
let c5without = NSLayoutConstraint.constraints(withVisualFormat:
    "V:[v1]-(20)-[v3(20)]", metrics: nil, views: ["v1":v1, "v3":v3])
// apply common constraints
NSLayoutConstraint.activate([c1, c3, c4].flatMap{$0})
// first set of constraints (for when v2 is present)
self.constraintsWith.append(contentsOf:c2)
self.constraintsWith.append(contentsOf:c5with)
// second set of constraints (for when v2 is absent)
self.constraintsWithout.append(contentsOf:c5without)

Now we’re ready to start alternating between constraintsWith and constraintsWithout. We start with v2 present, so it is constraintsWith that we initially make active:

// apply first set
NSLayoutConstraint.activate(self.constraintsWith)

Figure 1-14. Alternate sets of views and constraints

All that preparation may seem extraordinarily elaborate, but the result is that when the time comes to swap v2 out of or into the interface, it’s trivial to swap the appropriate constraints at the same time:

if self.v2.superview != nil {
    self.v2.removeFromSuperview()
    NSLayoutConstraint.deactivate(self.constraintsWith)
    NSLayoutConstraint.activate(self.constraintsWithout)
} else {
    self.view.addSubview(v2)
    NSLayoutConstraint.deactivate(self.constraintsWithout)
    NSLayoutConstraint.activate(self.constraintsWith)
}

Margins and Guides

So far, I’ve been assuming that the anchor points of your constraints represent the literal edges and centers of views. Sometimes, however, you want a view to vend a set of secondary edges, with respect to which other views can be positioned. For example, you might want subviews to keep a minimum distance from the edge of their superview, and the superview should be able to dictate what that minimum distance is.

This notion of secondary edges is expressed in two different ways:

Edge insets

A view vends secondary edges as a UIEdgeInsets, a struct consisting of four floats representing inset values starting at the top and proceeding counterclockwise — top, left, bottom, right. This is useful when you need to interface with the secondary edges as numeric values — to set them, for example, or to perform manual layout.

Layout guides

The UILayoutGuide class represents secondary edges as a kind of pseudoview. It has a frame (its layoutFrame) with respect to the view that vends it, but its important properties are its anchors, which are the same as for a view. This, obviously, is useful for autolayout.

let arr = NSLayoutConstraint.constraints(withVisualFormat:
    "V:|-0-[v]", metrics: nil, views: ["v":v])

let c = v1.topAnchor.constraint(equalTo: v.safeAreaLayoutGuide.topAnchor)

let c = v.leadingAnchor.constraint(equalTo:
    self.view.layoutMarginsGuide.leadingAnchor)

let arr = NSLayoutConstraint.constraints(withVisualFormat:
    "H:|-[v]", metrics: nil, views: ["v":v])

Custom layout guides

You can add your own custom UILayoutGuide objects to a view, for whatever purpose you like. They constitute a view’s layoutGuides array, and are managed by calling addLayoutGuide(_:) or removeLayoutGuide(_:). Each custom layout guide object must be configured entirely using constraints.

Why would you want to do that? Well, you can constrain a view to a UILayoutGuide, by means of its anchors. Thus, since a UILayoutGuide is configured by constraints, and since other views can be constrained to it, it can participate in layout exactly as if it were a subview — but it is not a subview, and therefore it avoids all the overhead and complexity that a UIView would have.

For example, consider the question of how to distribute views equally within their superview. This is easy to arrange initially, but it is not obvious how to design evenly spaced views that will remain evenly spaced when their superview is resized. The problem is that constraints describe relationships between views, not between constraints; there is no way to constrain the spacing constraints between views to remain equal to one another automatically as the superview is resized.

You can, on the other hand, constrain the heights or widths of views to remain equal to one another. The traditional solution, therefore, is to resort to spacer views with their isHidden set to true. But spacer views are views; hidden or not, they add overhead with respect to drawing, memory, touch detection, and more. Custom UILayoutGuides solve the problem; they can serve the same purpose as spacer views, but they are not views.

I’ll demonstrate. Suppose I have four views that are to remain equally distributed vertically. I constrain their left and right edges, their heights, and the top of the first view and the bottom of the last view. This leaves open the question of how we will determine the vertical position of the two middle views; they must move in such a way that they are always equidistant from their vertical neighbors (Figure 1-15).

Figure 1-15. Equal distribution

To solve the problem, I introduce three UILayoutGuide objects between my real views. A custom UILayoutGuide object is added to a UIView, so I’ll add mine to the superview of my four real views:

let guides = [UILayoutGuide(), UILayoutGuide(), UILayoutGuide()]
for guide in guides {
    self.view.addLayoutGuide(guide)
}

I then involve my three layout guides in the layout. Remember, they must be configured entirely using constraints (the three layout guides are referenced through my guides array, and the four views are referenced through another array, views):

NSLayoutConstraint.activate([
    // guide left is arbitrary, let's say superview margin 
    guides[0].leadingAnchor.constraint(equalTo:self.view.leadingAnchor),
    guides[1].leadingAnchor.constraint(equalTo:self.view.leadingAnchor),
    guides[2].leadingAnchor.constraint(equalTo:self.view.leadingAnchor),
    // guide widths are arbitrary, let's say 10
    guides[0].widthAnchor.constraint(equalToConstant:10),
    guides[1].widthAnchor.constraint(equalToConstant:10),
    guides[2].widthAnchor.constraint(equalToConstant:10),
    // bottom of each view is top of following guide 
    views[0].bottomAnchor.constraint(equalTo:guides[0].topAnchor),
    views[1].bottomAnchor.constraint(equalTo:guides[1].topAnchor),
    views[2].bottomAnchor.constraint(equalTo:guides[2].topAnchor),
    // top of each view is bottom of preceding guide
    views[1].topAnchor.constraint(equalTo:guides[0].bottomAnchor),
    views[2].topAnchor.constraint(equalTo:guides[1].bottomAnchor),
    views[3].topAnchor.constraint(equalTo:guides[2].bottomAnchor),
    // guide heights are equal! 
    guides[1].heightAnchor.constraint(equalTo:guides[0].heightAnchor),
    guides[2].heightAnchor.constraint(equalTo:guides[0].heightAnchor),
])

I constrain the leading edges of the layout guides (arbitrarily, to the leading edge of their superview) and their widths (arbitrarily).

I constrain each layout guide to the bottom of the view above it and the top of the view below it.

Finally, our whole purpose is to distribute our views equally, so the heights of our layout guides must be equal to one another.

(In that code, I clearly could — and should — generate each group of constraints as a loop, thus making this approach suitable for any number of distributed views; but I have deliberately unrolled those loops for the sake of the example.)

In real life, however, you are unlikely to use this technique directly, because you will use a UIStackView instead, and let the UIStackView generate all of that code for you — as I will explain a little later.

Intrinsic Content Size and Alignment Rects

Some built-in interface objects, when using autolayout, have an inherent size in one or both dimensions. For example:

• A UIButton, by default, has a standard height, and its width is determined by its title.

• A UIImageView, by default, adopts the size of the image it is displaying.

• A UILabel, by default, if it consists of multiple lines and if its width is constrained, adopts a height sufficient to display all of its text.

This inherent size is the object’s intrinsic content size. The intrinsic content size is used to generate constraints implicitly (of class NSContentSizeLayoutConstraint).

A change in the characteristics or content of a built-in interface object — a button’s title, an image view’s image, a label’s text or font, and so forth — may thus cause its intrinsic content size to change. This, in turn, may alter your layout. You will want to configure your autolayout constraints so that your interface responds gracefully to such changes.

You do not have to supply explicit constraints configuring a dimension of a view whose intrinsic content size configures that dimension. But you might! And when you do, the tendency of an interface object to size itself to its intrinsic content size must not be allowed to conflict with its obedience to your explicit constraints. Therefore, the constraints generated from a view’s intrinsic content size have a lowered priority, and come into force only if no constraint of a higher priority prevents them. The following methods allow you to access these priorities (the parameter is an NSLayoutConstraint.Axis, either .horizontal or .vertical):

contentHuggingPriority(for:)

A view’s resistance to growing larger than its intrinsic size in this dimension. In effect, there is an inequality constraint saying that the view’s size in this dimension should be less than or equal to its intrinsic size. The default priority is usually .defaultLow (250), though some interface classes will default to a higher value if initialized in a nib.

contentCompressionResistancePriority(for:)

A view’s resistance to shrinking smaller than its intrinsic size in this dimension. In effect, there is an inequality constraint saying that the view’s size in this dimension should be greater than or equal to its intrinsic size. The default priority is usually .defaultHigh (750).

Those methods are getters; there are corresponding setters, and situations exist where you would need to change the priorities. For example, here are visual formats configuring two horizontally adjacent labels (lab1 and lab2) to be pinned to the superview and to one another:

"V:|-20-[lab1]"
"V:|-20-[lab2]"
"H:|-20-[lab1]"
"H:[lab2]-20-|"
"H:[lab1(>=100)]-(>=20)-[lab2(>=100)]"

The inequalities ensure that as the superview becomes narrower or the text of the labels becomes longer, a reasonable amount of text will remain visible in both labels. At the same time, one label will be squeezed down to 100 points width, while the other label will be allowed to grow to fill the remaining horizontal space. The question is: which label is which? You need to answer that question. To do so, it suffices to raise the compression resistance priority of one of the labels by a single point above that of the other (see Appendix B for an extension allowing a number to be added to a UILayoutPriority):

let p = lab2.contentCompressionResistancePriority(for: .horizontal)
lab1.setContentCompressionResistancePriority(p+1, for: .horizontal)

You can supply an intrinsic size in your own custom UIView subclass by overriding intrinsicContentSize. Obviously you should do this only if your view’s size somehow depends on its contents. If you need the runtime to ask for your intrinsicContentSize again, because the contents have changed and the view needs to be laid out afresh, it’s up to you to call your view’s invalidateIntrinsicContentSize method.

Another question with which your custom UIView subclass might be concerned is what it should mean for another view to be aligned with it. It might mean aligned with your view’s frame edges, but then again it might not. A possible example is a view that draws, internally, a rectangle with a shadow; you probably want to align things with that drawn rectangle, not with the outside of the shadow. To determine this, you can override your view’s alignmentRectInsets property (or, more elaborately, its alignmentRect(forFrame:) and frame(forAlignmentRect:) methods).

By the same token, you may want to be able to align your custom UIView with another view by their baselines. The assumption here is that your view has a subview containing text that itself has a baseline. Your custom view will return that subview in its implementation of forFirstBaselineLayout or forLastBaselineLayout.

Stack Views

A stack view (UIStackView) is a view whose primary task is to generate constraints for some or all of its subviews. These are its arranged subviews. In particular, a stack view solves the problem of providing constraints when subviews are to be configured linearly in a horizontal row or a vertical column (possibly obviating the need to use the visual format language to do the same thing). In practice, it turns out that many layouts can be expressed as an arrangement, possibly nested, of simple rows and columns of subviews. Thus, you are likely to resort to stack views to make your layout easier to construct and maintain.

You can supply a stack view with arranged subviews by calling its initializer init(arrangedSubviews:). The arranged subviews become the stack view’s arrangedSubviews read-only property. You can also manage the arranged subviews with these methods:

• addArrangedSubview(_:)

• insertArrangedSubview(_:at:)

• removeArrangedSubview(_:)

The arrangedSubviews array is different from, but is a subset of, the stack view’s subviews. It’s fine for the stack view to have subviews that are not arranged (and which you’ll have to provide with constraints yourself); on the other hand, if you set a view as an arranged subview and it is not already a subview, the stack view will adopt it as a subview at that moment.

The order of the arrangedSubviews is independent of the order of the subviews; the subviews order, you remember, determines the order in which the subviews are drawn, but the arrangedSubviews order determines how the stack view will position those subviews.

Using its properties, you configure the stack view to tell it how it should arrange its arranged subviews:

axis

Which way should the arranged subviews be arranged? Your choices are (NSLayoutConstraint.Axis):

• .horizontal

• .vertical

alignment

This describes how the arranged subviews should be laid out with respect to the other dimension. Your choices are (UIStackView.Alignment):

• .fill

• .leading (or .top)

• .center

• .trailing (or .bottom)

• .firstBaseline or .lastBaseline (if the axis is .horizontal)

If the axis is .vertical, you can still involve the subviews’ baselines in their spacing by setting the stack view’s isBaselineRelativeArrangement to true.

distribution

How should the arranged subviews be positioned along the axis? This is why you are here! You’re using a stack view in the first place because you want this positioning performed for you. Your choices are (UIStackView.Distribution):

.fill

The arranged subviews can have real size constraints or intrinsic content sizes along the arranged dimension. Using those sizes, the arranged subviews will fill the stack view from end to end. But there must be at least one view without a real size constraint, so that it can be resized to fill the space not taken up by the other views. If more than one view lacks a real size constraint, one must have a lowered content hugging (if stretching) or compression resistance (if squeezing) so that the stack view knows which view to resize.

.fillEqually

No view may have a real size constraint along the arranged dimension. The arranged subviews will be made the same size in the arranged dimension, so as to fill the stack view.

.fillProportionally

All arranged subviews must have an intrinsic content size and no real size constraint along the arranged dimension. The views will then fill the stack view, sized according to the ratio of their intrinsic content sizes.

.equalSpacing

The arranged subviews can have real size constraints or intrinsic content sizes along the arranged dimension. Using those sizes, the arranged subviews will fill the stack view from end to end with equal space between each adjacent pair.

.equalCentering

The arranged subviews can have real size constraints or intrinsic content sizes along the arranged dimension. Using those sizes, the arranged subviews will fill the stack view from end to end with equal distance between the centers of each adjacent pair.

The stack view’s spacing property determines the spacing (or minimum spacing) between all the views. Starting in iOS 11, you can set the spacing for individual views by calling setCustomSpacing(_:after:); if you need to turn individual spacing back off for a view, reverting to the overall spacing property value, set the custom spacing to UIStackView.spacingUseDefault. To impose the spacing that the system would normally impose, set the spacing to UIStackView.spacingUseSystem.

isLayoutMarginsRelativeArrangement

If true, the stack view’s internal layoutMargins are involved in the positioning of its arranged subviews. If false (the default), the stack view’s literal edges are used.

To illustrate, I’ll rewrite the equal distribution code from earlier in this chapter (Figure 1-15). I have four views, with height constraints. I want to distribute them vertically in my main view. This time, I’ll have a stack view do all the work for me:

// give the stack view arranged subviews
let sv = UIStackView(arrangedSubviews: views)
// configure the stack view
sv.axis = .vertical
sv.alignment = .fill
sv.distribution = .equalSpacing
// constrain the stack view
sv.translatesAutoresizingMaskIntoConstraints = false
self.view.addSubview(sv)
let marg = self.view.layoutMarginsGuide
let safe = self.view.safeAreaLayoutGuide
NSLayoutConstraint.activate([
    sv.topAnchor.constraint(equalTo:safe.topAnchor),
    sv.leadingAnchor.constraint(equalTo:marg.leadingAnchor),
    sv.trailingAnchor.constraint(equalTo:marg.trailingAnchor),
    sv.bottomAnchor.constraint(equalTo:self.view.bottomAnchor),
])

Inspecting the resulting constraints, you can see that the stack view is doing for us effectively just what we did earlier (generating UILayoutGuide objects and using them as spacers). But letting the stack view do it is a lot easier!

Another nice feature of UIStackView is that it responds intelligently to changes. For example, having configured things with the preceding code, if we were subsequently to make one of our arranged subviews invisible (by setting its isHidden to true), the stack view would respond by distributing the remaining subviews evenly, as if the hidden subview didn’t exist. Similarly, we can change properties of the stack view itself in real time. Such flexibility can be very useful for making whole areas of your interface come and go and rearrange themselves at will.

Internationalization

Your app’s entire interface and its behavior are reversed when the app runs on a system for which the app is localized and whose language is right-to-left. Wherever you use leading and trailing constraints instead of left and right constraints, or if your constraints are generated by stack views or are constructed using the visual format language, your app’s layout will participate in this reversal more or less automatically.

There may, however, be exceptions. Apple gives the example of a horizontal row of transport controls that mimic the buttons on a CD player: you wouldn’t want the Rewind button and the Fast Forward button to be reversed just because the user’s language reads right-to-left. Therefore, a UIView is endowed with a semanticContentAttribute property stating whether it should be flipped; the default is .unspecified, but a value of .playback or .spatial will prevent flipping, and you can also force an absolute direction with .forceLeftToRight or .forceRightToLeft. This property can also be set in the nib editor (using the Semantic pop-up menu in the Attributes inspector).

Interface directionality is a trait, a trait collection’s .layoutDirection; and a UIView has an effectiveUserInterfaceLayoutDirection property that reports the direction that it will use to lay out its contents, and which you can consult if you are constructing a view’s subviews in code.

Mistakes with Constraints

Creating constraints manually, as I’ve been doing so far in this chapter, is an invitation to make a mistake. Your totality of constraints constitute instructions for view layout, and it is all too easy, as soon as more than one or two views are involved, to generate faulty instructions. You can (and will) make two major kinds of mistake with constraints:

Conflict

You have applied constraints that can’t be satisfied simultaneously. This will be reported in the console (at great length).

Underdetermination (ambiguity)

A view uses autolayout, but you haven’t supplied sufficient information to determine its size and position. This is a far more insidious problem, because nothing bad may seem to happen. If you’re lucky, the view will at least fail to appear, or will appear in an undesirable place, alerting you to the problem.

Only .required constraints (priority 1000) can contribute to a conflict, as the runtime is free to ignore lower-priority constraints that it can’t satisfy. Constraints with different priorities do not conflict with one another. Nonrequired constraints with the same priority can contribute to ambiguity.

Under normal circumstances, layout isn’t performed until your code finishes running — and even then only if needed. Ambiguous layout isn’t ambiguous until layout actually takes place; it is perfectly reasonable to cause an ambiguous layout temporarily, provided you resolve the ambiguity before layoutSubviews is called. On the other hand, a conflicting constraint conflicts the instant it is added. That’s why, when replacing constraints in code, you should deactivate first and activate second, and not the other way around.

Let’s start by generating a conflict. In this example, we return to our small red square in the lower right corner of a big magenta square (Figure 1-12) and append a contradictory constraint:

let d = ["v2":v2,"v3":v3]
NSLayoutConstraint.activate([
    NSLayoutConstraint.constraints(withVisualFormat:
        "H:|[v2]|", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "V:|[v2(10)]", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "H:[v3(20)]|", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "V:[v3(20)]|", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "V:[v3(10)]|", metrics: nil, views: d) // *
].flatMap{$0})

The height of v3 can’t be both 10 and 20. The runtime reports the conflict, and tells you which constraints are causing it:

Unable to simultaneously satisfy constraints. Probably at least one of the
constraints in the following list is one you don't want...

<NSLayoutConstraint:0x60008b6d0 UIView:0x7ff45e803.height == + 20 (active)>,
<NSLayoutConstraint:0x60008bae0 UIView:0x7ff45e803.height == + 10 (active)>

Now we’ll generate an ambiguity. Here, we neglect to give our small red square a height:

let d = ["v2":v2,"v3":v3]
NSLayoutConstraint.activate([
    NSLayoutConstraint.constraints(withVisualFormat:
        "H:|[v2]|", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "V:|[v2(10)]", metrics: nil, views: d),
    NSLayoutConstraint.constraints(withVisualFormat:
        "H:[v3(20)]|", metrics: nil, views: d)
].flatMap{$0})

No console message alerts us to our mistake. Fortunately, however, v3 fails to appear in the interface, so we know something’s wrong. If your views fail to appear, suspect ambiguity. In a less fortunate case, the view might appear, but (if we’re lucky) in the wrong place. In a truly unfortunate case, the view might appear in the right place, but not consistently.

Suspecting ambiguity is one thing; tracking it down and proving it is another. Fortunately, the view debugger will report ambiguity instantly (Figure 1-16). With the app running, choose Debug → View Debugging → Capture View Hierarchy, or click the Debug View Hierarchy button in the debug bar. The exclamation mark in the Debug navigator, at the left, is telling us that this view (which does not appear in the canvas) has ambiguous layout; moreover, the Issue navigator, in the Runtime pane, tells us more explicitly, in words: “Height and vertical position are ambiguous for UIView.”

Figure 1-16. View debugging

Another useful trick is to pause in the debugger and give the following mystical command in the console:

(lldb) expr -l objc -O -- [[UIWindow keyWindow] _autolayoutTrace]

The result is a graphical tree describing the view hierarchy and marking any ambiguously laid out views:

UIWindow:0x7fe8d0d9dbd0
|   •UIView:0x7fe8d0c2bf00
|   |   +UIView:0x7fe8d0c2c290
|   |   |   *UIView:0x7fe8d0c2c7e0
|   |   |   *UIView:0x7fe8d0c2c9e0- AMBIGUOUS LAYOUT

UIView also has a hasAmbiguousLayout property. I find it useful to set up a utility method that lets me check a view and all its subviews at any depth for ambiguity; see Appendix B.

To get a full list of the constraints responsible for positioning a particular view within its superview, log the results of calling the UIView instance method constraintsAffectingLayout(for:). The parameter is an axis (NSLayoutConstraint.Axis), either .horizontal or .vertical. These constraints do not necessarily belong to this view (and the output doesn’t tell you what view they do belong to). If a view doesn’t participate in autolayout, the result will be an empty array. Again, a utility method can come in handy; see Appendix B.

Given the notions of conflict and ambiguity, it is easier to understand what priorities are for. Imagine that all constraints have been placed in boxes, where each box is a priority value, in descending order. Now pretend that we are the runtime, performing layout in obedience to these constraints. How do we proceed?

The first box (.required, 1000) contains all the required constraints, so we obey them first. (If they conflict, that’s bad, and we report this in the log.) If there still isn’t enough information to perform unambiguous layout given the required priorities alone, we pull the constraints out of the next box and try to obey them. If we can, consistently with what we’ve already done, fine; if we can’t, or if ambiguity remains, we look in the next box — and so on.

For a box after the first, we don’t care about obeying exactly the constraints it contains; if an ambiguity remains, we can use a lower-priority constraint value to give us something to aim at, resolving the ambiguity, without fully obeying the lower-priority constraint’s desires. For example, an inequality is an ambiguity, because an infinite number of values will satisfy it; a lower-priority equality can tell us what value to prefer, resolving the ambiguity, but there’s no conflict even if we can’t fully achieve that preferred value.

Autoresizing in the Nib

When you drag a view from the Library into the canvas, it uses autoresizing by default, and will continue to do so unless you involve it in autolayout by adding a constraint that affects it.

When editing a view that uses autoresizing, you can assign it springs and struts in the Size inspector. A solid line externally represents a strut; a solid line internally represents a spring. A helpful animation shows you the effect on your view’s position and size as its superview is resized.

Creating a Constraint

The nib editor provides two primary ways to create a constraint:

Control-drag

Control-drag from one view to another. A HUD (heads-up display) appears, listing constraints that you can create (Figure 1-17). Either view can be in the canvas or in the document outline. To create an internal width or height constraint, Control-drag from a view to itself.

When you Control-drag within the canvas, the direction of the drag is used to winnow the options presented in the HUD; for example, if you Control-drag horizontally within a view in the canvas, the HUD lists Width but not Height.

While viewing the HUD, you might want to toggle the Option key to see some alternatives; for example, this might make the difference between an edge or safe area constraint and a margin-based constraint. Holding the Shift key lets you create multiple constraints simultaneously.

Figure 1-17. Creating a constraint by Control-dragging

Layout bar buttons

Click the Align or Add New Constraints button at the right end of the layout bar below the canvas. These buttons summon little popover dialogs where you can choose multiple constraints to create (possibly for multiple views, if that’s what you’ve selected beforehand) and provide them with numeric values (Figure 1-18). Constraints are not actually added until you click Add Constraints at the bottom!

Figure 1-18. Creating constraints from the layout bar

If you create constraints and then move or resize a view affected by those constraints, the constraints are not automatically changed. This means that the constraints no longer match the way the view is portrayed; if the constraints were now to position the view, they wouldn’t put it where you’ve put it. The nib editor will alert you to this situation (a Misplaced Views issue), and can readily resolve it for you, but it won’t change anything unless you explicitly ask it to.

There are additional view settings in the Size inspector. To set a view’s layout margins explicitly, change the Layout Margins pop-up menu to Fixed (or better, to Language Directional). To make a view’s layout margins behave as readableContentGuide margins, check Follow Readable Width. To allow construction of a constraint to the safe area of a view that isn’t a view controller’s main view, check its Safe Area Layout Guide.

Viewing and Editing Constraints

Constraints in the nib are full-fledged objects. They can be selected, edited, and deleted. Moreover, you can create an outlet to a constraint (and there are reasons why you might want to do so).

Constraints in the nib are visible in three places (Figure 1-19):

Figure 1-19. A view’s constraints displayed in the nib

In the document outline

Constraints are listed in a special category, “Constraints,” under the view to which they belong. (You’ll have a much easier time distinguishing these constraints if you give your views meaningful labels!)

In the canvas

Constraints appear graphically as dimension lines when you select a view that they affect (unless you uncheck Editor → Canvas → Show Constraints).

In the Size inspector

When a view affected by constraints is selected, the Size inspector lists those constraints, along with a grid that displays the view’s constraints graphically. Clicking a constraint in the grid filters the constraints listed below it.

When you select a constraint in the document outline or the canvas, you can view and edit its values in the Attributes or Size inspector. The inspector gives you access to almost all of a constraint’s features: the anchors involved in the constraint (the First Item and Second Item pop-up menus), the relation between them, the constant and multiplier, and the priority. You can also set the identifier here (useful when debugging, as I mentioned earlier).

The First Item and Second Item pop-up menus may list alternative constraint types; thus, for example, a width constraint may be changed to a height constraint. These pop-up menus may also list alternative objects to constrain to, such as other sibling views, the superview, and the safe area. Also, these pop-up menus may have a “Relative to margin” option, which you can check or uncheck to toggle between an edge-based and a margin-based constraint.

Thus, if you accidentally created the wrong constraint, or if you weren’t quite able to specify the desired constraint at creation time, editing will usually permit you to fix things. For example, when you constrain a subview to the view controller’s main view, the HUD offers no way to constrain to the main view’s edge; your choices are to constrain to the main view’s safe area (the default) or to its margin (if you hold Option). But having constrained the subview to the main view’s margin, you can then uncheck “Relative to margin” in the pop-up menu.

For simple editing of a constraint’s constant, relation, priority, and multiplier, double-click the constraint in the canvas to summon a little popover dialog. When a constraint is listed in a view’s Size inspector, double-click it to edit it in its own inspector, or click its Edit button to summon the little popover dialog.

A view’s Size inspector also provides access to its content hugging and content compression resistance priority settings. Beneath these, there’s an Intrinsic Size pop-up menu. The idea here is that your custom view might have an intrinsic size, but the nib editor doesn’t know this, so it will report an ambiguity when you fail to provide (say) a width constraint that you know isn’t actually needed; choose Placeholder to supply an intrinsic size and relieve the nib editor’s worries.

In a constraint’s Attributes or Size inspector, there is a Placeholder checkbox (“Remove at build time”). If you check this checkbox, the constraint you’re editing won’t be instantiated when the nib is loaded: in effect, you are deliberately generating ambiguous layout when the views and constraints are instantiated from the nib. You might do this because you want to simulate your layout in the nib editor, but you intend to provide a different constraint in code; perhaps you weren’t quite able to describe this constraint in the nib, or the constraint depends upon circumstances that won’t be known until runtime.

Problems with Nib Constraints

I’ve already said that generating constraints manually, in code, is error-prone. But it isn’t error-prone in the nib editor! The nib editor knows whether it contains problematic constraints. If a view is affected by any constraints, the Xcode nib editor will permit them to be ambiguous or conflicting, but it will also complain helpfully. You should pay attention to such complaints! The nib editor will bring the situation to your attention in various places:

Canvas

Constraints drawn in the canvas when you select a view that they affect use color coding to express their status:

Satisfactory constraints

Drawn in blue.

Problematic constraints

Drawn in red.

Misplacement constraints

Drawn in orange; these constraints are valid, but they are inconsistent with the frame you have imposed upon the view. I’ll discuss misplaced views in the next paragraph.

Document outline

If there are layout issues, the document outline displays a right arrow in a red or orange circle. Click it to see a detailed list of the issues (Figure 1-20). Hover the mouse over a title to see an Info button which you can click to learn more about the nature of this issue. The icons at the right are buttons: click one for a list of things the nib editor is offering to do to fix the issue for you. The chief issues are:

Conflicting Constraints

A conflict between constraints.

Missing Constraints

Ambiguous layout.

Misplaced Views

If you manually change the frame of a view that is affected by constraints (including its intrinsic size), then the canvas may be displaying that view differently from how it would really appear if the current constraints were obeyed. A Misplaced Views situation is also described in the canvas:

• The constraints in the canvas, drawn in orange, display the numeric difference between their values and the view’s frame.

• A dotted outline in the canvas may show where the view would be drawn if the existing constraints were obeyed.

Figure 1-20. Layout issues in the document outline

Having warned you of problems with your layout, the nib editor also provides tools to fix them.

The Update Frames button in the layout bar (or Editor → Update Frames) changes the way the selected views or all views are drawn in the canvas, to show how things would really appear in the running app under the constraints as they stand. Alternatively, if you have resized a view with intrinsic size constraints, such as a button or a label, and you want it to resume the size it would have according to those intrinsic size constraints, select the view and choose Editor → Size to Fit Content.

The Resolve Auto Layout Issues button in the layout bar (or the Editor → Resolve Auto Layout Issues hierarchical menu) proposes large-scale moves involving all the constraints affecting either selected views or all views:

Update Constraint Constants

Choose this menu item to change numerically all the existing constraints affecting a view to match the way the canvas is currently drawing the view’s frame.

Add Missing Constraints

Create new constraints so that the view has sufficient constraints to describe its frame unambiguously. The added constraints correspond to the way the canvas is currently drawing the view’s frame.

This command may not do what you ultimately want; you should regard it as a starting point. After all, the nib editor can’t read your mind! For example, it doesn’t know whether you think a certain view’s width should be determined by an internal width constraint or by pinning it to the left and right of its superview; and it may generate alignment constraints with other views that you never intended.

Reset to Suggested Constraints

This is as if you chose Clear Constraints followed by Add Missing Constraints: it removes all constraints affecting the view, and replaces them with a complete set of automatically generated constraints describing the way the canvas is currently drawing the view’s frame.

Clear Constraints

Removes all constraints affecting the view.

Varying the Screen Size

The purpose of constraints will usually be to design a layout that responds to the possibility of the app launching on devices of different sizes, and perhaps subsequently being rotated. Imagining how this is going to work in real life is not always easy, and you may doubt that you are getting the constraints right as you configure them in the nib editor. Have no fear: Xcode is here to help.

There’s a View As button at the lower left of the canvas. Click it to reveal (if they are not already showing) menus or buttons representing a variety of device types and orientations. Choose one, and the canvas’s main views are resized accordingly. When that happens, the layout dictated by your constraints is obeyed immediately. Thus, you can try out the effect of your constraints under different screen sizes right there in the canvas.

Conditional Interface Design

The View As button at the lower left of the canvas states the size classes (see “Trait Collections and Size Classes”) for the currently chosen device and orientation, using a notation like this: wC hR. The w and h stand for “width” and “height,” corresponding to the trait collection’s .horizontalSizeClass and .verticalSizeClass respectively; the R and C stand for .regular and .compact.

The reason you’re being given this information is that you might want the configuration of your constraints and views in the nib editor to be conditional upon the size classes that are in effect at runtime. You can arrange in the nib editor for your app’s interface to detect the traitCollectionDidChange notification and respond to it. Thus, for example:

• You can design directly into your interface a complex rearrangement of the interface when an iPhone app rotates to compensate for a change in device orientation.

• A single .storyboard or .xib file can be used to design the interface of a universal app, even though the iPad interface and the iPhone interface may be quite different from one another.

The idea when constructing a conditional interface is that you design first for the most general case. When you’ve done that, and when you want to do something different for a particular size class situation, you’ll describe that difference in the Attributes or Size inspector, or design that difference in the canvas:

In the Attributes or Size inspector

Look for a Plus symbol to the left of a value in the Attributes or Size inspector. This is a value that you can vary conditionally, depending on the environment’s size class at runtime. The Plus symbol is a button! Click it to see a popover from which you can choose a specialized size class combination. When you do, that value now appears twice: once for the general case, and once for the specialized case which is marked using wC hR notation. You can now provide different values for those two cases.

In the canvas

Click the Vary for Traits button, to the right of the device types buttons. Two checkboxes appear, allowing you to specify that you want to match the width or height size class (or both) of the current size class. Any designing you now do in the canvas will be applied only to that width or height size class (or both), also modifying the Attributes or Size inspector as needed.

I’ll illustrate these approaches with a little tutorial. You’ll need to have an example project on hand; make sure it’s a Universal app.

View Debugger

To enter the view debugger, choose Debug → View Debugging → Capture View Hierarchy, or click the Debug View Hierarchy button in the debug bar. The result is that your app’s current view hierarchy is analyzed and displayed (Figure 1-21):

Figure 1-21. View debugging (again)

• On the left, in the Debug navigator, the views and their constraints are listed hierarchically. (View controllers are also listed as part of the hierarchy.)

• In the center, in the canvas, the views and their constraints are displayed graphically. The window starts out facing front, much as if you were looking at the screen with the app running; but if you swipe sideways a little in the canvas (or click the Orient to 3D button at the bottom of the canvas, or choose Editor → Orient to 3D), the window rotates and its subviews are displayed in front of it, in layers. You can adjust your perspective in various ways; for example:

  • The slider at the lower left changes the distance between the layers.

  • The double-slider at the lower right lets you eliminate the display of views from the front or back of the layering order (or both).

  • You can double-click a view to focus on it, eliminating its superviews from the display. Double-click outside the view to exit focus mode.

  • You can switch to wireframe mode.

  • You can display constraints for the currently selected view.

• On the right, the Object inspector and the Size inspector tell you details about the currently selected object (view or constraint).

When a view is selected in the Debug navigator or in the canvas, the Size inspector lists its bounds and all the constraints that determine those bounds. This, along with the layered graphical display of your views and constraints in the canvas, can help you ferret out the cause of any constraint-related difficulties.

Previewing Your Interface

When you’re displaying the nib editor in Xcode, show the assistant pane. Its Tracking menu (the first component in its jump bar) includes the Preview option. Choose it to see a preview of the currently selected view controller’s view (or, in a .xib file, the top-level view).

At the lower left, the Plus button lets you add previews for different devices and device sizes; you can thus compare your interface on different devices simultaneously. At the bottom of each preview, a Rotate button lets you toggle its orientation. The previews take account of constraints and conditional interface.

At the lower right, a language pop-up menu lets you switch your app’s text (buttons and labels) to another language for which you have localized your app, or to an artificial “double-length” language.

Designable Views and Inspectable Properties

Your custom view can be drawn correctly in the nib editor canvas and preview even if it is configured in code. To take advantage of this feature, you need a UIView subclass declared @IBDesignable.

If an instance of this UIView subclass appears in the nib editor, then its self-configuration methods, such as willMove(toSuperview:), will be compiled and run as the nib editor prepares to portray your view. In addition, your view can implement the special method prepareForInterfaceBuilder to perform visual configurations aimed specifically at how it will be portrayed in the nib editor. In this way, you can even portray in the nib editor a feature that your view will adopt later in the life of the app. For example, if your view contains a UILabel that is created and configured empty but will eventually contain text, you could implement prepareForInterfaceBuilder to give the label some sample text to be displayed in the nib editor.

In Figure 1-22, I refactor a familiar example. Our view subclass gives itself a magenta background, along with two subviews, one across the top and the other at the lower right — all designed in code. The nib contains an instance of this view subclass. When the app runs, willMove(toSuperview:) will be called, the code will run, and the subviews will be present. But because willMove(toSuperview:) is also called by the nib editor, the subviews are displayed in the nib editor as well:

Figure 1-22. A designable view

@IBDesignable class MyView: UIView {
    func configure() {
        self.backgroundColor = UIColor(red: 1, green: 0.4, blue: 1, alpha: 1)
        let v2 = UIView()
        v2.backgroundColor = UIColor(red: 0.5, green: 1, blue: 0, alpha: 1)
        let v3 = UIView()
        v3.backgroundColor = UIColor(red: 1, green: 0, blue: 0, alpha: 1)
        v2.translatesAutoresizingMaskIntoConstraints = false
        v3.translatesAutoresizingMaskIntoConstraints = false
        self.addSubview(v2)
        self.addSubview(v3)
        NSLayoutConstraint.activate([
            v2.leftAnchor.constraint(equalTo:self.leftAnchor),
            v2.rightAnchor.constraint(equalTo:self.rightAnchor),
            v2.topAnchor.constraint(equalTo:self.topAnchor),
            v2.heightAnchor.constraint(equalToConstant:20),
            v3.widthAnchor.constraint(equalToConstant:20),
            v3.heightAnchor.constraint(equalTo:v3.widthAnchor),
            v3.rightAnchor.constraint(equalTo:self.rightAnchor),
            v3.bottomAnchor.constraint(equalTo:self.bottomAnchor),
        ])
    }
    override func willMove(toSuperview newSuperview: UIView!) {
        self.configure()
    }
}

In addition, you can configure a custom view property directly in the nib editor. To do that, your UIView subclass needs a property that’s declared @IBInspectable, and this property’s type needs to be one of a limited list of inspectable property types (I’ll tell you what they are in a moment). Now let’s say there’s an instance of this UIView subclass in the nib: that property will get a field of its own at the top of the view’s Attributes inspector, where you can set the initial value of that property in the nib editor rather than its having to be set in code. (This feature is actually a convenient equivalent of setting a nib object’s User Defined Runtime Attributes in the Identity inspector.)

The inspectable property types are: Bool, number, String, CGRect, CGPoint, CGSize, NSRange, UIColor, or UIImage. For classes (UIColor and UIImage), the property type can be an Optional. The property won’t be displayed in the Attributes inspector unless its type is declared explicitly. You can assign a default value in code; the Attributes inspector won’t portray this value as the default, but you can tell it to use the default by leaving the field empty (or, if you’ve entered a value, by deleting that value).

@IBDesignable and @IBInspectable are unrelated, but the former is aware of the latter. Thus, you can use an inspectable property to change the nib editor’s display of your interface.

In this example, we use @IBDesignable and @IBInspectable to work around an annoying limitation of the nib editor. A UIView can draw its own border automatically, by setting its layer’s borderWidth (Chapter 3). But this can be configured only in code. There’s nothing in a view’s Attributes inspector that lets you set a layer’s borderWidth, and special layer configurations are not normally portrayed in the canvas. @IBDesignable and @IBInspectable to the rescue:

@IBDesignable class MyButton : UIButton {
    @IBInspectable var borderWidth : Int {
        set {
            self.layer.borderWidth = CGFloat(newValue)
        }
        get {
            return Int(self.layer.borderWidth)
        }
    }
}

The result is that, in nib editor, our button’s Attributes inspector has a Border Width custom property, and when we change the Border Width property setting, the button is redrawn with that border width (Figure 1-23). Moreover, we are setting this property in the nib, so when the app runs and the nib loads, the button really does have that border width in the running app.

Figure 1-23. A designable view with an inspectable property

Layout-Driven UI

The combination of calling setNeedsLayout to trigger layout and implementing layoutSubviews to perform layout gives rise to a programming paradigm that Apple, in a 2018 WWDC video, calls layout-driven UI. Let’s say, for example, that a subview in the interface needs to move to a different position. Your code, when it discovers this fact, instead of changing its center directly on the spot, instead calls setNeedsLayout on the subview’s superview. Eventually the superview’s layoutSubviews is called, and at that moment the superview lays out its subviews. Control over where its subviews are placed is thus encapsulated in the superview and its layoutSubviews implementation.

To illustrate, suppose we have a rudimentary card game app where the user can tap a card in the deck to place it into a “hand” of cards. (This is basically the example posited by the WWDC video.) To simplify things, I’ll have each card be an instance of a UIButton subclass called Card that emits a notification when it is tapped:

class Card : UIButton {
    static let tappedNotification = Notification.Name("tapped")
    required init?(coder aDecoder: NSCoder) {
        super.init(coder:aDecoder)
        self.addTarget(self, action: #selector(tapped), for: .touchUpInside)
    }
    @objc func tapped(_ sender:UIGestureRecognizer) {
        NotificationCenter.default.post(
            name: Card.tappedNotification, object: self)
    }
}

The superview of the Cards is an instance of a UIView subclass called GameBoard. It registers for the notification emitted by a tapped Card:

class GameBoard : UIView {
    required init?(coder aDecoder: NSCoder) {
        super.init(coder:aDecoder)
        NotificationCenter.default.addObserver(
            self, selector: #selector(tapped),
            name: Card.tappedNotification, object: nil)
    }
    // ...
}

Now comes the interesting part. When a card is tapped, it needs to be moved out of the deck area and into the user’s “hand” area. In its tapped method, however, all GameBoard does is add the tapped card to its own hand array. It doesn’t actually move the card! Instead, hand has a setter observer that responds to modification of itself by triggering layout:

var hand = [Card]() {
    didSet {
        self.setNeedsLayout()
    }
}
@objc func tapped(_ n:Notification) {
    guard let v = n.object as? Card else {return}
    if let ix = self.hand.firstIndex(of:v) {
        // do nothing
    } else {
        self.hand.append(v)
    }
}

So when does the card move? In layoutSubviews! This is where we see the benefits of encapsulation. The cards in the user’s “hand,” let’s say, should appear in a left-to-right row in the “hand” area of the interface, demarcated by a subview called handView. (For purposes of the example, I’m keeping things simple and assuming that all the cards in the “hand” can fit in a single horizontal row.) layoutSubviews expresses this — and enforces it — by establishing a simple correspondence between the Cards that constitute the hand array and the positions of those Cards:

override func layoutSubviews() {
    super.layoutSubviews()
    for (ix,v) in self.hand.enumerated() {
        let p = CGPoint(
            self.handView.frame.minX + 20 + v.bounds.width / 2.0 +
                (10 + v.bounds.width) * CGFloat(ix),
            self.handView.frame.minY + 10 + v.bounds.height / 2.0
        )
        v.center = p
    }
}

This method is called any time there is layout, including when a Card is tapped. The beauty of its expression is that layoutSubviews doesn’t know or care what Card was tapped, or whether any Card was tapped. It knows only one thing: the cards in the “hand” must always appear, in order, in the handView area. As far as layout is concerned, that is what it means to be in the “hand.” It may be that at the time layoutSubviews is called, most or even all of the Cards in the hand array are already in the correct position. That doesn’t matter! Asserting their correct positions does no harm, even if they already occupy those positions. But any card in the hand that doesn’t occupy its correct position will occupy it after layoutSubviews is called.

Tweaking Autolayout

When you’re using autolayout, what happens in layoutSubviews? The runtime, having examined and resolved all the constraints affecting this view’s subviews, and having worked out values for their center and bounds, now simply assigns center and bounds values to them. In other words, layoutSubviews performs manual layout!

Knowing this, you might override layoutSubviews when you’re using autolayout, in order to tweak the outcome. A typical structure is: first you call super, causing all the subviews to adopt their new frames; then you examine those frames; if you don’t like the outcome, you can change things; and finally you call super again, to get a new layout outcome. As I mentioned earlier, setting a view’s frame (or bounds or center) explicitly in layoutSubviews is perfectly fine, even if this view uses autolayout; that, after all, is what the autolayout engine itself is doing. Keep in mind, however, that you must cooperate with the autolayout engine. Do not call setNeedsUpdateConstraints — that moment has passed — and do not stray beyond the subviews of this view. (Disobeying those rules can cause your app to hang.)

Simulating Autolayout

It is possible to simulate layout of a view in accordance with its constraints and those of its subviews. This is useful for discovering ahead of time what a view’s size would be if the autolayout engine were to perform layout at this moment.

Send the view the systemLayoutSizeFitting(_:) message. The system will attempt to reach or at least approach the size you specify, at a very low priority. This call is relatively slow and expensive, because a temporary autolayout engine has to be created, set to work, and discarded. But sometimes, it’s the best way to get the information you need.

Mostly likely you’ll specify either UIView.layoutFittingCompressedSize or UIView.layoutFittingExpandedSize, depending on whether what you’re after is the smallest or largest size the view can legally attain. The idea here is that the view’s size is constrained internally by the constraints of its subviews. There are a few situations where the iOS runtime actually does size a view that way (most notably with regard to UITableViewCells and UIBarButtonItems). I’ll show an example in Chapter 7.