A SwiftUI view is a struct that SwiftUI creates, reads and throws away whenever it likes. So where does “the user switched on the Large Expenses Only filter” live? Not in a normal property: the struct holding it may be gone a moment later, and from inside body you can’t even change it. SwiftUI’s answer is a small set of property wrappers, each answering one question: who owns this data?
import SwiftUI\n\nstruct ExpensesScreen: View {\n @State private var showLargeOnly = false\n\n var body: some View {\n Toggle(\"Large expenses only\", isOn: $showLargeOnly)\n }\n}@State tells SwiftUI to keep the value in storage it manages, tied to this view’s place in the hierarchy. The struct can be recreated a hundred times and the value survives. When the value changes, SwiftUI re-reads body and updates the screen.
The $ in $showLargeOnly asks for a binding: a two-way connection to the state. Toggle doesn’t own the on/off value; it receives a binding so it can read the current value and write the new one when tapped. Every input control (TextField, Toggle, Picker, DatePicker, Slider) works this way.
Extract the toggle into its own view, and the child needs to change state that the parent owns:
\nstruct FilterBar: View {\n @Binding var showLargeOnly: Bool\n\n var body: some View {\n Toggle(\"Large expenses only\", isOn: $showLargeOnly)\n }\n}\n\n// In ExpensesScreen's body:\nFilterBar(showLargeOnly: $showLargeOnly)The parent remains the single source of truth; the child gets a binding to it. If the child declared @State instead, it would hold a separate copy that starts with the parent’s value and then drifts apart. That’s the bug behind most “my toggle does nothing” questions.
A filter switch belongs to one screen. The list of expenses belongs to the whole app: the list shows it, the summary totals it, the add form appends to it. That’s shared identity, which the structs lesson said calls for a class. Mark it with the @Observable macro from the Observation framework:
import Observation\nimport Foundation\n\n@Observable\nfinal class BudgetStore {\n var expenses: [Expense] = []\n var monthlyLimit: Decimal = 1500\n\n var totalSpent: Decimal {\n expenses.reduce(0) { $0 + $1.amount }\n }\n\n var remaining: Decimal {\n monthlyLimit - totalSpent\n }\n\n func add(_ expense: Expense) {\n expenses.append(expense)\n }\n}No property wrappers on the properties, no publishers. The macro rewrites each stored property so SwiftUI can record which ones a body reads. A view that shows store.remaining reads monthlyLimit and expenses through it, so it updates when either changes; a view that only shows the limit ignores new expenses.
Notice that totalSpent and remaining are computed, not stored. It’s tempting to keep a var total and update it in add, but then every future method that touches expenses (delete, edit, import) must remember to update it too, and one day one won’t. Store the minimum facts and derive everything else. Observation tracks computed properties through the stored ones they read, so the screen stays correct for free.
Create the store once, near the top of the app, and own it with @State:
@main\nstruct PocketBudgetApp: App {\n @State private var store = BudgetStore()\n\n var body: some Scene {\n WindowGroup {\n ExpensesScreen(store: store) // ExpensesScreen now has `let store: BudgetStore`\n .environment(store)\n }\n }\n}Child views can take the store as a plain let store: BudgetStore property and call store.add(…); no wrapper is needed to read or call methods. For screens deep in the hierarchy, .environment(store) makes it available without threading it through every initializer, and a view picks it up with @Environment(BudgetStore.self) private var store.
A TextField that edits the monthly limit needs a binding to store.monthlyLimit. @Bindable provides it:
struct SettingsScreen: View {\n @Environment(BudgetStore.self) private var store\n\n var body: some View {\n @Bindable var store = store\n Form {\n TextField(\"Monthly limit\", value: $store.monthlyLimit, format: .currency(code: \"USD\"))\n .keyboardType(.decimalPad)\n }\n }\n}When the store arrives as a property, write @Bindable var store: BudgetStore instead; the local form shown here is for objects that come from the environment.
To decide which wrapper to use, ask who owns the data. Does this view own a simple value? @State. Does it need to change a value someone else owns? @Binding. Is it shared app data? An @Observable class, owned once with @State and passed down. The next lesson puts the store to work in a real list with navigation and an add-expense form.
@State stores a value outside the view struct so it survives re-renders; mark it private, because the view owns it.","A $ prefix gives you a Binding: read and write access to someone else’s source of truth, which is what controls like Toggle and TextField need.","Mark a shared model class with @Observable, and SwiftUI re-renders exactly the views whose body read a property that changed.","Own an @Observable object with @State at the top, then pass it down directly or through .environment(_:).","Use @Bindable when you need bindings to the properties of an @Observable object, for example to edit them in a form."],"further":[{"title":"Managing model data in your app","url":"https://developer.apple.com/documentation/swiftui/managing-model-data-in-your-app"},{"title":"State","url":"https://developer.apple.com/documentation/swiftui/state"},{"title":"Observation","url":"https://developer.apple.com/documentation/observation"}],"quiz":[{"q":"A view declares var count = 0 and a button runs count += 1. What happens?
body can’t mutate a plain stored property, so the build fails."},{"text":"It fails to compile, because self is immutable inside body; the property needs @State.","why":"Correct. @State moves the storage out of the struct into SwiftUI, which makes it writable and observed."},{"text":"It works, because SwiftUI views are classes.","why":"Views are structs, and that’s exactly why plain properties can’t change from inside body."}],"answer":1},{"q":"A parent owns @State private var showLargeOnly = false. A child FilterBar must flip it. What does the child declare, and what does the parent pass?
@Binding var showLargeOnly: Bool. Parent passes $showLargeOnly.","why":"Correct. The binding gives the child read and write access while the parent stays the single source of truth."},{"text":"Child: @State var showLargeOnly: Bool. Parent passes showLargeOnly.","why":"@State would create a second, independent copy; the parent would never see the change."},{"text":"Child: var showLargeOnly: Bool. Parent passes $showLargeOnly.","why":"A plain property can’t receive a Binding, and even with a matching type it couldn’t write back."}],"answer":0},{"q":"Which views re-render when store.monthlyLimit changes on an @Observable store?
body actually read."},{"text":"Only views whose body read monthlyLimit, or a computed property that uses it.","why":"Correct. That fine-grained tracking is the main improvement over the older ObservableObject."}],"answer":2},{"q":"A settings screen gets the store with @Environment(BudgetStore.self) private var store and needs $store.monthlyLimit for a TextField. What do you add?
@State.","why":"@State would create a new store owned by this screen instead of using the shared one."},{"text":"@Bindable var store = store at the top of body.","why":"Correct. @Bindable creates bindings to an @Observable object’s properties, and it can be declared as a local in body."},{"text":"Mark monthlyLimit with @Published.","why":"@Published belongs to the older ObservableObject system and doesn’t create bindings by itself."}],"answer":1}],"exercise":{"kind":"spot-bug","language":"swift","code":"import SwiftUI\n\nstruct ExpenseCard: View {\n let expense: Expense\n var isExpanded = false\n\n var body: some View {\n VStack(alignment: .leading, spacing: 8) {\n Text(expense.title)\n .font(.headline)\n if isExpanded {\n Text(expense.date, format: .dateTime.weekday().day().month())\n Text(expense.category.title)\n }\n Button(isExpanded ? \"Less\" : \"More\") {\n isExpanded.toggle()\n }\n }\n }\n}","bugLines":[5],"title":"The card that won't expand","prompt":"This card should show the date and category when the user taps More. It doesn’t build: Xcode reports “cannot use mutating member on immutable value: ‘self’ is immutable” on the toggle() call. Select the line you need to change to fix it.
isExpanded declared?","View structs can’t change their own plain stored properties from inside body.","Which property wrapper tells SwiftUI to own and store a value for this view?"],"explanation":"Line 5 declares isExpanded as a plain stored property of a struct, so nothing inside body can change it, and SwiftUI wouldn’t know to redraw even if it could. Declare it as view-owned state:
@State private var isExpanded = falseNow SwiftUI stores the value outside the struct, toggle() compiles, and every tap re-renders the card. private signals that only this view owns the value; a parent that needs to control it would pass a @Binding instead.