Explain the primary differences between a struct and a class in Swift

WHAT THIS TESTS: This question tests your mental model of Swift's type system and whether you can reason about memory safety, performance tradeoffs, and API design. Interviewers want to see that you choose structs by default for simple data and model objects, but reach for classes when you need identity, inheritance, or interop with Objective-C.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, semantics: structs are value types so assignment copies the entire instance, while classes are reference types so assignment copies the pointer and mutations are visible to all references. Second, storage: structs are typically allocated on the stack when local and inline within containing values, whereas classes are always heap-allocated with reference counting overhead from ARC. Third, capabilities: classes support inheritance, deinitializers, and identity comparison with the triple equals operator, while structs do not support inheritance and use static dispatch for methods. Fourth, performance nuance: large structs can be expensive to copy blindly, so Swift uses copy-on-write for standard library collections and you can implement the same pattern manually to avoid linear duplication on every assignment.

COMMON WRONG ANSWERS: Red flags include claiming structs always live on the stack, because large value types or captured values can live on the heap. Another red flag is saying classes are always faster; in reality, heap allocation and ARC retain or release traffic can make classes slower for high-frequency operations. A third red flag is asserting that value types cannot cause memory leaks; while they avoid retain cycles, a struct containing a closure that captures self strongly from a class can still leak. Finally, do not say structs cannot use protocols; they use protocol-oriented programming extensively.

LIKELY FOLLOW-UPS: The interviewer may ask when you would choose a struct over a class, how copy-on-write works under the hood, or whether structs are thread-safe. They might also ask about the performance cost of passing a large struct across an API boundary, or how to implement manual copy-on-write for a custom collection.

ONE CONCRETE EXAMPLE: Imagine a Canvas app where you have a Shape struct with a CGPoint origin and CGSize bounds. Because Shape is a value type, every undo snapshot gets an independent copy without risk of accidental mutation. If Shape were a class, undo history would hold references to the same mutable instance and every change would retroactively alter prior states. However, if the struct stores a large backing pixel buffer, you would wrap that buffer in a class-backed reference type and implement copy-on-write so that copies remain cheap until mutation occurs.