How to Add Constraints Programmatically in Swift: Optimization and Performance

Why Programming Constraints is a Must-Have for iOS Developers?

Imagine: you're working on an app late at night, Storyboard is lagging, conflicts in Interface Builder are endless, and the client asks you to add an adaptive screen for all iPhones. Sound familiar? That's exactly the moment you Google "How to add constraints programmatically using Swift". And for good reason — this is one of the most popular questions on Stack Overflow with thousands of views. But let's dig deeper: we won't just translate the answer, but break down how to do it correctly, quickly, and painlessly.

Programmatic constraints give you full control over your layout. No pink elephants from Storyboard, no magic numbers — just clean, predictable code. And most importantly, performance. When you write constraints manually, you know exactly what is created and when. No unnecessary objects, no "surprises" from Interface Builder. Today, we'll learn how to do it like a pro.

What Are Programmatic Constraints and Why Do You Need Them?

Constraints are rules that describe how views are positioned relative to each other and to their parent. In Swift, there are three main ways to add them programmatically:

\n
• NSLayoutConstraint — the classic but verbose method
\n
• NSLayoutAnchor — a modern, readable, and safe API (recommended by Apple)
\n
• Visual Format Language (VFL) — a string format for describing groups of constraints
\n

Why is this needed? Imagine you're building a dynamic interface: a chat, a news feed, or a form with changing fields. Storyboard is powerless here — you need to change the sizes and positions of elements while the app is running. Or you work in a team where code reviewers hate conflicts in XIB files. Programmatic constraints solve all these problems.

NSLayoutAnchor: Your New Best Friend

Let's start with the most popular and correct approach — NSLayoutAnchor. This API was introduced in iOS 9 and has since become the standard. It is type-safe, readable, and prevents you from accidentally mixing up axes. Check it out:

import UIKit\n\nclass ViewController: UIViewController {\n    override func viewDidLoad() {\n        super.viewDidLoad()\n        \n        let myView = UIView()\n        myView.backgroundColor = .systemBlue\n        myView.translatesAutoresizingMaskIntoConstraints = false\n        view.addSubview(myView)\n        \n        // Adding constraints via anchors\n        NSLayoutConstraint.activate([\n            myView.centerXAnchor.constraint(equalTo: view.centerXAnchor),\n            myView.centerYAnchor.constraint(equalTo: view.centerYAnchor),\n            myView.widthAnchor.constraint(equalToConstant: 200),\n            myView.heightAnchor.constraint(equalToConstant: 200)\n        ])\n    }\n}\n

Notice the key line: myView.translatesAutoresizingMaskIntoConstraints = false. This is a mandatory condition. If you skip it, your constraints will conflict with automatic masks, and the app will crash with an error. Remember once and for all: every time you add constraints programmatically, disable autoresizing.

Why Are Anchors Faster and Safer?

In older projects, you might encounter NSLayoutConstraint with parameters. It looks intimidating:

NSLayoutConstraint(item: myView, attribute: .centerX, relatedBy: .equal, toItem: view, attribute: .centerX, multiplier: 1.0, constant: 0).isActive = true\n

You'll agree, this looks like a spell. One wrong parameter and you get a bug that you search for half a day. Anchors solve this problem: you simply write .centerXAnchor.constraint(equalTo: ...). The compiler checks types, Xcode suggests options — beautiful!