“NSPersistentCloudKitContainer”

Hi, When using NSPersistentCloudKitContainer lots of error / debug messages are shown in Xcode Debug area. Feedback FB11794798: Overview When I use NSPersistentCloudKitContainer I get the following error / debug messages printed on the Xcode Debug Area. Syncing seems to happen fine. Tested on device and simulator. I am still using Development (not deployed to Production yet) I even tried with a new project using the default code generated for by enabling CloudKit coredata sync and I still get the same messages. I have filed a feedback FB11794798 Steps to Reproduce Create a new project check Use CoreData and Host in CloudKit check boxes Run the project Notice the error messages shown below. Questions How to resolve these errors? Or is this a bug from the Apple Frameworks? (Feedback FB11794798) Error / debug message printed on Xcode debug area CoreData: debug: CoreData+CloudKit: -[PFCloudKitOptionsValidator validateOptions:andStoreOptions:error:](36): Validating options: containerIdentifier:

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

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

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.

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

Hi, I have implemented iCloud Sync using NSPersistentCloudKitContainer. However, I have a lot of data to sync in my use case which can take quite some time (minutes) especially when starting with a new device (10's of minutes). I was wondering if there is a way to make good use of BGProcessingTaskRequest (ie long running task over night, potentially with requiresExternalPower). The idea is to let the device catch up with the remote store during such a long running background task over night/during charge. I already tried to hack my way into this by trying to just listen to sync events during the task and not finish the task until sync events have stopped but it seems the sync processor does have its own awareness of the app moving to the background and therefore might not even wake up during the background task. Any idea how I can help the CloudKitContainer to catch up in the background with very large workloads? Thanks!