NEW: Master Swift design patterns with my latest book! >>

How to make your user interface in code

Written by Paul Hudson    @twostraws

Creating your user interface in code gives you the flexibility to build things conditionally, to step through problems in a debugger, to re-use components more easily, and to monitor changes more closely in source control. On the flip side, you lose features like easy segues, static cell design in table views, the ability to preview on multiple devices simultaneously, and more.

However, I’m going to assume you’ve already decided you want to make your UI in code, so let’s take a look at how it’s done:

Often you’ll see code like this inside the viewDidLoad() method of a view controller:

backgroundColor = UIColor(white: 0.9, alpha: 1)

let stackView = UIStackView()
stackView.translatesAutoresizingMaskIntoConstraints = false
stackView.spacing = 10

stackView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor).isActive = true
stackView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor).isActive = true
stackView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor).isActive = true
stackView.axis = .vertical

let notice = UILabel()
notice.numberOfLines = 0
notice.text = "Your child has attempted to share the following photo from the camera:"

let imageView = UIImageView(image: shareImage)

let prompt = UILabel()
prompt.numberOfLines = 0
prompt.text = "What do you want to do?"

for option in ["Always Allow", "Allow Once", "Deny", "Manage Settings"] {
    let button = UIButton(type: .system)
    button.setTitle(option, for: .normal)

That’s a complex user interface, but if you’re writing that sort of thing inside your viewDidLoad() method you’re making a terrible mistake. In fact, if you write that kind of code and you aren’t just prototyping or learning something, then you lose all rights to complain that your view controllers are massive later on.

All the code above – literally all of it – is view code, and needs to be treated as such. It is not controller code, and even with Apple’s muddied definition of MVC it is not view controller code either. It’s view code, and belongs in a subclass of UIView.

This change is trivial to make: you copy all that code, paste it into a new subclass of UIView called SharePromptView, then change the class of your view controller to your new subclass.

The final SharePromptView class should look something like this:

class SharePromptView: UIView {
    override init(frame: CGRect) {
        super.init(frame: frame)

    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)

    func createSubviews() {
        // all the layout code from above

All UIView subclasses must implement init(coder:), but as you’re creating your UI in code you will also need to add init(frame:). The createSubviews() method is there to support both.

Thanks to that custom UIView subclass you can now take a huge amount of code out of your view controller:

class ViewController: UIViewController {
    var shareView = SharePromptView()

    override func loadView() {
        view = shareView

    override func viewDidLoad() {

Having a dedicated shareView property allows you to access any properties you declare inside SharePromptView without having to keep casting view.

Available from iOS 9.0 – learn more in my book Swift Design Patterns

Did this solution work for you? Please pass it on!

Other people are reading…

About the Swift Knowledge Base

This is part of the Swift Knowledge Base, a free, searchable collection of solutions for common iOS questions.

Want to build macOS apps?

Hacking with macOS delivers 18 awesome projects that teach you macOS development in no time – take control of your desktop today!

Click here to visit the Hacking with Swift store >>