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

CloudKit has native support for location fields. See https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitQuickStart/AddingAssetsandLocations/AddingAssetsandLocations.html for a query example.

The debugger is working! ;-) Managed objects should never cross thread boundaries, and accessing attributes from a managed object outside of the context in which is was created or fetched can cause crashes. The call to completion(result) should be within the the self.backgroundContext.performAndWait block.

the real question is, how are you displaying your profiles? Are you using FetchedResultsControllers? If yes, you need to create and save a new profile in a background context, which will then notify the FRC and (if you've wired the FRC up properly) update your UI.