NSPersistentCloudKitContainer

I'm having some issues where only a subset of records appear in CloudKit dashboard after I have saved some records in my iOS app using NSPersistentCloudKitContainer. I have noticed that when I'm running my app using the development environment of my CloudKit container everything works smoothly and is uploaded as expected but when I'm using the production environment only a subset of records are actually uploaded. I'm pulling my hair on how to debug this. -com.apple.CoreData.CloudKitDebug and -com.apple.CoreData.SQLDebug pukes out too much info in the console for me to pinpoint any issue.

Hi, I recently added iCloud sync capability to my app via NSPersistentCloudKitContainer. It does push data to the cloud, in other words seems to be working fine. However, I noticed a strong increase in battery drain and when I debug (release and debug build configs) I can see that a NSManagedObjectContext thread that is definitely not mine has 100% CPU load basically all the time. (I waited a few minutes, yes minutes, for it to finish while not using the app at all and it does not stop.) Component utilization shows that most the energy impact is CPU and overhead is very low (goes to 0 quickly). There is no network activity visible, so this seems to be some kind of background processing. Also, memory is very, very low (~ 35 MB). I am wondering if I am doing something wrong here or if there is a better practice. Some info about how my app works: It downloads things from the web and generates a lot of entities while doing so. It frequently saves changes (incremental changes in entities, there are lots o

Hi, I've been using Core Data + CloudKit via NSPersistentCloudKitContainer for several years now. Back then I just created my Core Data AND CloudKit fields by hand. Now the time has come for a little lightweight migration to a new Core Data model, let's say I just needed to add one String attribute. So I've done the Core Data local migration as usual, then added this to container code: try? persistentContainer.initializeCloudKitSchema(options: NSPersistentCloudKitContainerSchemaInitializationOptions()) Run. And everything worked great. but… Now I've noticed that CloudKit created new CKAsset fields for each String attribute that I had in Core Data (about 5 new CKAsset fields). Is this normal!? Why? ! Is it safe to deploy these changes to prod? ty. ChatGPT said: This field is used internally by CloudKit to handle large string values. If the string value is small enough, it is stored in the normal String field, but if it exceeds the size limit (about 1KB), the string is automatically stored as a CKAsset

I've encountered a significant sync issue with watchOS 10 RC on every device combination I've tested, running both iOS 17 and watchOS 10. I'm curious if others have noticed a similar problem. Context: Standalone watchOS app developed in SwiftUI with a companion iOS app. Both apps use NSPersistentCloudKitContainer for bi-directional CloudKit CoreData Sync between the iOS app and watch. Previously, this sync mechanism was near instant in the foreground and took max 1-2 minutes in the background NSPersistentCloudKitContainer has been reliable since the app was first developed in the watchOS 6/iOS 13 era. Issue: In watchOS 10 RC, sync can take hours--and doesn't even occur when the app is in the foreground. Sync only reliably happens when the watch is placed on the charger, seemingly only if the charge is over 50%. Once taken off the charger, the watch will continue push and receive CoreData changes briefly before becoming unresponsive to sync again. Additional Info: The problem persists even wh

I am trying to deduplicate data created by NSPersistentCloudKitContainer in my app. I have a universal app, with Share Extensions on both macOS and iOS. On each platform I share a store between the app and the extension with an App Group. The app and the extensions are both configured to sync to CloudKit. (This means local sharing is handled when offline, and a remote share extension will sync to CloudKit work when the main app is closed) This configuration is causing duplicates to be generated. I believe this is because when the macOS app is open, both it and the macOS share extension will try and (almost simultaneously) sync a newly shared object, resulting in two copies in CloudKit. On the macOS app, I can look through the persistent history and see the insertion 'author'. The first insertion is made by the extension macOSShareExtension, the second is made by NSCloudKitMirroringDelegate.import. I could easily make a choice to delete the second object. However, at the same time, on the iOS app, I w