If you have spent any significant time building apps with SwiftData, you have inevitably run into the brick wall that is dynamically updating a @Query.

It usually happens when you try to do something completely mundane, like filtering a list based on a search bar or a user selection. You instinctively try to pass a variable into the view’s initializer to update the fetch descriptor, only to be met with a wall of compiler errors or completely frozen data.

To understand why this happens and how to fix it, we have to look at a fundamental design tension in SwiftUI: Property Wrappers vs. View Containers. 

The Core Frustration: The @Query Init Trap

When you declare a query in SwiftData, it looks elegant and declarative:

Swift

@Query(sort: \Item.timestamp, order: .reverse) 
private var items: [Item]

But what happens when the user types into a search text field, and you need to apply a dynamic Predicate? You might try to rewrite the query inside the view’s initializer:

Swift

struct InventoryList: View {
    @Query private var items: [Item]
    
    init(filterText: String) {
        // ❌ Compiler Error: Append-only or immutable state traps
        let predicate = #Predicate<Item> { $0.name.contains(filterText) }
        _items = Query(filter: predicate) 
    }
}

This fails because @Query is a property wrapper whose storage lifecycle is strictly managed by SwiftUI outside of your view’s initialization pass. By the time init runs, the backing storage (_items) has already been wired up to the framework’s internal AttributeGraph. Trying to re-assign it on the fly breaks the compiler’s safety guarantees.

To update a query dynamically using native tools, Apple forces you to extract the entire rendering layout into a separate child view, passing the dynamic parameter down to force a hard structural recreation. It works, but it pollutes your codebase with boilerplate views whose only job is to bridge data.

Why Was It Designed This Way?

Why did Apple choose a property wrapper for SwiftData instead of giving us a dedicated view container? It all comes down to Data Flow Scope and Xcode Previews.

A database query isn’t just used to render items in a loop; it often drives structural logic across the entire screen. By placing @Query at the very top of the view struct, the fetched array is instantly available to every single layout modifier in your body:

Swift

@Query var items: [Item]

var body: some View {
    List(items) { ... }
        // Clean scope access to calculate layout geometry
        .navigationTitle("Items (\(items.count))") 
        .disabled(items.isEmpty)
}

If the query were buried inside a closure, accessing items.count to update a navigation title on the parent container would become a nightmare of pass-through bindings. Furthermore, a property wrapper allows Apple’s macro engine to seamlessly look up the @Environment(\.modelContext) injected at the window level, making it incredibly fast to spin up mock data for Xcode Previews.

The Elegant Alternative: Turning Data Into a View

But Apple has already shown us a better architectural pattern elsewhere in the framework: TimelineView.

When you need high-frequency time updates (like a ticking clock or a stopwatch), Apple doesn’t give you a @Timelineproperty wrapper that invalidates your entire view every second. Instead, they give you a TimelineView container. This localizes the high-frequency updates to a specific node in the rendering engine, preventing wide-scope parent layout thrashing.

What if we applied that exact same philosophy to database queries? We can build a custom QueryView that acts exactly like TimelineView, safely isolating the fetch logic into its own container.

Building the QueryView

Swift

struct QueryView<Model: PersistentModel, Content: View>: View {
    @Query private var items: [Model]
    let content: ([Model]) -> Content
    
    init(descriptor: FetchDescriptor<Model>, @ViewBuilder content: @escaping ([Model]) -> Content) {
        self._items = Query(descriptor)
        self.content = content
    }
    
    var body: some View {
        content(items)
    }
}

Solving the Paradox with the Overlays Trick

Once you shift your mindset to treating data fetches as view containers, you can use your layout structure to elegant effect. Instead of using if/else statements that completely destroy view identities, you can use a combination of your QueryView and the .overlay modifier to handle complex layouts cleanly.

Look at how beautifully your parent view code reads when you move the query logic up and drive states via overlays:

Swift

struct InventoryScreen: View {
    var searchText: String
    
    var body: some View {
        // 1. Construct the fetch descriptor dynamically right in the layout pass
        let descriptor = FetchDescriptor<Item>(
            predicate: #Predicate { $0.name.contains(searchText) }
        )
        
        // 2. Wrap the view tree in our custom data container
        QueryView(descriptor: descriptor) { items in
            // 3. Always render your primary structural container first
            List(items) { item in
                Text(item.name)
            }
            // 4. Modifiers apply upward and inward seamlessly
            .navigationTitle("Items (\(items.count))")
            // 5. Handle empty states gracefully without tearing down view identity
            .overlay {
                if items.isEmpty {
                    ContentUnavailableView(
                        "No Matches", 
                        systemImage: "magnifyingglass", 
                        description: Text("Try checking your spelling.")
                    )
                }
            }
        }
    }
}

Conclusion: Architectural Harmony

By shifting the data-fetch engine out of a property wrapper and into a dedicated view container wrapper, we unlock three massive wins:

1. Perfect Reusability: QueryView doesn’t care if you’re rendering a List on iOS, a LazyVGrid on macOS, or a custom Canvas. It is a pure data injector.
2. Dynamic Freedom: Because the fetch descriptor is evaluated during the parent layout pass, passing dynamic filters or sort orders into the container becomes trivial.
3. Identity Preservation: Using an .overlay to manage empty states ensures SwiftUI never destroys the structural state or identity of your primary views, resulting in flawless, buttery-smooth transition animations.

The property wrapper approach of @Query is great for quick prototyping, but when your app demands dynamic agility, wrapping your data in a view container is the ultimate architectural upgrade.