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.

its almost like the section "Isolate the Current View from Store Changes" should be prefaced with "If you are not using NSFetchedResultsControllers, …"

iOS SDK provides the building blocks, we have to build the solutions. I too am working on a body tracking app (and I've released an open source lib for recording and playback https://github.com/deeje/AVBody ) And I think the solution is to build a companion watch app, a la Camera.app, that shows a slow frame rate video feed, and buttons to start/stop recording. fwiw

adding to Claude31, SwuiftUI's @FetchedResults, and the underlying NSFetchedResultsController, are IMHO a key reason to adopt CoreData: changes in the background at the model layer get signaled to the main thread view layer, which can then be dynamically updated. The other reason to use CoreData is enabling device-to-device synchronization (for a user with multiple devices, or data shared between users) via NSPersistentCloudKitContainer (or an open-source sync engine like CloudCore).

is your app pointing to production?

From my experience… this permission persists with the user's iCloud account, not the device. If you reset your developer CloudKit environment, the permissions are reset, but in production they cannot be reset.

you need to use App Groups, and store and access your core data in your app group container. start here https://www.avanderlee.com/swift/core-data-app-extension-data-sharing/

Yes, in my experience, CloudKit only works when the user is signed into iCloud and iCloud Drive is enabled. it is better than it used to be… for years, CKContainer.default().accountStatus() would return .available even when iCloud Drive was disabled. That changed in the few years.

Changes made in one process aren't automatically propagated to other processes that share the same core data file. NSPersistentHistoryTracking was introduced to address this. See https://developer.apple.com/videos/play/wwdc2019/230

Did you make any progress on this issue?

You're asking two distinct frameworks (ARSession and AVFoundation) to access the camera at the same time. Look at using the ARSession.currentFrame.capturedImage property for the RGB data.

I don't know anything about the specific messages you're seeing, but… Instead of storing "super long strings" in a field of type String, store them in a field of type Binary Data. Also, consider the "Allows External Storage" option.

I recommend enabling all the debugging support for Core Data in Xcode. See here for more… https://useyourloaf.com/blog/debugging-core-data/ most often, a crash during save means you created an NSManagedObject in one context, and tried to save in another context. Also, you should be doing a save within the thread owned by the context, like this context.perform { // load objects // make changes try context.save() }