iOS interviews test the Swift type system, how ARC manages memory, and whether you can reason about UI state — plus at least one question where a retain cycle is hiding in plain sight. Below are the questions asked most often, each with a model answer. Senior: architecture, trade-offs, mentoring, and decision-making.
By what the app's complexity actually is. Apple's MVC is fine for a screen that displays and edits one thing; MVVM earns its place when view state is complex enough to test separately; a unidirectional architecture pays off when state is shared across many screens and bugs are about state getting out of sync. Choosing the heaviest one first costs velocity for years.
Measure first — the build timing summary tells you which files dominate, and it is usually a handful with heavy type inference. Then: explicit types where inference is expensive, modularisation so a change recompiles one module, and fewer whole-module optimisations in debug. Blanket advice without measurement usually moves nothing.
Start from the crash report's frequency and grouping — which OS versions, which devices, which app version, and what the user was doing. Add breadcrumb logging around the suspected path and ship it, because the fastest way to reproduce something rare is to instrument the population that hits it. Guessing at a fix and shipping it teaches you nothing when the rate does not change.
Lightweight migration handles additive changes automatically; anything that transforms data needs a mapping model and a tested path from every version still in the wild. The constraint people forget is that users skip versions — someone updates from a release two years old, so the migration chain must work from each of them, not just the last.
By assuming old versions live indefinitely: the API must stay backward compatible, features that require a client change need a server-side flag, and anything removed has to be tolerated by clients that still call it. A kill switch is worth having before the release that needs it. Phased rollout limits the blast radius of the mistake you have not found yet.
Business logic and anything with a rule — pricing, validation, state machines — as unit tests, because they are fast and stable. A small number of UI tests over the critical paths that must never break, accepting they are slow and occasionally flaky. Testing that a button is blue is where suites go to become maintenance.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior iOS (Swift) interview →