“NSPersistentCloudKitContainer”

After replacing NSPersistentCloudKitContainer with NSPersistentContainer, I'm still getting the crash, as you suspected. Attached is the crash report when I ran the code on the simulator. BugTest.txt

This is pretty similar to an existing issue we know. Would you mind to try the following? Replace NSPersistentCloudKitContainer with NSPersistentContainer and verify that the issue is still there. This is to simplify the issue by ruling out CloudKit. Reproduce the issue, gather a crash report, and share here. I'd be able to confirm by reading the crash report. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Other than what @Fat Xu said, the following post and technote may provide more context: SwiftData and CloudKit Development vs. Production Database TN3163: Understanding the synchronization of NSPersistentCloudKitContainer. Best, —— Ziqiao Chen  Worldwide Developer Relations.

@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.