What's with Constraints in SwiftUI? - ios

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.

Answer 2

It still has constraint, in WWDC examples we saw HStack and VStack, which seems like UIStackView, so my guess it just clips to edges. You can still add padding to views so if you want constraint a UILabel (Text) 10pt to left you do something like this:
Text("Hello World").padding(EdgeInsets(top: 0, leading: 10, bottom: 0, trailing: 0))

Answer 3

Constraints are very well gone, which is great, but there is something called .padding(), which can do some sort of constraint look by putting it on the left side with something like leading parameters which make an image go to the side of a view
struct ContentView: View {
var body: some View {
Image("x")
.padding(.leading)
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
}