NSPersistentCloudKitContainer

You can use the feedback assistant to file bugs against NSPersistentCloudKitContainer. Include the following: A sysdiagnose from all of the participating devices The persistent store files from all of the participating devices If your dataset is large, a detailed accounting of the affected records and the mutations made to them from each device (as well as you recall, history tracking is the truth)

You need to create a custom Core Data class and inject it into ContentView() I don‘t have a default file at hand but you can inject it like below let context = PersistentCloudKitContainer.persistentContainer.viewContext tt ContentView().environment(.managedObjectContext, context) Below my CloudKitContainer but you can simply change that to a regular PersistentContainer class import CoreData public class PersistentCloudKitContainer { tt tt// MARK: - Define Constants / Variables ttpublic static var context: NSManagedObjectContext { ttttreturn persistentContainer.viewContext tt} tt tt// MARK: - Initializer ttprivate init() {} tt tt// MARK: - Core Data stack ttpublic static var persistentContainer: NSPersistentCloudKitContainer = { tt ttttlet container = NSPersistentCloudKitContainer(name: Container_Name) ttttcontainer.loadPersistentStores(completionHandler: { (storeDescription, error) in ttttttif let error = error as NSError? { ttttttt ttttttttfatalError(Unresolved error (error), (error.userInf

If you are trying to use an App Group container to share a database between your iOS app and an WatchKit extension, that won't work because the iOS app runs on iPhone and the WatchKit extension runs on the paired watch, and an app ground container can't be cross devices. You will have to synchronize the data across the devices with your own code. As Nick points out, you can try with NSPersistentCloudKitContainer, you can also use CloudKit directly to synchronize the data you need. WatchConnectivity is not recommended if you want your watch app to be standalone.

NSPersistentCloudKitContainer does not yet support sharing, please consider filing a feedback request with details about your desired use case.

AFAIK Watch apps do not naturally sync data back to the companion. This has to be done via one or more of these solutions, Keeping Your watchOS Content Up to Date - https://developer.apple.com/documentation/watchkit/keeping_your_watchos_content_up_to_date. The easiest way to do that would be NSPersistentCloudKitContainer, however WatchConnectivity - https://developer.apple.com/documentation/watchconnectivity may be a better fit depending on your needs.

How can I check that an entity already exists remotely ? In theory you could write some CloudKit code to execute a CKQueryOperation that checks for your seed content. But that won't handle the race between a device exporting the data and another device launching the app and parsing the json file. You can also check if records exist in the local store using NSFetchRequest. However for the same reason that won't prevent you from inserting duplicate records on multiple devices if they haven't synced with the CloudKit server yet. There are a number of approaches to seeding your application store with content in a reliable way: Don't sync the seed content, instead use an un-synced store to hold the data from the JSON file and a synced store to hold user data Unique the seed content on each device as it is updated by NSPersistentCloudKitContainer Unfortunately NSPersistentCloudKitContainer does not support unique constraints yet, you can file a feedback request for that though.

You can use the feedback assistant to file bugs against NSPersistentCloudKitContainer. Include the following: A sysdiagnose from all of the participating devices The persistent store files from all of the participating devices If your dataset is large, a detailed accounting of the affected records and the mutations made to them from each device (as well as you recall, history tracking is the truth)

You wrote: [objectID] certainly changes from run to runI'm not seeing that. It seems to be completely consistent. I was using `objectID.uriRepresentation()` to implement `Identifiable`, and the docs for `uriRepresentation` say it is archivable, which suggests to me that it doesn't change. (?) I'm using `NSPersistentCloudKitContainer`, if that matters.I think that what's getting me now is...ForEach(dataSource.fetchExercises(moc:moc)) { ex in NavigationLink(destination: ExerciseView(exercise: ex)) { ListItemView(exercise: ex) } }If that detail view (ExerciseView), changes the exercise in way that should _reorder_ the results of fetchExercises and the ForEach, then I make `dataSource` (which is an observable object) emit `objectWillChange`. As expected, SwiftUI re-calls `fetchExercises`. But sadly, it pops off the detail view (ExerciseView) and returns to this list view.I thought it should see that the exercise objects have the same IDs, so it would keep the ExerciseView pushed.I too am interested to se

I have exactly the same problem, I use NSPersistentCloudKitContainer with Catalyst. The problem started after I deployed the Schema to production.The synchronization works perfectly on all devices (mac, iPhone, Simulator) until I add a photo from Simulator. This photo is synchronized with Mac, but as soon as it tries to sync with iPhone, it crashes. The only way I found not to crash, is to delete as many photos as I had added from Simulator. After that, iPhone crashes stops and starts syncing again.EDIT:I've found that the problem is not from the simulator but from a big image.I tried that using a 8k image and it crashed.If I deselect the Allow External Storage option though, it works fine.

I have this problem where your crash originates on the queue:com.apple.xpc.activity.com.apple.cloudkit.scheduler.com.apple.coredata.cloudkit.activity.export (serial)This might be the same problem you are speaking of.I reported it to Apple (no solution yet).But important point is: It seems to happen only in debug mode. I have released an app with NSPersistentCloudKitContainer and it does not crash in production.