NSPersistentCloudKitContainer

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!

My experience implementing Core Data + CloudKit has frankly been relatively easy and I feel very positive about the new NSPersistentCloudKitContainer.Introduction and ThanksHonestly, I approached the new implementation of Core Data + CloudKit with some trepidation.My fears and anxiety were unfounded and I quickly learned just how (unsettlingly) easy it is to implement a CloudKit backed persistent store using NSPersistentCloudKitContainer.The new Core Data documentation is the best I've read by Apple for many years, so a huge and sincere thank you to the Core Data team.A couple of good posts on SO and a good blog by Andrew Bancroft helped close out my preliminary education... https://www.andrewcbancroft.com/blog/ios-development/data-persistence/getting-started-with-nspersistentcloudkitcontainer/The sample app provided by Apple (per WWDC session 202: Using Core Data with CloudKit) is madness for a beginner, however I really appreciate the effort that has gone into demonstrating SO MANY capabilities of

I have expanded my CoreData model quite a few times, including renaming entities, properties (and as far as I remember relationships). I am still working in the (CloudKit) development environment, only. Now I am getting errors each time I start the app (one line out of many shown): CoreData: debug: CoreData+CloudKit: -PFCloudKitMetadataModelMigrator calculateMigrationStepsWithConnection:error:(404): Skipping migration for 'ANSCKDATABASEMETADATA' because it already has a column named 'ZLASTFETCHDATE' The app is working as expected, it seems this error has no effect on correct CoreData+CloudKit execution. But I want to get rid of this error warning before I deploy to production for TestFlight or expand CoreData further. To have a clean CD+CK base I can start migrations from in future. Can I just reset CD (or CoreData's model) to make CD accept the current model as the base model without any migrations attached to it? An Apple Engineer suggested here - https://developer.apple.com/forums/thread/47637?answerId=146

In my app I have a defaultJournal: Journal, that automatically gets added on the user's device on launch. There should only be one default journal, and I know that deduplication as shown in the Apple Demo, is the correct approach to ensure this on multiple devices. Journal looks something like: class Journal: NSManagedObject { @NSManaged var isDefaultJournal: Bool @NSManaged var entries: Set? } Since Journal has a relationship to entries, how can I deduplicate it ensuring that I don't orphan or delete the entries? I am worried that the entries aren't guaranteed to be synced, when we discover a duplicate journal in processPersistentHistory. This would lead to either orphaned or deleted entries depending on the deletion rule. How can one handle deduplicating entities with relationships? For example here is my remove function: func remove(duplicateDefaultCalendarNotes: [Journal], winner: Journal, on context: NSManagedObjectContext) { duplicateDefaultCalendarNotes.forEach { journal in defer { context.delete(journ

I'm really excited about the new public database options introduced in the Sync a Core Data store with the CloudKit public database talk! I see in the documentation that the databaseScope refers to the CKDatabase.Scope which includes an option for the shared database. Does this mean that we will be able to automatically sync CoreData records to a shared CloudKit database this year? I would really like to add support to my app to sync data with friends through CloudKit, but with the existing system it is too much work to sync shared objects through a CKShare, so I have avoided building it so far. I'm really excited to start using the new changes. Thanks!

So I tried the public database feature of NSPersistentCloudKitContainer last year but never really got anywhere so I thought i'd try it again this year. However I've still had basically no luck and I figured now might be a good time to try and document the issues I have had. The documentation for this at https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/creating_a_core_data_model_for_cloudkit mentions shouldInitializeSchema which from what I can gather was removed in a beta version a long ** time ago. It appears to now be a method on the container - container.initializeCloudKitSchema(). Ya'll should update this documentation. initializeCloudKitSchema does not work if you have options.databaseScope = .public on the NSPersistentCloudKitContainerOptions. You get a bunch of errors saying No authToken received for asset Turning off the public scope and then calling initializeCloudKitSchema gets you the Record types you need created in the CloudKit console, then r