I think that's all you can do for now as lightweight migration gives you no opportunity to intervene and, as far as I know, custom migration fails with iCloud enabled.

Looking at your code above, you are trying to migrate from SchemaV1 to SchemaV2 using a custom migration stage. If you think your changes can be done using a lightweight migration, use a lightweight migration stage instead and see what happens. However, you are trying to establish relationships after migration in your didMigrate logic, which you can't do with a lightweight migration stage, not as part of the migration anyway.

I agree with your point about it being a big issue. I face the same problem and have come to the conclusion that custom migration is not supported under SwiftData with iCloud enabled. As SwiftData is currently layered on top of Core Data it must share the same limitations. With Core Data, if you are using iCloud, you must use lightweight migration. I can't find anything in Apple's documentation that specifically says you can or cannot do a custom migration with SwiftData and iCloud. I sincerely hope someone can prove me wrong and say this is possible.

If you enable only your local configuration in your model container does both your willMigrate and didMigrate logic in your custom migration stage execute and does your schema version update? If instead you enable only your cloud configuration, what happens? If this route hits your willMigrate but crashes before it hits didMigrate then the migration is not happening. Setting up both configurations in series and discarding the local configuration might be masking this issue by preventing a crash while at the same time failing to migrate. Could this be why your schema version is not changing?

Did you get any further with this? I have the same problem. I need to have access to the source and the destination models to change attribute types and values as part of the migration. How I understand the current MigrationStage logic is that willMigrate gives you access to the source models and didMigrate gives you access to the destination models, but you can't have access to both at the same time, like with the Core Data mapping model and migration policy approach. Am I wrong?

If you omit the modifiers argument, if defaults to .command, so if you try cmd + space, your keyboard shortcut will probably work. public func keyboardShortcut(_ key: KeyEquivalent, modifiers: EventModifiers = .command) -> some View Try .keyboardShortcut(.space, modifiers: []) and space on its own should work.

I don't think this is possible yet in a pure SwiftUI way. I raised a Technical Support Incident for this as I too needed to know how and the solution I received from Apple is below: if let windowScene = UIApplication.shared.connectedScenes.first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene { SKStoreReviewController.requestReview(in: windowScene) } I was hoping the active scene would be available as an @Environment value, but alas no. My app uses the SwiftUI lifecycle and so I prefer not to fall back to UIApplication like this.