NSPersistentCloudKitContainer

@Engineer Thanks for sharing the sample project. It shows several examples how to use CloudKit, however, it doesn't include a Widget Extension or any references to WidgetKit. Is there another project that showcases this concrete use case, updating the same Core Data objects from both a Widget and an app? @Jordan wrote in 2022: Do note they also said NSPersistentCloudKitContainer does not support multi-process sync so only your app should be attempting to sync. And even if a widget were to attempt sync, it’ll never really be able to because iOS doesn’t give it enough time to execute, and widgets don’t run in the background they’re only running when they need to get more timeline entries for example, and widgets don’t get the app’s push notifications which is what enables background syncs to be scheduled. Your app will need to try to keep the widget up to date as opposed to the widget attempting to sync and keep itself up to date. Is this (still) correct (in 2025)? If so, then any attempt to update Cor

The code path of lightweight migration, which does migration in place, is different from the one of running NSMigrationManager, and so I am not too surprised that the logs are different. If you can provide the logs generated by running NSMigrationManager for me to compare, I will be able to confirm. I'll be very surprised if NSMigrationManager doesn't checkpoint the data though. I don't see any way that can force Core Data to write to the -wal file. I think if you set up a Core Data stack with multiple persistent store coordinators and write a bigger data set simultaneously, you will more likely see data being witten to the -wal file. I don't expect the behavior being different for NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.

How can I confirm this behavior when migrating using NSMigrationManager? I don't think you need to explicitly checkpoint the store. The Core Data migration process should handle that for you – If it doesn't, I'd see that a framework bug When I enable com.apple.CoreData.MigrationDebug the lightweight migration logs the WAL checkpointing, however, when using NSMigrationManager no such log appears. When I tried inserting 1000 objects, all of them get inserted into the sqlite file. Nothing gets inserted in WAL file. Is the behavior different for NSPersistentCloudKitContainer? Regarding the error, did you try to set up options in the following way: Yes, this works. However, if the NSMigrationManager handles this then should be avoided, right?

Given that you are already using Core Data, you can consider using NSPersistentCloudKitContainer. If the data you would synchronize is as simple as several values, you can consider using the CloudKit framework as well, which gives you more flexibility. You might want to start with looking into the above APIs, and follow up with your further questions, if any. Best, —— Ziqiao Chen  Worldwide Developer Relations.

What CloudKit API are you using? If you are using NSPersistentCloudKitContainer, I'd suggest that you start with the following technotes: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3164: Debugging the synchronization of NSPersistentCloudKitContainer If you are using the CloudKit framework, start with: TN3162: Understanding CloudKit throttles The general methodology to debug a CloudKit synchronization issue is to capture and analyze a sysdiagnose, and try to find relevant CloudKit errors from there. If you did find an error and need further discussion, please post the detailed error message here for folks to take a look. In any case, if you believe that CloudKit should be improved in some way, please feel free to provide actionable feedback for the CloudKit folks to consider. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Since Swift Playground 4.6, as you have observed, it is no longer possible to import PlaygroundSupport because the PlaygroundSupport framework provides no functionality to app playgrounds. However, starting in Swift Playground 4.6, you can conditionalize code with the SwiftPlaygrounds condition: #if SwiftPlaygrounds container = NSPersistentContainer(name: myApp, managedObjectModel: Self.createModel()) #else container = NSPersistentCloudKitContainer(name: myApp) #endif

+1 I've built an app using CoreData + CloudKit and now I have to rewrite everything using NSPersistentCloudKitContainer.

This issue is still ongoing. Thus far we have not been able to figure out what is going on but have reduced complaints quite a bit by rolling back to minimum OS / Devkit of iOS 17. So it is some kind of bug or behavioral issue with iOS 18 SDK. We cannot find a pattern to it other than that most users are in Europe and are not using iCloud to backup. This means we are using the NSPersistentCloudKitContainer regardless of if users enable or do not enable iCloud usage. This might be the root so if anyone is aware of what might have changed in iOS 18 that would do this PLEASE let me know. We have also now default always enable iCloud usage without asking if we find an account present. They can turn it off (with big warnings) if they want but we no longer ask on launch. Also we will investigate not always using NSPersistentCloudKitContainer if iCloud is not used.

Well something changed since we switched to iOS 18 SDK and it definitely did not work this way in earlier versions of iOS. At some point after iOS 15 SDK something changed and the cleaning process you mentioned is literally wiping users data and if it was never in iCloud in the first place it is totally gone now?! We have always used an NSPersistentCloudKitContainer since we first implemented it years back regardless of if the person enabled iCloud (in our App or not). This was based on statements Apple Engineers made in the past that you could always use NSPersistentCloudKitContainer since it was subclass of nspersistentcontainer and with History on but options set to nil for NOT ALLOWED. But now it seems that users running iOS 18 and who did not allow us to use iCloud (are getting data wiped). It is not clear if they are entirely logged out of iCloud or just have iCloud Drive off or what, but something is different in iOS 18. I really need a way to zero in on what is going on. This is one

are you aware of any behavioral changes in iOS 18 that causes an NSPersistentCloudKitContainer to delete data? Not that I am aware of. To be clear, NSPersistentCloudKitContainer does clean the data on the device if it gets notified of a change on the current logged-in Apple ID, but that has been the as-designed behavior since the very beginning. Note that it only cleans the local data; the data on CloudKit is still there, and will be synchronized back when the user logs back in with the same account, and so no data loss will happen. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Ziqiao are you aware of any behavioral changes in iOS 18 that causes an NSPersistentCloudKitContainer to delete data? In past we were told it could be used in all cases with history on, even if user was not allowing cloudkit. This was true until iOS 18 it seems now if that initializes and user is not using iCloud would it delete data. I thought I was seeing people talking about that and that it does that for security. if That is true that is a huge damn change and which Apple should tell people about?!