“NSPersistentCloudKitContainer”

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

When I sync my large Core Data database with NSPersistentCloudKitContainer, inserting new rows works well for up to 10k rows. (in batches of ~400 inserts) After that, CloudKit receives a 503 Service Unavailable error with a timeout. Here's the log: CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExporter exportIfNecessary]_block_invoke_2(153): : Found 22161 objects needing export. 2021-01-14 11:26:54.985447+0100 [1299:350390] [error] error: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _exportFinishedWithResult:exporter:](1163): : Export failed with error: The API documentation - https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/ErrorCodes.html#//apple_ref/doc/uid/TP40015240-CH4-SW1 says 503 means interal server error (try again later) and also says that for throttling the status code would be 429, so I guess it's not rate limiting? I only found that there is a rate limit of 40 requests/second, but since CoreData is doing batch ins

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