NSPersistentCloudKitContainer

I'd like to comment the second question a bit, as it hasn't been addressed yet: Sometimes when running on a new device it will create a second UserSettings while it is waiting for the original one to sync from CloudKit. When you use SwiftData + CloudKit, under the hood, the framework uses NSPersistentCloudKitContainer to synchronize data. In that environment, duplicate data is sometimes inevitable, which is discussed in great details in the following section: Remove duplicate data The solution is to de-duplicate the data. How to do so is discussed and demonstrated in the sample code. Back to what to what you intent to achieve, my suggestion will be: If you plan to use SwiftData + CloudKit extensively in your app, you might need to handle duplicate data anyway. In this case, persisting user settings to your SwiftData store (and Synchronizing them via NSPersistentCloudKitContainer) makes a lot of sense. If the target is as simple as saving some Cloud-based user settings, I'd probably consider

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.

When you use SwiftData + CloudKit, under the hood, the SwiftData framework converts SwiftData models to Core Data managed objects, and use NSPersistentCloudKitContainer to synchronize the objects with CloudKit. NSPersistentCloudKitContainer mirrors each Core Data managed object to (at least) a CloudKit record (CKRecord), as described in Reading CloudKit Records for Core Data. To manage the internal state of the synchronization, it adds a few tables to the store, and the ANSCKRECORDMETADATA table is one of them, which is used to store the metadata of the CloudKit records. The metadata includes the system fields and encoded data of every CloudKit record, so yes, you can see that the size of table gets quite large. The ANSCKRECORDMETADATA table is an internal data structure that NSPersistentCloudKitContainer creates and consumes. You can review the documentation mentioned above to make sure that your models are translated to CloudKit schema correctly, but other than that, I don't see a

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.

If a user writes changes to the app and the app saves those changes to the Core Data store, they should never be permanently deleted just because iCloud was disabled. It seems quite wrong to me that NSPersistentCloudKitContainer will delete even changes that have not been synced to the cloud. As a developer, what could I do to ensure this does not occur? I believe it is a bad idea to programmatically switch between NSPersistentContainer and NSPersistentCloudKitContainer (discouraged by Apple) and you lose privacy and security.

This occurs even if the changes to the managed objects are saved (to the local store) -- it's simply they aren't synced in time. This is by design. Turning off iCloud for an app is equivalent to signing out of the account. Perhaps before NSPersistentCloudKitContainer wipes the local store it ought to force sync with the cloud first? Typically that won't work. By the time an application finds out about an account transition (whether by turning off iCloud for an application or signing out) sync will just fail with CKErrorNotAuthenticated.

You would need to mark the zone as user-purged for the DefaultStore to obey an out of band delete. Alternatively you can use NSPersistentCloudKitContainer to manage CloudKit sync on the side through Coexistence and use its purge APIs.

I’m having a similar problem. I found a reddit post about this issue where the author writes, “I’m guessing it only shows up for devs who bulk import/delete during testing, while normal users with a few hundred records never notice.” Which makes sense because I am also bulk importing. I’m seeing about a 6-8 times increase between the local storage and CloudKit. (Specifically, 15k records comes out to around 13mb of local storage, but 100mb with CloudKit enabled. ANSCKRECORDMETADATA appears to be the main culprit.) I’m making a flashcard app, and of course users can import as many cards as they want, which could become a storage problem pretty quickly. From my understanding, and as you mentioned, a storage increase is expected. But the increase I’m seeing just seems excessive. … Or is it? I can’t really find anything on what to expect. I wonder if there’s something I can change in the model to make this work. Or maybe the problem is unique to NSPersistentCloudKitContainer and I should look at other sy

If you are using SwiftData + CloudKit, which is based on NSPersistentCloudKitContainer, it doesn't support cross-share relationships, and so you can't have a collection in one zone and a relationship of the collection (a sub-collection, for example) in another. This is mentioned in here: NSPersistentCloudKitContainer doesn’t support cross-share relationships. That is, it doesn’t allow relating objects associated with different shares. When sharing an object, NSPersistentCloudKitContainer moves the entire object graph, which includes the object and all its relationships, to the share’s record zone. If you are using the CloudKit framework directly, the source and target objects of CKRecord.Reference must be in the same zone of the same database, and so you will need to maintain the relationship with your own logic. Best, —— Ziqiao Chen  Worldwide Developer Relations.

For data that needs to be accessible across multiple devices (that are logged in with the same Apple ID), even when your app is removed from one of them, consider using cloud storage services, which allow data to be synced across all devices. To use Apple's cloud service, you can look at the following APIs: CloudKit NSPersistentCloudKitContainer NSUbiquitousKeyValueStore iCloud documents This is a lot of things, but it gives you the whole picture about what the platforms have so you can pick the one that fits your use case best. Best, —— Ziqiao Chen  Worldwide Developer Relations.

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