iOS Developer interview questions and how to answer them
iOS interviews are about the bugs you've already met. The interviewer wants to hear about the retain cycle that kept a screen alive forever, the view that redrew itself into a stutter, the build that App Review bounced on a Friday. Here's what each round checks, the questions that keep coming up, and what a good answer sounds like.
What happens in each round
- 1
Recruiter screen
What happens
Whether you've shipped a native app in Swift to the App Store, whether you work in SwiftUI, UIKit or both, and whether your pay range and location fit. Have the name of your last release and what you personally built in it ready to go.
- 2
Technical phone screen
What happens
Core Swift and platform knowledge: value versus reference types, optionals, memory management with ARC, and the basics of async/await. Expect a shared editor and a small Swift problem where clear, idiomatic code beats a clever trick.
- 3
Take-home or live build
What happens
Can you build a small app that fetches from an API, shows a list, handles loading and error states, and doesn't fall over when the network drops. They read your project structure, your naming and whether you wrote any tests at all.
- 4
Mobile system design
What happens
How you'd structure a real feature such as an offline-first feed or a chat screen: the layers, caching, pagination, background refresh and what happens when the app is killed. Senior roles lean hard on this round.
- 5
Team and hiring manager chat
What happens
How you work with designers and backend engineers, how you handle a crash spike after release, and whether you push back on a design that fights Apple's Human Interface Guidelines. They're checking you'll be easy to ship with.
Questions you're likely to get
1.What's the difference between a struct and a class in Swift, and how do you decide which to use?
Why they ask
It's the fastest way to tell whether you understand Swift or just write Objective-C habits in new syntax. SwiftUI is built on value types, so the answer shows how you think about state.
How to answer
- Structs are value types that get copied; classes are reference types that share one instance
- Default to structs for models and view state because copies can't be changed behind your back
- Reach for a class when you need identity, shared mutable state, inheritance or Objective-C interop
- Mention copy-on-write for arrays and dictionaries so large value types stay cheap
2.Walk me through how you'd find and fix a retain cycle.
Why they ask
Memory leaks are one of the most common real bugs in iOS apps, and they rarely show up in a demo. They want to know you've actually chased one down.
How to answer
- Explain ARC and how two objects holding strong references to each other never get freed
- Name the usual culprits: closures capturing self, delegates declared strong, timers and notification observers
- Use weak or unowned captures and weak delegate properties, and say when unowned is risky
- Find leaks with the Memory Graph Debugger in Xcode or the Leaks instrument, and confirm deinit fires
3.In SwiftUI, when would you use @State, @Binding, @StateObject, @ObservedObject or @Observable?
Why they ask
State ownership is where most SwiftUI bugs come from: views that reset, data that doesn't update, or screens that redraw far too often.
How to answer
- @State for simple values a single view owns, @Binding to hand write access to a child
- The view that creates a reference-type model owns it with @StateObject, or @State with the Observation framework
- @ObservedObject only for a model someone else created and passed in
- Explain the classic bug: creating a model with @ObservedObject inside the view, so it's rebuilt on every redraw
4.How does async/await change the way you write networking code, and where does the main actor come in?
Why they ask
Swift concurrency has replaced most completion-handler code on active teams, and threading mistakes cause crashes and purple runtime warnings.
How to answer
- Async functions read top to bottom, errors flow through throws, and no more nested completion handlers
- UI updates must happen on the main actor, so mark view models or specific methods with @MainActor
- Use a Task to start async work from synchronous code and cancel it when the view disappears
- Mention actors for protecting shared mutable state and Sendable checks catching data races at compile time
5.A list screen scrolls badly on older iPhones. How do you figure out why?
Why they ask
Performance problems separate people who guess from people who measure. It's also a real complaint every app team gets.
How to answer
- Reproduce it on a real older device, not the simulator, in a Release build
- Profile with Instruments: Time Profiler for main-thread work, the SwiftUI template or Hangs for redraws
- Look for image decoding on the main thread, heavy work in cell configuration or body, and views redrawing too often
- Fix the biggest cost first, then measure again so you know it helped
6.How would you design an offline-first feed that syncs when the network comes back?
Why they ask
This is the classic mobile system design prompt. It tests layering, persistence and how you handle conflicts and failure.
How to answer
- The UI reads from a local store such as SwiftData, Core Data or SQLite, never straight from the network
- A sync layer fetches pages, writes them to disk and the UI updates from the store
- Queue writes made offline and retry them, with a clear rule for conflicts
- Talk about background refresh limits, pagination cursors and what the user sees while data is stale
7.Tell me about a time App Review rejected a build. What did you do?
Why they ask
Every iOS developer who's shipped has a rejection story. It shows whether you know the guidelines and how you act under release pressure.
How to answer
- Name the actual reason, such as a missing account deletion flow, an unclear permission string or an in-app purchase rule
- Explain how you read the guideline, replied in App Store Connect or fixed the build
- Say what you changed so it wouldn't happen again, like a pre-submission checklist
- Keep it calm and specific; blaming Apple doesn't land well
8.What happens between tapping an app icon and seeing the first screen, and how would you make that faster?
Why they ask
Launch time is something users feel and product managers track. It also tests how well you know the app lifecycle.
How to answer
- Cover process launch, dynamic library loading, the app and scene delegates or the SwiftUI App struct, then the first frame
- Move work out of launch: defer analytics setup, lazy-load services, avoid synchronous disk and network calls
- Measure with the App Launch instrument and the launch metrics in Xcode Organizer
- Mention cutting down dynamic frameworks if the app links a lot of them
9.How do you test an iOS app, and which tests do you think are worth writing?
Why they ask
Plenty of iOS codebases have almost no tests. They want someone with a sensible, honest view rather than a coverage slogan.
How to answer
- Unit tests on view models and business logic using XCTest or Swift Testing, with protocols so you can swap in fakes
- A small set of XCUITest flows on the paths that make money, like sign-in and checkout
- Snapshot tests for design-heavy screens if the team already uses them
- Run it all in CI on every pull request so flaky tests get fixed, not ignored
10.How do you handle secrets, tokens and user data on the device?
Why they ask
Security mistakes on mobile are easy to make and expensive to clean up. Anyone touching sign-in needs to get this right.
How to answer
- Store tokens in the Keychain, never in UserDefaults or plain files
- Remember the app binary can be pulled apart, so real secrets belong on the server
- Use App Transport Security, and consider certificate pinning for sensitive apps
- Mention data protection classes and clearing sensitive data on sign-out
11.Tell me about a disagreement with a designer or backend engineer.
Why they ask
iOS developers sit between design and the API all day. They want to know you can argue for the platform without being difficult.
How to answer
- Pick a real case, such as a custom gesture that fought the system back swipe or an API shape that broke pagination
- Show you understood what they were trying to achieve
- Explain the tradeoff you proposed, ideally with a quick prototype on a device
- Say how it ended and what you'd do the same next time
Mistakes that sink good candidates
Talking only about tutorials and sample apps when they ask about something you shipped
Dismissing UIKit as dead when most large apps still depend on it
Guessing at a performance problem instead of saying how you'd measure it
Speaking badly about Apple's review team or a past employer's codebase
Need more iOS Developer interviews to prep for?
HeroApply applies to iOS Developer jobs that match you, every day. 250 jobs are open today.