You open an expense, change its amount from 4.50 to 5.00 in an edit screen, then tap Cancel. Should the list still say 4.50? With a struct it does, automatically. With a class, the list already shows 5.00, because the edit screen and the list were looking at the same object. That one difference, value versus reference semantics, decides more about how an iOS app behaves than any other modelling choice.
\nHere is the expense type, now with var properties so it can be edited:
import Foundation\n\nstruct Expense {\n var title: String\n var amount: Decimal\n}\n\nvar original = Expense(title: \"Coffee\", amount: 4.5)\nvar draft = original\ndraft.amount = 5\n\nprint(original.amount) // 4.5\nprint(draft.amount) // 5var draft = original makes a complete, independent copy. Editing the draft can’t affect the original, so the edit screen can work on a draft and the Cancel button costs nothing: you throw the draft away. Swift gives every struct a free memberwise initializer, which is why Expense(title:amount:) works without you writing init.
Strings, arrays, dictionaries, Decimal and Int are all structs. That’s why var copy = amounts in the collections lesson gave you an independent array. Swift makes those copies cheap by sharing storage until one side actually changes it.
final class Account {\n var balance: Decimal\n\n init(balance: Decimal) {\n self.balance = balance\n }\n}\n\nlet checking = Account(balance: 500)\nlet sameAccount = checking\nsameAccount.balance -= 50\n\nprint(checking.balance) // 450\nprint(checking === sameAccount) // true: same instanceA class instance lives in one place; variables hold references to it. let sameAccount = checking copies the reference, so both names point at the same account. === asks “is this the very same instance?”, a question that makes no sense for structs. Classes need an explicit init for stored properties without defaults. Mark them final unless you plan to subclass, which is rare in modern Swift.
let freezes whatever the name holds. For a struct, the name holds the whole value, so nothing inside can change. For a class, the name holds a reference, so the reference is fixed but the object’s var properties are still changeable, which is exactly why sameAccount.balance -= 50 compiled even though sameAccount is a let.
Struct methods that change properties must say so with mutating:
struct Budget {\n var limit: Decimal\n var spent: Decimal = 0\n\n var remaining: Decimal { limit - spent } // computed property\n\n mutating func record(_ amount: Decimal) {\n spent += amount\n }\n}\n\nvar food = Budget(limit: 300)\nfood.record(42)\nprint(food.remaining) // 258Apple’s guidance, and mine, is to start with a struct. Values are easier to reason about because nothing can change them behind your back, and they’re safe to pass between threads, which matters a great deal in Swift 6. Use a class when you need identity: one shared thing that several parts of the app see and update. In Pocket Budget, each Expense is a struct, and the store that owns the list and that several screens observe will be a class. The Observation framework’s @Observable and SwiftData’s @Model, which you’ll use later, both require classes for exactly this reason.
A quick test when you’re unsure: imagine handing a copy to another screen. If that screen should get its own version to edit freely, you want a struct. If it should see every change the rest of the app makes, and changes it makes should show up everywhere, you want a class. Most data in most apps passes the first test.
\nClasses are freed by automatic reference counting (ARC): each strong reference adds one to a count, and when the count reaches zero the object is freed and its deinit runs. Trouble starts when an object stores a closure that captures the object itself:
final class BudgetAlert {\n let threshold: Decimal\n var onTrigger: (() -> Void)?\n\n init(threshold: Decimal) {\n self.threshold = threshold\n }\n\n func arm() {\n onTrigger = { [weak self] in\n guard let self else { return }\n print(\"Spent more than \\(self.threshold)\")\n }\n }\n\n deinit { print(\"BudgetAlert freed\") }\n}Without [weak self], the alert owns the closure and the closure owns the alert. Neither count ever reaches zero, deinit never runs, and you’ve leaked memory. The capture list [weak self] makes the closure’s reference weak and optional, so guard let self unwraps it while it’s still alive. A struct on its own can’t form these cycles, which is one more reason structs are the default.
Value or reference is half of modelling. The other half is describing data that comes in different shapes, like an expense paid by card versus cash. That’s what enums with associated values are for, and they’re next.
\n","toc":[{"id":"sec-1","text":"Structs copy","level":2},{"id":"sec-2","text":"Classes share","level":2},{"id":"sec-3","text":"let means different things","level":2},{"id":"sec-4","text":"Which one to choose","level":2},{"id":"sec-5","text":"ARC and retain cycles","level":2}],"takeaways":["Assigning a struct makes an independent copy; assigning a class instance makes a second reference to the same object.","Alet struct is frozen all the way down, while a let class reference can still have its var properties changed.","Struct methods that change properties must be marked mutating, and they can only be called on a var.","Default to structs for your data; reach for a class when you need shared identity, such as one object many screens observe.","A class that stores a closure which captures self strongly creates a retain cycle; capture [weak self] to break it."],"further":[{"title":"Choosing Between Structures and Classes","url":"https://developer.apple.com/documentation/swift/choosing-between-structures-and-classes"},{"title":"Structures and Classes","url":"https://docs.swift.org/swift-book/documentation/the-swift-programming-language/classesandstructures/"},{"title":"Automatic Reference Counting","url":"https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/"}],"quiz":[{"q":"Budget is a struct with a mutating func record(_:). Why does let food = Budget(limit: 300); food.record(42) fail to compile?
mutating and called on a var."},{"text":"food is a let, so the whole value is immutable and mutating methods are off-limits.","why":"Correct. Change it to var food and the call compiles."},{"text":"The method needs to be marked static.","why":"static methods belong to the type, not to one budget. That would change the design, not fix the error."}],"answer":1},{"q":"Account is a class. let a = Account(balance: 500); let b = a; b.balance -= 50. What is a.balance?
a and b refer to the same object, so a change through one is visible through the other."},{"text":"500","why":"That’s struct behaviour. Class assignment copies the reference, not the object."},{"text":"It doesn’t compile because b is a let.","why":"let freezes the reference b, not the object’s var properties."}],"answer":0},{"q":"Which data in Pocket Budget is the best fit for a class rather than a struct?
","options":[{"text":"A single expense with a title, amount and date.","why":"An expense is plain data with no identity beyond its values; a struct keeps copies independent and safe."},{"text":"A pair of start and end dates for a report.","why":"Small immutable data is the textbook struct."},{"text":"The one shared store that several screens read and update.","why":"Correct. Several screens need to see the same instance, which is exactly what reference semantics gives you."},{"text":"A currency code such as “EUR”.","why":"A code is a value; a struct or even a plainString fits better."}],"answer":2},{"q":"A class stores onTrigger = { print(self.threshold) } in its own property. What’s the consequence?
self, so changes to the object are invisible.","why":"Classes are never copied by capture. The closure holds a strong reference to the same object."},{"text":"Swift refuses to compile any closure that mentions self.","why":"Swift only makes you write self. explicitly in escaping closures; it doesn’t forbid capturing it."},{"text":"Nothing special; ARC frees both when the screen closes.","why":"ARC can’t free objects that keep each other alive. That’s the whole problem."},{"text":"Object and closure keep each other alive, so the object is never freed.","why":"Correct. Capture [weak self] so the closure doesn’t own the object."}],"answer":3}],"exercise":{"kind":"choice","options":["a","b","c","d"],"correct":["b"],"title":"Struct or class: predict the output","prompt":"Limit is a struct and Wallet is a class. Read the snippet and predict the single line it prints.
import Foundation\n\nstruct Limit {\n var amount: Decimal\n}\n\nfinal class Wallet {\n var balance: Decimal\n init(balance: Decimal) { self.balance = balance }\n}\n\nvar food = Limit(amount: 300)\nvar fun = food\nfun.amount = 100\n\nlet mine = Wallet(balance: 500)\nlet shared = mine\nshared.balance -= 50\n\nprint(food.amount, fun.amount, mine.balance)var fun = food, how many Limit values exist?","After let shared = mine, how many Wallet objects exist?"],"explanation":"var fun = food copies the struct, so changing fun.amount to 100 leaves food.amount at 300. let shared = mine copies only the reference: there is still one Wallet, and subtracting 50 through shared is visible through mine. The output is 300 100 450.
Notice that shared is a let and the subtraction still compiled. let fixes which object shared points to, not the object’s var properties.
100 100 450","why":"This treats the struct like a class. var fun = food made a separate copy, so food keeps 300."},"b":{"text":"300 100 450","why":"Correct. The struct copy is independent, and the two class references share one wallet."},"c":{"text":"300 100 500","why":"This treats the class like a struct. shared and mine are the same object, so the 50 is gone from both."},"d":{"text":"It doesn’t compile: shared is a let.","why":"let freezes the reference, not the object’s var properties, so shared.balance -= 50 is legal."}}},"words":691,"readMinutes":3}