Interview guide
iOS Developer Interview Questions & Answers Guide (2026)
A hiring-manager’s interview kit for ios developers — with specific “what to look for” notes on every answer, red flags to watch, and a practical test.
Interviewing a iOS Developer? This guide gives you 26 real interview questions — 14 technical (tagged easy, medium, and hard), 7 behavioral, and 5 role-fit — each with a specific “what to look for” scoring rubric, 8 red flags to reject on, and a hands-on practical test, so you hire on demonstrated evidence, not a confident-sounding résumé.
Key facts
- Role
- iOS Developer
- Technical questions
- 14
- Behavioral
- 7
- Role-fit
- 5
- Red flags
- 8
- Practical test
- Included
How to use this guide
Pick 4-6 technical questions across difficulties, 2-3 behavioral, and 1-2 role-fit for a 45-minute interview. For senior roles, weight harder technical and role-fit higher. Always close with the practical test so you are hiring on evidence, not impressions. The “what to look for” notes are a scoring rubric: strong answers touch most points, weak answers miss them or replace them with platitudes.
Technical questions — Easy
1. What is the difference between a struct and a class in Swift, and how do you decide which to use for a model type?
EasyWhat to look for: Value vs reference semantics, copy-on-write, when identity matters (reference) vs when data equality matters (value). Should default to structs for models and reach for classes when they need identity, inheritance, or reference sharing. Red flag: no idea copies happen.
2. Write (verbally or on paper) a Codable model for a JSON payload where the API keys are snake_case and one field is optional. How do you handle a malformed response?
EasyWhat to look for: CodingKeys mapping or a keyDecodingStrategy of .convertFromSnakeCase, optional property for the nullable field, and decoding inside do/catch surfacing a typed error rather than crashing. Bonus: custom init(from:) for a tricky field like a date or enum.
Technical questions — Medium
1. Explain a retain cycle in Swift and show how you would break one in a closure. When do you use weak versus unowned?
MediumWhat to look for: Two objects (or a closure and its captured self) holding strong references so neither deallocates. Capture list [weak self] or [unowned self]. weak when the reference can become nil, unowned when it logically cannot outlive self. Bonus: has found one with the memory graph debugger.
2. In SwiftUI, when do you use @State, @StateObject, @ObservedObject, and @EnvironmentObject?
MediumWhat to look for: @State for value-type view-local state, @StateObject for a reference object the view owns and creates once, @ObservedObject for one passed in from a parent, @EnvironmentObject for shared dependency injection down the tree. Common bug: using @ObservedObject where @StateObject is needed, causing the object to be recreated.
3. How does Swift Concurrency (async/await, Task, actors) improve on completion handlers and DispatchQueue, and what is an actor for?
MediumWhat to look for: Linear readable async code, structured concurrency and cancellation, no callback pyramids. Actors serialize access to mutable state to prevent data races. Should know @MainActor for UI updates and that await is a suspension point, not a thread hop guarantee.
4. Walk me through submitting an app to the App Store: signing, provisioning, TestFlight, and review. Where does it usually go wrong?
MediumWhat to look for: Certificates and provisioning profiles, bundle ID, App Store Connect record, archive and upload, TestFlight, then review. Common failures: expired or mismatched profiles, missing privacy manifest, App Tracking Transparency prompt, guideline 4.3 spam, incomplete metadata. Bonus: uses fastlane match.
5. When would you drop from SwiftUI to UIKit, and how do you bridge between the two frameworks?
MediumWhat to look for: Missing controls, fine-grained collection view behavior, camera or complex text input, or performance-critical screens. UIViewRepresentable / UIViewControllerRepresentable to host UIKit in SwiftUI, UIHostingController to host SwiftUI in UIKit. Should not treat SwiftUI as all-or-nothing.
6. How does ARC work, and how is it different from a tracing garbage collector? What does that mean for how you write code?
MediumWhat to look for: Deterministic reference counting at compile-inserted retain/release, freed when count hits zero, no background GC pauses. Cost: programmer must avoid strong reference cycles. Contrast with mark-and-sweep GC. Practical impact: capture lists and weak delegates.
7. What is the SwiftUI view lifecycle? Explain onAppear, task, and how body recomputation works.
MediumWhat to look for: body is a pure function recomputed when observed state changes; SwiftUI diffs the result. onAppear fires when the view enters the hierarchy; task runs async work tied to the view lifetime and cancels on disappear. Should know body can run many times and must be cheap and side-effect-free.
8. How do you keep view models testable and free of UIKit or SwiftUI dependencies?
MediumWhat to look for: Plain observable classes with injected dependencies (network, persistence) behind protocols, no import UIKit, no direct navigation. Tests exercise state transitions with mock dependencies. Should discuss why coupling a view model to the view layer makes it untestable.
Technical questions — Hard
1. A SwiftUI list scrolls smoothly with 50 items but stutters at 5,000. Walk me through diagnosing and fixing it.
HardWhat to look for: Instruments Time Profiler and the SwiftUI template, identify expensive body recomputation, use LazyVStack/List for lazy loading, move image decoding off the main thread, cache, stable identity via Identifiable, avoid heavy work in body. Should mention measuring before guessing.
2. You have a Core Data app that occasionally crashes on a background thread. What are the likely causes and how do you fix them?
HardWhat to look for: NSManagedObject and contexts are not thread-safe; objects must not cross contexts. Use perform/performAndWait, a background context for writes, object IDs to pass across contexts, and a sensible merge policy. Red flag: fetching on the main context and mutating on another thread.
3. Design the networking layer for an app that hits a REST API with auth tokens, retries, and offline caching. What do you reach for?
HardWhat to look for: URLSession with async/await, Codable models, a token refresh flow, typed error handling, retry with backoff, and a cache (URLCache or Core Data/SwiftData) for offline. Should discuss testability via protocol-based injection rather than a hard dependency on URLSession.
4. Tell me about a production bug you fixed that only reproduced on a real device or a specific iOS version. How did you track it down?
HardWhat to look for: Real story. Device-only issues: memory pressure, camera, background task expiry, Keychain, a deprecated API changing behavior across iOS versions. Should describe reproducing on-device, reading crash logs symbolicated, and using Instruments or os_log rather than guessing.
Behavioral questions
1. Tell me about a time you disagreed with a designer about an iOS interaction pattern. How did you resolve it?
What to look for: Brought platform conventions (Human Interface Guidelines), accessibility, or performance to the discussion, proposed alternatives, respected the designer craft, landed a decision without ego.
2. Describe the worst App Store rejection or production incident you shipped and what you learned.
What to look for: Takes ownership, names the root cause specifically, describes the guardrails added after (a pre-submission checklist, crash monitoring, staged rollout). Avoids blaming Apple review.
3. How do you keep your code review comments useful without coming across as pedantic?
What to look for: Separates blockers from nits, praises good choices, explains the why (memory, concurrency, lifecycle), asks questions rather than issuing decrees.
4. Walk me through how you onboard yourself into an unfamiliar iOS codebase.
What to look for: Runs it on device, traces a user flow end to end, maps the module and navigation structure, checks the concurrency and state patterns, opens small PRs early to validate understanding.
5. What is the most technically ambitious iOS thing you have shipped, and why was it hard?
What to look for: Specific: names the dimensions of difficulty (scale, offline sync, real-time, a hard Apple API, a migration). Shows depth and taste.
6. How do you manage your day when you have 7 hours async with the team and only 1 hour of overlap?
What to look for: Batches questions, writes long-form PR descriptions, records screen walkthroughs, protects the overlap hour for blocking questions. Demonstrates async discipline.
7. When have you pushed back on a deadline, and how did you frame the conversation?
What to look for: Offers a trade-off (scope, quality, deadline) rather than a flat no. Communicates early, not at the deadline. Flags App Store review lag as a real scheduling constraint.
Role-fit questions
1. Why native iOS specifically, rather than a cross-platform stack like React Native or Flutter?
What to look for: Has an opinion grounded in performance, platform APIs, or a genuine preference — not just "that is what I know". Can name where cross-platform is the right call too, which shows judgment rather than dogma.
2. What does the first 30 days look like in this role for you to feel productive?
What to look for: Get the build green on device, ship a small PR in week 1, own a screen by week 2, ask to pair. Red flag: expects weeks of onboarding with no output.
3. How do you feel about 4 hours of timezone overlap with a US team?
What to look for: Treats the overlap as sacred for syncs, protects the async hours for deep work, has done it before if possible.
4. Our app is SwiftUI-first with a UIKit legacy layer, Core Data, and Swift Concurrency. Anything there you have not used, and how would you ramp up?
What to look for: Honest gap assessment plus a concrete ramp plan (docs, a side screen, pair sessions). Fakery is a red flag; nobody has done everything.
5. Which side of pragmatism-versus-purism are you on when trade-offs come up near a release?
What to look for: Names the trade-off, picks pragmatism with a follow-up ticket for the debt, versus purism when it matters (memory safety, accessibility, a crash risk).
Red flags
Any one of these alone is usually reason to pass, especially combined with weak answers elsewhere.
- • Cannot explain a retain cycle or when to use weak versus unowned.
- • Uses @ObservedObject where @StateObject is needed and does not know why the object keeps resetting.
- • Has never shipped an app to the App Store and cannot describe signing or review.
- • Mutates Core Data managed objects across threads without perform or a background context.
- • Blocks the main thread with network or decoding work and does not notice the dropped frames.
- • Treats SwiftUI as all-or-nothing and cannot bridge to UIKit when needed.
- • Reaches for force-unwraps everywhere and shrugs when asked about crash risk.
- • Blames Apple, the SDK, or the reviewer before suspecting their own code.
Practical test
4-hour take-home: build a small SwiftUI app that fetches a paginated list from a mock REST API, persists it locally with Core Data or SwiftData for offline viewing, and shows a detail screen. Requirements: async/await networking with Codable, loading and error and empty states, pull-to-refresh, VoiceOver labels on the list rows, and at least 3 XCTest tests for the view model. We grade on: code quality and architecture (40%), memory and concurrency correctness (20%), accessibility and states (20%), and tests (20%). Bonus points for a clean dependency-injection seam and for handling a malformed API response without crashing.
Scoring rubric
Score each answer 1-4: (1) Misses most of the rubric or gives platitudes; (2) Hits some points but cannot go deep when pressed; (3) Covers the rubric and can defend the answer under follow-ups; (4) Adds unprompted nuance, trade-offs, or real examples beyond the rubric. Hire at an average of 3.0+ across technical, behavioral, and role-fit, with zero red flags, and a pass on the practical test.
Skip the interview grind — hire a pre-vetted iOS Developer
We run this exact vetting process for you. Tell us the role and we’ll send 3 pre-vetted ios developers within 5 business days — from $3000/mo, with a 30-day replacement guarantee.
Related
Written by Syed Ali
Founder, Remoteria
Syed Ali founded Remoteria after a decade building distributed teams across 4 continents. He helps US businesses source, vet, onboard, and scale pre-vetted offshore talent in engineering, design, marketing, and operations.
- • 10+ years building distributed remote teams
- • Direct hiring experience across US, UK, EU, and APAC markets
- • Specialist in offshore vetting and cross-timezone team integration
Last updated: April 12, 2026