“NSPersistentCloudKitContainer”

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.

SwiftData default store is based on Core Data. As a historical implementation detail, at runtime, a Core Data to-many relationship, once persisted, is always a [], and never a nil. To adapt this behavior in an effective way, SwiftData always initializes a nil to-many relationship with an empty collection at runtime. So to your first question, the behavior that optional to-many relationships in SwiftData are never nil at runtime is as-designed. The requirement that relationships must be optional is a way to express that NSPersistentCloudKitContainer does not handle relationships atomically, and is enforced by a schema validator at compile time. The validation doesn't have any impact at runtime, and so SwiftData to-many relationships being [] at runtime doesn't break the CloudKit synchronization. To use SwiftData + CloudKit, you make sure your model schema is compatible with the rules so the schema validator doesn't complain, and that will be it. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Is this indeed true? Yes. If it isn't allowed, is the only solution to disable multiple instances of the process via a lock file? I was thinking one could somehow coordinate a single leader process that syncs to the cloud, with the others using NSPersistentContainer, but this would be complicated when the leader process terminates. I'm skeptical that's a workable solution. Holding file locks across assertion boundaries will cause your app to get killed. However the system regularly suspends apps doing NSPersistentCloudKitContainer work for load balancing. There isn't a convenient process model for multiple apps coordinating on a shared networking space. If extensions fail to meet your use case needs, you will have to elect a leader application to manage the CloudKit sync. Other applications can access the same store file without the NSPersistentCloudKitContainerOptions set, but only one process can manage sync.

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