iOS Swift interview questions — the follow-ups that expose whether you've shipped, not just studied

Swift interviews lean on a familiar set of topics — memory management, optionals, protocol-oriented design — and most candidates arrive with a definition ready for each one. The interviews that actually separate people go one question further: not "what is it," but "what happens when you get it wrong, and how did you find out."

ARC and retain cycles

What gets recited: Automatic Reference Counting frees an object when its reference count hits zero; a retain cycle happens when two objects hold strong references to each other.

The follow-up: "You have a closure inside a view controller that captures self. Walk me through when that becomes a memory leak, and how you'd fix it."

The definition-only answer stops at "use weak self." The real answer explains why: a closure stored as a property captures self strongly by default, and if the view controller also owns that closure, neither can ever be deallocated because each is keeping the other alive. [weak self] breaks one side of the cycle. Candidates who've actually chased a memory leak in Instruments can usually describe what that looks like on a graph; candidates who've only read about ARC tend to stop at the syntax.

Optionals

What gets recited: an optional represents a value that might be nil; force-unwrapping with ! crashes if it's nil.

The follow-up: "Your app crashes in production with a force-unwrap crash that never showed up in testing. What's your first move?"

This tests debugging instinct, not optional syntax. The honest answer involves the crash log's stack trace, reproducing the nil case (often a network response missing a field the API contract promised), and the deeper fix — not removing the !, but asking why the code trusted a value it shouldn't have assumed was always present.

Protocol-oriented programming

What gets recited: Swift favors protocols and protocol extensions over class inheritance for sharing behavior.

The follow-up: "Give me a case where you chose a protocol extension over subclassing, and what you'd have lost by picking the other one."

Apple's own guidance repeats "protocol-oriented" often enough that most candidates can recite the philosophy. Fewer can point to an actual decision they made — value types don't need inheritance's shared-state baggage, multiple protocol conformance sidesteps single inheritance's limits — with a real trade-off attached rather than a slogan.

Main thread and concurrency

What gets recited: UI updates must happen on the main thread; DispatchQueue.main.async or @MainActor handles that.

The follow-up: "You update a table view from a background thread and it works fine in the simulator but crashes intermittently on a physical device. Why?"

The real answer is about timing, not syntax — UIKit isn't thread-safe, and updating from a background thread sometimes appears to work because the render happens to land correctly, until a race condition catches it at the wrong moment. Simulators and real devices schedule threads differently, which is exactly why this class of bug is notorious for "not reproducing" until it ships.

App lifecycle

What gets recited: the stages — not running, inactive, active, background, suspended — and which delegate methods fire at each transition.

The follow-up: "A user gets a phone call mid-form-entry in your app. What happens to their unsaved data, and whose job is it to prevent losing it?"

This turns a lifecycle diagram into a real product decision. The honest answer names applicationDidEnterBackground or a scenePhase change as the place to persist state, and explains why waiting for applicationWillTerminate is not a safe assumption — iOS can kill a backgrounded app without ever calling it.

Why the follow-up is where the interview actually happens

Every topic above shows up in the first page of any iOS interview guide, and interviewers know that. The follow-up exists specifically because a definition tells them what you've read, and the follow-up tells them what you've actually run into.

---

Prepair asks Swift and iOS questions scoped to your level, and the follow-ups work the same way this post does — a real scenario to reason through, not a term to define. Try a free interview — 3 a month, no signup required to start.