Window Scene Architecture

Starting in iOS 13, an app’s window is backed by a window scene (UIWindowScene). This is a major architectural change from iOS 12 and before, where window scenes didn’t exist. It will be useful to distinguish two different architectures:

Window architecture

The old architecture, in iOS 12 and before, is window-based. The window is a property of the app delegate. If your app was created in Xcode 10 or before, it uses the old architecture by default.

Scene architecture

The new architecture, in iOS 13 and later, is scene-based. The window is a property of the scene delegate. If your app was created in Xcode 11 or later, it uses the new architecture by default.

An old-architecture app running on iOS 13 or later is given a window scene, but it is unaware of that fact and its behavior is not affected; it still runs under the old architecture. A new-architecture app, on the other hand, cannot run on, or even compile for, iOS 12 or earlier, without alterations to the code.

What determines the architecture? To find out, just create an app in Xcode 11 or later; the app template configures it for the new architecture. The app has a scene delegate, which contains the window property:

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?
    // ...
}

The app delegate also contains two methods that refer to scenes:

class AppDelegate: UIResponder, UIApplicationDelegate {
    // ...
    func application(_ application: UIApplication,
        configurationForConnecting connectingSceneSession: UISceneSession,
        options: UIScene.ConnectionOptions) -> UISceneConfiguration {
            // ...
    }
    func application(_ application: UIApplication,
        didDiscardSceneSessions sceneSessions: Set<UISceneSession>) {
            // ...
    }
}

In addition, the Info.plist contains an “Application Scene Manifest” entry:

<key>Application Scene Manifest</key>
<dict>
    <!-- ... -->
</dict>

If you want your new-architecture app to be backward-compatible to iOS 12 and before, you must do three things:

1. Copy and paste the window property declaration into the AppDelegate class. Now both the AppDelegate and the SceneDelegate have window properties. The former is used on iOS 12 and before, while the latter is used on iOS 13 and later.

2. In the AppDelegate class, mark any methods that refer to UISceneSession as @available(iOS 13.0, *).

3. In the SceneDelegate class, mark the entire class as @available(iOS 13.0, *).

The result is that when this app runs in iOS 13 or later, it uses the new architecture and the scene delegate’s window property holds the window, but when it runs in iOS 12 or before, it uses the old architecture and the app delegate’s window property holds the window — and your other code may then need to take account of that in order to be backward compatible. Lifetime delegate messages and notifications (see Appendix A) will be routed differently; for instance, on iOS 12 and before, you’ll get the applicationDidBecomeActive(_:) message in the app delegate, but on iOS 13 and after, you’ll get the sceneDidBecomeActive(_:) message in the scene delegate.

If all of that is too overwhelming and you want your new app to run with the old architecture even on iOS 13 and later, then theoretically you can: delete all code that refers to UISceneSession or SceneDelegate, and delete the “Application Scene Manifest” entry in the Info.plist. You have now reduced your code to look as if it was created in Xcode 10. (I’m not actually recommending that you do that.)

How an App Launches

How does your app, at launch time, come to have its 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. But “automatically” does not mean “by magic!” The procedure at launch is straightforward and deterministic, and your code can take a hand in it. It is useful to know how an app launches, not least because, if you misconfigure something and app launch goes wrong, you’ll be able to figure out why.

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.) This call creates some of your app’s most important initial instances; if your app uses a main storyboard, those instances include the window and its root view controller.

Exactly how UIApplicationMain proceeds depends on whether your app uses the old or new architecture. They are two quite different launch trajectories. I will describe just the launch trajectory for the new architecture.

Here’s how UIApplicationMain bootstraps your app with window scene support as it launches on iOS 13 and later:

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 that is because it is marked @main. It retains the app delegate instance, ensuring that it will persist for the lifetime of the app, and assigns it as the application instance’s delegate.

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

3. UIApplicationMain creates a UISceneSession, a UIWindowScene, and an instance that will serve as the window scene’s delegate. The Info.plist specifies, as a string, what the class of the window scene delegate instance should be (“Delegate Class Name” inside the “Application Scene Manifest” dictionary’s “Scene Configuration”). In the built-in app templates, it is the SceneDelegate class; this is written in the Info.plist as $(PRODUCT_MODULE_NAME).SceneDelegate to take account of Swift “name mangling.”

4. UIApplicationMain looks to see whether your initial scene uses a storyboard. The Info.plist specifies, as a string, the name of its storyboard (“Storyboard Name” inside the “Application Scene Manifest” dictionary’s “Scene Configuration”). If so, it instantiates that storyboard’s initial view controller.

5. If the scene uses a storyboard, UIApplicationMain instantiates UIWindow and assigns the window instance to the scene delegate’s window property, which retains it.

6. If the scene uses a storyboard, UIApplicationMain assigns the initial view controller instance to the window instance’s rootViewController property, which retains it. The view controller’s view becomes the window’s sole subview.

7. UIApplicationMain causes your app’s interface to appear, by calling the UIWindow instance method makeKeyAndVisible.

8. The scene delegate’s scene(_:willConnectTo:options:) is called.

App Without a Storyboard

It is possible to write an app that lacks a main storyboard:

• Under the old architecture, this means that the Info.plist contains no “Main storyboard file base name” entry.

• Under the new architecture, it means that there is no “Storyboard Name” entry under “Application Scene Configuration” in the “Application Scene Manifest” dictionary.

Such an app simply does in code everything that UIApplicationMain does automatically if the app has a main storyboard. Under the old architecture, you would do that in the app delegate’s application(_:didFinishLaunchingWithOptions:). Under the new architecture, you do it in the scene delegate’s scene(_:willConnectTo:options:):

func scene(_ scene: UIScene,
    willConnectTo session: UISceneSession,
    options connectionOptions: UIScene.ConnectionOptions) {
        if let windowScene = scene as? UIWindowScene {
            self.window = UIWindow(windowScene: windowScene) 
            let vc = // ...                                  
            self.window!.rootViewController = vc             
            self.window!.makeKeyAndVisible()                 
        }
}

Instantiate UIWindow and assign it as the scene delegate’s window property. It is crucial to make the connection between the window scene and the window by calling init(windowScene:).

Instantiate a view controller and configure it as needed.

Assign the view controller as the window’s rootViewController property.

Call makeKeyAndVisible on the window, to show it.

A variant that is sometimes useful is an app that has a storyboard but doesn’t let UIApplicationMain see it at launch. That way, we can dictate at launch time which view controller from within that storyboard should be the window’s root view controller. A typical 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:

func scene(_ scene: UIScene,
    willConnectTo session: UISceneSession,
    options connectionOptions: UIScene.ConnectionOptions) {
        if let windowScene = scene as? UIWindowScene {
            self.window = UIWindow(windowScene: windowScene)
            let userHasLoggedIn : Bool = // ...
            let vc = UIStoryboard(name: "Main", bundle: nil)
                .instantiateViewController(identifier: userHasLoggedIn ?
                    "UserHasLoggedIn" : "LoginScreen") // *
            self.window!.rootViewController = vc
            self.window!.makeKeyAndVisible()
        }
}

Referring to the Window

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

From a view

If a UIView is in the interface, it automatically has a reference to the window that contains it, 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.

From the scene delegate

The scene delegate instance maintains a reference to the window through its window property.

From the application

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

let w = UIApplication.shared.windows.first!

Interface Style

The trait collection’s userInterfaceStyle (a UIUserInterfaceStyle) reports whether the environment is in light mode (.light) or dark mode (.dark). For the significance of these for your app, see the discussion of colors earlier in this chapter. If your colors are dynamic colors, then for the most part everything will happen automatically; the user switches modes, and your colors change in response. However, there are circumstances under which you may be managing some colors manually, and you’ll want to know when the interface style changes so that you can change a color in response.

Let’s say we’re applying a custom named dynamic color from the asset catalog to the border of a view. This is actually done at the level of the view’s layer (Chapter 3), and requires that we take the color’s cgColor property:

self.otherView.layer.borderWidth = 4
self.otherView.layer.borderColor =
    UIColor(named: "myDarkColor")?.cgColor

The problem is that neither a layer nor a color’s cgColor knows anything about the trait collection. So it is up to us to listen for trait collection changes and apply our dynamic color again. We can save ourselves from doing unnecessary work, thanks to the trait collection hasDifferentColorAppearance method:

override func traitCollectionDidChange(_ prevtc: UITraitCollection?) {
    super.traitCollectionDidChange(prevtc)
    if prevtc?.hasDifferentColorAppearance(
        comparedTo: self.traitCollection) ?? true {
            self.otherView.layer.borderColor =
                UIColor(named: "myDarkColor")?.cgColor
    }
}

Observe that we don’t have to know what the userInterfaceStyle actually is; we simply take our dynamic color’s cgColor and apply it, exactly as we did before. How can this be? It’s because the act of accessing the named color from the asset catalog — UIColor(named: "myDarkColor") — takes place in the presence of a global value, UITraitCollection.current. In traitCollectionDidChange and various other places where the runtime is drawing or performing layout, this value is set for us, and so our dynamic color arrives in the correct interface style variant and our derived cgColor is the correct color. In contexts where UITraitCollection.current is not set automatically, you are free to set it manually, ensuring that subsequent operations involving dynamic colors will take place in the correct environment.

The trait collection is also the key to understanding what color a named dynamic color really is. What color is .systemYellow? Well, it depends on the trait collection. So to find out, you have to supply a trait collection. That’s easy, because you can make a trait collection. Now you can call resolvedColor:

let yellow = UIColor.systemYellow
let light = UITraitCollection(userInterfaceStyle: .light)
let dark = UITraitCollection(userInterfaceStyle: .dark)
let yellowLight = yellow.resolvedColor(with: light)
// 1 0.8 0 1
let yellowDark = yellow.resolvedColor(with: dark)
// 1 0.839216 0.0392157 1

In addition to the userInterfaceStyle, the trait collection also has a userInterfaceLevel, which is .base or .elevated. This affects dynamic background colors. Only confined regions in front of the main interface are normally affected. An alert (Chapter 14) has an .elevated interface level, even if the main interface behind the alert does not.

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 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 pair of size classes which are vended as trait collection properties:

horizontalSizeClass

verticalSizeClass

A UIUserInterfaceSizeClass value, either .regular or .compact.

In combination, the size classes have the following meanings when, as will usually be the case, your app’s window 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 a “big” iPhone 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.

Clearly, a change in the size classes detected through traitCollectionDidChange is not the way to learn simply that the interface has rotated. Size classes don’t distinguish between an iPad in portrait orientation and an iPad in landscape orientation. They distinguish between the most important extreme situations: if the horizontal size class goes from .regular to .compact, the app is suddenly tall and narrow, and you might want to compensate by changing the interface in some way. In my experience, however, you won’t typically implement traitCollectionDidChange in order to hear about a change in size classes; rather, the size classes are something you’ll consult in response to some other event. (I’ll talk more in Chapter 6 about how to detect actual rotation at the level of the view controller.)

Overriding Trait Collections

Under certain circumstances, it can be useful to isolate part of the UITraitEnvironment hierarchy and lie to it about what the trait collection is. You might like part of the hierarchy to believe that we are on an iPhone in landscape when in fact we are on an iPhone in portrait. (I’ll give an example in Chapter 6.) Or there might be some area of your app that should not respond to a change between light and dark mode.

You cannot insert a trait collection directly into the inheritance hierarchy simply by setting a view’s trait collection; traitCollection isn’t a settable property. However, in a UIViewController you can inject your own trait collection by way of the overrideTraitCollection property (and UIPresentationController has a method that is similar).

For the user interface style, there is a simpler facility available both for a UIViewController and for a UIView: the overrideUserInterfaceStyle property. It isn’t a trait collection; it’s a UIUserInterfaceStyle. The default value is .unspecified, which means that the interface style of the trait collection should just pass on down the hierarchy. But if you set it to .light or .dark, you block inheritance of just the userInterfaceStyle property of the trait collection starting at that point in the hierarchy, substituting your own custom setting.

Autoresizing

Autoresizing is a matter of conceptually assigning a subview “springs and struts.” A spring can expand and contract; a strut can’t. Springs and struts can be assigned internally or externally, horizontally or vertically. With two internal springs or struts, you specify whether and how the view can be resized; with four external springs or struts, you specify whether and how the view can be repositioned:

• 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 four struts externally and two 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 four springs externally and two struts internally.

• Imagine an OK button that is to stay in the lower right of its superview. It would have two struts internally, two struts externally from its right and bottom, and two springs externally from 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 three struts externally and a spring from 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 (and the view is pinned by struts to the top left).

In debugging, when you log a UIView to the console, its autoresizingMask is reported using the word autoresize and a list of the springs. The external springs are LM, RM, TM, and BM; the internal springs are W and H. autoresize = LM+TM means there are external springs from the left and top; autoresize = ​W⁠+BM means there’s an internal horizontal spring and a spring from the bottom.

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-13):

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-13. 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, bringing autoresizing into play; as you can see (Figure 1-14), the subviews remain pinned in their correct relative positions:

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

Figure 1-14. 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; 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. The possible attribute values are:

• .width, .height

• .top, .bottom

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

• .centerX, .centerY

• .firstBaseline, .lastBaseline

If the constraint is describing a view’s absolute height or width, the secondItem will be nil and the secondAttribute will be .notAnAttribute.

.firstBaseline applies primarily to multiline labels, and is some distance down from the top of the label (Chapter 11); .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 second attribute’s value is multiplied by the multiplier; the constant is added to that product; and the first attribute is set to the result. 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. 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.

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. 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! Instead of adding a constraint to a particular view explicitly, you can activate the constraint. An activated constraint is added to the correct view automatically, relieving you from having to determine what view that would be. 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. There is also an NSLayoutConstraint class method activate(_:), which takes an array of constraints, along with deactivate(_:). Deactivating a constraint is like removing a subview: the constraint is removed from its view, and will go out of existence if you haven’t retained it.

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 replace it with a new one.

An NSLayoutConstraint also has a writable string identifier property. It can be set to any value you like, and can be useful for debugging or for finding a constraint later — so useful, in fact, that it might be good to have on hand an extension that lets you activate a constraint and set its identifier at the same time:

extension NSLayoutConstraint {
    func activate(withIdentifier id: String) {
        (self.identifier, self.isActive) = (id, true)
    }
}

(I owe that idea to Stack Overflow user Exquisitian; see https://stackoverflow.com/a/57102973/341994.)

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 the view 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 (“Hello”) 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 I’ll add a second label (“Howdy”) 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 (“Hello”) 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 H:[UILabel:'Hello']-(63)-|>
<NSAutoresizingMaskLayoutConstraint UILabel:'Hello'.minY == 20>
<NSAutoresizingMaskLayoutConstraint UILabel:'Hello'.width == 42>
<NSAutoresizingMaskLayoutConstraint UILabel:'Hello'.height == 22>

Recall that the original frame was (270,20,42,22). I’m on an iPhone 8 simulator, so the main view width is 375. I’ve simplified and rearranged the output, but what it says is that the label’s right edge is 63 points from the main view’s right (the label’s original x value of 270 plus its width of 42 is 312, and the main view’s width of 375 minus 312 is 63), its top is 20 points from the main view’s top, and it is 42×22 in size.

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.

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 the identifier, both of which can be set later if desired.

I’ll generate the same views and subviews and layout behavior as in Figures 1-13 and 1-14, 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

And here come the constraints; I’ll add them to their views manually, just to show how it’s done:

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-13 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. 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-15). 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-15. 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:

func doSwap() {
    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)
    }
}

In that code, I deactivate the old constraints before activating the new ones. Always proceed in that order; activating the new constraints with the old constraints still in force will cause a conflict (as I’ll explain later in this chapter).

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. 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 — perhaps to set them or to perform manual layout based on them.

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. Since a UILayoutGuide is configured by constraints, and since other views can be constrained to it, it can participate in autolayout 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.

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. Suppose I have four views of equal heights that are to remain equally distributed vertically. Between them, I interpose three spacer views, also of equal heights. If we pin every view to the view below it, and the first and last view to the top and bottom of the superview, and hide the spacer views, they become the equal spaces between the visible views.

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. We have four views that are to remain equally distributed vertically. I constrain the left and right edges of the four views, their heights, and the top of the first view and the bottom of the last view. Now we want to set the vertical position of the two middle views such that they are always equidistant from their vertical neighbors (Figure 1-16).

Figure 1-16. 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 view controller’s main view. I then involve my three layout guides in the layout. Remember, they must be configured entirely using constraints! The four views are referenced through an array, views:

var guides = [UILayoutGuide]()
// one fewer guides than views 
for _ in views.dropLast() {
    let g = UILayoutGuide()
    self.view.addLayoutGuide(g)
    guides.append(g)
}
// guides leading and width are arbitrary 
let anc = self.view.leadingAnchor
for g in guides {
    g.leadingAnchor.constraint(equalTo:anc).isActive = true
    g.widthAnchor.constraint(equalToConstant:10).isActive = true
}
// guides top to previous view 
for (v,g) in zip(views.dropLast(), guides) {
    v.bottomAnchor.constraint(equalTo:g.topAnchor).isActive = true
}
// guides bottom to next view 
for (v,g) in zip(views.dropFirst(), guides) {
    v.topAnchor.constraint(equalTo:g.bottomAnchor).isActive = true
}
// guide heights equal to each other! 
let h = guides[0].heightAnchor
for g in guides.dropFirst() {
    g.heightAnchor.constraint(equalTo:h).isActive = true
}

I create the layout guides and add them to the interface.

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

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

I constrain each layout guide to 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.

Tip

In real life, if the problem is equal distribution, 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

Certain built-in interface objects, when using autolayout, have an inherent size in one or both dimensions, dependent upon the object type and its content. Here are some examples:

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

• A UIImageView adopts the size of the image that it is displaying.

• A UILabel consisting of a single line of text adopts the size of the text that it is displaying.

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 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 created 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, because you might need to change the priorities. 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 give the two labels different compression resistance priorities; even a tiny difference will do:

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 content. 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.

Self-Sizing Views

So far, I have talked about layout (and autolayout in particular) as a way of solving the problem of what should happen to a superview’s subviews when the superview is resized. However, autolayout also works in the opposite direction. If a superview’s subviews determine their own size, they can also determine the size of the superview.

Consider this simple example. We have a plain vanilla UIView, which has as its sole subview a UIButton. And suppose this UIButton is pinned by constraints from all four edges to its superview, the plain vanilla UIView. Well, as I’ve already said, a UIButton under autolayout has an intrinsic size: its height is standard, and its width is dependent upon its title. So, all other things being equal, the size of the button is determined. Then, all other things being equal, the size of the plain vanilla view is also determined, from the inside out, by the size of the button, its subview. (See Figure 1-17; the inner rectangle with the black border is the button, and the outer rectangle is the plain vanilla UIView.)

Figure 1-17. A self-sizing view

What I mean by “all other things being equal” is simply that you don’t determine the size of the plain vanilla superview in any other way. Let’s say you pin the leading and top edges of the superview to its superview. Now we know the position of the superview. But we do not pin its trailing or bottom edges, and we don’t give it a width or height constraint. You might say: Then the width and height of the superview are unknown! But not so. In this situation, the autolayout engine simply gets the width and height of the superview from the width and height of its subview, the button — because the width and height of the button are known, and there is a complete constraint relationship between the width and height of the button and the width and height of the superview.

I call a view such as our plain vanilla superview a self-sizing view. In effect, it has an intrinsic content size — not literally (we have not configured its instrinsicContentSize), but in the sense that it is, in fact, sized by its content. A self-sizing view’s size does not have to be determined solely by its content; it is fine to give a self-sizing view a width constraint (or pin it on both sides) but allow its height to be determined by its content. If the superview is also pinned to its subview(s) horizontally to determine its width, that could result in a conflict between constraints — but in many cases it won’t. Our plain vanilla superview can have its width determined by a hard-coded width constraint without causing a conflict; its subview is pinned to it horizontally, but its subview is a button whose width is determined by its intrinsic content size at a lower priority than the superview’s width constraint, so the superview’s width wins without a struggle (and the button subview is widened to match).

When a view is self-sizing based on the constraints of its subviews, you can ask it in code to size itself immediately in order to discover what its 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 that’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. 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.

Stack Views

A stack view (UIStackView) is a kind of pseudoview whose job 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. In practice, it turns out that many layouts can be expressed as an arrangement, possibly nested, of simple rows and columns of subviews. 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 (for which you’ll have to provide 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 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 of them must have a lowered priority for its 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-16). 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. 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.

A stack view, in certain configurations, can behave as a self-sizing view: its size, if not determined in any other way, in one or both dimensions, can be based on its subviews.

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. You can consult this property 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 round.

To illustrate, 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-13) 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, 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-18). 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-18. View debugging

Another useful trick is to pause in the debugger and conduct the following mystical conversation in the console:

(lldb) e -l objc -- [[UIApplication sharedApplication] windows][0]
(UIWindow *) $1 = ...
(lldb) e -l objc -O -- [$1 _autolayoutTrace]

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

•UIView:0x7f9fa36045c0
|   +UIView:0x7f9fa3604930
|   |   *UIView:0x7f9fa3604a90
|   |   *UIView:0x7f9fa3604e20- AMBIGUOUS LAYOUT
            for UIView:.minY{id: 33}, UIView:.Height{id: 34}

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. 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.

Starting in Xcode 11, in the nib editor an individual view has a Layout pop-up menu in the Size inspector allowing you specify its behavior with regard to constraints:

Inferred

The default. The view’s translatesAutoresizingMaskIntoConstraints is true, and you can position the view with autoresizing, until the view becomes involved in constraints, at which point its translatesAutoresizingMaskIntoConstraints becomes false and you will have to position and size this view entirely with constraints. New in Xcode 12, the title of this pop-up menu changes to help you; if translatesAutoresizingMaskIntoConstraints is true, the title is Inferred (Autoresizing Mask), but if it is false (because you’ve involved the view in constraints), the title is Inferred (Constraints).

Autoresizing Mask

The view’s translatesAutoresizingMaskIntoConstraints is true, and it will stay true. This view will resist becoming involved in constraints within the nib; it wants to use autoresizing only. You can’t give it a width constraint or a constraint to its superview. You can involve the view in constraints from other views, as long as these would not cause a problem.

You can cause problems yourself by behaving irrationally; if a view starts out as Inferred and you give it constraints, and then you switch it to Autoresizing Mask, you can readily create a conflict at runtime. Don’t do that.

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-19). 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: 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; 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-19. 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-20). Constraints are not actually added until you click Add Constraints at the bottom!

Figure 1-20. 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-21):

Figure 1-21. 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 → 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, or when you double-click a constraint in a view’s Size inspector, you can view and edit that constraint’s 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; a width constraint may be changed to a height constraint, for example. 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.

So 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. 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 safe area, you can then change Safe Area to Superview 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:

Figure 1-22. Layout issues in the document outline

In the 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.

In the 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-22). 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. You can turn off ambiguity checking for a particular view; use the Ambiguity pop-up menu in the view’s Size inspector. This means you can omit a needed constraint and not be notified by the nib editor that there’s a problem. You will need to generate the missing constraint in code, obviously, or you’ll have ambiguous layout in the running app.

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.

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! 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. So you can try out the effect of your constraints under different screen sizes right there in the canvas.

(This feature works only if the view controller’s Simulated Size pop-up menu in the Size inspector says Fixed. If it says Freeform, the view won’t be resized when you click a device type or orientation button.)

Conditional Interface Design

The View As button at the lower left of the canvas states the 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:

• You can design your interface to rearrange itself 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 if the iPad interface and the iPhone interface are 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 (click View As if you don’t see the Vary for Traits button). 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), and the Attributes or Size inspector will be modified 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-23):

Figure 1-23. 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:

  • 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 Option-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 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, you’re already seeing the results of your constraints in the current device size. You can change device size using the buttons or menu that appears when you click View As at the lower left. The same interface lets you toggle orientation and switch between light and dark mode.

For an even more realistic display, choose Editor → Preview (or choose Preview from the Editor Options pop-up menu). You’ll see a preview of the currently selected view controller’s view (or, in a .xib file, the top-level view).

At the bottom of each preview, a label tells you what device you’re seeing, and a rotate button lets you toggle its orientation. At the lower left, a Plus button lets you add previews for different devices and device sizes, so you can view your interface on different devices simultaneously. 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. To remove a previewed device, click to select it and press Delete.

Designable Views and Inspectable Properties

Your custom view can be drawn 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 portray in the nib editor a feature that your view will adopt later in the life of the app. 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-24, 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-24. 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). If 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. 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. This means 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 the 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-25). 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-25. A designable view with an inspectable property