NSPersistentCloudKitContainer

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

I've tried to implement some code for sharing manually with working CloudKit + CoreData mirroring. I've stuck on the parent records (I have one-to-many relationship and child records need to be shared when parent record is shared) and here is why. I've implemented code that is setting parent records for each NSManagedObject's CKRecord, syncing works well, but it causes huge troubles like: I call my setParentRecords among other places from NWPathMonitor's pathUpdateHandler (literally when internet restored), and fetching NSManagedObjects that's CKRecords if any don't have parent on the server yet. Apple's NSCloudKitMirroringDelegate is doing the same also on internet restore. And my any fetching at this second causes crash of Mirroring. Mirroring do not work since this point and says probably no internet each time! I could not beat that problem and I am afraid that will have to implement whole sync by myself, even for privateDatabase just because of such bugs (and no any completion handlers in NSPersistentCloudKitContainer

You wrote: [objectID] certainly changes from run to runI'm not seeing that. It seems to be completely consistent. I was using `objectID.uriRepresentation()` to implement `Identifiable`, and the docs for `uriRepresentation` say it is archivable, which suggests to me that it doesn't change. (?) I'm using `NSPersistentCloudKitContainer`, if that matters.I think that what's getting me now is...ForEach(dataSource.fetchExercises(moc:moc)) { ex in NavigationLink(destination: ExerciseView(exercise: ex)) { ListItemView(exercise: ex) } }If that detail view (ExerciseView), changes the exercise in way that should _reorder_ the results of fetchExercises and the ForEach, then I make `dataSource` (which is an observable object) emit `objectWillChange`. As expected, SwiftUI re-calls `fetchExercises`. But sadly, it pops off the detail view (ExerciseView) and returns to this list view.I thought it should see that the exercise objects have the same IDs, so it would keep the ExerciseView pushed.I too am interested to se

Is there a way to get the container from a device NOT having Xcode or Development tools if they can connect to a Mac? Not that I am aware of. Many of whom DO NOT use iCloud which is also weird. A few using iCloud but most are NOT. Any thoughts on why that might be? If the impacted users didn't use iCloud, you can rule out CloudKit, which will simplify the issue a bit. However, I still can't say anything for sure – Debugging a random data loss can be hard and my sitting here and guessing won't be helpful. To eventually figure it out, you might consider reaching out the impacted users to hopefully find more hints, or ideally, create a reproducible case. now it is almost as if a user has NSPersistentCloudKitContainer options set to nil and the data is deleted. Can you confirm or provide a link to documentation confirming? Setting the CloudKit option to nil does not delete the data in the existing Core Data store. Best, —— Ziqiao Chen  Worldwide Developer Relations.

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

I've posted a suggestion for a sync enabled/disabled switch on NSPersistentCloudKitContainer through the feedback tool (FB8571301). This is the reply I got: We do not encourage applications to implement their own sync controls. The user can control the sync state of an application using the iCloud Preferences in the Settings app. The problem is that the iCloud preferences in the settings app are rather hidden.. And there is no way to directly link to this page from my app. There are inherent ownership challenges with toggling between synced and unsynced data. For this reason we recommend using a separate persistent store to hold unsynced data separately from the user’s iCloud data. This is necessarily a heavy-weight operation, the local store must be added and the cloud store removed when the user disables sync. You can customize the persistent store descriptions of a container after it is initialized. For example, you can set the store descriptions on it immediately, which will prevent the default d

Syncing large data files in CoreData<->CloudKit is particularly challenging. If you just store data in Binary Data attributes, that get converted into CKAssets, then fetching and modifying those CKRecords can take a long time, and potentially timeout, particularly if the user backgrounds the app and it gets suspended. To my knowledge, NSPersistentCloudKitContainer does use background tasks for syncing, but these aren't the same as long-lived operations, which are handled outside of the app. I've been pondering these issues for a while now, and have been working on an update to an open-source sync engine called CloudCore, with support for Cacheable Assets. Its a bit complex to establish your schema and code, but once done, large files you associate with CoreData managed objects are uploaded and downloaded using long-lived operations. The feature isn't quite ready yet, still doing some real-world testing, but you can see the progress here… https://github.com/deeje/CloudCore/pull/28 and feel free

So for any passers-by that are interested in how I eventually achieved this... (Credit to mtsrodrigues for how to deal with change of Scene in his answer in this thread... https://developer.apple.com/forums/thread/650876) My Core Data implementation for SwiftUI and the new App and Scene protocols and Window container! My SwiftUI App... struct MyApp: App { @Environment(.scenePhase) private var scenePhase @StateObject private var persistentStore = PersistentStore.shared var body: some Scene { WindowGroup { ContentView() .environment(.managedObjectContext, persistentStore.context) } .onChange(of: scenePhase) { phase in switch phase { case .active: print((#function) REPORTS - App change of scenePhase to ACTIVE) case .inactive: print((#function) REPORTS - App change of scenePhase to INACTIVE) case .background: print((#function) REPORTS - App change of scenePhase to BACKGROUND) savePersistentStore() @unknown default: fatalError((#function) REPORTS - fatal error in switch statement for .onChange modifier) } } } func

I believe that yes, it will create two stores and two different containers with private databases. I used to think, incorrectly, that there was a 1 to 1 mapping between an instance of NSPersistentCloudKitContainer, and a single CloudKit store description, but I've come to realize that one instance can handle multiple cloud synced stores.When working with multiple stores, create an instance of NSPersistentCloudKitContainerOptions for each store you wish to use with CloudKit.And no, you can't access the public, or shared database with Core Data for CloudKit. Also, if you want to write to the public database but not as an individual user, you can't do that through the iOS CloudKit API. CloudKit CKRecord instances are always owned by the user who created them. You'd have to use a server to server key and use their REST API from your app. That way you can write records as admin. I was thinking of using the public database to store app configuration data, but I'm not sure I want to develop with yet another

I bought a new iPad and using my app (downloaded from the App Store, not via Xcode) I can confirm that: Data created/modified on iOS 14.7.1 successfully syncs bidirectionally on iOS 14.7.1 devices Data created/modified on iOS 14.7.1 successfully syncs down only to iOS 15 (beta 4, 5 or 6) devices Data created/modified on iOS 15 (beta 4, 5 or 6) does not upload to iCloud (and eventually crashes the App)^ In order to see the iOS 14.7.1 -> iOS 15 (beta) changes appear I have to reload the app as the download seems to occur before the upload. Once the upload task 'starts' (it never really actually uploads anything), it prevents any changes from downloading. I've made no changes to my code, data model or NSPersistentCloudkitContainer related methods and it was something that abruptly appeared after installing iOS 15 beta 4. ^ basically any changes made on the device after iOS 15 (beta 4) was installed have not ever been sent to iCloud.

Here is the code that works only if the user is logged in. Again, I'm connecting to the Public database. class CoreDataManager: ObservableObject{ // Singleton static let instance = CoreDataManager() private let queue = DispatchQueue(label: CoreDataManagerQueue) private var iCloudSync = true lazy var context: NSManagedObjectContext = { return container.viewContext }() lazy var container: NSPersistentContainer = { return setupContainer() }() func updateCloudKitContainer() { queue.sync { container = setupContainer() } } func setupContainer()->NSPersistentContainer{ let container = NSPersistentCloudKitContainer(name: CoreDataContainer) guard let description = container.persistentStoreDescriptions.first else{ fatalError(###(#function): Failed to retrieve a persistent store description.) } description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) let cloudKitContainerIdentifier = iCloud.com.example.PublicDatabaseTest let options = NSPersistentCloudKitContainerOptions(containerIdent

@DD21 Did you end up finding a solution? I'm using NSPersistentCloudKitContainer to have CloudKit + Core Data and I'm observing the same issue. I have saved ~6000K items in Core Data, which some of them have images. The local size for the sum of the images is around 76 MB, but if you check it on iPhone > Settings > Apple ID > iCloud > Manage Storage, it shows up as ~760 MB, which is the 10x increase in size that you reported a year ago. This seems to be a bug on the whatever's in charge of calculating the size for iCloud assets, because when I delete my app from my device and let it download all the information stored on iCloud again, it finishes the download extremely fast (I'm assuming because it's only downloading 76MB). If it were downloading 760MB, it would take much longer knowing my network connection speed. Now, if this bug actually affects user's iCloud quota (which it seems that it does), it is a large scale issue that might be impacting millions of users. Users might have much

BAD_REQUEST typically means that the CloudKit server receives an invalid request. That can happen when, for example, your request has a CloudKit record or field that doesn't exist in the CloudKit schema. You mentioned your development scheme had been fully deployed to production, but that doesn't completely rule out the possibility of having invalid requests. For example, if you are using Core Data / SwiftData + CloudKit (NSPersistentCloudKitContainer), and the Core Data / SwiftData model in your app isn't completely mapped to the CloudKit schema, a bad request may happen. What CloudKit API are you using? For Core Data / SwiftData + CloudKit and the CloudKit framework, you might consider capturing and analyzing a sysdiagnose to hopefully find detailed messages that indicate the concrete reason of a bad request. If you are only using NSUbiquitousKeyValueStore, or using file system APIs to access iCloud Drive, you don't directly get involved to CloudKit requests, and so I’d suggest that you file a feed

Yeah, I see people reporting that CloudKit synchronization on macOS doesn't happen as quickly as it does on iOS, and that it only happens when the app comes to the foreground. I don't think that is really a bug because CloudKit was designed to synchronize only when it determines appropriate. In this case, it is that CloudKit on macOS chooses to synchronize when your app comes to the foreground. To be very clear, bringing your app to the foreground doesn't always trigger a synchronization, because a synchronization may be throttled if the rate is too high. For more information, see: TN3162: Understanding CloudKit throttles TN3163: Understanding the synchronization of NSPersistentCloudKitContainer In the production environment, that may not be a real issue, because people typically don't put their devices side by side to see the synchronization. Instead, they typically use your app on one device, and switch to another device some time later. When they switch the device and bring your app up, the synchr

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