Ups, I totally mixed that up! 😅 Thanks for the hint! Seems like the only viable option that is supported is then to convert to a Double and back for the intents.

I’ve changed the data model in my MigrationPlan, so I don’t think you need to keep the models in sync. Works for me to keep the Core Data model at the old state before switching and migrating to SwiftData. 🤔 Yeah true, that’s weird that the „old“ .sqlite files won’t automatically get transferred. Seems like a bug to me. Thanks for the hints for enabling iCloud! Will keep an eye on that once I get to that, but sounds like I’m already at a good base.

What a bummer that this isn’t supported yet. 😢 I’ve created a feedback now. Please create duplicates and link to this one to show Apple we need this. My feedback number is: FB15094698

Also, you are mentioning that after the configuration I’ll need to move the newly created .store database and rename it to .sqlite and use this from now on. But how do I do that specifically? I guess in the MigrationStage’s didMigrate? Can you help me how to perform this in code with an example? … if that is even necessary considering my comment above. Maybe there is a better way to make the migration find my old store file and then use the default app group location from then on?

Hey, thanks a lot for your detailed response! 🙏 Yes, the migration from Core Data to SwiftData itself works successfully for me. In my case I don’t want to keep the .sqlite name extension … it’s rather that the migration didn’t find the old Core Data for migration and simply created a new database. So how do I get the migration to 1) find my old „Something.sqlite“ Core Data database, 2) then move it to the App Group 3) so that I can then use it for my Widget and enable it for CloudKit?

This is a bit old now and I already managed to get it to work (see my answer below). Though, as yours was basically the same, I’m accepting yours as answer – thanks! My example code shows an alternative way, when the Core Data model was named differently before via NSPersistentContainer(name: "Model").

I was recommended by Apple (in my filed Feedback) that for the Toggle() you have to place .buttonStyle(.borderless) before the .toggleStyle(.button).

Is there a workaround for a Toggle inside a SwiftUI toolbar? I tried using an additional buttonStyle, but that alters the design of the toolbar and doesn’t show the Tip on macOS anyway …

This issue is still existing as of Xcode 15.0 beta 8 (15A5229m) with iOS 17. I’ve filed a duplicated feedback: FB13136801

Okay, I’ve figured it out! Yes, you have to add CFBundleIconFiles and UIPrerenderedIcon as well. And no you don’t have to use both new keys. I’ve ended up only using NSAppIconComplementingColorNames for the background gradient now. Seems like you have to add both strings to this array, though. So if you want to have a flat color, just put the same name for the top and bottom color. Btw, here is a tweet showing how it can look like: https://twitter.com/emcro/status/1677437755197132801

For some reason I can’t get this to work. Do I need to define the other CFBundlePrimaryIcon keys as well? And I have to use bot new NSAppIconActionTintColorName and NSAppIconComplementingColorNames keys?

Can confirm, it finally works! Tested with Xcode 15 Beta 7.

This should be the accepted answer! Looking into the build logs (View > Navigators > Reports) helped a lot. For me it was an issue with the caseDisplayRepresentations that didn’t include all cases. Even after including all cases I still had to change from DisplayRepresentation(stringLiteral: ) to DisplayRepresentation(title: ). Maybe that helps.

I had the same issue with Xcode 15 beta 6 and adding the deleteRule: before .cascade + removing the default value fixed it. This should be the accepted answer!

Good to know the enum has to conform to Codable! Nevertheless this isn’t working for me – the enum won’t be persisted when changing in the app.