NSPersistentCloudKitContainer

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.

The SwiftData version of the Adopting SwiftData for a Core Data app does pretty much the same thing as what you described, except that it doesn't use CloudKit, and so you can probably start with checking if the sample demonstrates the same issue on your side. To figure out what really happens when the value changes, you can use the SwiftData history API to dump the history and analyze the update transaction (HistoryUpdate). The sample mentioned above demonstrates how to use the history API as well. If you are using SwiftData + CloudKit, which is based on NSPersistentCloudKitContainer today, in an extension, you might want to look at the following technote section: Avoid synchronizing a store with multiple persistent containers. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I open the app. Few seconds later I receive two new tokens (183 and 184) which are the mirroring of 180 & 181. They override 182. New state = 181 instead of 182. This is the bug. This does sound like a bug to me. I unfortunately don't see any workaround because the synchronization logic is all encapsulated in NSPersistentCloudKitContainer. I’d suggest that you file a feedback report for the Core Data + CloudKit folks to take a look – If you do so, please share your report ID here for folks to track. As discussed in Avoid synchronizing a store with multiple persistent containers though, I'd probably have the main app, and not its extension, do the CloudKit synchronization. Best, —— Ziqiao Chen  Worldwide Developer Relations.

this project is using CloudKit for persistence through SwiftData... In order to use CloudKit's sharing APIs, such as CKShare.Participant, which contains the info you'd like to access, you'd need to implement a coexistence approach with Core Data and SwiftData. In iOS 17 SwiftData can express only a subset of NSPersistentCloudKitContainer's capabilities, and CloudKit sharing isn't one of them. That said, does your app have a use for CloudKit sharing? If not, and if your app is for macOS, you could use NSFullUserName(). In the event someone is using CloudKit sharing and needs to access the current user's name components, I found that using a CKShare directly works in iOS 17: func fetchCurrentUsername(for share: CKShare) -> String { var name = let currentUser = share.currentUserParticipant if let nameComponents = currentUser?.userIdentity.nameComponents { name = nameComponents.formatted() } return name }

NSPersistentCloudKitContainer doesn’t support unique constraints today. To make sure that a record is unique across devices, you need to implement your own mechanism. In case you are interested in doing that, I have a sample project (I use it as my testbed) that may help: Sharing Core Data Objects Between iCloud Users It is a SwiftUI project that supports iOS and watchOS, and covers the following topics: Creating the CloudKit Schema for Apps Setting up the Core Data Stack Sharing a Core Data object Detecting Relevant Changes by Consuming Store Persistent History Removing Duplicate Data Implementing a Custom Sharing Flow #4 and #5 are probably the most relevant to your question. Feel free to provide your feedback here so I can improve the project and hopefully better help.

I get the error This NSPersistentStoreCoordinator has no persistent stores (unknown). It cannot perform a save operation. What does this error exactly mean? The error message says the persistent store coordinator has no persistent stores. Core Data saves data to a persistent store. If there are no persistent stores, Core Data cannot save your app's data. My container is initialised so it should have a persistent store, right? Are you sure the container was initialized correctly? let container = NSPersistentCloudKitContainer(name: TaskDataModel) Do you have a CloudKit container named TaskDataModel? Set a breakpoint at the start of the init function in DataController. Does the container property have the value you expect? Step through the code line by line. Does the call to loadPersistentStores run correctly or does it generate an error?

Dear Ziqiao Chen, thank you for your reply and the hints pointing me in the right direction. I managed to solve my problem no. 1 and now the sync works both between the app and the widget, but also between different devices. I had already observed the .NSPersistentStoreRemoteChange notification in my sample project, but it turns out that wasn't even necessary when automaticallyMergesChangesFromParent is set to true on the viewContext. The Problem with Syncing from a Widget Now the problem is the following: Regarding using Core Data + CloudKit (NSPersistentCloudKitContainer) in an extension, I'd like to suggest against doing that ⬆️ Your reply and the linked Technical Note both imply that syncing data with iCloud this way from both the app and its widget is not reliable as two NSPersistentCloudKitContainers pointing to the same persistent store can get in conflict (running on different threads) and throw the following error: CloudKit setup failed because there is another instance of this pers

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

SwiftData + CloudKit integration is based NSPersistentCloudKitContainer as of today, and so you can observe the synchronization events using eventChangedNotification with the following steps: Observe the eventChangedNotification notification. In your notification handler, use eventNotificationUserInfoKeyto retrieve the the event from notification.userInfo. Look into the event type, startDate, and endDate to understand the state of the event. For a runnable sample, please see Sharing Core Data objects between iCloud users. It is a Core Data sample, but the way to observe eventChangedNotification can be applied to SwiftData. Note that eventChangedNotification tells you the state of an individual export or import event, and not that the whole Core Data store is synchronized with the CloudKit server (or not), because there may have new changes happening on the CloudKit server while the event is being handled. Best, —— Ziqiao Chen  Worldwide Developer Relations.

This is NOT fixed with beta 5. Two problems related to NSPersistentCloudkitContainer persist since beta 4. I've submitted a bug report to Apple - no response yet. The issues: Account temporarily unavailable due to bad or missing auth token when using the Development Environment (device or simulator), despite being signed in and despite it working on beta 1, 2 & 3. When using the App Store version of my App (in the Production Environment) on an iOS 15 device (beta 4 & 5), the syncing appears to start but nothing syncs. The app crashes to the springboard after a minute without warning. Crash reports are vague but I have captured a CloudKit sysdiagnose and sent it to Apple in the hope they can decipher it. I really hope they sort this out as it's going to render my currently available app useless if iOS15 is released in this state and my users install it.

I found a solution for my case, so I'm posting to help anyone else with a similar setup. If you're sharing a CloudKit container across multiple apps (using different bundle IDs), apart from specifying the container identifier when initializing the container, you must set NSPersistentCloudKitcontainerOptions on the NSPersistentCloudKit container (this is in the AppDelegate if you selected the Use CloudKit option during project creation) as shown below: let container = NSPersistentCloudKitContainer(name: ModelName) guard let description = container.persistentStoreDescriptions.first else { tt fatalError(No container descriptions available) } description.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier:iCloud.com.organization.ContainerName) container.persistentStoreDescriptions = [ description ] In your code, when you access the desired container, you use the same container ID as in the description above: let container = CKContainer(identifier: iCloud.com.organization.C

hi, i would think your easiest solution is to use the built-in linkage between Core Data and CloudKit using NSPersistentCloudKitContainer. this takes care of all of your concerns: your data is stored locally in Core Data and mirrored to/from the cloud for you. everything works fine when offline or not signed in to iCloud. just remember that in this design, the Cloud becomes the source of truth for your data. modify data on one device; it is synced with iCloud; and then the data is synced with your other devices, where their local Code Data store is synced to match what's in the cloud. there would be no option for the user here to choose which data they want to use, as you say, the backed-up data or the new data. once your device is online and signed into iCloud, your on-device data will be synced to be a mirror of what's in the cloud. hope that helps, DMG

SwiftData + CloudKit uses NSPersistentCloudKitContainer under the hood, which requires all relationships must be optional. For more information, see Creating a Core Data Model for CloudKit. The requirement exists because of the latency of the synchronization: When you create an object graph in device A, which is being synchronized to device B, the system doesn't guarantee to synchronize the whole graph all at once. As a result, it's possible that an object is synchronized but its relationship is not. This situation is expressed as the relationship being nil. By checking if the relationship is nil, the app instance running on device B can consume the object appropriately. In your case, wrapping a relationship with a computed property to return an empty array if nil makes sense to me, if the other part of your app prefers to consume an empty array. It doesn't matter if the data is big or small. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Is this indeed true? Yes. If it isn't allowed, is the only solution to disable multiple instances of the process via a lock file? I was thinking one could somehow coordinate a single leader process that syncs to the cloud, with the others using NSPersistentContainer, but this would be complicated when the leader process terminates. I'm skeptical that's a workable solution. Holding file locks across assertion boundaries will cause your app to get killed. However the system regularly suspends apps doing NSPersistentCloudKitContainer work for load balancing. There isn't a convenient process model for multiple apps coordinating on a shared networking space. If extensions fail to meet your use case needs, you will have to elect a leader application to manage the CloudKit sync. Other applications can access the same store file without the NSPersistentCloudKitContainerOptions set, but only one process can manage sync.

SwiftData default store is based on Core Data. As a historical implementation detail, at runtime, a Core Data to-many relationship, once persisted, is always a [], and never a nil. To adapt this behavior in an effective way, SwiftData always initializes a nil to-many relationship with an empty collection at runtime. So to your first question, the behavior that optional to-many relationships in SwiftData are never nil at runtime is as-designed. The requirement that relationships must be optional is a way to express that NSPersistentCloudKitContainer does not handle relationships atomically, and is enforced by a schema validator at compile time. The validation doesn't have any impact at runtime, and so SwiftData to-many relationships being [] at runtime doesn't break the CloudKit synchronization. To use SwiftData + CloudKit, you make sure your model schema is compatible with the rules so the schema validator doesn't complain, and that will be it. Best, —— Ziqiao Chen  Worldwide Developer Relations.