Lead with tradeoffs, not buzzwords
Interviewers reward clear comparisons—when to use actors vs queues, diffable data sources vs manual updates, async/await vs completion handlers—and why it matters in production.
Practice iOS interviews with questions worth your time
Work through realistic prompts on concurrency, UIKit, SwiftUI, and how systems fit together—written for engineers preparing for phone screens, loops, and senior-level conversations.
How to use this site
Pick a topic or browse the full catalog. Open a question for a deeper write-up with code where it helps. Use the exercise on each card to practice explaining your answer out loud or on paper—same rhythm as the interview room.
Questions across Swift, SwiftUI, UIKit, and architecture—the topics that show up in real iOS and iPadOS interviews.
Each card gives you a tight summary, talking points for how to answer, and a small exercise so you rehearse instead of skimming.
Filter by topic, difficulty, or tag when you want to drill one area before a loop or on-site.
What we emphasize
The habits that separate strong iOS candidates
Tie answers to real app behavior
Expect to connect APIs to scrolling, memory, threading, and state. The goal is to sound like someone who has shipped and debugged iOS apps, not someone who only read release notes.
Practice out loud
Use the short exercises on each card to rehearse how you would walk through a problem on a whiteboard or in a live-coding session.
Featured Questions
Questions to start with
What concurrency problems should you know in Swift?
Distinguish race conditions, data races, priority inversion, deadlock, and actor reentrancy anomalies with short Swift examples and practical fixes
Key points
- Separate race condition from data race: the first is an ordering bug, the second is unsynchronized shared mutable memory access.
- Cover the common liveness problems too: priority inversion and deadlock.
- Explain why actors help, but also why actor reentrancy means the order around `await` still matters.
On which thread does Swift call deinit?
Explain that deinit runs where the last strong reference is released, then connect that rule to UI safety, MainActor isolation, and isolated deinit
Key points
- State clearly that Swift does not promise a fixed thread for deinit; it runs where the last strong reference is released.
- Show that `@MainActor` does not automatically isolate a normal deinit, and that `isolated deinit` is the opt-in fix with timing tradeoffs.
What is the difference between let and var in Swift?
Explain that `let` creates an immutable binding while `var` creates a mutable one, then separate how that rule behaves for value types versus reference types
Key points
- Start with the shortest correct rule: `let` declares a constant and `var` declares a variable.
- Explain that for value types, a `let` binding makes the whole value immutable.
- Explain that for reference types, `let` freezes the reference, not necessarily the object's mutable properties.
Topics
Learn by area
Swift
Core Swift language rules and reasoning patterns that frequently appear in iOS interviews before the discussion narrows into UI or concurrency specifics
6 questions · Value vs reference semantics, immutability, ownership, optionals, and API design
Concurrency
Modern Swift concurrency, synchronization tradeoffs, and the reasoning interviewers expect around safety and performance
5 questions · Actors, structured concurrency, cancellation, data-race prevention
UIKit
Collection and table view architecture, rendering performance, and classic UIKit tradeoffs still common in production codebases
3 questions · Diffable data sources, cell identity, rendering pipelines, view-controller design
SwiftUI
State ownership, view identity, data flow, and interoperability decisions for modern Apple platform teams
3 questions · Property wrappers, dependency flow, lifecycle, compositional UI design