One of these two changes fixe my issue. (1) My CoreDataStack was inside of a package, and the package didn't include .macCatalyst inside of the platforms. Adding it fixed the issue. platforms: [ .macCatalyst(.v26), ], (2) Adding managedObjectContext to the view explicitly inside of a sheet .sheet() { View() .environment(\.managedObjectContext, managedObjectContext) }

After some more debugging, it appears that the managedObjectModel is nil managedObjectContext.persistentStoreCoordinator?.managedObjectModel

My best guess right now is that something with the managedObjectContext or my CoreDataStack in the environment behaves differently on Mac than it does on iOS and VisionOS. I have 3 stores and the version hash in the metadata is up to date for all of them. So I don't think it's related to the managedObjectModel.

It appears to be related explicitly to persistent store. Removing the assign call allows the object to be created, modified, saved as expected. Further, I tried to editing objects with the following code let managedObjectContext = managedObjectContext.child(with: .mainQueueConcurrencyType) let object = managedObjectContext.object(with: objectID) as! Object And this crashed with Thread 1: "Object 0x82018e630c8dd320 <x-coredata://E8D86530-2F0D-4680-98AC-D42B1FF23DE4/Object/p33> persistent store is not reachable from this NSManagedObjectContext's coordinator" Again, this isn't an issue for iOS, but it does appear to be an issue for both Mac and VisionOS. It's also not feasible to provide a minimal project that is minimal.

I contacted them and they never replied. This issues appears to be with how Asset Packs are queried by App Store Connect. I just went to approve new versions of Asset Packs for external testing, and all Asset Packs for all my apps are displayed in the list

After thinking about this some more, I'm not sure reading a store directly from the asset pack will solve my issue. The database get's updated regularly, so if there's an update that finishes downloading while the app is running, the original linked store will be destroyed and replaced with the new one. Which probably will crash the app.

Further, I archived this Asset Pack in the Test Flight section for App B, but the Asset Pack was in production for App A. If an Asset Pack is in production, it shouldn't have the option to be archived from the Test Flight section.

None of the steps are using NSLightweightMigrationStage and they are all NSCustomMigrationStage. I ended up just adding a version to the end of the entity.

There was a few issues here. None of which are documented very well. And all crash with the same error message. (1) My orginal .xcdatamodel file didn't have a Core Data Model Identifier. Which lead to a crash with NSCustomMigrationStage, even though the versionChecksum are different. (2) The steps passed into NSStagedMigrationManager are not clear or documented. But it appears that if you pass the first version of the model into the steps, it crashes. (3) I'm using manual code generation for the model classes. So my goal was to switch the model names, then switch them back, so I didn't have to change anything. For some reason, stepping through the one migration step per app launch instead of all at once allowed for a successful migration. But running all steps threw an error. Turns out I could just rename the model classes with the _v2 suffix, and the only thing I needed to update was the string in the fetch request. Overall, to resolve this I added a model version identifier I duplicated the model version and incremented the model version identifier Deleted the final migration step that removed the entity versioning

Unfortunately I don't know what the cause is. It happened a few times around the time I posted this thread, but I haven't seen it happen since.

Can we please update the alert message to clarify that? All versions of this asset will no longer be accessible by your app. Is not clear

Thank you for those detailed answers!

To test with Xcode you have to run a local server. https://developer.apple.com/documentation/backgroundassets/testing-asset-packs-locally

This is also still an issue with 26.1 Beta 4

This is still an issue with 26.1 Beta 3