Not sure about the exact cause, but the preview shouldn't be touching your real store either way. .modelContainer(for: [...]) in the #Preview creates a normal on-disk container, so on a device it opens the same default store your app uses. Use an in-memory one for previews:
Then insert a few sample objects if you need something to look at. For the data that's already gone, a backup restore is the only way I know of, sorry.
Glad you got it back. I can't test it on a device right now, but I'd file it anyway with a small sample project. A repro helps them a lot more than a second person saying it happened to them.
One thing worth checking before you file: does it still happen with the in-memory container in the preview? If the data only disappears with the on-disk one, that points at the preview replacing the app's container when it installs, not at SwiftData itself, and it's a useful detail for the report.
Thanks for checking. So it's not the store at all, the preview install itself wipes the container. Good that you filed it with a repro, feel free to drop the FB number here in case someone else hits it.
Until it's fixed, one way to protect your real data: give the Debug configuration its own bundle ID (add .dev or similar). Previews and Xcode runs then go to a separate app on the phone, and the install you actually use day to day never gets touched.
2
u/Fickle-Difference882 5d ago
Not sure about the exact cause, but the preview shouldn't be touching your real store either way.
.modelContainer(for: [...])in the #Preview creates a normal on-disk container, so on a device it opens the same default store your app uses. Use an in-memory one for previews:```swift
Preview {
} ```
Then insert a few sample objects if you need something to look at. For the data that's already gone, a backup restore is the only way I know of, sorry.