Home / SwiftUI interview questions

SwiftUI

SwiftUI interview questions

SwiftUI is the default for new iOS work, so senior interviews expect architecture-level answers, not just view syntax. This overview links the deep dives.

What senior SwiftUI interviews cover

Expect state management and data flow (@State, @Binding, @StateObject, @Environment, and Observation), the migration from ObservableObject to @Observable, navigation with NavigationStack and deep links, performance and unnecessary re-renders, and when to drop to UIKit. Interviewers want trade-offs and ownership reasoning, not memorized property wrapper definitions.

How to answer at a senior level

Frame answers around state ownership and the single source of truth: who owns the data, who can mutate it, and how changes flow to the view. Talk about identity and diffing when discussing performance, and about decomposing large views. Acknowledging where SwiftUI still needs UIKit reads as experienced, not evasive.

When do you use @State versus @StateObject versus @ObservedObject?

The spoken answer: "@State is for value type state the view owns. @StateObject is for a reference type the view creates and owns, so SwiftUI keeps it alive across view updates. @ObservedObject is for a reference type someone else owns and passes in. The question underneath all three is ownership: who creates it, who keeps it alive." That is one breath on ownership and one on the wrappers.

The trap: "What happens if you use @ObservedObject where you should have used @StateObject?" The obvious answer says nothing visible changes, and it often looks fine in a demo. It fails because view structs are recreated constantly, and an @ObservedObject initialized inline is recreated with them, silently resetting its state mid session. The recovery line: "The object gets rebuilt whenever the parent re-renders, so state resets at unpredictable times; @StateObject pins it to the view identity." The senior differentiator is mentioning that with the Observation framework and @Observable this whole family collapses: plain properties for owned state, and the view tracks only the properties it reads. Knowing both worlds, and which one the codebase you are joining likely uses, reads as current.

Why is my SwiftUI view re-rendering too often?

The spoken answer: "SwiftUI re-evaluates body whenever an observed dependency changes. Too many re-renders usually means the view observes more than it reads: a big ObservableObject where any published property invalidates every subscriber. I fix it by splitting the model, passing narrower values down, or moving to @Observable, which tracks per property access."

The trap: the interviewer asks how you found the problem, not how you fixed it. Guessing at fixes without measurement walks into it. The recovery line: "First I confirm with Self._printChanges or the SwiftUI profiler in Instruments, because the expensive part is often one subtree, not the whole screen." The senior differentiator is talking about identity: stable ids in ForEach and structural identity in conditionals decide whether SwiftUI diffs a view or tears it down, and getting identity wrong causes both performance problems and lost state like animation glitches.

When would you still choose UIKit?

The spoken answer: "For most new screens, SwiftUI. I drop to UIKit for heavy collection views with custom layouts, fine grained control over text input and first responder behavior, and some media and camera surfaces. I wrap it with UIViewRepresentable and keep the boundary thin so the rest of the feature stays SwiftUI."

The trap: "So SwiftUI is not production ready?" Agreeing walks into it, and so does pretending SwiftUI does everything. Both read as tribal. The recovery line: "It is production ready for the large majority of screens; the question is which specific surface in this app justifies the interop cost." The senior differentiator is describing the representable boundary concretely: a coordinator for delegate callbacks, updateUIView kept idempotent, and state flowing one way so the wrapped view never fights the SwiftUI update cycle.

The 3 signals interviewers score in a SwiftUI round

• Ownership reasoning. Every wrapper question is secretly "who owns this state". Candidates who answer at that level survive the follow-ups; candidates who recite wrapper definitions do not.
• Measurement before optimization. Naming Instruments or _printChanges before proposing a fix separates people who have debugged SwiftUI performance from people who have read about it.
• Version awareness without name dropping. Knowing that @Observable changed the invalidation model matters. Listing every WWDC API does not.

I have written no hire on candidates who knew every property wrapper but could not say who owned the state in their own code sample. The wrappers are the entry fee. Ownership is the score.

One more pattern from the hiring side: the SwiftUI round rarely ends with your first correct answer. The interviewer changes a requirement, adds a second screen sharing the same state, or asks what breaks on rotation. Rehearse the follow-up, not the definition, because the follow-up is where the round is decided.