SwiftUI Interview Questions: Views & Fundamentals

Custom SwiftUI views are written as structs conforming to View, which makes them value types. A view struct is a lightweight, declarative description of the desired UI rather than a heavyweight object tied to the screen. SwiftUI compares the old and new view descriptions and applies minimal updates to the rendered output, so the statement is true.

SwiftUI's View protocol requires a body property whose type is some View. Writing some View uses Swift's opaque return type feature, available since Swift 5.1. The some keyword lets the compiler fix one concrete type at compile time without exposing it to the caller. any View is an existential container rather than an opaque type, View alone names the protocol and is not a return-type annotation, and ObservableObject is an unrelated protocol, so none of these is the conventional body return type.

SwiftUI's View protocol declares body with the return type some View, using Swift's opaque return type feature (available since Swift 5.1). The some keyword guarantees the concrete type is fixed at compile time without exposing it to the caller. any View is an existential container, View is the protocol itself, and ObservableObject is an unrelated protocol, so none of these satisfy the body requirement.

SwiftUI applies modifiers in sequence, each wrapping the view produced by the previous one. In Snippet A, .padding() is applied first, creating a view with extra space around the text; .background(Color.red) then wraps that padded view, so the red fills the entire padded region and extends beyond the text. In Snippet B, .background(Color.red) is applied to the bare Text first, so the red covers only the text bounds; .padding() then wraps that result and adds transparent space around it, which shows the container's color rather than red. The visible difference is therefore caused solely by modifier order.

The Text view is first padded by 16 points on each side, which enlarges its layout box. The .background(Color.red) modifier then fills that padded box, so the red area surrounds the text with a margin. The .foregroundColor(.white) modifier sets the text glyphs to white instead of the default black. Finally, .cornerRadius(10) clips the whole padded, red-backed view to a rounded rectangle with a 10-point radius, giving white centered text inside a red rounded rectangle with visible padding on every side.

@State is designed for values that a view owns and mutates internally. SwiftUI persists @State storage across view re-creations, so the value assigned in init is only observed the very first time the view is created. When the parent recreates BadgeView with a different label, the @State wrapper ignores the new initializer value and keeps the original, producing stale text. Because label is never mutated inside BadgeView and always originates from the parent, it should be a plain let label: String — which re-reads the passed value on every re-creation. Custom initializers are perfectly valid in SwiftUI, label and self.label are equivalent in this context, and the order of .padding and .background is a layout choice, not a correctness issue.

On first render @State initializes maxDisplay to 2. The computed displayed property calls scores.prefix(2), yielding the first two tuples — Alice (100) and Bob (85) — which ForEach renders in array order. The if branch then checks scores.count (3) > maxDisplay (2), which is true, so the text “…and 1 more” appears and the else branch (“All shown”) is skipped. VStack arranges children top-to-bottom, so the four Text views appear in that exact order.

A @StateObject stores its ObservableObject in SwiftUI-managed storage associated with the view's identity, not in the value-type struct. When the parent re-renders, SwiftUI recreates the ChildView struct and runs its initializer, but the @StateObject's wrapped-value autoclosure is evaluated only on first insertion into the hierarchy. On later re-renders SwiftUI reuses the existing CounterVM, so its count is kept. A correct answer must say the instance persists or is reused rather than being recreated, and should give the reason: SwiftUI-managed storage tied to view identity, with the initializer evaluated only once.

Line 15 is the bug: @State private var displayName = name copies the parent's value into state. SwiftUI creates that state storage once, when the view first appears, and keeps it for the view's identity afterward. When ContentView re-renders and passes a new name (because userIdx changed), the UserProfileView struct is recreated but its stored displayName is not reset, so it keeps showing "Alice". Line 17 is correct: it faithfully displays the state it is given. The fix is to remove the @State copy and render Text(name) directly, since name is already the source of truth; syncing with .onChange(of: name) is a workaround that duplicates the data.

The bug is on line 19, the .id(UUID()) modifier applied to Counter. @State storage is tied to a view's identity in SwiftUI's view tree. UUID() returns a new value on every call, so each time RootView.body is evaluated (for example, when tab changes from tapping 'Switch Tab'), the Counter receives a different identity. SwiftUI treats that as a brand-new view, discards the old Counter along with its @State value, and creates a fresh one starting at 0. Removing the .id(UUID()) modifier, or replacing it with a constant identifier, keeps the @State alive across re-renders.

SwiftUI's View protocol declares body with @ViewBuilder. That result builder rewrites an if/else into _ConditionalContent<TrueView, FalseView>, a single concrete generic type that conforms to View when both branches do. Here the branches are Text("Online") and Image(systemName: "wifi.slash"), so the concrete return type is _ConditionalContent<Text, Image>, which the some View opaque return type hides from callers. No type erasure such as AnyView is involved; the builder produces a statically typed value.

The bug is on line 13: @ObservedObject var viewModel = CounterViewModel(). @ObservedObject subscribes to an object that is owned elsewhere; it does not store the object itself. The default-value expression CounterViewModel() is evaluated whenever ChildView is initialized. Tapping Toggle changes trigger, which ParentView's body reads, so SwiftUI re-evaluates the parent body and constructs a new ChildView value. That re-initialization creates a fresh CounterViewModel with count = 0, which replaces the instance that held the user's increments. The fix is to change line 13 to @StateObject var viewModel = CounterViewModel(), since @StateObject keeps the object in SwiftUI's persistent storage across re-initializations of the view. Lines 3-9, 17-18, and 23-31 are correct as written.

The key consequence is that AnyView hides the concrete type of each branch from SwiftUI's diffing engine. SwiftUI relies on static types in the view graph to compare old and new view values and update matching views in place. Because the helper produces a type-erased value on every body evaluation, SwiftUI sees an opaque replacement and rebuilds the subtree rather than updating it, which adds work and can reset @State and interrupt implicit animations. The idiomatic fix is @ViewBuilder, which keeps the concrete type through _ConditionalContent, or Group, which is transparent to diffing.