Sample questions
Ios Swiftui State RenderingDifficulty 1
In SwiftUI, what does marking a view's property with @State actually do?
- aIt makes the property accessible from any other view in the app.
- bIt stores the value permanently on disk between app launches.
- cIt marks the property as constant so it can never change after init.
- dIt tells SwiftUI to own the value and re-render the view on change.✓
Explanation:@State is a property wrapper that gives SwiftUI ownership of a value type's storage outside the view struct's own lifetime, so the value survives repeated body calls, and mutating it triggers a re-render.
Ios Swiftui State RenderingDifficulty 1
What is the primary purpose of @Binding in SwiftUI?
- aTo create a brand-new independent copy of a value inside a child view.
- bTo permanently cache a network response for offline use.
- cTo give a child view read-write access to a parent-owned value.✓
- dTo declare a global singleton shared across the whole app.
Explanation:@Binding does not own storage; it is a reference back to state owned elsewhere, letting a child view read and write that value while the parent (or the original owner) stays the source of truth.
Ios Swiftui State RenderingDifficulty 1
A parent view owns @State private var isOn: Bool and passes $isOn to a child Toggle. The user taps the toggle. What happens?
- aOnly the child view updates; the parent's stored value never changes.
- bNothing updates until the app is manually relaunched.
- cThe binding creates a separate copy, so parent and child now disagree on the value.
- dThe child writes through the binding and mutates the parent's state.✓
Explanation:The $ prefix projects a Binding from the @State storage. Writing to that binding writes through to the parent's actual storage, so SwiftUI invalidates and re-renders any view whose body depends on that state, including the parent.
Ios Swiftui State RenderingDifficulty 2
Why does SwiftUI require @State properties to be private by convention?
- aBecause only that view should own and mutate the value.✓
- bBecause private properties compile faster.
- cBecause SwiftUI silently ignores non-private state.
- dBecause Swift forbids non-private property wrappers entirely.
Explanation:@State models local, view-owned storage. Marking it private is a convention (not a hard compiler rule) that reinforces the intent: outside code should interact through a passed Binding, not by reaching into the view's internal state directly.
Ios Swiftui State RenderingDifficulty 2
What is the key behavioral difference between @ObservedObject and @StateObject when applied to the same reference-type model in a view?
- a
@ObservedObject supports Combine publishers while @StateObject does not. - b
@StateObject ties the instance's creation and lifetime to the view.✓ - cThey are fully interchangeable with no behavioral difference.
- d
@ObservedObject only works with structs, never with classes.
Explanation:@StateObject allocates and keeps the object alive for the lifetime of the view identity (created once). @ObservedObject does not manage the object's lifetime itself — if the parent view re-creates and passes a new instance on every body evaluation, the observed object can be unintentionally reset.
Ios Swiftui State RenderingDifficulty 2
A view declares @ObservedObject var viewModel = ViewModel() directly as a default value on the property. Every time the parent's body re-runs, a brand-new ViewModel instance is silently created. What is the correct fix?
- aWrap the ViewModel in an extra
@State var around the class instance. - bChange the wrapper to
@StateObject var viewModel = ViewModel().✓ - cMove the default value initialization into
onAppear instead. - dMark the ViewModel class as
final to fix the lifetime issue.
Explanation:The bug is a classic @ObservedObject-with-default-value mistake: since @ObservedObject doesn't manage lifetime, a default init expression re-runs on every struct re-creation. @StateObject exists specifically to own that first-time creation and keep the same instance alive.