Compare UIKit Auto Layout and SwiftUI layout systems

WHAT THIS TESTS: This question tests whether you understand the fundamental architectural difference between UIKit's imperative, constraint-driven layout system and SwiftUI's declarative, composition-driven approach. Interviewers want to see that you know UIKit relies on an external constraint solver while SwiftUI uses an internal two-pass sizing negotiation. They are looking for awareness of how this shift changes performance characteristics, debugging strategies, and mental models for alignment and spacing.

A GOOD ANSWER COVERS: First, explain that UIKit Auto Layout builds a constraint graph of linear equations that the solver resolves to produce frames, using NSLayoutConstraint, anchors, and priority values. Second, describe SwiftUI's layout as a recursive two-pass system where a parent proposes a size to its child, the child chooses its own size based on that offer, and the parent places the child in its coordinate space. Third, note that SwiftUI expresses layout through structural composition, specifically HStack, VStack, ZStack, Spacer, and frame modifiers, rather than through a separate constraint system. Fourth, mention that SwiftUI invalidates and recomputes layout when state changes, whereas UIKit requires manual invalidation or constraint updates, and that SwiftUI's approach eliminates ambiguous layout warnings but introduces its own complexity with fixedSize and layout priorities.

COMMON WRONG ANSWERS: A major red flag is claiming SwiftUI simply wraps Auto Layout or translates into constraints under the hood. Another is describing SwiftUI layout as magic without explaining the parent-child size negotiation. Avoid saying Auto Layout is more powerful; instead, acknowledge that both handle complex layouts but SwiftUI pushes you toward predictable, composable structures. Do not confuse SwiftUI stacks with UIKit UIStackView without noting that UIStackView itself uses Auto Layout internally while SwiftUI stacks are primitive layout containers.

LIKELY FOLLOW-UPS: The interviewer may ask how you would replicate a complex constraint, such as equal widths or aspect ratios, in SwiftUI. They might probe performance by asking about the cost of deep view hierarchies in SwiftUI versus UIKit, or ask how UIHostingController bridges the two worlds. Another common follow-up is asking how you debug layout issues in SwiftUI without Interface Builder or view debugger constraints.

ONE CONCRETE EXAMPLE: Consider a login screen with a logo, two text fields, and a button centered vertically with padding. In UIKit, you would pin the logo top anchor to the safe area, center the text fields horizontally with equal widths, and set the button bottom anchor with a greater-than-or-equal constraint to the keyboard. In SwiftUI, you wrap the elements in a VStack, apply Spacer above and below to center the group, use frame maxWidth infinity on the text fields to mimic equal widths, and apply padding as a modifier on the stack. This shows how UIKit thinks in external relationships between independent views while SwiftUI thinks in nested containers that own their children's arrangement.