Let's think about it this way for a second
SwiftData is a framework that modernizes Core Data (Apple's traditional local database framework) with Swift-native syntax — just adding the `@Model` macro to a class (a concept similar to Android's Room `@Entity`) auto-generates a database table, no manual SQL/DAO required. Using the `@Query` property wrapper in a View automatically fetches/observes data from the database — when data changes, the UI automatically updates too (similar to Room's Flow concept).
Let's connect this to a real-world scenario
If you define `@Model class TodoItem { var title: String; var isDone: Bool; init(title: String, isDone: Bool = false) { self.title = title; self.isDone = isDone } }` and write `@Query private var todos: [TodoItem]` in your View — all the todo items in the database get automatically fetched, and calling `modelContext.insert(newTodo)` permanently saves data to the device disk, so it'll still be there even after force-closing and reopening the app.
Let's look at it together
import SwiftData
@Model
class TodoItem {
var title: String
var isDone: Bool
init(title: String, isDone: Bool = false) {
self.title = title
self.isDone = isDone
}
}
struct TodoListScreen: View {
@Environment(\.modelContext) private var modelContext
@Query private var todos: [TodoItem]
var body: some View {
List(todos) { todo in Text(todo.title) }
}
}Even after force-closing the app and reopening it, the todo list data doesn't disappear and stays intact (thanks to SwiftData pulling it back).5-minute try-it
Write `TodoItem` (@Model) yourself and display it using `@Query` inside `TodoListScreen` — add a new item with `modelContext.insert()`, then confirm the data still remains after force-closing/reopening the app.
A quick heads-up
If you change your `@Model` schema (properties) during an app update without a migration strategy in place, it can cause data compatibility issues for existing users — the same kind of risk as Room's version/Migration concept.