All resources
checklist
Swift Concurrency Interview Checklist
A senior-level Swift concurrency audit for cancellation, task ownership, actor reentrancy, MainActor boundaries, Sendable and flaky async tests.
Use this in practice
Use this as a final-pass audit before a senior iOS interview. The goal is not to memorize keywords. The goal is to explain where concurrency bugs come from in app code.
Must be able to explain
- Structured concurrency: a parent task owns child tasks, so lifetime, cancellation and error propagation are easier to reason about than detached callback chains.
- Cancellation is cooperative: a task has to check cancellation or reach an async suspension point that throws. If expensive work ignores cancellation, the UI still pays.
- Task ownership: every Task should have a reason to exist, an owner and a cancellation story. A random Task in a view model is usually a leak waiting to happen.
- Actors protect isolated mutable state, but they do not make a multi-step workflow atomic across awaits.
- Actor reentrancy means other work can enter the actor while the first call is suspended. If state changes across an await, re-check assumptions after resuming.
- MainActor is for UI state and UI-bound models. It should not become a hiding place for parsing, networking, database writes or image decoding.
- Sendable is about what can safely cross concurrency domains. The real answer includes value semantics, immutable references and why unchecked Sendable is a promise I need to justify.
Questions to rehearse
- A search screen fires requests on every keystroke. How do you cancel stale requests, prevent older results from winning and keep loading state accurate?
- A SwiftUI view starts a task in .task. What happens when the view identity changes, and how would you avoid doing the same work twice?
- A cache is shared between image loading, prefetching and detail screens. Would you use an actor, a serial queue, locks or immutable snapshots, and why?
- An actor method reads state, awaits the network, then writes state. What can change while it is suspended, and what would you verify before writing?
- A team wrapped everything in @MainActor to silence warnings. What performance and design problems could that hide?
- A type is marked @unchecked Sendable. What proof would you ask for in code review?
- An async test passes locally but flakes in CI. How would you remove sleeps, inject clocks, observe state and make the assertion deterministic?
Red flags to avoid saying
- Actors solve thread safety. Better: actors serialize access to isolated state, but logic can still be wrong around awaits.
- Cancellation just stops the task. Better: cancellation is cooperative, so my code still needs to check it and clean up state.
- Task.detached is for background work. Better: detached tasks escape structured concurrency, so I use them rarely and only with explicit ownership.
- MainActor fixes the warning. Better: MainActor is a correctness boundary for UI, not a performance strategy.
- Sendable is just a compiler requirement. Better: Sendable is a design constraint that forces me to prove safe cross-domain sharing.
Go deeper
The iOS Interview Blueprint
Turn iOS interview pressure into structured engineering judgment, from junior fundamentals to architect and leadership rounds.
The Senior Signal
Prepare for senior Android interviews with current reasoning across Kotlin, Coroutines, Flow, Compose, architecture, performance, security and system design.
Use this resource inside a path.
The free tools are designed to plug into the larger Salari career system.
