The PersistentIdentifier is basically an abstraction over the DB primary key, it's a Struct consisting of the storeId, the entity name, and the primary key. You can normally use PersistentIdentifiers in SwiftData predicates, so you can do { post in post.persistentModelID == aModelIdIAmLookingFor } I cannot use the Category directly in the predicate, since it is an Optional. SwiftData predicates have problems comparing Optionals, such things only tend to work if you provide a default value before the comparison, e.g. (optionalString ?? "") == someNonOptionalString. After some debugging, I have discovered that what is causing the issue, is not the PersistentIdentifier itself, but the if-let clause with the PersistentIdentifier. Thus, performing the optional binding with Category instead of the PersistentIdentifier makes it work: if let cat = $0.category { return categoryIds.contains(cat.persistentModelID) }

Thank you, I will file a feedback report about this. Is there, by the way, any way to disable the context menu preview and the preceding press animation (that in my case, shrinks the long pressed view to the wrong (unscaled) size) altogether?

Thank you for response, I've reported this under the ticket number FB16448657

Update: the problem occurs when the app goes to the background, comes back, and SwiftUI tries to access relationships of SwiftData models that are direct input parameters to the View. My app has a function that opens a URL in a browser, it is when you press the Back button and return from the browser to the app that this fatal error tends to occur. When the app goes to the background, the BackingData of every relationship of this main model seems to get replaced with some subclass of "FutureBackingData". Accessing them results in the fatal error above. Explicitly querying the relationship with @Query instead of relying on the relationship property seems to solve the problem. It would be great to have some documentation on how exactly SwiftData is behaving when the app goes to the background.

Indeed, I could reproduce this. It seems that the ModelContext injectable via the @Environment in document based apps does not autosave. That is, one needs to manually call modelContext.save(). (This is contrary to non-document based apps, where the main context autosaves by default, see here: https://developer.apple.com/documentation/swiftdata/modelcontext/autosaveenabled). One would need to look into the architecture of the DocumentGroup in detail, but my intuition would be that what you inject via the @Environment, in this case, is not a MainActor-bound ModelContext, but a Scene scoped one, since you can have multiple documents open at the same time.