Classes and reference semantics

One object, many names

class Account {
    var balance: Double = 0
}

let shared = Account()
let alias = shared
alias.balance = 100
print(shared.balance)   // 100 — same object

A class instance lives in one place, and variables hold references to it. Copying a variable copies the reference, not the object.

That is sometimes exactly right. A bank account, a database connection, a view controller, a download in progress — these are things where "the same one" is a meaningful idea and multiple parts of the program genuinely should see the same state.

=== asks "are these the same object?" — a question that only makes sense for reference types. == asks "are these equal?", which you define yourself.

Classes need initializers

Structs get a memberwise initializer for free. Classes do not — you write one, and it must assign every stored property that has no default. The missing synthesis is inheritance's fault: if Download gained a subclass, a synthesised memberwise init would have to either ignore the subclass's new properties (leaving them silently unset behind an init that looks complete) or rewrite its own signature every time the superclass changed a stored property. Two bad programs — so Swift refuses to pick one, and asks you to write the initialization story down.

class Account {
    let owner: String
    var balance: Double

    init(owner: String, balance: Double = 0) {
        self.owner = owner
        self.balance = balance
    }
}

self.owner = owner disambiguates the property from the parameter of the same name. This is idiomatic and worth getting comfortable with.

Inheritance

Only classes can inherit.

class Vehicle {
    var wheels: Int { 0 }
    func describe() -> String { "A vehicle with \(wheels) wheels" }
}

class Bicycle: Vehicle {
    override var wheels: Int { 2 }
}

class Car: Vehicle {
    override var wheels: Int { 4 }
    override func describe() -> String {
        super.describe() + ", which is a car"
    }
}

• override is required. Accidentally shadowing a superclass member is a compile error, not a subtle bug.
• super calls the superclass version.
• final prevents further overriding, and lets the compiler devirtualise the call.

Notice the last loop: every element is typed Vehicle, yet each one runs its own describe. That is dynamic dispatch — the method chosen at runtime by the object's actual type.

Deinitializers

A class can run cleanup when its last reference goes away:

class FileHandle {
    deinit {
        print("closing the file")
    }
}

Structs have no deinit, because there is no single moment when a value "goes away" — copies of it may still exist.

Which should you use?

Swift's own guidance, and the practical rule:

Use a struct by default. Switch to a class when one of these is true:

1. Identity matters. Two objects with identical contents are still meaningfully different things — two open network connections, two rows in a UI that must be tracked individually.
2. You need shared mutable state. Several parts of the app must see the same changes.
3. You need inheritance, or must subclass an Apple framework class (UIViewController, NSObject).
4. You need deinit to release a non-memory resource.
5. The type wraps something that is already a reference, such as a file handle or a Core Data object.

Everything else — models, configuration, coordinates, view state, network payloads — is a struct.