SwiftUI

SwiftUI is Apple's declarative UI framework: instead of mutating elements step by step, you describe how the screen looks for a given state, and the framework brings it to that shape itself. The screen is the body, a pure function of state: change the state and SwiftUI recomputes the body and updates only what changed.

The main mindset shift for someone coming from UIKit is grasping the "source of truth". Data lives in one place (@State), and everything else merely references it. A child control does not hold its own copy — it gets a Binding, a two-way reference to someone else's state. Layout is declarative too: not Auto Layout constraints but nested stacks and modifiers. The full map is in the layers below.

Topic map

• @State — a view's local mutable state, whose mutation re-renders the body.
• Binding — a two-way $state reference letting a child control read and write someone else's value without owning it.
• Declarative layout — composing the screen from stacks, modifiers, and conditional view inclusion instead of Auto Layout and isHidden.

Common traps

Interview relevance

SwiftUI is asked to check whether you absorbed the declarative model or just carry UIKit habits over. A candidate who says "the body is a function of state, and @State is the single source of truth that a Binding only references" immediately looks stronger than one who "hides a label with isHidden".

Typical checks:

• The difference between @State (ownership) and Binding (reference) and the role of the $ prefix.
• Why mutating @State re-renders the body, and that the body is a function of state.
• When @StateObject is needed instead of @State for reference-type models.
• How to replace isHidden and Auto Layout with declarative layout.

Common wrong answer: "@State is a static property shared across all instances, and a Binding is a one-way snapshot of a value". In fact @State is per-instance state, and a Binding is a two-way reference reflecting changes in both directions.