NSPersistentCloudKitContainer

Is there a way to get the container from a device NOT having Xcode or Development tools if they can connect to a Mac? Not that I am aware of. Many of whom DO NOT use iCloud which is also weird. A few using iCloud but most are NOT. Any thoughts on why that might be? If the impacted users didn't use iCloud, you can rule out CloudKit, which will simplify the issue a bit. However, I still can't say anything for sure – Debugging a random data loss can be hard and my sitting here and guessing won't be helpful. To eventually figure it out, you might consider reaching out the impacted users to hopefully find more hints, or ideally, create a reproducible case. now it is almost as if a user has NSPersistentCloudKitContainer options set to nil and the data is deleted. Can you confirm or provide a link to documentation confirming? Setting the CloudKit option to nil does not delete the data in the existing Core Data store. Best, —— Ziqiao Chen  Worldwide Developer Relations.

SwiftData and CloudKit are two different frameworks, and so you are free to use both of them in your app. Note that CloudKit here means the CloudKit framework, not NSPersistentCloudKitContainer. As of today, when you configure SwiftData to use CloudKit, as mentioned in here, SwiftData uses NSPersistentCloudKitContainer underneath to sync the data, and so you won't want to create your own NSPersistentCloudKitContainer instance for the purpose. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for the reply! Firstly, correct, we're using CoreData + CloudKit and mirrored relationships means reflexive relationships (e.g., Article.similarArticles whereby both are of the type Article). Assuming that you are using Data + CloudKit, I am guessing that this can be triggered by your code and data. Regrettably, that doesn't seem to be the case, also given the Delete Rule is Nullify. Digging through our old messages, we found out that we had already reported this very same issue a couple of years ago with a similar data model but where no entity was ever deleted. At that time we filed feedback report 9118745 and we were told that this was likely a bug. it is worth filing a feedback report for the Core Data team Given this seems to be the very same issue, I’ve added the information of this post to our above ticket (and have provided the relevant system diagnose logs, data model, etc. there too). Does your Core Data model indeed has the reflexive relationship? If yes, has it been there for long time, or

Adding a CKAsset field for a Core Data String attribute is as designed. It is because the size of a CloudKit record (not counting assets) is limited to 1MB, while a Core Data attribute has no size limit. What ChatGPT said is basically right – When the size of a Core Data String attribute exceeds a certain value, NSPersistentCloudKitContainer converts it to a CKAsset object in the data transformation process. Whether the value is about 1KB or not is not formally documented though. Best, —— Ziqiao Chen  Worldwide Developer Relations.

@DTS Engineer We are not currently using any APIs specifically for iCloud account switches. Our app’s data is managed entirely through Core Data, backed by NSPersistentCloudKitContainer for synchronization with iCloud. When my colleague checked the CloudKit Console after logging into their iCloud account, they did not see the custom zone we use to store Core Data records. This absence has us concerned about whether the data is still recoverable. If the iCloud account is still active, should Core Data records managed via NSPersistentCloudKitContainer automatically sync back? Or does switching iCloud accounts result in the permanent deletion of associated Core Data records? Our plan is to recommend that the user logs back into their original iCloud account, ensures that iCloud is enabled for our app, and opens the app to allow time for the data to sync back. Is this the correct approach for recovering the data, or are there additional steps we should take? Any guidance would be greatly appreci

You can't save and delete the same record Assuming that you are using Data + CloudKit, I am guessing that this can be triggered by your code and data. Consider the following configuration as an example: Delete Rule: cascade articleA.associatedArticles -> [articleB, articleC...] articleB.associatedArticles -> [articleA, articleC...] If you delete articleA, Core Data will delete articleB due to 1 and 2, and change articleB due to 3 at the same time. You can review your code to see if the above case can happen. When you use Core Data + CloudKit, NSPersistentCloudKitContainer configures and performs the CloudKit operations without any involvement of your code, and so it is worth filing a feedback report for the Core Data team to investigate why the case isn't handled – If you do so, please share your report ID here. Already have a mirrored relationship registered for this key Based on the (more) information you provided to DTS, this seems to indicate that you has a reflexive relationship (a relatio

Thanks for sharing. SwiftData + CloudKit is based on NSPersistentCloudKitContainer as of today, which doesn't do any synchronization if the app is not launched. Even if the app is running, it will be up to the system to decide when to synchronize data. There is no way for an app to force NSPersistentCloudKitContainer to synchronize with CloudKit. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I'd firstly point you the following technotes, which I believe will give you the whole picture about how Core Data + CloudKit works: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3164: Debugging the synchronization of NSPersistentCloudKitContainer TN3162: Understanding CloudKit throttles Concretely to your questions: What are the solutions I have when the user first loads the app? How to force CoreData to query directly cloudKit? There is no API for an app to speed up the initial synchronization as of today. If there is a lot of data on the server, the synchronization will indeed take long time. I'd suggest that you file a feedback report against that. There is no API to force CoreData to import from CloudKit, and that is as-designed, as discussed in the technotes mentioned above. Does CoreData + CloudKit + NSPersistentCloudKitContainer will download the whole CloudKit database in my local, is that good???? When using NSPersistentCloudKitContainer

Hi, Thanks for your response. I don't think we do any of the things you are concerned about. Here is some of the code I use to set up the CoreData/Cloudkit stack and have been using this for a few years now. Nothing changed here in at least 12 months (I am not exactly a piker in this realm :) : class CoreDataUtil: NSObject { @objc var pc = NSPersistentCloudKitContainer(name:iphemeris) private lazy var historyRequestQueue = DispatchQueue(label:history) let coreDataLogSubsystem = com.iPhemeris.coreData let coreDataLogger = Logger(subsystem:com.iPhemeris.coreData, category:Cloudkit) @objc var useiCloud:Bool = userSettings.bool(forKey:UseIcloudKey) { didSet { userSettings.set(useiCloud, forKey:UseIcloudKey) if(pc.persistentStoreCoordinator.persistentStores.count > 0) { let store = pc.persistentStoreCoordinator.persistentStores[0] do { try pc.persistentStoreCoordinator.remove(store) } catch { coreDataLogger.log(*** CoreDataUtil toggle use iCLoud ON/OFF FAILED: (error, privacy:.public)) } } self.initCor

Did you ever run your app and save some data to the CloudKit-backed Core Data store? NSPersistentCloudKitContainer only creates the custom zone when there is data. Also, you need to initialize the CloudKit schema, if not yet. See Create the CloudKit schema for the more details. Best, —— Ziqiao Chen  Worldwide Developer Relations.

SwiftData + CloudKit is currently based on NSPersistentCloudKitContainer. Duplicate data can be generated if you have multiple app instances uploading a same piece of data, as discussed in Remove duplicate data. NSPersistentCloudKitContainer doesn't support unique constraints as of today, and so you will need to remove duplicate data with your own algorithm and code. Best, —— Ziqiao Chen  Worldwide Developer Relations.

To work around this and improve the user experience, we want to use CKContainer.accountStatus to check if the user has an available iCloud account, and if not, disable the CloudKit sync before it erases the local data. This is fine but doesn't completely solve your problem: While your app is running, a user can launch Settings.app and log out their iCloud account or turn off iCloud for your app, which still triggers an account change, but your app can't respond because it only checks the account availability at the beginning of a launch session. You can probably observe the CKAccountChanged notification, but then there may have a race – NSPersistentCloudKitContainer may still erase the data before you release the current model container. However, we are receiving regular reports from users for whom the system has incorrectly indicated that the app's access to iCloud is unavailable, even when the user hasn't logged out or toggled off permission to access iCloud. This triggers the behavior to clear the