NSPersistentCloudKitContainer

Thank you, this is very helpful. To confirm we're aligned: Open the database in read-only mode If loadPersistentStores fails, try it again in read-write mode If that succeeds destroy those CoreData object and do a read-only open again If that fails show an error message to the user destroy those CoreData object Is that accomplished via container.persistentStoreCoordinator.destroyPersistentStore, so all together like so? let container = NSPersistentCloudKitContainer(name: AppName) let sharedStoreURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: group.com.domain.appname)!.appendingPathComponent((container.name).sqlite) guard FileManager.default.fileExists(atPath: sharedStoreURL.path) else { // Show error to user return } let description = container.persistentStoreDescriptions.first! description.url = sharedStoreURL description.isReadOnly = true container.loadPersistentStores { description, error in if let error { container.persistentStoreDescriptions.first?.isReadOnly = fals

Hi, and thank you for the quick response. It's greatly appreciated! Unfortunately, this crash does not appear to generate a crash log. However, we're able to reproduce it consistently on two separate Apple Watch devices. When using NSPersistentCloudKitContainer and the device is offline (no Wi-Fi and no Bluetooth), the app crashes when entering the background. If we switch to NSPersistentContainer, no crash occurs under the same conditions. If the device is online, no crash occurs, even when using NSPersistentCloudKitContainer and allowing the app to enter the background. If we keep the app in the foreground (e.g., by continuously tapping the screen), the app also does not crash, even when offline and using NSPersistentCloudKitContainer. So in summary, the crash consistently occurs under the following three conditions: Using NSPersistentCloudKitContainer Device is offline (no Wi-Fi, no Bluetooth) App transitions to the background. We would appreciate any insight, particular

I'm sorry, I thought I'd already replied to this... destroyPersistentStore isn't the right API that deletes the data lol Can you clarify what you mean by destroy those CoreData objects? What I mean by destroy here is get rid of your reference to the read/write NSPersistentCloudKitContainer object. That will then: Free up some memory (minor benefit). Ensure that you can't accidentally get a read/write object reference, since your app won't have a reference to the object that COULD have given you one. (major benefit). In code level terms, this would mean either NULL out a var reference or having the let go out of scope. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thanks a lot, Ziqiao, for your quick response. You’re absolutely right – I now realize that .shared CloudKit containers are not yet supported with SwiftData. In my implementation, I attempted to use a SwiftData model with a ModelContainer(for:sharing:) configuration and used UICloudSharingController to manage sharing between Apple IDs. The ModelContainer was configured like this: @main struct FoodGuardApp: App { var body: some Scene { WindowGroup { ContentView() } .modelContainer(for: FoodItem.self, configurations: [ ModelConfiguration(Default, cloudKitDatabase: .shared) ]) } } The sharing worked locally (between users in the same Apple ID), but failed when another Apple ID accepted the share, producing this error: CKError: Bad Container (5/1014) Couldn't get container configuration from the server for container iCloud.com.de.seki.FoodGuard Based on your reply and DTS confirmation, I now plan to migrate my project to Core Data + CloudKit, using NSPersistentCloudKitContainer and UICloudSharingControll

This was helpful, I wasn't able to find much this failure. The formatting of your code block didn't work, lets see if I can paste your snippet and get the formatting better: let bundle = Bundle.module let modelURL = bundle.url(forResource: ModelName, withExtension: .momd)! let model = NSManagedObjectModel(contentsOf: modelURL)! let container = NSPersistentCloudKitContainer(name: ModelName, managedObjectModel: model) My situation was a little different, a test case target that wasn't finding the model for some reason, and Bundle.main wasn't right, that was some test runner process embedded in Xcode.app, . To find the right one I have to dive into allBundles with let bundle = Bundle.allBundles.first(where: { $0.bundleURL.pathExtension == xctest }): guard let bundle = Bundle.allBundles.first(where: { $0.bundleURL.pathExtension == xctest }) else { fatalError(can't find test bundle containing model) } guard let modelURL = bundle.url(forResource: Storage, withExtension: .momd) else { fatalError(can't find

This topic is discussed in the following technote section: Avoid synchronizing a store with multiple persistent containers. The technote is about NSPersistentCloudKitContainer. As of today, SwiftData (DefaultStore) + CloudKit uses NSPersistentCloudKitContainer under the hood, and so the content applies. Basically, the use case of sharing a CloudKit-back store between a main app and its extension and synchronizing with NSPersistentCloudKitContainer isn't quite supported, and so you might consider avoiding do that. Best, —— Ziqiao Chen  Worldwide Developer Relations.

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

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

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,

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

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.

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.

'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

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.