Chapters
Chapters

Chapters

Hide chapters

Auto Layout by Tutorials

First Edition · iOS 13 · Swift 5.1 · Xcode 11

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Section I: Beginning Auto Layout

Section 1: 3 chapters
Show chapters Hide chapters

Section II: Intermediate Auto Layout

Section 2: 10 chapters
Show chapters Hide chapters

Section III: Advanced Auto Layout

Section 3: 6 chapters
Show chapters Hide chapters

4. Construct Auto Layout with Code
Written by Jayven Nhan

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

There are two ways to implement Auto Layout into your projects. You already learned how to implement Auto Layout using Interface Builder. Now, it’s time to learn the second approach: using code.

Almost every iOS developer eventually raises the question: Should you construct your UI using storyboards or code? There is no silver bullet, and no one-size-fits-all solutions; however, there are solutions that fit much better based on your specific needs and requirements.

To help you achieve fluency in constructing UIs using code, you’ll learn about the following topics in this chapter:

  • Launching a storyboard view controller using code.
  • Launching a non-storyboard view controller using code.
  • Refactoring Interface Builder UIs into code.
  • Using visual format language to construct Auto Layout.
  • Benefits and drawbacks of constructing Auto Layout using code.

As a developer, you’ll see projects implement their UIs using Interface Builder, code, and in some cases, both approaches within the same project. To build optimized solutions for new projects, and to help maintain existing projects, it’s vitally important to understand both methods of building an app’s UI.

By the end of this chapter, you’ll know how to use code interchangeably with Interface Builder. You’ll also gain the knowledge to make more decisive presentation logic decisions to achieve more optimal solutions.

Launching a view controller from the storyboard in code

Open MessagingApp.xcodeproj in the starter folder, and then open the project target’s general settings. Set the Main Interface text field to empty.

Build and run, and you’ll see a black screen.

With the Interface Builder implementation, the app launches the initial view controller of the storyboard set in the target’s Main Interface. To do something similar in code, you need to take a different approach.

Open AppDelegate.swift and replace the code inside application(_:didFinishLaunchingWithOptions:) with the following:

// 1
let storyboard = UIStoryboard(name: "TabBar", bundle: nil)
// 2
let viewController =
  storyboard.instantiateInitialViewController()
// 3
window = UIWindow(frame: UIScreen.main.bounds)
// 4
window?.rootViewController = viewController
// 5
window?.makeKeyAndVisible()
return true

Here’s what you’ve done:

  1. Initialize the storyboard in code using the storyboard name.
  2. Create a reference to the storyboard’s initial view controller.
  3. Set the app delegate’s window using the device’s screen size as the frame.
  4. Set the window’s root view controller to the storyboard’s initial view controller.
  5. By calling makeKeyAndVisible() on your window, window is shown and positioned in front of every window in your app. For the most part, you’ll only need to work with one window. There are instances where you’d want to create new windows to display your app’s content. For example, you’ll work with multiple windows when you want to support an external display in your app. Chapter 17, “Auto Layout for External Displays”, covers supporting external displays.

When you use storyboards, the app delegate’s window property is automatically configured. In contrast, when you use code, you need to do more manual work. This is generally true when using code over Interface Builder.

Build and run, and you’ll see the following:

That’s only a taste of what it’s like using more code and less Interface Builder. Are you ready for some more?

Launching a view controller without initializing storyboard

You now know how to launch a view controller in code from a storyboard. But no set rule dictates that a project can’t mix storyboards/.xibs and code. For example, there may come a time where your team’s objective is to refactor an existing codebase that uses storyboards/.xibs into one that uses code. You’re going to do that now.

Building out a view controller’s user interface in code

When you built the UI in Interface Builder, the profile view controller had a header view with a gray background. The header view encapsulated the main stack view, and the main stack view encapsulated two stack views. One stack view contained the profile image view and the full name label. The other stack view contained the action buttons. It’s time to recreate those user interfaces in code.

Layout anchors

Before the introduction of layout anchors, developers created constraints in code using NSLayoutConstraint initializers. NSLayoutConstraint describes the relationship between two user interface objects, and that relationship has to satisfy the Auto Layout engine. Although this approach still works, there’s room for improvements in the code readability and cleanliness departments. Consequently, Apple introduced layout anchors for this purpose.

Setting up profile header view

Open ProfileViewController.swift and add the following property to ProfileViewController:

Refactoring profile image view

It’s time to create the profile image view in code.

Refactoring profile name label

Open ProfileNameLabel.swift and remove @IBDesignable from the class declaration.

Refactoring stack views

To begin rebuilding the stack views in code, add the following extension to the bottom of ProfileHeaderView.swift (outside of the class):

Auto Layout with visual format language

Using visual format language is another way of constructing your Auto Layout in code. Building Auto layout in code has come a long way in terms of code readability since the debut of visual format language. As you may have guessed, visual format language isn’t exactly the most user-friendly tool available. So you may be wondering: Why should anyone learn visual format language to construct Auto Layout then?

Symbols

For reference, here are the symbols to describe your layout in visual format language:

Visual format string example

Here’s what the string above does to create constraints:

Thinking visual format language

Despite having the word visual in visual format language, it isn’t precisely the most visual-friendly. It’s important to have the right strategy to think about constraints to effectively create or maintain constraints created using visual format language.

Horizontal and vertical axes

When you think about visual format language, imagine either drawing a line from top-to-bottom or left-to-right on your device. Then, looking at the line you drew, track down the property name of every UI object the line passes through.

Metrics dictionary

You can define metrics string with a dictionary using visual format language. You can then use a metrics key-value pair to define a constraint’s constant or multiplier. You may want to use the metrics dictionary to pass in values for the visual format string to reference.

Views dictionary

So, how are you going to tell the constraints about the views using visual format language? This is where the views dictionary comes into play. Similar to the metrics dictionary, your key-value pairs consist of a string and the view object for the key and value, respectively.

Layout options

When creating your constraints using visual format language, you’ll have the option to use the options parameter. options lets you describe the views’ constraints perpendicular to the current layout orientation.

Setting up constraints

Open NewContactViewController.swift.

Benefits and drawbacks from choosing the code approach

Whether you choose Interface Builder or code to layout your user interface, it is an unquestionably subjective matter. Before you come to a decisive conclusion on your approach, have a look at the benefits and drawbacks when using code to construct Auto Layout.

Challenges

You’ve reached the end of the chapter. To help solidify your understanding, try these challenges:

Key points

  • Working with code requires more upfront manual work than working with Interface Builder.
  • You can refactor UI layouts built in Interface Builder into code format.
  • There are various methods to create Auto Layout constraints using code.
  • Learning visual format language, although rarely seen on new projects, can assist you in debugging constraint conflicts and maintaining legacy codebases.
  • Consider the pros and cons when choosing between Interface Builder and code approach to creating your UI layout.
3. Stack View
5. Scroll View
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now