Done, thanks!

Such a weird bug. Still happening two years later with iOS 16.4. struct ContentView: View { var body: some View { NavigationView { List { NavigationLink("Go to detail view") { Text("Detail view") .toolbar { ToolbarItem(placement: .bottomBar) { Button(action: { print("tap") }) { Image(systemName: "square.and.arrow.up") } } } } } } // Without this, toolbar is either empty or doesn't appear in detail view .navigationViewStyle(.stack) } }

A couple other things I noticed. First, the crash occurs between the calls to willMigrate and didMigrate. Second, if I try to run the app again after the crash then it runs fine, albeit with the new property being nil since didMigrate didn't execute, but this seems to suggest that the crash occurs downstream from the new schema version being applied to the database.

Thanks Ziqiao, I will take a look at the code sample you pointed to and try to come up with a reduction that I can share. Either way I'll report back.

Trying different things with my project, I discovered that the problem only occurs when CloudKit syncing is enabled. Turning off syncing by passing cloudKitDatabase: .none to ModelConfiguration or by unchecking the CloudKit option in Signing & Capabilities makes the problem go away. But then of course iCloud syncing doesn't work. Makes sense considering the error message I get. I was able to reproduce the problem easily with a new project based on the SwiftData Xcode template. I don't think it's doing anything out of the ordinary but I'm looking forward to find out. The project can be found here: https://www.icloud.com/iclouddrive/0a5WkBaQRA1N-FOLGjKukV8Ag#MigrationSample There are actually two projects, one for schema v1 and one for schema v2. To reproduce the error I get: Open the MigrationSampleV1 project, build and run. In the running app, create some data. Open the MigrationSampleV2 project, build and run. Expected result: The migration kicks in and the app opens. Actual result: A crash occurs before the migration's didMigrate.

Oh here's a direct link to the zip file instead of a shared folder. https://www.icloud.com/iclouddrive/022QsLMXmVHAU2lAcuj4XuV4w#MigrationSample

Thanks Ziqiao. I filed the report. It's FB16712454.

This issue is fixed in the iOS 26 beta. ✅

I did some of investigation of this issue because I ran into the same problem when trying to convert an old project from groups to folders. I discovered what is happening is that Xcode 16 changes the model's current version to the last one alphabetically. I was able to reproduce it this way: Create a brand new, folder-based, Xcode project. Add an xcdatamodeld with one entity. Add a new model version and name it "a". Make it current. Quit Xcode. Relaunch Xcode. Expected result: The "a" model version should still be current. Actual result: The original model version is current. I was able to reproduce with Xcode 16.2 and 16.4. It appears to be fixed in Xcode 26 beta 6. Based on these steps, one workaround appears to be to name the model versions alphabetically. Another workaround is to keep the xcdatamodeld file in a group, not a folder. And of course if you can switch to Xcode 26, then you don't need to workarounds above.