NSPersistentCloudKitContainer

I'm trying to call CKFetchRecordZoneChangesOperation to get the latest changes from the shared database.But when I run that operation from inside didFinishLaunchingWithOptions, NSPersistentCloudKitContainer will break. It will save to coredata, but it will no longer sync to Cloudkit. It's as if it's paused. When I restart the app, the sync resumes.But if I call CKFetchRecordZoneChangesOperation later in the app lifecycle, say in viewDidLoad, everything works fine. Why is this?

I'm using Core Data and NSPersistentCloudKitContainer to sync the data using iCloud. There is some data that I want to just be local to the device, how would I make a CoreData model that is not synced with the cloud?

I’m working on an app that uses the new sharing support in NSPersistentCloudKitContainer. I do not see a way to tell Core Data that an object, or set of objects, is no longer shared. For example, if I create a set of objects and then call share(_:to:completion:), the objects are shared properly and moved to a new, custom CKRecordZone, as expected. Now, if the user stops sharing an object using UICloudSharingController, the CKShare that Core Data created is properly deleted from CloudKit, but the objects are still in the custom zone, and Core Data still has the original CKShare associated with those objects. So, when I call fetchShares(matching:), I still get the CKShare, but of course, that is no longer valid. Forcing Core Data to fetch CloudKit changes by either moving the app to background and then foreground, or by stopping the app and relaunching does not cause Core Data to notice the change to the share. Does anyone know how to tell Core Data that these objects are no longer shared? Note, I’ve t

I cannot change my existing core data stack to NSPersistentCloudKitContainer because that is only a iOS 13 and later support feature but I would like to have that set for iOS 13 and later while having NSPersistentContainer for earlier versions.I have a decent amount of experience working with swift and iOS but have not ever had to do something like this for versioning and certain vars/lets on certain verions.This is my code for my coredata stack for the iOS 13 and later for NSPersistentCloudKitContainer: lazy var persistentContainer: NSPersistentCloudKitContainer = { let container = NSPersistentCloudKitContainer(name: Shopping_App) container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { fatalError(Unresolved error (error), (error.userInfo)) } }) return container }()This is my code for iOS 12 and earlier: lazy var persistentContainer: NSPersistentContainer = { let container = NSPersistentContainer(name: Shopping_App

I am developing an App using CoreData & CloudKit (NSPersistentCloudKitContainer). I am working on an App Update which includes an Update to the CoreData Model. I have created a new Model Version and applied the Changes (including new Properties & Relationships as well as Renaming of Entities & Properties). For Renaming I set the Renaming ID to the old Entity- / Property-Name. These Changes should be supported by Lightweight-Migration. Questions Is there anything else I have to consider when updating a CoreData Model or did I cover all? What about the CloudKit Synchronization? How does CloudKit handle the CoreData Model Update? I read about adding this Method *(initializeCloudKitSchemaWithOptions)* during Development and removing it when deploying to Production. What does this Method do exactly? Thanks a lot for your help in Advance. This is quiet a huge Update and the App does have an existing Userbase, so Migration-Problems are no Option;)

Is it ok to use automaticallyMergesChangesFromParent to true for a managed object context that pins its query generation to current? I have heard from a few sources that in most cases, it’s not recommended to set automaticallyMergesChangesFromParent to true for a managed object context that pins its query generation to current. A source I have seen says: When you pin a managed object context to a specific query generation, you’re explicitly telling the context to view the data as it existed at the time of that generation token (often referred to as a snapshot). This ensures that the context is isolated from any subsequent changes made by other contexts or background tasks. But this may Conflict with Automatic Merging because: The purpose of setting automaticallyMergesChangesFromParent to true is to have the context automatically merge changes from the parent (e.g., background or main context) into itself whenever the parent context saves changes. This behavior conflicts with the concept of a pinned query gene

I wonder if anyone has managed to get NSPersistentCloudKitContainer with a public database with a pre-seeded sqlite to work. Our app has a few thousand records held in coredata that I'd like to move to cloudkit so that when we add new data it gets shared by everyone. Currently the only way to do this is by throwing up a new version to the app store with a new sqlite database embedded inside. NSPersistentCloudKitContainer seemed like the way to go. But I cannot get it to work with pre seeded data. It seems it works fine if I download it to a device with the same apple id as added the original data. The data is there ready as soon as it's installed and new data syncs with the device. But if I install the app onto a device with a different apple id than the original seeder it deletes all the data and starts downloading it fresh from the server. This would be fine but if the data is not there when the app launches it crashes as it's critical to the app and I can't pause the app launch until it's

I've tried using renaming Identifier: 1) Automatic / Lightweight migration seems to fail, because CloudKit integration forbids renaming entities. older devices cannot process these records 2) Tried using just NSPersistentContainer, and the lightweight migration still fails with the above message. NSPersistentCloudKitContainer seems to have marked/tainted the persistent store / SQLite so that renaming of entities is not possible at all. Does anyone know if it is possible to rename entities once you start using NSPersistentCloudKitContainer? (heavyweight migration or such?) Has anyone done this before, in a production app or otherwise?

Hopefully everyone's recovered from WWDC2021 last week! I've been digging through as much of the new documentation as I can about the NSPersistentCloudKitContainer and sharing over the last couple of days (since I can't get my code working in the XC 13 Beta... looks like a couple of bugs, I think...), and have a question. It appears that this uses Sharing by Record Zone rather than Sharing by Record, which is fine, but... How does this work when you are sharing entities between multiple users? for example... My Db contains a hierarchy of entities under a single root node, and there are multiple such entities (at the moment without overlap between the sub-entities, but I feel like that's just around the corner). Lets call them Entities A, B, and C. Now: Entity A I want to share with Joe. Entity B I want to share with Joe and Sally. Entity C I want to share with Sally and Simon. So, for Entity A I presume that it (and it's sub entities) wind up being represented in a shared record zone (SRZ) of it's ow

I have an app that's built entirely using SwiftUI. It uses NSPersistentCloudKitContainer to ensure that the iOS, watchOS and widgetKit targets all have the same fresh data. The problem is, this works well when the target is in the foreground, but once any of them are in the background, those targets serve stale data. As soon as they're brought into the foreground, the data gets merged in and I see the correct data. I can tell that this is the case because I have a background task running and when I read from my entity in the background, it is always stale. Because of this, my widget always shows stale data as well as my watch complications. Here are my findings. iPhone App: Data is only fresh when active, if I try reading from the bg, data is stale Watch App: Same as above WidgetKit: The data is only fresh on launch I don't think this is a bug, I think I'm just missing something in my implementation of Core Data. I know that there's Persistent History Tracking that might be a solution, but that seems

I'm using NSPersistentCloudKitContainer with Core Data and I receive errors because my iCloud space is full. The errors printed are the following: . I want to inform the user about this issue, but I can't find a way to access the details of the error. I'm listening to NSPersistentCloudKitContainer.eventChangedNotification, I receive a error of type .partialFailure. But when I want to access the underlying errors, the partialErrorsByItemID property on the error is nil. How can I access this Quota Exceeded error? import Foundation import CloudKit import Combine import CoreData class SyncMonitor { fileprivate var subscriptions = Set() init() { NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification) .sink { notification in if let cloudEvent = notification.userInfo?[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { guard let ckerror = cloudEvent.error as? CKError else { return } print(Error: (ckerror.localizedDes

After upgrading to iOS 18, my Core Data stack using NSPersistentCloudKitContainer in a shared App Group container stopped syncing correctly. The persistent store configuration, which previously worked in iOS 17, now experiences delayed or missing sync updates between devices. Then the app freezes and writes terminal the same error detail (which I provided) too many times. The debug logs from the CloudKit mirroring delegate (NSCloudKitMirroringDelegate) show repetitive notifications but no updates in persistent history. Additionally, the persistent history tracking key appears unresponsive to local changes, causing transactions to fail in updating or syncing as expected. Key setup details: Core Data is set up within an App Group container using NSPersistentCloudKitContainer. NSPersistentHistoryTrackingKey and NSPersistentStoreRemoteChangeNotificationPostOptionKey options are set to true. Any insights into changes in iOS 18 Core Data or CloudKit handling with NSPersistentCloudKitContainer

I am looking into using the new NSPersistentCloudKitContainer to sync some internal data for my app. Generally it works great, but I have one scenario that I cannot figure out.Here the basic scenario, there is a single record in CloudKit that created and used to keep track of some internal state. Keeping it the cloud allows for two cases: when the user open the app on another device (say an iPad) and when the user re-installs the app on the same device.If its indeed the very first time the user is using the app on any device, I need to create the record with a bunch of default initial values. I am okay with spending a little time at app startup determining if its a brand new user or an existing user installing on another device.I thought maybe observing NSPersistentStoreRemoteChangeNotification would provide a useful point in time that I can say ah ha, now I know its a new user, or an existing user. However its gets called a lot and I cannot find anything in its userInfo that gives me a definitive an