imo "occasional crash" almost always means "race condition". Look at refactoring your code to add and remove objects in the - (void)renderer:(id )renderer updateAtTime:(NSTimeInterval)time callback?

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/