“NSPersistentCloudKitContainer”

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

Have you set automaticallyMergesChangesFromParent = trueI choose to do this after I load my persistent container... lazy var persistentContainer: NSPersistentContainer = { let container = NSPersistentCloudKitContainer(name: persistentStoreName) container.viewContext.automaticallyMergesChangesFromParent = true container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { fatalError(Unresolved error (error), (error.userInfo)) } container.viewContext.automaticallyMergesChangesFromParent = true return container }()

You can't save and delete the same record Assuming that you are using Data + CloudKit, I am guessing that this can be triggered by your code and data. Consider the following configuration as an example: Delete Rule: cascade articleA.associatedArticles -> [articleB, articleC...] articleB.associatedArticles -> [articleA, articleC...] If you delete articleA, Core Data will delete articleB due to 1 and 2, and change articleB due to 3 at the same time. You can review your code to see if the above case can happen. When you use Core Data + CloudKit, NSPersistentCloudKitContainer configures and performs the CloudKit operations without any involvement of your code, and so it is worth filing a feedback report for the Core Data team to investigate why the case isn't handled – If you do so, please share your report ID here. Already have a mirrored relationship registered for this key Based on the (more) information you provided to DTS, this seems to indicate that you has a reflexive relationship (a relatio

No, unfortunately if you hadn't set true for key NSPersistentHistoryTrackingKey, they will never get it to cloud, they will stay only in your device. A workaround that I used and worked fine, is to add a property to all entities (I used cloudReady: Bool, and at the first run of the app, after you adopt NSPersistentCloudKitContainer, change that property to true for all entities. This will force iCloud to sync those objects.

This is pretty similar to an existing issue we know. Would you mind to try the following? Replace NSPersistentCloudKitContainer with NSPersistentContainer and verify that the issue is still there. This is to simplify the issue by ruling out CloudKit. Reproduce the issue, gather a crash report, and share here. I'd be able to confirm by reading the crash report. Best, —— Ziqiao Chen  Worldwide Developer Relations.

First, I’d like to be clear about the behavior NSPersistentCloudKitContainer implements when you use it to share a managed object (NSManagedObject) so we are on the same page: When you save object A to the Core Data store associated with the private database, NSPersistentCloudKitContainer transforms the object to a CloudKit record A, and synchronizes it to the record zone 1 in the CloudKit private database, with zone ID being com.apple.coredata.cloudkit.zone. When you then use NSPersistentCloudKitContainer.share(_:to:completion:) to create a new share (CKShare) and share object A to another user, NSPersistentCloudKitContainer moves record A to a record zone 2, with zone ID being com.apple.coredata.cloudkit.share. . Note that zone 2 is still in the private database. What you call NSPersistentCloudKitContainer.share(_:to:completion:) with an unsaved managed object A. Core Data saves the object for you, and the associated record A will be saved to zone 2. Regarding Core Data relationsh

I've been waiting on CloudKit + CoreData integration for a while, and I don't see how NSPersistentCloudKitContainer can't be used to share. Zero of my users has asked to sync the data between devices, everyone wants to share it between users, and how is such a core feature missing?Have to say, I'm not sure if it's missing because I can't find any documentation or tutorials, but it sure looks that way!

AFAIK Watch apps do not naturally sync data back to the companion. This has to be done via one or more of these solutions, Keeping Your watchOS Content Up to Date - https://developer.apple.com/documentation/watchkit/keeping_your_watchos_content_up_to_date. The easiest way to do that would be NSPersistentCloudKitContainer, however WatchConnectivity - https://developer.apple.com/documentation/watchconnectivity may be a better fit depending on your needs.

My two cents... My Core Data implementation for SwiftUI using the new App and Scene protocols and Window container! Credit to: mtsrodrigues for how to deal with change of Scene in his answer in this thread. KrakenDev's article on how to write a one line singleton My SwiftUI App... import SwiftUI @main struct YourApp: 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 savePersistentStore() { persiste

Yup! I am suddenly seeing a lot of crash reports (over 100 in the last couple of days) and ALL from users on iOS 16.1. This is new and nothing in that part of the App changed. Crashing right after the CoreData is initialized and NSPersistentCloudKitContainer is ready. At that point the controller does a fetchRequest for items in the Table and Crash with some kind of memory error. In my case it is simply making a request for items sorted alphabetically?!

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.

'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

I'm not sure how to rectify the two answers from Apple. The staff answer reads to me as yes, with some extra work. The engineer answer reads to me as a flat no, don't even try. Can someone please clarify? Does does not yet support sharing mean you literally can't use sharing with NSPersistentCloudKitContainer at all, even with additional code?

Given that you are already using Core Data, you can consider using NSPersistentCloudKitContainer. If the data you would synchronize is as simple as several values, you can consider using the CloudKit framework as well, which gives you more flexibility. You might want to start with looking into the above APIs, and follow up with your further questions, if any. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Given this constraint, I believe there could be a more elegant sync approach than the Create duplicates in CloudKit and delete one method if only it would be possible for me to set recordName as I wish. There isn't unfortunately. This topic is discussed in Remove duplicate data. SwiftData with CloudKit Sync is based on NSPersistentCloudKitContainer, so the discussion applies to SwiftData as well. Best, —— Ziqiao Chen  Worldwide Developer Relations.