What is @State in SwiftUI and how does it affect the view?

What's really being asked

Whether you understand the source of truth and ownership model in SwiftUI's declarative architecture. The interviewer is checking that you know why a view struct, which is a value type, can appear to mutate its own state without breaking value semantics. They also want to see that you grasp the difference between state owned by the view versus state owned externally and passed in, because mixing these up leads to architecture bugs and unnecessary view invalidations across the tree.

The full answer

First, define @State as a property wrapper that creates private storage for a value type, owned exclusively by the view that declares it. Second, explain that modifying the wrapped value marks the view as invalid and schedules an asynchronous re-render of the body, but does not mutate the struct instance directly. Third, clarify that SwiftUI manages the actual backing storage outside the view struct, which is why var is permitted even though body is computed inside an immutable struct context. Fourth, note that @State should be private and is intended for simple local UI state like toggle positions, text field input, or animation flags. Fifth, mention that the projected value is a Binding, allowing child views to mutate the value without owning it.

The mistakes people make

Confusing @State with @ObservedObject or @Binding, which are for external or shared data. Claiming that @State persists across app launches or process death. Saying that @State gives a struct reference semantics. Asserting that mutating @State immediately and synchronously redraws the view on the same line of code, rather than invalidating and scheduling a future render pass. Using @State for non-private or globally shared data, which breaks the single source of truth principle.

What usually comes next

When would you use @State versus @ObservedObject or @StateObject? Why does SwiftUI require @State variables to be private? What happens if you pass a @State binding to a child view? How does @State interact with the identity of a view, such as when a view is removed from the hierarchy and later reinserted? Can you use @State with a reference type, and what are the risks?

A concrete example

A simple toggle. Declare @State private var isOn: Bool = false inside a View struct. Bind it to a Toggle("Airplane Mode", isOn: $isOn). When the user taps the toggle, SwiftUI writes to the backing storage, invalidates the view, and recomputes body with the new value, moving the toggle switch to the on position without any imperative UI update code. If the view is removed from the window, SwiftUI can discard the storage, and if it returns with the same identity, the state may be restored depending on the container.