What's with Constraints in SwiftUI?

Question

What is happening now with constraints in SwiftUI? Do View types adapt automatically for bigger devices etc. or what should we have to do instead?

Answer 1

RIP, Constraints!

SwiftUI doesn't use layout constraints. UIKit is still around, it's not deprecated and fully functional, so if you continue to use the classic approach, you can use as many constraints as you wish.

However, if you choose to go with SwiftUI → rest in peace, constraints!

The core concept to align views with each other is using stacks:

• HStack
• VStack

If you want to overlay views (i.e. put one view on top of another), you can use a

• ZStack

The View protocol itself (to which all view types mysteriously conform) has tons of functions called modifiers that you can use to customize your view's layout.

---

Examples

Here are some examples how you can achieve specific layouts with those modifiers compared to using constraints:

1. Aspect Ratio

Instead of

view.widthAnchor.constraint(equalTo: view.heightAnchor, multiplier: 2)

in UIKit you would write

view
    .aspectRatio(2, contentMode: .fit)

in SwiftUI.

2. Spacing Between Views

Instead of

view2.leadingAnchor.constraint(equalTo: view1.leadingAnchor, constant: 8)

in UIKit you could arrange the views in a horizontal stack and add a spacer between them and add the frame modifier to specify its width:

HStack {
    view1
    Spacer()
        .frame(width: 30)
    view2
}

3. Equal Widths

This is where it gets more complicated. You can no longer specify that two views have an equal width. If they are in the same vertical stack (i.e. aligned in a vertical line), fine: just set the contentMode to .fill and control the actual width by setting the stack view's width → mission accomplished. ✅ But if they are not (for example, when they are in a horizontal stack), you have to find other ways to express that. The actual implementation will depend on the concrete layout you're trying to describe.

---

The general idea of SwiftUI is to keep views as small as possible and compose them. There's a little trade-off here: You pay the price that "constraints" between views in different view hierarchies get a lot more verbose to implement, the ultimate gain is that the layout is declarative and the code to create the most common user interfaces is dramatically simplified.

---

Screen Adaptation / Responsiveness

Custom views fill the entire available space by default, which means that the top most view automatically fills the entire screen – regardless of the actual screen size. You can use modifiers to change that behavior.