“SwiftData inheritance relationship”

Even though this doesn’t provide a direct solution for cross-device real-time database persistence, it may simulate the behavior you’re looking for. If both devices are on the same network, you can leverage the MultipeerConnectivity framework to send data to other devices immediately and then persist it locally. This way you can achieve a “live update” experience within the Apple ecosystem, while still using SwiftData for storage.

The original post had been a year ago, and had run out of my radar since then, until this new post brought this back, thanks to @jenyalebid. If simply creating a SwiftData model container with CloudKit integration, which kicks off the initialization of NSPersistentCloudKitContainer under the hood, causes the hang, I'd suggest that you start with filing an actionable feedback report, because the initialization is not supposed to be a long task. SwiftData + CloudKit integration is based on NSPersistentCloudKitContainer, and so folks can follow the tips described in the following technote to analyze if there is anything goes wrong in the initialization phase: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer If somebody can share a minimal project, with detailed steps, that reproduces the issue, I'd be able to take a look as well. The orignal post does contain a link, but it has been a year, and I am not sure if the issue is the same. Best, —— Ziqiao Chen  Worldwide De

I don't have a lot to say about implementing a real-time data persistence system cross devices, but just to confirm that CloudKit isn't a real-time system, and so SwiftData / Core Data + CloudKit integration is not real time either, as you have found out. To optimize the overall experience, CloudKit even implemented a mechanism to throttle requests, if the rate is too high, as discussed in TN3162: Understanding CloudKit throttles. And yes, a custom data store will be the way to go, if you would use SwiftData. You need to take care the real-time synchronization part when going along this path. There is no system-provided framework specifically for that purpose. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Could anyone from Apple weigh in on this? this is a real and easily reproducible issue. on active scenePhase, if CloudKit, specially SwiftData, is enabled… there is a noticeable hang first few seconds. I am assuming it has to do with the @Query sync with remote.

So, the first thing to understand here is that the IOKitPersonalities is called that because it IS in fact a fully valid IOKitPersonalities dictionary. That is, what the system actually uses that dictionary for is: Perform a standard IOKit match and load cycle in the kernel. The final driver in the kernel then uses the DEXT-specific data to launch and run your DEXT process outside the kernel. So, working through the critical keys in that dictionary: IOProviderClass-> This is the in-kernel class that your driver loads on top of. In your case, that would be IOSCSIPeripheralDeviceNub or one of its variants. IOClass-> This is the in-kernel class that your driver loads on top of. This is where things can become a bit confused, as some families work by: Routing all activity through the provider reference so that the DEXT-specific class does not matter (PCIDriverKit). Having the DEXT subclass a specific subclass which corresponds to a specific kernel driver (SCSIPeripheralsDriverKit). This distinction is descr

Nice to know that the original issue goes away in the latest Beta. Regarding the crash triggered by the access to Item.children, if you can provide a runnable code snippet to demo the issue, I'll take another look. You have mentioned a few classes with inheritance, and so I think it is probably worth mentioning that over-using inheritance may impact your app's performance negatively. Concretely, with today's default store (DefaultStore), all the types in an inheritance hierarchy are persisted with one single table in SQLite. If your inheritance hierarchy has many classes, the table (columns and data) can be quite big, which can slow down the performance of fetching and inserting data. That being said, when adopting SwiftData inheritance, you might examine if that is a right use case. This WWDC25 session(starting from around 4:25) covers this topic a bit. You can take a look, if haven't yet. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I’m not sure of your relationship to niggeulimann, but I responded to their copy of this question over on this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Ziqiao, I've tried with iOS 26 Beta 7 and since Beta 8 (landed tonight) on device (because my Xcode is stuck on iOS Beta 6, don't know why) and the problem is solved. I can now query CollectionItem with predicate that contains inherited properties. Now I have only got problems with accesses to the children property in List. When i got the following hierarchy and the SwiftUI view List access to the Item.children property I got another kind of crash. Category: Work (parent: none) Category: Tech (parent: Work) Thread 1: Fatal error: Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0x9872c0007ba42159 ))) with Optional(7639D151-5D48-46AC-AB2A-7F0F50919AC5) But I guess it's a different kind of problem now.

it would be helpful to see a small test project that has the relationship between your navigation toolbar and the content view set up the same way as your real app and see if you get the same results. If so, please provide a link to that test project. — Ed Ford,  DTS Engineer

There are some subtle things that determine if a change on a SwiftData model is observable, as discussed in this WWDC25 session (starting from around 14:00.) Your code snippet doesn't show where the folder in FolderView is from and how you add a new item. If you can share a runnable code snippet that demonstrates the issue, I'd be able to figure out why folder doesn't trigger an update. Best, —— Ziqiao Chen  Worldwide Developer Relations.