Swift struct vs class: differences and when to choose each

WHAT THIS TESTS: The interviewer wants to see if you understand value semantics versus reference semantics, not just memorize a feature list. At the senior level, they care that you know how memory layout, mutability, and thread safety interact. They want to hear you reason about identity, shared mutable state, automatic reference counting, and when copy-on-write optimizations matter.

A GOOD ANSWER COVERS: First, structs are value types and classes are reference types. This means assigning a struct copies the instance, while assigning a class copies the reference to the same heap memory. Second, memory allocation: structs are typically allocated on the stack or inline within other values, whereas classes are always allocated on the heap and incur reference counting overhead through ARC. Third, mutability rules with let: a let struct is completely immutable because the entire value is fixed, but a let class only prevents reassigning the reference; mutable properties on that class can still be changed unless they are explicitly marked otherwise. Fourth, inheritance and identity: classes support inheritance and have object identity, so === works, while structs do not support inheritance. Fifth, decision criteria: choose struct for small data models, value semantics, and thread safety because each context gets its own copy; choose class when you need identity, inheritance, a deinitializer, Objective-C interoperability, or shared mutable state across multiple owners.

COMMON WRONG ANSWERS: Claiming structs are always faster or always live on the stack. Swift may allocate structs on the heap when they are large, captured in closures, or part of a class. Another red flag is saying you always use classes for view models or everything in UIKit; senior candidates should explain that structs are preferred by default in Swift and classes are chosen deliberately. Also, confusing mutability by saying let makes a class immutable is a major mistake. Finally, ignoring that classes can create retain cycles while structs cannot because they are not reference counted.

LIKELY FOLLOW-UPS: How does copy-on-write work with collections like Array and String? What happens when a struct contains a class property? How would you implement copy-on-write for a custom struct wrapping a buffer? Can you give an example of a race condition with a class but not a struct? When would you use a struct with a class-backed property to get value semantics?

ONE CONCRETE EXAMPLE: Imagine a Canvas app where each stroke has a color and an array of points. If Stroke is a struct, undoing a stroke simply reverts the canvas array to the previous value without affecting other canvases. If Stroke were a class, copying the canvas array would share the same stroke references, so mutating a stroke for undo would corrupt the redo history or other canvas instances. Therefore, Stroke should be a struct, while the CanvasRenderer that manages a shared graphics context and coordinates with Core Graphics should be a class because it needs identity, shared mutable state, and a deinitializer to clean up resources.