Senior iOS Interview Preparation: Questions, System Design and Portfolio

By now you know the topics. An interview asks something different: *can you explain it, choose between options and defend the choice?* This lesson gives you a way to prepare. We cannot know what any one company will ask, and we do not claim that these questions were asked anywhere in particular. They are common, current topics, and the best answers are your own words, with an example from your own project.

How interviews usually go

• A screen of your resume and portfolio. Be ready to explain every project in a minute.
• Language and framework questions, short answers, to check your base.
• Live coding or a take-home task. A small feature, often a list with a network call and a detail screen.
• Architecture or system design: how you would build a larger feature or app.
• Talking about work with others: disagreements, mistakes, reviews.

Swift questions, with the ideas behind the answers

• Struct or class? Value versus reference semantics, copying, identity, inheritance, and why SwiftUI uses structs. Give an example of a bug caused by shared reference.
• What is ARC? What is a retain cycle? Strong references and counts, weak versus unowned, [weak self], and how you find a leak (Memory Graph, Instruments).
• What is an optional? The type that can hold nothing, safe unwrapping, and why force unwrapping is risky.
• Protocols versus inheritance? Composition, protocol extensions, multiple conformance, testing with fakes.
• What does `escaping` mean for a closure? The closure may be called after the function returns, so it is stored, and may capture self.
• Generics and `some` versus `any`? One type known at compile time versus a box that holds any type.

Concurrency questions

• GCD and OperationQueue versus async/await? Callbacks and queues versus structured code that reads in order, with cancellation and error handling built in.
• What is an actor? Isolated state that handles one call at a time. Mention reentrancy.
• What does `@MainActor` do? Runs code on the main thread, so UI updates are safe.
• How do you cancel a search as the user types? Keep the task, cancel it on each change, add a short delay, check Task.isCancelled.
• What is a data race, and how does Swift help? Two threads using the same data with one writing. Sendable, actors and strict concurrency checks.

SwiftUI questions

• `@State`, `@Binding`, `@Observable`, `@Environment`: when each? Own local value, share a value with a child, an observable model object, a value or object from the environment.
• Why did my view update, or not update? Which state it reads, identity, and what a view body is allowed to do.
• `ObservableObject` versus `@Observable`? The older @Published approach versus the iOS 17 macro that tracks the properties a view reads.
• How do you navigate from code? NavigationStack with a NavigationPath and a router.
• How do you mix SwiftUI and UIKit? UIHostingController and UIViewRepresentable.

Architecture and platform questions

• MVC, MVVM, Clean Architecture, TCA: how do you choose? Team size, testing needs, the size of the app, and the cost of each. Say what you would do on a small app and on a large one.
• How do you handle auth tokens? Keychain, refresh through one shared task, never log them.
• How do you test a view model? Inject a fake service through a protocol, call the method, check the state.
• How do you make an app work offline? A local database as the source of truth, a sync step, clear states for *offline* and *stale*.
• How do you speed up a slow list or a slow launch? Measure with Instruments first, then fix the biggest cause.

A system design walkthrough: an offline-first expense app that syncs

Interviewers like a design question because there is no single right answer. They watch how you *think*. Here is a way to organise the answer, using our own app. Talk through it out loud, and ask questions before you start.

1. Clarify. Who uses it? Do they need it offline? How many records? Several devices per person? Any shared accounts?
2. Local first. The device database (SwiftData or Core Data) is the source of truth for the screen. The screen never waits for the network.
3. A sync layer. Changes made offline go into a queue of pending operations (create, update, delete), each with a client-generated id and a timestamp. When the network is back, a worker sends them in order, with retries and backoff, and marks each one done.
4. Conflicts. Two devices edit the same item. Say your rule: *last write wins* is simple, and field-level merging is safer. Tell them what you trade away.
5. Server API. Incremental pull with a *since* cursor, so the app asks only for changes. Pagination for large lists. Idempotent writes, so a retry cannot create duplicates.
6. Auth and security. Tokens in the Keychain, refresh handled once, HTTPS, no secrets in the app.
7. Push. A silent push tells the app that something changed, and the app pulls. Remember that delivery is not guaranteed.
8. Errors and states. Loading, empty, offline, failed with retry, syncing. Say what the user sees in each.
9. Testing and rollout. Unit tests for the sync rules with fake services, a feature flag, a phased release, crash reporting.

Live coding and take-home tips

• Read the brief twice. Ask what is in scope and what is not.
• Get a small working version first, and improve it. A running app beats a perfect plan.
• Keep the structure simple, with a view model and a protocol for the network, and show you can test it.
• Handle loading, empty and error states. Many people forget them.
• Write a short README: how to run it, what you chose, and what you would do next.

Your portfolio

• Three to four finished projects are better than ten half-done ones. Link the code, add screenshots and, if you can, a TestFlight or App Store link.
• In each README, explain one hard decision and why you made it. This is what interviewers talk about.
• Show tests, a clean structure and a continuous integration badge.
• Keep your resume honest and specific. List the frameworks you really used, and what you built with them.

Build your resume with our resume builder and check it with the ATS checker. Practise on the interview questions page, and read the roadmaps to plan what to add next. If you have not done it yet, the beginner iOS course and our Git and GitHub course cover the base that these questions assume.

No preparation can promise an offer, because hiring depends on many things you do not control. What you can control is being able to explain, with examples, what you built and why.

Your task

1. Pick ten questions from this lesson and answer each aloud in under a minute. Record yourself and listen back.
2. Write a one-page system design for an app of your choice, using the nine steps above.
3. Choose your best project and write the README with one hard decision and its trade-offs.
4. Ask a friend to ask you three questions you did not prepare, and practise saying *I am not sure, but here is how I would find out*.

How to check it worked

• You can explain value versus reference types, ARC and actors in your own words, with one example each.
• Your system design names at least two trade-offs.
• Your best project has a README that a stranger could follow.