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 24-Hour iOS Interview Answer Book
Review the highest-frequency senior iOS interview questions and rehearse answers, follow-ups and recovery lines you can say out loud.
Use this resource inside a path.
The free tools are designed to plug into the larger Salari career system.
