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.

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.

Did you make any progress on this issue?

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

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.

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/

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.

is your app pointing to production?

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).

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

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

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.

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.

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.

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