iOS technical interview: the rounds and what each scores

This guide is for iOS engineers with a loop booked who want to know what is coming: which rounds an iOS technical interview contains, what each round is scored on, the questions that come up in the screen with the answer an interviewer wants to hear, and how the debrief weighs one round against another. It ends with a one-week plan.

The short version: the loop is a set of separate rounds, each with its own interviewer and its own notes, and they are read side by side at the end. Knowing Swift well gets you through the screen. It does not carry the design round or the behavioural round for you.

The loop, as it is usually run

Expect four, five or six rounds in an iOS loop. Every company labels them differently; underneath, the formats repeat.

Level changes the balance. Below senior, most rounds are coding. Senior loops add weight to design and behavioural rounds, yet keep coding, since the panel wants evidence you still write production code. At staff, a coding round is sometimes replaced by a deep review of architecture you have built.

So start by learning which version you face. The recruiter will answer, but only if asked, and few candidates ask: the number of rounds, the tooling (Xcode or a browser editor), and whether AI assistants are allowed.

Do not skip the AI question: companies split both ways on it, and the answer changes the grading. If an assistant is allowed, writing code is no longer the skill on test. Steering it is: a precise prompt, reading every generated line before it runs, saying out loud where it got something wrong, and checking it against edge cases you raised. If you cannot explain a line it produced, that line counts against you. If it is banned, keep everything inside the shared editor, no second screen. And if autocomplete does half your typing at work, do a few practice sessions with it switched off before the screen, or you will stall on API names you know perfectly well.

The screen: questions that filter

The technical screen is the filter. These questions come up in iOS screens in some form. For each one: what is scored, the answer that scores, the trap where there is one, and the follow-up. The screen is short, so the answers are short too.

1. “When do you pick a struct over a class?”

What is scored: whether you know value semantics are shallow.

The answer that scores: default to structs for predictable copies; use a class for shared identity, inheritance, a deinit, or Objective-C interop.

The trap: “structs are thread-safe”. A struct holding a class instance still shares that object.

Follow-up: “What is copy-on-write?” Arrays, dictionaries and sets keep one shared storage until somebody writes, and only then copy.

2. “What is the difference between some and any?”

What is scored: whether you know existentials cost something.

The answer that scores: With some, the compiler knows the exact type and simply keeps it private from the caller. With any, the value sits in an existential box and the type is lost, so calls are dispatched at runtime and the optimiser has less to work with. Swift made any explicit so that cost is visible at the call site.

Follow-up: “When do you need any?” A heterogeneous collection, or real runtime polymorphism.

3. “weak or unowned?”

What is scored: lifetime reasoning, not habit.

The answer that scores: weak is optional and becomes nil when the object is freed. unowned is not optional, and touching it once the object is gone traps. Default to weak; use unowned only when the two lifetimes are guaranteed to match.

The trap: “I use unowned to avoid the optional.”

4. “How does task cancellation work?”

What is scored: knowing cancellation is cooperative.

The answer that scores: cancel() sets a flag and cancels child tasks. Your own loops must check Task.isCancelled or call try Task.checkCancellation(). Let CancellationError propagate instead of swallowing it in a generic catch.

Follow-up: “It kept running after cancel(). Why?”

5. “What makes SwiftUI run a view’s body again?”

What is scored: precision.

The answer that scores: a change to its own @State, to an observed property that body reads, or to an environment value it reads; a different value passed in by the parent; or a new identity.

The trap: “when the data changes”. The follow-up is “which data, exactly?”

6. “Some responses lack one field, and then the entire screen is empty. Why?”

What is scored: whether you have debugged Codable in production.

The answer that scores: arrays decode all or nothing, so one bad element or one unknown enum case throws away the whole payload. Make new fields optional, decode unknown enum values to an unknown case, and skip bad elements instead of failing the list.

Follow-up: “How would you find which key failed?” The DecodingError names the coding path. Log it.

7. “Walk me through the view controller lifecycle.”

What is scored: placement, not recitation.

The answer that scores: one-time setup in viewDidLoad, nothing that depends on geometry, since the bounds can still change; refresh on every visit in viewWillAppear; animations and screen analytics in viewDidAppear. viewIsAppearing is the place for work that needs real sizes.

Follow-up: most large apps are still UIKit or mixed. See UIKit interview questions.

8. “Tell me about the last bug that took you more than a day.”

What is scored: method. This is a technical question disguised as a behavioural one.

The answer that scores: the symptom, how you reproduced it, the hypothesis you tested first, the tool that confirmed it, the fix, and what you changed so it would not come back.

The trap: a story with no reproduction step.

The deeper versions of the concurrency and SwiftUI questions, the ones asked at senior level, are in senior iOS interview questions.

A screen question, followed through

This is how one of those questions plays out in the screen, and where it is won or lost.

Interviewer: “What makes SwiftUI run a view’s body again?”

Weak answer: “Whenever the data changes, it redraws.”

Interviewer: “Which data, exactly?”

Recovery: “Five things: its own @State changed, an observed property it reads changed, an environment value it reads changed, its parent passed a new value, or its identity changed. That is why body stays cheap, reads the minimum, and identity does not change between updates.”

The first answer was not wrong. It was unscorable. The interviewer had to ask a second question to find out whether you knew, and in a 45-minute screen every second question costs you one you did not get to. Answer the question behind the question the first time.

Coding: practical or algorithmic, and how to tell

There are two common formats, and they reward different preparation.

• A shared editor that compiles Swift but has no UIKit or SwiftUI. Questions skew towards the language, concurrency and data structures.
• Xcode, live, while you share your screen, frequently starting from a tiny project they hand you. Expect a small feature end to end: load data, decode it, show it, keep a copy.

Ask which one you are getting. On a shared pad the grade is tidy Swift that stands on its own. In Xcode it is how quickly you move through the simulator, the debugger and a throwaway screen. A phrase like “pairing session” or “programming and debugging in iOS” in the invitation does not tell you which, so ask with a forced choice: “Will I write new code from scratch, work in a starter project you provide, or review existing code?”

In both formats the same four things are scored: decomposition, correctness, communication, and testing instinct. Speed counts for less than candidates expect: a correct core with tests, finished late, beats a quick solution with a subtle bug nobody went looking for. The tasks that recur and how they are graded are in the iOS coding interview.

Architecture and system design

For an iOS role the design round is usually mobile system design, not backend design. The interviewer hands you a product (“design a photo feed with offline posting”) and waits for the device to show up in your answer: the local store as the source of truth, what happens when the process is killed mid-upload, what iOS lets you do in the background. Candidates who prepared with backend material draw load balancers and lose the round there. The iOS system design guide covers the platform details that decide it.

The architecture round is different. It is about decisions you can defend: why MVVM here and not TCA, who owns navigation, how the modules depend on each other, and what your choice costs. The question behind every one of them is “what would change your answer?” More in iOS architecture interview questions.

The behavioural round is technical too

At senior level the behavioural round carries as much weight as the coding rounds. It is also where levelling happens. “Walk me through a project you led” is a technical question: which decision you made, which alternative you rejected, what broke, and what you changed afterwards. Answers that describe the team’s work in the plural and your own role in one sentence read as mid-level, whatever the title on your CV.

Behavioural evaluation also rides inside every other round. “Why that architecture?” and “tell me about a disagreement” can arrive in the design round. Prepare two stories you can tell in depth, with names of the decisions and the trade-offs, rather than ten you can only summarise.

What the debrief compares

After the loop, each interviewer’s notes are read side by side. This is the part candidates never see, and it changes how you should prepare.

• Rounds are not averaged. Each one answers a different question about you. A strong coding round does not rescue a weak design round, because they are evidence for different things.
• Behavioural weight is real. A mediocre coding performance with a strong behavioural loop often still converts. The reverse rarely does.
• The notes need sentences. An interviewer cannot argue for you with “seemed smart”. They can argue with “named the out-of-order response race before writing the code” or “changed the design when I moved the constraint, and said why.” Every round, you are writing those sentences for them, or not.

When I write up an iOS candidate, the notes fall into four columns: signal (did the first answer contain something only a person who has shipped this would say), structure (could I follow the reasoning), depth (did it hold at the second and third question), and judgement (did the answer change when I changed the constraint). A correct answer that scores on none of them reads as mid-level.

How to prepare in one week

If you have less than a week, cut days 3 and 4 to the round you are least sure about. If you want one book for the whole loop, iOS interview books compares them by the time you have left.

What changed in 2024 to 2026

• Swift 6.2 shipped on 15 September 2025 with what the Swift team calls approachable concurrency (Swift.org, Swift 6.2 released).
• A module can opt in to main actor isolation by default, so its code runs on the main actor without @MainActor written on every type.
• The new @concurrent attribute marks a function that should run concurrently, which makes it visible in the code when work leaves the actor.

Sources

• Apple Developer, viewIsAppearing(_:)
• The Swift Programming Language, Concurrency
• The Swift Programming Language, Opaque and boxed protocol types
• Apple Developer, Encoding and decoding custom types
• Swift.org, Swift 6.2 released

What to do next

• Build a prep plan for your loop: four questions, and it recommends one guide or book and says why.
• If the coding round is the one you are least sure about, read the iOS coding interview next.