NSPersistentCloudKitContainer

Just to add that SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the technotes my colleague mentioned apply to your topic. Specifically, you can use CloudKit Console to determine if the data is synchronized to CloudKit. From there, you can determine if the issue happens on the exporting or importing side, and go ahead to capture and analyze a sysdiagnose, as described in the Capture and analyze a sysdiagnose section. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Our general set of debugging / inspection Tech Notes are: https://developer.apple.com/documentation/technotes/tn3163-understanding-the-synchronization-of-nspersistentcloudkitcontainer https://developer.apple.com/documentation/technotes/tn3162-understanding-cloudkit-throttles https://developer.apple.com/documentation/technotes/tn3164-debugging-the-synchronization-of-nspersistentcloudkitcontainer

Thanks so much, @tbartelmess1—this is super helpful, and really appreciated a bit more context from our app: App context (what we store) The blobs we persist will be user-generated cruise photos, we would downsize those to more manageable size as iphone format photos can be quite big, but they would still be in the 1-3 mb after downsizing Realistic volume per active user: a few hundred images/year; heavy users could reach low thousands over time. Decision: use Core Data Binary Data + “Allows External Storage” We’ll keep originals as Binary Data (Allows External Storage) so Core Data handles externalization transparently, my philosophy has always been to offload as much work to the system services as possible. We’ll keep thumbnails as well inline in coredata (let coredata decide but likely will be inline (blob)). CloudKit mirroring We’ll rely on NSPersistentCloudKitContainer mirroring; we understand CloudKit decides when an attribute becomes a CKAsset independently of Core Data’s externalization thres

You might start with the following technote section: Present the latest data If that doesn't immediately help, the following technotes cover the details about how CoreData + CloudKit works and how to debug a synchronization issue: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3164: Debugging the synchronization of NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.

If you are using SwiftData + CloudKit in both your main app and extension, which uses NSPersistentCloudKitContainer under the hood, I'd start with pointing you the following technote: Avoid synchronizing a store with multiple persistent containers Please feel free to follow up with further questions, if any. Best, —— Ziqiao Chen  Worldwide Developer Relations.

SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, which requires all relationships must be optional. For more information, see Creating a Core Data Model for CloudKit. The requirement exists because of the latency of the synchronization: When you create an object graph in device A, which is being synchronized to device B, the system doesn't guarantee to synchronize the whole graph all at once. As a result, it's possible that an object is synchronized but its relationship is not. This situation is expressed as the relationship being nil. By checking if the relationship is nil, the app instance running on device B can consume the object appropriately. In your case, wrapping a relationship with a computed property to return an empty array if nil makes sense to me, if the other part of your app prefers to consume an empty array. It doesn't matter if the data is big or small. Best, —— Ziqiao Chen  Worldwide Developer Relations.

'Error' occurred after updgrading from 16.4 to 26 Importing combine solves the problem of an empty class XYZ: ObservableObject When using CoreData in a Swift App, I was used to have a Class 'DataController : ObservableObject' to manage the CoreData Stack. In the past I was used to only import CoreData and everything works fine: // // Observable Object to enable Access to CoreData within the App // therefore include in @main: // ... 1. @StateObject var dataController = DataController() // ... 2. ContentView() // .environment(.managedObjectContext, dataController.container.viewContext) // .environmentObject(dataController) import CoreData class DataController: ObservableObject { let container: NSPersistentCloudKitContainer init() { container = NSPersistentCloudKitContainer(name: Main) container.loadPersistentStores { storeDescription, error in if let error { fatalError(Fatal error loading store: (error.localizedDescription)) } } } // DO some stuff here func save() { if container.viewContext.ha

An app and its extensions can share a SwiftData store located in a shared App Group container. The following Apple sample demonstrates that: Adopting SwiftData for a Core Data app The discussion in this post may help as well, if you have any data update issue. CloudKit integration adds more complexity on this topic. You can start with checking if this post helps. SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the content applies. Best, —— Ziqiao Chen  Worldwide Developer Relations.

You might want to check if this post answers your question. SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the content applies. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Did you wait some time to make sure the error didn't pop up? It might take a minute or two. Try inserting a record then re-running and waiting a few minutes. Yeah, I've tried waiting until seeing the new record being synchronized across my devices, and haven't seen the issue. NSKeyedUnarchiveFromData is the default transformer and comes to play when you use a Core Data / SwiftData transformable attribute without explicitly specifying a transformer. Unless you are using a transformable attribute, it shouldn't be engaged. My best guess is that your CloudKit schema / data contains something that needs a transformer (due to your historical changes?), and that triggers the error when NSPersistentCloudKitContainer tries to synchronize the data from the server to your device. If that is the case, consider cleaning up the schema and data on the CloudKit server. Assuming you are on the CloudKit development environment, you can remove the existing schema and data by resetting the environment, and then re-creat

In CloudKit development environment, when your app creates a record, CloudKit automatically creates the record type, if it doesn’t exist. With that, if you ever persist (at least) an instance for each of your SwiftData type, and the instance is pushed to CloudKit, the CloudKit schema will have the record type for you. Otherwise, the record type will be missed. initializeCloudKitSchema(options:) works by creating a set of representative records, uploading them to CloudKit, and removing them. This may help if it is indeed that no instance of your new SwiftData type has ever been uploaded to CloudKit. Note that even initializeCloudKitSchema(options:) can miss something, and that is why I called out the following: After running the target, use CloudKit Console to ensure each Core Data entity and attribute has a CloudKit counterpart. See Reading CloudKit Records for Core Data for the mapping rules. The documentation discusses how NSPersistentCloudKitContainer maps a Core Data model to a CloudKit schema,

Your crash report is only partially symbolicated. To be completely clear what happened in your app, you might consider fully symbolicating your report. The details of how to do so is covered in this article. Having said that, your crash report indicates that the main thread (thread 0) was blocked when SwiftUI initialized a tab view (frame 8). Your app got involved into the process (frame 4, 5), and eventually ran into _dispatch_once_wait (frame 3) and __ulock_wait (frame 0): Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1df207f70 __ulock_wait + 8 1 libdispatch.dylib 0x196334c3c _dlock_wait + 56 2 libdispatch.dylib 0x196367408 _dispatch_once_wait.cold.1 + 148 3 libdispatch.dylib 0x196334b98 _dispatch_once_wait + 60 4 MyApp 0x10047b7d4 0x100360000 + 1161172 5 MyApp 0x100563524 0x100360000 + 2110756 6 SwiftUI 0x19369cbd4 Tab<>.init<>(_:systemImage:value:content:) + 300 7 MyApp 0x1005628a8 0x100360000 + 2107560 8 SwiftUI 0x1931b5780 TabView.init(sele

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  Wor