use NSPersistentCloudKitContainerOptions to configure the container identifier to sync with class PersistenceApp1: ObservableObject { static let shared = PersistenceApp1() let container: NSPersistentCloudKitContainer init(…) { container = NSPersistentCloudKitContainer(name: “App1”) let store = NSPersistentStoreDescription() store.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.com.example.App1") container = [store] container.loadPersistentStores… } … } Also, make sure to add both container identifiers to your app's Signing & Capabilities > iCloud > Containers list

fwiw, I also saw this two days ago. It's not often I change my CloudKit schema, so unsure how long this has been an issue. To resolve it to my own satisfaction, I manually restored the various indices in dev, such that the only change being pushed to production was the actual new fields, and it worked.

Yes, you can…

You're fighting an unwindable battle here. If you're just learning Core Data, you should avoid trying to marry it to Swift concurrency. Core Data has its own, very specific, means of handling background thread implementations, in that, all managed objects should only be retrieved, changed, and saved within a managed object context perform { } block.

This call presents UI only once per user, per instance of the CloudKit container. To continue to test the experience of the user interface in your dev environment, reset the schema in the CloudKit dashboard.

"In my searching I've seen one suggestion is to create an App Group and share the Core Data stack in there". Do that.

In the CloudKit Dashboard, did you push your schema changes from Development to Production?

technically, if you add or remove attributes from a model, the version (hash) will be different from before. The good news is, lightweight migrations can often handle simple additions and removals of attributes. as always, test to verify

check your clipping planes? https://developer.apple.com/documentation/scenekit/scncamera/1436592-znear

https://developer.apple.com/documentation/scenekit/scncamera/1436592-znear

No.

research @FetchRequest

None of the existing ARConfiguration classes do this, which suggests that vision tracking is foundational to accurate position and motion tracking. and for completeness, I'll point you to Core Motion https://developer.apple.com/documentation/coremotion

I recommend turning on full Core Data debugging, see if it highlights any issues. https://useyourloaf.com/blog/debugging-core-data/

Syncing large data files in CoreData<->CloudKit is particularly challenging. If you just store data in Binary Data attributes, that get converted into CKAssets, then fetching and modifying those CKRecords can take a long time, and potentially timeout, particularly if the user backgrounds the app and it gets suspended. To my knowledge, NSPersistentCloudKitContainer does use background tasks for syncing, but these aren't the same as long-lived operations, which are handled outside of the app. I've been pondering these issues for a while now, and have been working on an update to an open-source sync engine called CloudCore, with support for Cacheable Assets. Its a bit complex to establish your schema and code, but once done, large files you associate with CoreData managed objects are uploaded and downloaded using long-lived operations. The feature isn't quite ready yet, still doing some real-world testing, but you can see the progress here… https://github.com/deeje/CloudCore/pull/28 and feel free to check out the branch here… https://github.com/deeje/CloudCore/tree/feature/Cacheable