“NSPersistentCloudKitContainer”

Given that you'd move the Core Data store to a group container, I'd assume that the store will be shared across different processes, such as your main app and its extension (a widget, for example). In that case, I'd like to start with pointing you the following threads: Core Data Light Migration Crash When Widget is Installed (Error 134100). CoreData error=134100 Failed to open the store. These threads made it clear that: After a user installed your new version app, depending on what extension you have, the app and extension can open and migrate the store simultaneously, and so you will need to implement a mechanism to make sure that the store is only migrated once. Consider having your main app in charge of the the synchronization, as discussed in Avoid synchronizing a store with multiple persistent containers. Now to your questions: Store relocation vs schema migration Is it advisable to perform store relocation and schema migration in a single step, or should these be separate releases? If combined, are th

This sounds like a general synchronization issue, and so you can probably start with the technotes mentioned in this post to hopefully figure out the cause of the issue. NSPersistentCloudKitContainer supports many-to-many relationships. Before seeing an evidence that proves it doesn't work (by going through the debugging process the technotes describe), I probably won't change the Core Data model. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I've already played with the samples and was able to share one by one or a set of records. BUT, let me rephrase, I have a set of entities that I want to share ONCE between invited users with ONE sharing at the top. Could you confirm that is it possible? If Yes, there is probably one missing step or misunderstood in the following code. In my understanding, based on the samples, to do this, I'm doing : 1/ on owner and participant : configure a NSPersistentCloudKitContainer with inside a databaseScope = .private store AND a databaseScope = .shared store 2/ on owner before presenting the UICloudSharingController: 2.1/ create a shared zone-wide share ID let shareRecordID = CKRecord.ID(recordName: CKRecordNameZoneWideShare, zoneID: zoneID) 2.2/ create or get an existing CKShare with: func getOrCreateShare() async throws -> CKShare { let zoneID = CKRecordZone.ID(zoneName: sharedZoneName) // Zone-wide share ID let shareRecordID = CKRecord.ID( recordName: CKRecordNameZoneWideShare, zoneID: zoneID ) // Try

For a large dataset, the initial synchronization with CloudKit, which can happen in several cases, including on-boarding a new device, can indeed be slow, or even failed. A similar issue was discussed in this thread as well. Depending on your concrete use case, you might address the issue in the following way: Have your app functional before the dataset is fully synchronized. Synchronize the data in batches in the background, until the whole data set is done. As an example, an email app that is just installed on a new device allows users to compose a new email, while synchronizing existing emails in the background. When using the CloudKit framework, you control what kind and amount of data to be synchronized with CloudKit, and hence can implement the strategy, though the implementation can be quite involved. Now that you are using SwiftData + CloudKit integration, NSPersistentCloudKitContainer takes care the synchronization process. I don't really see anything to work around or mitigate the issue in

Just to share a bit more color, the error happens when Core Data + CloudKit schedules a new export task when another one is still in progress. In this situation, the scheduling will fail, and the system will drop the new task. In Core Data + CloudKit, however, I don't think this is an issue, because NSPersistentCloudKitContainer will schedule another export task next time when it detects something yet to export, which can happen some time after it detects that a previous export task failed, or that a new change on the Core Data store was made, and so the data should eventually be exported. You should be able to observe the behavior by capturing and analyzing a sysdiagnose. Best, —— Ziqiao Chen  Worldwide Developer Relations.

When using SwiftData + CloudKit integration, which uses NSPersistentCloudKitContainer under the hood, the synchronization typically doesn't happen immediately. To better understand the synchronization, consider going through the following technotes: TN3164: Debugging the synchronization of NSPersistentCloudKitContainer TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3162: Understanding CloudKit throttles In your case, the first three bullets are pretty much as-designed. The last one, no edits sync between either Mac, if lasting for ever, which means the synchronization is broken, will be an issue. In that case, you can figure out what happens by capturing and analyzing a sysdiagnose, as described in TN3163. Best, —— Ziqiao Chen  Worldwide Developer Relations.

The following console log says that your app detected an account switching at the beginning of the launch process, which may erase the existing data created before the switching. It also says that you were using a simulator. CoreData: warning: CoreData+CloudKit: -[PFCloudKitSetupAssistant _checkUserIdentity:]_block_invoke_3(1487): : CKIdentity record has changed from _b09f3f2b1357d21fdd823f58762f6077 to _4e8dc229775b034192825a3081a709a4 error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _performSetupRequest:]_block_invoke(1242): : Failed to set up CloudKit integration for store: (URL: file:///Users/yuanping_ke/Library/Developer/CoreSimulator/Devices/BA9191E9-6DB4-4A30-9196-0A6C06A11F2E/data/Containers/Data/Application/5977FE0D-50D4-4AE0-8134-5D8B0B662298/Library/Application%20Support/default.store) Later your app did successfully set up CloudKit integration, as shown below, and then did several successful exports and imports, but it seems that there is no change merged into the store. CoreData: warning:

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