iOS interviews rarely start with an algorithm. They start with someone asking you to explain something you use every day — and finding out whether you actually understand it or just know which keyword makes the compiler stop complaining.

Below are 20 questions grouped the way real iOS loops are structured, with a note on the experience level each group usually targets. For every group you'll also see what a strong spoken answer sounds like — because in most of these rounds you're talking, not typing.

WhalePrep observation: the most common way strong iOS candidates lose points isn't a wrong answer. It's a correct answer delivered as a definition, with no example of where it actually bit them in a real app.

20
Questions across the 5 rounds iOS loops reuse
5
Topic areas that cover most iOS screens
1
Concrete example is what separates a memorized answer

Swift language fundamentals

Usually the opening round, and the one most weighted for Junior and Middle candidates.

  1. What's the difference between a struct and a class, and how do you decide which one to use?
  2. What problem do optionals solve, and when would you use guard let instead of if let?
  3. What is protocol-oriented programming, and when is a protocol extension a better choice than a base class?
  4. What does @escaping mean on a closure parameter, and why does the compiler force you to mark it?

Saying it out loud: for question 1, don't stop at "struct is a value type, class is a reference type" — that's the definition, not the answer. Add the decision: "I reach for a struct by default, because value semantics mean nobody else can mutate my copy out from under me. I switch to a class when I need identity — like a view model that several views observe, or something that has to live in a reference cycle-aware graph." The second half is what tells the interviewer you've actually made this choice before.

Memory management and ARC

The classic Middle-level filter. Almost every iOS loop has at least one of these.

  1. How does ARC decide when to deallocate an object?
  2. What is a retain cycle? Walk me through one you've actually run into.
  3. What's the difference between weak and unowned, and how do you choose?
  4. Why does a closure need a capture list, and what happens if you forget one?

Saying it out loud: question 6 is a trap for memorized answers, because it explicitly asks for your example. The strongest version is a short war story: "I had a view controller holding a network client, and the completion closure captured self strongly, so the controller never deallocated after dismiss. I caught it because the deinit log never fired. Fixed it with a weak self capture list." Notice the structure — what leaked, how you noticed, how you fixed it. That's three sentences, and it beats a textbook definition every time.

Why this works: interviewers can't tell whether you memorized ARC rules last night. They can tell whether you've debugged a leak, because the details of how you noticed it are impossible to fake.

UIKit and SwiftUI

Expect both, even at shops that are "fully SwiftUI" — most real codebases are still mixed.

  1. Walk me through the UIViewController lifecycle. Which method would you use to start a network request, and why?
  2. Why do table and collection view cells get reused, and what bug does that cause if you forget?
  3. In SwiftUI, what's the difference between @State, @StateObject, and @ObservedObject?
  4. What causes a SwiftUI view to re-render, and how would you debug one that re-renders too often?

Saying it out loud: for question 11, name the ownership rule rather than listing the three: "The question is always who owns the object. @State is for value-type state the view itself owns. @StateObject is for a reference-type object the view creates and owns — so it survives re-renders. @ObservedObject is for one that's passed in from outside, where somebody else owns the lifetime." Framing it as one rule with three cases sounds like understanding; listing three definitions sounds like flashcards.

Concurrency

Middle to Senior. This is where interviews increasingly focus, because it's where production bugs come from.

  1. What's the difference between GCD and Swift's async/await, and why did Apple introduce structured concurrency?
  2. Why must UI updates happen on the main thread, and what does @MainActor actually guarantee?
  3. What is a data race, and how does an actor prevent one?
  4. How does task cancellation work, and what does your code have to do to cooperate with it?

Saying it out loud: question 13 invites a history lecture — resist it. Lead with the problem being solved: "GCD works, but it pushes correctness onto you: you're manually hopping queues and there's nothing stopping you from forgetting one. Structured concurrency makes the lifetime of async work part of the language, so a child task can't outlive its parent and the compiler can actually check your threading." One sentence on the old way, one on what the new way buys you.

Architecture and system design

Senior rounds, and increasingly Middle too. Often the round that decides your level.

  1. How would you architect a screen that loads from the network, caches, and works offline?
  2. MVC, MVVM, VIPER — which do you use, and what actually goes wrong with "massive view controllers"?
  3. How do you make a class testable when it depends on the network or on the current date?
  4. How would you decide between Core Data, SwiftData, and just writing files yourself?

Saying it out loud: the architecture round rewards asking before answering. For question 17, open with scoping rather than a solution: "Before I design this — is offline read-only, or do users edit while offline and we sync later? That changes everything, because the second one means conflict resolution." Interviewers routinely leave that ambiguous on purpose. Candidates who notice score higher than candidates with a more elegant answer to the wrong question.

Practical target: for each of the five groups above, prepare one real story from your own work — a leak you fixed, a race you debugged, a screen you architected. Twenty questions become five stories, and stories survive interview nerves far better than definitions do.

The part that isn't about iOS at all

You can know every answer above and still have the interview go badly, because the technical screen is measuring two things at once: whether you know it, and whether you can make another engineer follow you while you explain it under time pressure.

That second skill degrades fast when you're nervous — answers get longer, structure disappears, and filler words spike. It's worth practicing separately from the material itself: we wrote a full breakdown of how in How to reduce filler words and sound more confident in English interviews.

The practical version: pick three questions from this page and answer them out loud, start to finish, before your next interview. Not in your head — out loud. The gap between those two is exactly what the interview measures.