random crashes, imo, often mean threading issues, and indeed what you shared shows a crash in thread 2 with several other threads running as well. FWIW, early in my SceneKit days, I experienced similar crashes, and solved it by refactoring my code to add and remove SCNNodes only in main thread. fwiw.

I implemented the userDidAcceptCloudKitShareWith… in the SceneDelegate, and set up the scene delegate as such: class AppDelegate { // MARK: UISceneSession Lifecycle func application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration { let config = UISceneConfiguration(name: nil, sessionRole: connectingSceneSession.role) config.delegateClass = SceneDelegate.self return config } } class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func windowScene(_ windowScene: UIWindowScene, userDidAcceptCloudKitShareWith cloudKitShareMetadata: CKShare.Metadata) { let acceptShareOperation = CKAcceptSharesOperation(shareMetadatas: [cloudKitShareMetadata]) acceptShareOperation.qualityOfService = .userInteractive acceptShareOperation.perShareResultBlock = { meta, result in guard let recordID = meta.hierarchicalRootRecordID else { return } // do the things… } acceptShareOperation.acceptSharesResultBlock = { result in // N/A } CKContainer(identifier: cloudKitShareMetadata.containerIdentifier).add(acceptShareOperation) } }

I've often wondered how NSPersistentCloudKitContainer.share… works, and your example goes a long way to explaining it. When you identify the objects you want to share, they get moved to a new zone. and that zone is what is shared. but the API probably wasn't designed to handle the scenario you describe, so once a record is moved to a shared zone, it doesn't/can't get move to another zone. 2¢

there are several open source libraries that use location… like https://github.com/AndrewHartAR/ARKit-CoreLocation

and finally, read TN3164: Debugging the synchronization of NSPersistentCloudKitContainer

then read TN3163: Understanding the synchronization of NSPersistentCloudKitContainer

start with TechNote 3162: Understanding CloudKit Throttles

I suspect that all apps using NSPersistentCloudKitContainer will behave the same way? If this genuinely surprises end-users, then it's on Apple to address, not you.

are you doing anything with core data in background threads?

is the question, you are building a new version of your app and want to load an existing store from an old version, and also enable history, does that work and what are the implications? My suggestion is to build a test app, define a core data schema, run the app, generate and save some test data, quit the app, enable the history bit, and launch again, does the call to load stores fail in some way? and if it succeeds, when you add new data, what does the history show?

also, in case you haven't found this yet… https://developer.apple.com/documentation/technotes/tn3162-understanding-cloudkit-throttles

is your code kicking off 100 CKModifyRecordsOperations simultaneously? yes, assume any CloudKit operation can receive a throttling error and respond as needed

In the "Signing and Capabilities" section of your app target, make sure you add the "Background Modes" capability and enable "Remote notifications" https://developer.apple.com/documentation/swiftdata/syncing-model-data-across-a-persons-devices

fwiw, I'm still getting up to speed on Swift concurrency, but I suspect that NSManagedObject is most definitely not sendable.

you can register for notifications of the player for events such as starting, stopping, pausing, etc. While the music player is playing, you'll want to set up a Timer to periodically update a progress bar. In SwiftUI you can use the TimelineView to periodically update the progress bar. https://developer.apple.com/documentation/swiftui/timelineview