“SwiftData inheritance relationship”

You haven’t provided the details about CollectionItem which seems to be the class that causes the crash but I must say that it’s a very strange design you have where the superclass both has a children property of self and is being inherited. Do you really need such a complex solution?

@DTS Engineer thank you for these suggestions. I've added the full crash report from Crashlytics to this post. After enabling the launch argument you suggested, I managed to reproduce the crash in the debugger once, so that's some progress. After enabling Swift 6 and complete concurrency checking, I got some build errors in the class owning the ModelActor. Wherever I accessed the ModelActor, I got this error: Sending 'self.localStorage.some' risks causing data races. As mentioned in my original post, the ModelActor conforms to a protocol because I am using another type of storage in iOS 16 which doesn't support SwiftData. This protocol didn't require that conforming types were Actors, leading me to suspect that the class owning the ModelActor didn't treat it as an actor, because it only know about the protocol. Adding the Actor requirement to the protocol, removed the build errors in the owning class. Now, I have to ship this change to confirm that it actually fixes it, since I cannot reliably reprod

I decided to run this task on app launch to sync the clinical labs into the SwiftData store. This allows me to use Query macro in the views where it's needed and no need to combine lab results. Let me know if this is the right approach: import SwiftData import SwiftUI import OSLog @ModelActor actor HealthKitSyncManager { private let logger = Logger(subsystem: com.trtmanager, category: HealthKitSyncManager) func sync() async { do { // Get all Clinical labs let hkClinicalRecords = try await TRTHealthKitService.getHKClinicalRecords() guard !hkClinicalRecords.isEmpty else { return } // Get existing HealthKit IDs in one query let descriptor = FetchDescriptor( // predicate: #Predicate { $0.source == .clinicalRecord } ) let existing = try modelContext.fetch(descriptor) .compactMap { $0.fhirResourceId } let existingIDs = Set(existing) let missingRecords = hkClinicalRecords.filter { lab in guard let fhirResource = lab.fhirResource else { return false } return !existingIDs.contains(fhirResource.identi

Do you have a full symbolicated crash report to share? You can include crash reports directly in your post using the forums attachment feature. For any random crash related to SwiftData / Core Data, I'd suggest that you add com.apple.CoreData.ConcurrencyDebug 1 as a launch argument of the app to check if there is any violation, as discussed here. Also, I guess ConsumptionSession is Sendable? Otherwise, Xcode will give you an error if you compile with Swift 6. If you haven't used Swift 6, I'd suggest that you give it a try to see if that unveils any race condition. Best, —— Ziqiao Chen  Worldwide Developer Relations.

It's unclear what LabResultDto in the code snippet is. If it is a Sendable type that wraps the data in a SwiftData model, that's fine; if it is a SwiftData model type, because a SwiftData model object is not Sendable, you won't want to pass it across actors – Otherwise, Swift 6 compiler will give you an error. For more information about this topic, see the discussion here. When using SwiftData + SwiftUI, I typically use @Query to create a result set for a view. Under the hood (of @Query), the query controller should be able to detect the changes you made from within a model actor, and trigger a SwiftUI update. Fore more information about observing SwiftData changes, see this WWDC25 video. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thank you @Aloisius for your following up. I'd like to confirm that you are right, and I was wrong. SwiftData does use a temporary identifier for a model that is not persisted yet. The identifier is converted to a permanent one when the model is saved. In the case of using transaction(block:), the transaction takes care the saving, and so the identifier does change when the scope goes outside the transaction block. This behavior originates in Core Data (SwiftData DefaultStore is based on Core Data). Core Data provides a way to obtain a permanent ID for a managed object (obtainPermanentIDs(for:)), while SwiftData doesn't, and so I was in an impression that persistentModelID had eliminated the difference – That is actually wrong. I've removed my previous reply to avoid confusing people. Sorry for that. Saving a model makes the model's persistentModelID permanent. Assuming that I need to set up an object graph in a transaction, I'd probably consider the following: Create the root item

What you observed is the behavior that the framework currently has – If you save the model context right after adding a book, you will see that the relationship turns from nil to [] immediately, and that's because SwiftData makes the change when persisting the model. SwiftData does that because the default store (DefaultStore) is based on Core Data, and Core Data expresses an empty toMany relationship with an empty set. (Core Data had been implemented with Objective C long before Swift was introduced.) Having said that, if you have a different opinion about the behavior, feel free to file a feedback report – If you do so, please share your report ID here. Thanks. Best, —— Ziqiao Chen  Worldwide Developer Relations.

It's best to use @Query to fetch data when working with UI, like in this case. ModelActor is is meant to work on background operations. But SwiftData is also fundamentally broken when merging changes between background and foreground contexts. I would avoid at all costs.