Home / Swift interview questions

Swift language

Swift interview questions

Swift language questions test whether you understand the mechanics behind the syntax you use every day. This overview links the deep-dive pages for each core topic.

The core language topics

Expect value versus reference semantics (structs vs classes and copy-on-write), optionals and safe unwrapping, protocols and protocol-oriented design, generics and associated types, closures and capture semantics, error handling with throws and Result, and memory management with ARC, weak, unowned, and retain cycles. Questions ask you to reason and refactor, not just define.

Answering at a senior level

Connect each feature to its consequence. Do not just say structs are value types; explain that value semantics remove a class of shared mutable state bugs and how copy-on-write keeps that cheap. Knowing when the default guidance does not apply, and saying so, is what separates a senior answer from a memorized one.

When would you choose a struct over a class?

The spoken answer: "I default to structs. Value semantics mean every copy is independent, so no other part of the program can mutate my data behind my back. I reach for a class when I need identity, shared mutable state, or interop with Objective C frameworks that require reference types." That takes about twenty seconds and covers the mechanics and the judgment.

The trap is the follow-up: "So structs are always cheaper to pass around?" The obvious answer says yes, copies are stack allocated and fast. It fails because a struct holding a class reference still triggers retain and release traffic on every copy, and a large struct without copy-on-write can be more expensive to pass than a class reference. The recovery line: "Cheaper by default, but a struct wrapping references pays ARC costs on copy, and I would measure before claiming a win." The senior differentiator is naming copy-on-write: standard library types like Array and String share storage until mutation, which is why value semantics stay affordable. I have watched candidates recite "structs good, classes bad" and then freeze when asked what an Array of class instances copies. It copies the references, not the objects. Saying that unprompted is a strong signal.

How do closures capture variables?

The spoken answer: "Closures capture variables by reference by default, so the closure and the enclosing scope see the same storage. A capture list copies the value at creation time instead, and for reference types it lets me weaken the capture to break cycles." Keep it to two breaths.

The trap: the interviewer shows a loop that appends closures printing a counter, then asks what they print. Candidates who say "each closure remembers its own value" walk into it, because all the closures share one captured variable and print the final value. The recovery line: "They share the same storage, so all print the last value; a capture list of [i] would snapshot each iteration." The senior differentiator is connecting this to memory management: a closure stored on self that captures self strongly is a retain cycle, and the fix is [weak self] with an explicit guard, not a reflexive weak everywhere. Interviewers score the reasoning about when a strong capture is fine, for example a short lived Task that should keep self alive until it finishes.

What is the difference between weak and unowned?

The spoken answer: "Both avoid a strong reference. Weak is optional and becomes nil when the object deallocates, so I use it when the other object can legitimately go away first. Unowned assumes the object outlives the reference, and the program traps if that assumption fails. I default to weak unless the lifetime guarantee is structural, like a child that never outlives its parent."

The trap: "Why not use weak everywhere and be safe?" The obvious answer has no cost model. Weak references carry bookkeeping overhead and force optional handling at every use site, which hides real lifetime bugs behind silent nil checks. The recovery line: "Weak everywhere trades a crash for silent no-ops, and a silent no-op is harder to debug." The senior differentiator is stating that unowned documents a lifetime invariant: if it traps, the model was wrong, and I want to know.

The 3 answers that get scored, not just heard

Across the Swift language round, three answers separate hire from no hire in my notes:

• Explaining a behavior by its mechanism. "Structs copy" is a fact. "Copy-on-write defers the copy until mutation, so passing is cheap and the first mutation pays" is a mechanism.
• Refactoring under pushback. When the interviewer says "now make this type thread safe", the score comes from how you reason about shared mutable state, not from which keyword you type first.
• Naming the exception to your own rule. Every default in Swift has a case where it is wrong. Candidates who volunteer that case, unprompted, read as people who shipped code, not people who read a list.

Correct definitions are the entry fee. The real Swift round starts after your first answer, when the interviewer pushes on it.