Add five expenses, quit Pocket Budget, open it again, and the list is empty. Everything lived in memory. Users expect their data to survive restarts, updates and a phone that ran out of battery mid-save. SwiftData is Apple’s persistence framework built for Swift: you describe your model in code, and it handles the database, the schema and keeping SwiftUI in sync.
\nimport Foundation\nimport SwiftData\n\n@Model\nfinal class Expense {\n var title: String\n var amount: Decimal\n var category: Category\n var date: Date\n var note: String = \"\"\n\n init(title: String, amount: Decimal, category: Category, date: Date = .now) {\n self.title = title\n self.amount = amount\n self.category = category\n self.date = date\n }\n}Two things changed from the struct you’ve used since the modelling section. First, @Model requires a class. A saved expense has one identity: the list, the detail screen and the edit form must all see the same record, which is the reference semantics you learned to reach for when data is shared. Second, you write an initializer yourself, because classes don’t get a memberwise one.
@Model makes the class conform to PersistentModel, which brings Identifiable and Hashable, so ForEach and NavigationLink(value:) keep working unchanged. The Category enum needs to conform to Codable to be stored; add it to its declaration. You can delete the id property: SwiftData gives every model a persistent identifier.
@main\nstruct PocketBudgetApp: App {\n var body: some Scene {\n WindowGroup {\n ExpensesScreen()\n }\n .modelContainer(for: Expense.self)\n }\n}The model container owns the database file and the schema. Creating it once on the scene also puts a model context into the environment. The context is your workspace: it tracks inserted, changed and deleted models and writes them to disk. The main context saves automatically, so most apps never call save() by hand.
Create the container in exactly one place. A ModelContainer built inside a view’s body or initializer gets recreated whenever SwiftUI rebuilds that view, and each copy opens the store again. Put it on the scene, as here, and every view below shares the same one.
struct ExpensesScreen: View {\n @Query(sort: \\Expense.date, order: .reverse) private var expenses: [Expense]\n @Environment(\\.modelContext) private var context\n\n var body: some View {\n NavigationStack {\n List {\n ForEach(expenses) { expense in\n NavigationLink(value: expense) {\n Text(expense.title)\n }\n }\n .onDelete { offsets in\n for index in offsets {\n context.delete(expenses[index])\n }\n }\n }\n .navigationTitle(\"Expenses\")\n .navigationDestination(for: Expense.self) { expense in\n EditExpenseView(expense: expense)\n }\n }\n }\n}@Query fetches every Expense, newest first, and re-runs whenever the stored data changes, so a delete or insert anywhere in the app updates this list on its own. The query result is read-only: you change data through the context. In the add form from the SwiftUI section, the Save button now calls context.insert(Expense(title: title, amount: amount, category: category, date: date)) instead of store.add(...). The expenses no longer live in BudgetStore; it keeps app settings such as the monthly limit and the exchange rates.
A model is an observable class, so @Bindable gives you bindings straight into it:
struct EditExpenseView: View {\n @Bindable var expense: Expense\n\n var body: some View {\n Form {\n TextField(\"Title\", text: $expense.title)\n TextField(\"Amount\", value: $expense.amount, format: .currency(code: \"USD\"))\n DatePicker(\"Date\", selection: $expense.date, displayedComponents: .date)\n }\n .navigationTitle(expense.title)\n }\n}There’s no Save button. Typing changes the model, the context notices and autosaves, and the list behind updates too. If you want Cancel semantics instead, copy the values into @State drafts as the add form does, and write them back on Save.
Pass a predicate to @Query to fetch a subset. When the filter depends on a value the view receives, build the query in init:
struct RecentExpensesView: View {\n @Query private var recent: [Expense]\n\n init(since start: Date) {\n _recent = Query(filter: #Predicate<Expense> { $0.date >= start },\n sort: \\.date, order: .reverse)\n }\n\n var body: some View {\n List(recent) { Text($0.title) }\n }\n}#Predicate is checked at compile time and translated into a database query, so filtering happens in storage rather than in a Swift loop. Keep predicates to simple stored properties such as dates, numbers and strings. Filtering on enum properties inside a predicate has historically been unreliable, so filter categories in Swift after fetching, or store the category’s raw value as a String if you need to query by it.
Adding a new property later, like note above, works without extra code when it has a default value: SwiftData migrates the store automatically. A rename needs a hint, @Attribute(originalName: "oldName"), so the old column carries over; changing a property’s type needs a versioned schema and a migration plan, which you can postpone until you have real users with real data.
Pocket Budget now survives restarts. The last lesson makes sure it keeps working as you change it, with Swift Testing, and gets it onto other people’s phones through TestFlight.
\n","toc":[{"id":"sec-1","text":"Making Expense a model","level":2},{"id":"sec-2","text":"One container for the app","level":2},{"id":"sec-3","text":"Reading with @Query, writing through the context","level":2},{"id":"sec-4","text":"Editing with @Bindable","level":2},{"id":"sec-5","text":"Filtering","level":2}],"takeaways":["@Model turns a class into persisted data; SwiftData builds the storage schema from its stored properties.",".modelContainer(for:) on the app’s scene creates the database once and puts a model context in the environment.","@Query fetches, sorts and filters models for a view and keeps the result up to date as data changes.","Insert and delete through modelContext; changes to a model’s properties save automatically, including edits bound with @Bindable.","[object Object]"],"further":[{"title":"SwiftData","url":"https://developer.apple.com/documentation/swiftdata"},{"title":"Preserving your app's model data across launches","url":"https://developer.apple.com/documentation/swiftdata/preserving-your-apps-model-data-across-launches"},{"title":"Query","url":"https://developer.apple.com/documentation/swiftdata/query"}],"quiz":[{"q":"Why does Expense change from a struct to a final class when it becomes a SwiftData model?
@Model requires a class, because a saved record has one identity that every screen observes and edits.","why":"Correct. Edit an expense in one view and every view showing it sees the change, which is reference semantics."},{"text":"Structs can’t contain Decimal or Date properties.","why":"Structs hold those types all the time; the earlier lessons used them."}],"answer":1},{"q":"A list uses @Query private var expenses: [Expense]. How do you remove an expense the user swiped away?
expenses.remove(at: index)","why":"The query result is read-only; it reflects the store, it doesn’t control it."},{"text":"Set the expense’s properties to empty values.","why":"That saves an empty expense; it doesn’t delete anything."},{"text":"context.delete(expenses[index]), using the model context from the environment.","why":"Correct. Changes go through the context, and the query updates itself to match."}],"answer":2},{"q":"An edit screen binds a TextField to $expense.title through @Bindable var expense: Expense. When is the change saved?
context.insert(expense) again.","why":"The expense is already in the context; inserting again isn’t how updates work."},{"text":"Never, because bindings create a copy of the model.","why":"A model is a class, and the binding writes straight to the shared instance."}],"answer":0},{"q":"Your SwiftUI preview of the expenses list should show sample data without touching the real database. What do you use?
","options":[{"text":"The app’s normal.modelContainer(for: Expense.self).","why":"That points at the same on-disk store the app uses; previews would read and write real data."},{"text":".modelContainer(for: Expense.self, inMemory: true), then insert sample expenses.","why":"Correct. The data lives only in memory and disappears when the preview ends."},{"text":"A plain array instead of @Query.","why":"That previews a different view from the one you ship, which defeats the purpose."}],"answer":1}],"exercise":{"kind":"fill","language":"swift","template":"@{{0}}\nfinal class Expense {\n var title: String\n var amount: Decimal\n var date: Date\n\n init(title: String, amount: Decimal, date: Date = .now) {\n self.title = title\n self.amount = amount\n self.date = date\n }\n}\n\nstruct ExpensesList: View {\n @{{1}}(sort: \\Expense.date, order: .reverse) private var expenses: [Expense]\n @Environment(\\.modelContext) private var context\n\n var body: some View {\n List {\n ForEach(expenses) { expense in\n Text(expense.title)\n }\n .onDelete { offsets in\n for index in offsets {\n context.{{2}}(expenses[index])\n }\n }\n }\n .toolbar {\n Button(\"Add coffee\") {\n context.{{3}}(Expense(title: \"Coffee\", amount: 4.5))\n }\n }\n }\n}","blanks":[{"answers":["Model"]},{"answers":["Query"]},{"answers":["delete"]},{"answers":["insert"]}],"title":"Persist expenses with SwiftData","prompt":"Make Expense a SwiftData model and finish the list: it must fetch expenses newest first, delete the ones the user swipes away, and add a coffee expense when the button is tapped. The app’s scene already has .modelContainer(for: Expense.self).
@Model turns the class into a persisted SwiftData model. @Query(sort: \\Expense.date, order: .reverse) fetches every expense newest first and refreshes when the data changes. Writes go through the context from the environment: context.delete(_:) removes a model and context.insert(_:) adds one. The main context autosaves, and the query updates the list on its own, so there’s no array to keep in sync by hand.