This is untested and probably has problems, but this approximates what I meant: import SwiftData import SwiftUI struct ReadingViewModifier: ViewModifier { @Query private var books: [Book] @State private var manager: ReadingManager func body(content: Content) -> some View { content .environment(\.readingManager, manager) .onChange(of: books) { manager.receive(books: books) } } } Inside another component, you can read the manager with: @Environment(\.readingManager) private var manger: ReadingManager

I am so late to this that I don't know whether it's useful, but the approach I take is having an observable as you did, but rather than trying to query there, just include a receive(books: [Book]) function that takes the query results from the SwiftUI view with the query and updates the @State var books: [Book] = [] state in the observable. You can feed the results from that view into the observable whenever something changes. You could also take it a step further and create a custom modifier that runs the query, passes it into the observable, then binds the observable into the environment. If anyone is interested in the approach, let me know and I can put together some sample code for it.

I am jumping in late to this discussion, and I am ignoring a couple details at this point until can I re-read a few times, but I did experience the same issue when attempting to attach a sheet to Buttons inside a List. It was about the same behaviour, with the sheet closing the first time it was opened, then it behaved reliably afterward. I spent time looking into making sure the items had a stable identity, but never found a way around the issue. I don't like the usage as much, but I ended up just moving the sheet outside the custom component and above the List, and everything is working as expected now. I was thinking there was something going on with 2-way binding and race conditions, and maybe something being managed based on animation completions (imagining something in a bridging layer to UIKit), but didn't dig into the thought too much. Also, I still know much more about React and other reactive JS setups than SwiftUI, though that's trending in the right direction. As a side note, I am curious about the package dependency that you're using and whether there are alternatives there. Again, not sure how helpful this is, but it might be something they're going to need to change if the view is used commonly inside Lists or other lazy containers. If you end up forking the package to attempt to adjust for your purposes, I would be interested in seeing it. I suppose it's just my long-winded way of saying you're not alone in the issue. I fought with the same problem for about a week before just accepting the muddier (though maybe better) state ownership and re-organizing the sheets/alerts/etc to exist outside the container.

In case anyone is interested, I landed on a solution where I listen for NSManagedObjectContextObjectsDidChange notifications, stopping background tasks when changes have been detected in the userInfo. I needed to update those tasks so they could be cancelled, and created a couple unit tests to confirm the behaviour.