Top 30 Swiftui Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   Why do type errors in result builder code sometimes reference compiler-generated boilerplate instead of the original developer code?

   • aBecause the builder protocol requires all partial results to be type-erased to Any, causing the compiler to validate types in generated wrappers rather than at call sites.
   • bBecause result builders use runtime metaprogramming to assemble the final value, so the compiler reports errors against hidden scaffolding rather than surface syntax.
   • cBecause the @resultBuilder attribute forces the function body into a separate compilation unit that strips original line number information during optimization.
   • dBecause the compiler performs a silent source-to-source rewrite into static method calls during type checking, and errors are reported against the generated code.
   Show the answer

   Answer: d · Because the compiler performs a silent source-to-source rewrite into static method calls during type checking, and errors are reported against the generated code.

   The card describes result builders as a compile-time source-to-source rewrite into static method calls, so type errors surface on the generated boilerplate rather than the original code. Distractor A incorrectly attributes the transformation to runtime metaprogramming, when the card explicitly states the rewrite happens during type checking.

   Read the full bite: Result Builders: Declarative Swift DSLs

2. Question 2 of 30

   What is the immediate effect of mutating a @State property in a SwiftUI view?

   • aThe new value is written to persistent storage to survive process death
   • bThe struct instance mutates in place, giving the view reference semantics
   • cThe view's body recomputes synchronously on the exact next line of code
   • dSwiftUI marks the view as invalid and schedules an asynchronous body re-evaluation
   Show the answer

   Answer: d · SwiftUI marks the view as invalid and schedules an asynchronous body re-evaluation

   Mutating @State marks the view invalid and schedules an asynchronous re-evaluation of body rather than redrawing immediately. The synchronous redraw distractor is wrong because SwiftUI batches state changes and updates the render tree in a future pass, not on the next line of code.

   Read the full bite: What is @State in SwiftUI and how does it affect the view?

3. Question 3 of 30

   Which statement accurately describes a key architectural difference between UIKit Auto Layout and SwiftUI?

   • aUIKit uses a declarative two-pass sizing system where parents propose sizes to children.
   • bUIKit uses an external constraint solver while SwiftUI uses parent-child two-pass size negotiation.
   • cSwiftUI translates its layout modifiers into Auto Layout constraints under the hood.
   • dSwiftUI relies on an external constraint solver that resolves linear equations to produce view frames.
   Show the answer

   Answer: b · UIKit uses an external constraint solver while SwiftUI uses parent-child two-pass size negotiation.

   UIKit Auto Layout depends on an external solver to resolve linear equation constraints into frames, while SwiftUI layout is driven by an internal two-pass size negotiation between parent and child. Option C represents a common misconception; SwiftUI does not wrap or compile down to Auto Layout constraints but instead uses its own compositional layout engine.

   Read the full bite: Compare UIKit Auto Layout and SwiftUI layout systems

4. Question 4 of 30

   A child view receives an ObservableObject from its parent, must update when it publishes changes, and must not manage its lifecycle. Which wrapper fits?

   • a@EnvironmentObject, because the object is shared across the view hierarchy
   • b@Binding, because the parent owns the truth and the child needs to mutate it
   • c@State, because the child needs to hold its own copy of the object
   • d@ObservedObject, because the child receives a reference-type object it does not own
   Show the answer

   Answer: d · @ObservedObject, because the child receives a reference-type object it does not own

   @ObservedObject is correct because the child gets an externally created ObservableObject and must react to its updates without taking ownership. @Binding is tempting because the data comes from the parent, but it is meant for value types, not reference-type ObservableObjects.

   Read the full bite: Differences between @State, @Binding, @ObservedObject, and @EnvironmentObject

5. Question 5 of 30

   When wrapping a delegate-based UIKit view for use in SwiftUI, what is the correct way to handle callbacks and avoid retain cycles?

   • aProvide a Coordinator object via makeCoordinator and use it as the delegate
   • bConform the UIViewRepresentable struct to the delegate protocol and assign self as the delegate
   • cReassign the delegate inside updateUIView whenever the SwiftUI state changes
   • dWrap the UIKit view in a UIHostingController before adding it to the SwiftUI hierarchy
   Show the answer

   Answer: a · Provide a Coordinator object via makeCoordinator and use it as the delegate

   A Coordinator provides a stable reference to handle delegate callbacks without retain cycles. Making the representable struct the delegate is wrong because structs cannot reliably act as reference-type delegates and it introduces mutability and lifecycle issues.

   Read the full bite: Integrate SwiftUI into UIKit and wrap UIKit for SwiftUI

6. Question 6 of 30

   When implementing the SwiftUI Layout protocol, what is the correct division of responsibility between sizeThatFits and placeSubviews?

   • aBoth methods position subviews, and sizeThatFits is optional
   • bsizeThatFits reports the container's required size for a proposal; placeSubviews positions each subview within the granted bounds
   • cplaceSubviews reports the size and sizeThatFits positions the subviews
   • dsizeThatFits draws the views and placeSubviews animates them
   Show the answer

   Answer: b · sizeThatFits reports the container's required size for a proposal; placeSubviews positions each subview within the granted bounds

   The protocol uses a measure-then-place model: sizeThatFits returns the size the container needs, and placeSubviews positions children inside the bounds the parent grants. The roles are not reversed, and neither method draws or animates views.

   Read the full bite: How do you build a custom SwiftUI Layout?

7. Question 7 of 30

   Which statement accurately characterizes a SwiftUI View?

   • aIt is a lightweight, declarative description of a UI element, frequently recreated by the framework.
   • bIt functions as a controller, coordinating interactions between data models and the user interface.
   • cIt primarily manages the application's state and business logic, separate from UI presentation.
   • dIt is a persistent object that directly renders pixels on the screen, similar to UIKit's UIView.
   Show the answer

   Answer: a · It is a lightweight, declarative description of a UI element, frequently recreated by the framework.

   A SwiftUI View is a lightweight, declarative recipe or blueprint for UI, not the actual persistent UI element itself, and is frequently recreated. Option D is incorrect because it describes a common misconception, treating it like a heavy, persistent UIKit UIView.

   Read the full bite: SwiftUI's View: A Blueprint, Not a Building

8. Question 8 of 30

   In SwiftUI, how does a ZStack arrange its child views along the Z-axis?

   • aAll views are positioned on the same plane, without any layering effect.
   • bThe first view declared appears at the front, obscuring subsequent views.
   • cViews are layered based on their content size, with larger views always at the back.
   • dThe first view declared is positioned at the back, with subsequent views layered on top.
   Show the answer

   Answer: d · The first view declared is positioned at the back, with subsequent views layered on top.

   A ZStack layers views from back to front, meaning the first view listed is at the back, and the last view is at the front. Option B describes the opposite behavior, which is a common misconception.

   Read the full bite: SwiftUI Stacks: Arrange Views Vertically, Horizontally, and in Layers

9. Question 9 of 30

   A parent view manages a boolean state and allows a child view to directly modify it. How should these properties be declared?

   • aParent: @State, Child: @Binding
   • bParent: @State, Child: @State
   • cParent: @Binding, Child: @State
   • dParent: @Binding, Child: @Binding
   Show the answer

   Answer: a · Parent: @State, Child: @Binding

   The parent view owns the data, making @State the correct choice for its private source of truth. The child view needs to modify the parent's data without owning it, which is the purpose of @Binding. Option B is incorrect because @State in the child would create a separate, owned copy, not modify the parent's original value.

   Read the full bite: SwiftUI State and Binding: Owning vs. Sharing Data

10. Question 10 of 30

    Which approach best implements modern SwiftUI navigation from a product list to a detail view using only an identifier?

    • aUse NavigationStack but place NavigationLink(destination: ProductDetailView(id:)) directly inside each list row.
    • bUse NavigationStack with NavigationLink(destination:isActive:) while passing the complete Product object to the detail view.
    • cWrap the list in NavigationView and pass the full Product model through NavigationLink(destination:).
    • dUse NavigationStack with NavigationLink(value: id), a stack-level navigationDestination(for: Product.ID.self), and a bound NavigationPath.
    Show the answer

    Answer: d · Use NavigationStack with NavigationLink(value: id), a stack-level navigationDestination(for: Product.ID.self), and a bound NavigationPath.

    This uses the iOS 16 value-based API that separates routing state from views, passes only identifiers for loose coupling, and enables programmatic control via NavigationPath. Option C is tempting but wrong because NavigationView triggers legacy split-view behavior on iPad and lacks bound path control.

    Read the full bite: Implement SwiftUI navigation between list and detail with product ID

11. Question 11 of 30

    According to the "Russian nesting dolls" mental model, why does the order of SwiftUI modifiers significantly impact a view's appearance?

    • aEach modifier creates a new, wrapped view, and subsequent modifiers operate on the result of the previous modification.
    • bEach modifier directly changes the original view's properties, and the final modifier in the chain overrides all previous changes.
    • cModifiers are processed from right to left, with the innermost modifier being applied last to the final visual output.
    • dThe order dictates the priority of layout constraints, with earlier modifiers having higher precedence over later ones.
    Show the answer

    Answer: a · Each modifier creates a new, wrapped view, and subsequent modifiers operate on the result of the previous modification.

    Option A accurately describes the mental model: each modifier returns a new view that wraps the previous one, so the order determines which 'doll' (or modified view) the next modifier acts upon. Option B is incorrect because modifiers are non-destructive and do not alter the original view; they return a new one.

    Read the full bite: SwiftUI Modifiers: Stacking Changes on Views

12. Question 12 of 30

    Which action explicitly leads to broken scrolling behavior when using a SwiftUI List?

    • aProviding a data collection where items are not Identifiable.
    • bNesting the List within a parent ScrollView.
    • cUsing the List to display a complex, non-linear grid layout.
    • dDisplaying only a few static items instead of a dynamic data collection.
    Show the answer

    Answer: b · Nesting the List within a parent ScrollView.

    The card explicitly warns that nesting a List inside another scrolling view like a ScrollView is a "footgun" that "breaks scrolling behavior." Other options describe inefficient uses or prerequisites, not actions that break the List's scrolling.

    Read the full bite: SwiftUI List: More Than Just a Table View

13. Question 13 of 30

    What is the primary role of UIHostingController in iOS development?

    • aTo enable the integration of SwiftUI views within an existing UIKit-based application.
    • bTo manage the lifecycle of UIKit view controllers when embedded within a pure SwiftUI application.
    • cTo convert existing UIKit views into SwiftUI views for a complete application rewrite.
    • dTo optimize the rendering performance of complex SwiftUI views by leveraging UIKit's core graphics.
    Show the answer

    Answer: a · To enable the integration of SwiftUI views within an existing UIKit-based application.

    UIHostingController is designed to bridge SwiftUI content into UIKit apps, allowing for incremental adoption of SwiftUI. It does not convert UIKit views, nor is it used for embedding UIKit in pure SwiftUI, and it can introduce performance overhead rather than optimize rendering.

    Read the full bite: UIHostingController: Bridge SwiftUI into UIKit Apps

14. Question 14 of 30

    To programmatically return to the root of a SwiftUI NavigationStack, what should you modify?

    • aThe underlying UINavigationController's view controller stack
    • bThe presentationMode environment value in the deepest view
    • cThe NavigationPath binding owned at or above the root view
    • dThe isActive Boolean binding on the root NavigationLink
    Show the answer

    Answer: c · The NavigationPath binding owned at or above the root view

    SwiftUI navigation is data-driven, so you clear the bound NavigationPath that serves as the source of truth for the stack depth. Reaching for the underlying UINavigationController breaks the declarative model and reflects a UIKit mindset.

    Read the full bite: How do you pop to root in SwiftUI NavigationStack?

15. Question 15 of 30

    For which scenario is ObservableObject the most suitable choice in SwiftUI?

    • aCreating a shared data model (class) whose properties, when changed, should update multiple views.
    • bManaging a simple counter variable that only affects a single view.
    • cStoring a collection of immutable data structures that are displayed in a list.
    • dPassing a struct containing user preferences down a view hierarchy without modification.
    Show the answer

    Answer: a · Creating a shared data model (class) whose properties, when changed, should update multiple views.

    ObservableObject is specifically designed for reference types (classes) that act as a single source of truth for shared data, allowing multiple views to observe and react to changes. Options A, C, and D describe scenarios better handled by @State, standard properties, or immutable data, respectively.

    Read the full bite: ObservableObject: Making Data Drive SwiftUI Views

16. Question 16 of 30

    Which scenario best justifies using UIViewRepresentable in a SwiftUI application?

    • aTo integrate a third-party SDK component that is only provided as a UIKit UIView.
    • bTo convert an entire legacy UIKit application into a SwiftUI application in a single step.
    • cTo simplify the implementation of common UI elements like buttons and text fields in SwiftUI.
    • dTo create highly performant custom drawing views that SwiftUI's native shapes cannot handle.
    Show the answer

    Answer: a · To integrate a third-party SDK component that is only provided as a UIKit UIView.

    UIViewRepresentable's primary purpose is to bridge existing, complex UIKit components into SwiftUI, especially when SwiftUI lacks a native equivalent or for third-party SDKs. Using it for simple views (Option C) is explicitly discouraged, and while it aids migration, it's not a single-step conversion of an entire app (Option B). While UIKit can be used for custom drawing, the card emphasizes leveraging *existing* complex components rather than creating new ones because SwiftUI's shapes are insufficient (Option D).

    Read the full bite: UIViewRepresentable: Bridging UIKit and SwiftUI

17. Question 17 of 30

    Which architectural change in NavigationStack fundamentally fixes the fragility of deep linking and multi-layer pushes that plagued NavigationView?

    • aIntroducing a new visual navigation bar appearance that synchronizes state automatically across view layers.
    • bReplacing per-link isActive boolean bindings with a single explicit array representing the entire route stack.
    • cMoving navigation state into the environment object so individual views no longer need bindings.
    • dAllowing NavigationLink to accept optional tag values that can be chained for complex route sequences.
    Show the answer

    Answer: b · Replacing per-link isActive boolean bindings with a single explicit array representing the entire route stack.

    NavigationStack replaces scattered isActive bindings with a centralized path array, enabling reliable deep linking by mutating a single data structure. Option A reflects the common misconception that NavigationStack is merely a visual or naming update, when in fact it fundamentally changes how navigation state is modeled.

    Read the full bite: What NavigationView limitations did NavigationStack solve for programmatic navigation?

18. Question 18 of 30

    Which approach correctly separates navigation from presentation in a unit-testable conditional wizard for both UIKit and SwiftUI?

    • aEmbed branching logic directly in the view body and view controller lifecycle methods, wrapping a UINavigationController for use in SwiftUI.
    • bUse a UIKit coordinator but manage the SwiftUI stack with local @State variables mutated inside onAppear handlers.
    • cModel the flow as a state machine enum with plain Swift transition logic and derive the UIKit and SwiftUI stacks from that state.
    • dStore the current step in a view model and use NavigationLink isActive booleans in SwiftUI while calling pushViewController from UIKit button actions.
    Show the answer

    Answer: c · Model the flow as a state machine enum with plain Swift transition logic and derive the UIKit and SwiftUI stacks from that state.

    Modeling the wizard as a state machine enum with plain Swift transition logic lets you derive the stack for both UIKit and SwiftUI and unit test transitions without launching a UI. Option B is tempting because coordinators correctly separate UIKit concerns, but relying on local @State inside onAppear handlers still buries imperative navigation inside the view rather than driving it declaratively from the model.

    Read the full bite: Design state-driven navigation for a conditional wizard in UIKit and SwiftUI

19. Question 19 of 30

    What is the primary advantage of implementing the MVVM pattern in a complex SwiftUI view?

    • aIt automatically manages all UI state, eliminating the need for @State or @Binding in the view.
    • bIt ensures all data fetching and persistence logic is handled exclusively by the ViewModel.
    • cIt makes the view's business logic independently testable and keeps the view focused solely on UI presentation.
    • dIt allows the view to become a struct, which inherently improves SwiftUI's rendering efficiency.
    Show the answer

    Answer: c · It makes the view's business logic independently testable and keeps the view focused solely on UI presentation.

    MVVM's core benefit is separating business logic from the UI, making the logic independently testable and simplifying the view's role to just rendering. While MVVM moves much of the state, purely presentational UI state can still reside in the view, so it doesn't eliminate all @State.

    Read the full bite: MVVM: Separate SwiftUI Logic from Layout

20. Question 20 of 30

    When is SwiftUI's TabView the most appropriate UI component to use?

    • aWhen allowing users to navigate between 2-5 distinct, equally important app sections.
    • bWhen displaying more than five primary content areas in a single screen.
    • cWhen presenting a series of steps in a user onboarding flow.
    • dWhen filtering a large dataset based on different criteria.
    Show the answer

    Answer: a · When allowing users to navigate between 2-5 distinct, equally important app sections.

    The card specifies that TabView is ideal for "primary, top-level navigation" with "between two and five main sections." It explicitly advises against using it for secondary navigation or when there are more than five main sections.

    Read the full bite: TabView: SwiftUI's Built-in Tab Bar

21. Question 21 of 30

    Which approach best describes how NavigationStack programmatically manages its view hierarchy?

    • aIt binds to an array of hashable data, where changes to the array reflect the navigation path.
    • bIt uses a global navigation manager to push and pop views based on user actions.
    • cIt directly manipulates the view tree by adding and removing child views as needed.
    • dIt relies on EnvironmentObject to pass navigation state down the view hierarchy.
    Show the answer

    Answer: a · It binds to an array of hashable data, where changes to the array reflect the navigation path.

    NavigationStack is data-driven, using a binding to an array (the 'path') to represent the navigation stack. Modifying this array directly controls the views on screen, unlike imperative global managers or direct view tree manipulation.

    Read the full bite: NavigationStack: Programmatic Navigation in SwiftUI

22. Question 22 of 30

    Which navigation scenario is the primary intended use case for SwiftUI's NavigationLink?

    • aPresenting a temporary, overlaying view that covers the entire screen.
    • bDisplaying a small, transient view anchored to a specific UI element.
    • cSwitching between distinct, top-level sections of an application.
    • dNavigating from a list item to its corresponding detailed information view.
    Show the answer

    Answer: d · Navigating from a list item to its corresponding detailed information view.

    NavigationLink is designed for hierarchical 'push' navigation, such as a master-detail flow where tapping a list item reveals its details. It is explicitly stated not to be used for tab-based navigation (like option C) or modal presentations like full-screen covers (option A) or popovers (option B).

    Read the full bite: NavigationLink: Pushing Views in SwiftUI

23. Question 23 of 30

    When should you prefer NavigationSplitView over NavigationStack for an application's primary interface?

    • aWhen you need to ensure a fixed number of columns are always visible, regardless of the device's screen dimensions.
    • bTo manage complex programmatic navigation and deep linking within a single, non-adaptive view stack.
    • cFor applications that require a multi-column layout to display hierarchical data adaptively across different screen sizes.
    • dWhen the user flow involves a simple, linear progression through a series of screens.
    Show the answer

    Answer: c · For applications that require a multi-column layout to display hierarchical data adaptively across different screen sizes.

    NavigationSplitView is designed for adaptive multi-column layouts that present hierarchical data, automatically adjusting to screen size. In contrast, NavigationStack is suitable for simple, linear flows or single-column hierarchies, making option D incorrect.

    Read the full bite: NavigationSplitView: Adaptive Layouts for All Screen Sizes

24. Question 24 of 30

    You wrap showPanel = true inside withAnimation, and three different views read showPanel. What animates?

    • aOnly views that also have an explicit .animation modifier attached
    • bOnly the view containing the button that called withAnimation
    • cNothing, because withAnimation needs a value parameter like .animation does
    • dAll three views, since each depends on the state changed in the closure
    Show the answer

    Answer: d · All three views, since each depends on the state changed in the closure

    withAnimation animates every view whose body depends on state mutated inside its closure. It is not limited to the call site, and unlike .animation(value:) it takes no value argument.

    Read the full bite: Implicit .animation() vs explicit withAnimation

25. Question 25 of 30

    An app needs a single NavigationStack where users can navigate from a Category screen, to a Product screen, to a Review screen, three unrelated model types, and wants to build and restore that exact path programmatically from a push notification. Why is NavigationPath the right tool over a plain array based path?

    • aNavigationPath is required because NavigationStack cannot be initialized with an array at all
    • bNavigationPath can hold a single ordered stack of mixed, unrelated Hashable types and reconstruct them, while a typed array path is limited to one concrete type for the whole stack
    • cNavigationPath automatically shows a back button while array based paths do not support back navigation
    • dNavigationPath is only needed for tab based navigation, not stack based navigation
    Show the answer

    Answer: b · NavigationPath can hold a single ordered stack of mixed, unrelated Hashable types and reconstruct them, while a typed array path is limited to one concrete type for the whole stack

    NavigationPath's core feature is type erasure across a single stack, which is exactly what mixing Category, Product and Review in one path requires. Option B is wrong since NavigationStack does support a plain typed array as its path for simpler, single type flows, and option C is wrong because the back button comes from NavigationStack itself, not from which path type backs it.

    Read the full bite: NavigationPath (SwiftUI)

26. Question 26 of 30

    Why can't SwiftUI animate directly between a triangle Shape and a pentagon Shape, and what makes animatableData work instead?

    • aShape paths are immutable, so only color can animate
    • bThere is no vertex correspondence between mismatched paths; animatableData interpolates one numeric parameter that regenerates the path
    • cShapes are value types, so the animation system copies them and loses state
    • danimatableData stores both completed paths and crossfades their pixels
    Show the answer

    Answer: b · There is no vertex correspondence between mismatched paths; animatableData interpolates one numeric parameter that regenerates the path

    Two paths with different point counts have no defined point-to-point mapping to tween. animatableData exposes a single VectorArithmetic value SwiftUI interpolates, and path(in:) rebuilds geometry for each intermediate value, producing the morph.

    Read the full bite: Animate a SwiftUI Shape morphing point count

27. Question 27 of 30

    What is the main tradeoff of using Canvas instead of composing regular SwiftUI views like Shape or Path views?

    • aCanvas skips the view tree for speed, but loses per element accessibility, hit testing, and implicit animation
    • bCanvas is slower than composed views because it re-renders on every state change regardless of what changed
    • cCanvas cannot render text or images, only vector paths
    • dCanvas only works inside a List or ScrollView and cannot be used standalone
    Show the answer

    Answer: a · Canvas skips the view tree for speed, but loses per element accessibility, hit testing, and implicit animation

    Canvas trades away the per element view tree, so individual drawn shapes are not accessible or hit testable and cannot animate independently, which is exactly what you give up for the performance win. It can render text and images through GraphicsContext.draw, and it works standalone.

    Read the full bite: Canvas in SwiftUI

28. Question 28 of 30

    A developer puts an expensive image-processing computation inside a custom GeometryEffect's effect(size:) function to drive a transform. What is the most likely consequence?

    • aA compile-time error, because effect(size:) is not allowed to contain computation beyond returning a ProjectionTransform
    • bThe animation automatically runs on a background thread, so the main thread stays unaffected regardless of the work done
    • cNo consequence, because effect(size:) only runs once when the animation starts and once when it ends
    • dVisible jank, because SwiftUI calls effect(size:) on every single frame of the animation, potentially over a hundred times a second
    Show the answer

    Answer: d · Visible jank, because SwiftUI calls effect(size:) on every single frame of the animation, potentially over a hundred times a second

    SwiftUI calls effect(size:) on every frame of an animation to recompute the transform for that instant, so expensive work there directly costs frame time and causes visible stutter. It does not run just twice, there is no such compile restriction, and GeometryEffect's computation runs on the main thread along with the rest of view rendering, not automatically backgrounded.

    Read the full bite: GeometryEffect

29. Question 29 of 30

    Which scenario best illustrates the core benefit of implementing SwiftUI Theming with the Environment?

    • aFacilitating complex data binding and state management across different view hierarchies.
    • bProviding a secure mechanism for passing sensitive user preferences throughout the app.
    • cOptimizing the rendering performance of deeply nested custom views.
    • dEnabling an entire application's visual appearance to be dynamically updated from a single source.
    Show the answer

    Answer: d · Enabling an entire application's visual appearance to be dynamically updated from a single source.

    The card states that theming allows "an entire app's look and feel to change by swapping out a single 'theme' object," which directly aligns with dynamically updating appearance from a single source. While the Environment can pass data, its core benefit for theming is about centralized style management, not general data binding or performance optimization.

    Read the full bite: SwiftUI Theming with the Environment

30. Question 30 of 30

    A SwiftUI detail view keeps stale @State when the selected item changes. Which approach correctly forces fresh state per item?

    • aWrap the view in a Group, which resets identity automatically
    • bAttach .id(item.id) so each item gives the view a distinct identity, resetting its state
    • cCall onAppear to manually clear every @State field
    • dMake the view struct conform to Equatable so SwiftUI diffs it by value
    Show the answer

    Answer: b · Attach .id(item.id) so each item gives the view a distinct identity, resetting its state

    Changing explicit identity via .id() makes SwiftUI treat it as a new view and reset @State. Equatable affects re-evaluation, not identity, so it would not reset the state.

    Read the full bite: View identity in SwiftUI and the .id() modifier