iOS Developer Interview Questions

"I started with Swift in my final year because I wanted to build a study timer for my friends, and I got hooked on how fast you see your work on a real phone. That app went on the App Store and picked up a few hundred users, which taught me about review, crash reports and people using it in ways I didn't expect. After that I joined a small agency where I worked on two client apps, mostly in UIKit, with newer screens in SwiftUI. I built login, a feed with image caching, and push notification handling. What I want next is a product team where I own features for longer and get deeper into concurrency and performance, not just ship and hand over."

"The one I'm proudest of is a field inspection app I built at my last company. Inspectors used it on sites with bad signal, so it had to work fully offline. I owned the data layer and the sync. The hardest part was sync conflicts, when two inspectors edited the same report. We looked at last-write-wins, but that silently lost notes, so I stored changes per field with a timestamp and merged field by field, and only asked the user when the same field changed on both sides. I also moved the upload to a background URLSession so large photo batches finished even if the inspector locked the phone. Complaints about lost work pretty much stopped after that release."

"On my last team, a designer gave me a custom bottom sheet with its own swipe gestures and a hand-drawn dimmed background. When I built it, the swipe fought with the system back gesture, and it didn't work well with larger text sizes or VoiceOver. Instead of saying it couldn't be done, I built two quick versions, his custom one and one using the system sheet with detents styled to match his colours and corners. We tried both on a real phone together, including with large text turned on. He liked that the system one felt native and got accessibility for free, and we kept his visual style. After that he started asking me to look at interaction ideas early, before designs were final, which saved us both a lot of rework."

"I'd sort the problems first. The singleton being changed from background threads is a real data race, and those crash randomly and are painful to trace, so that's a must-fix before merging. I'd explain the exact scenario, suggest making that state an actor or confining it to the main actor, and mention that Thread Sanitizer would show it. The force unwraps I'd look at one by one. If a value can genuinely be nil, like data from the network, I'd suggest a guard let with a proper error path. If it's something like a URL built from a constant string, a force unwrap is fine and I'd say so. I keep comments about the code, not the person, and offer to pair if it's a bigger change. If it keeps coming up, I'd suggest a lint rule so reviews aren't personal."

"Every year after the new SDK is announced, I watch the sessions that touch what we actually build, and I read the release notes for the frameworks we use most. For Swift itself I skim the evolution proposals that are accepted, because that's where language changes are explained properly. Then I try the interesting parts in a small side project, not in the main app. For production, my filter is simple: does it solve a problem we really have, and can we use it given our minimum iOS version? If yes, I try it in one small, low-risk screen first and write a short note for the team on what worked. For example, we moved to async/await on new code first, and only later converted older code where it was touched anyway."

"When I send code for review, I try to keep the pull request small and say what changed and why, and for UI work I add screenshots or a short screen recording, including dark mode and a large text size. When I review, I focus on the things tools can't catch: is the logic right, is anything touching the UI off the main thread, could a closure create a retain cycle, does it work with VoiceOver, and will the next person understand it. Formatting and naming conventions I'd rather leave to a linter, so we don't argue about them. I explain the reason behind a comment and mark small things as optional. When my own code gets comments, I assume good intent, ask questions if I don't agree, and change it if they're right."

"An optional says a value might be missing. String? means either a string or nil, and the compiler won't let me use it as a plain string until I deal with the nil case. Under the hood it's an enum with two cases, some and none. To unwrap safely I use if let when I only need the value in one branch, and guard let at the top of a function when I want to exit early and keep the unwrapped value for the rest. For a fallback I use the nil-coalescing operator, and for a chain of properties I use optional chaining, which just returns nil if any link is missing. A force unwrap with an exclamation mark crashes on nil, so I avoid it unless nil would be a programmer error."

"Structs are value types, so when I assign one to another variable or pass it into a function, I get an independent copy. If I change the copy, the original doesn't change. Classes are reference types, so two variables can point at the same instance and a change through one shows up through the other. Classes also give me identity checks, inheritance and deinit, and they're managed by ARC. My default is a struct for models and view state because it's easier to reason about and safer across threads. The standard collections like Array and Dictionary use copy-on-write, so copying them is cheap until one side actually changes. I reach for a class when something needs to be shared and mutated in one place, like a cache or a view model several screens observe."

"A protocol is a contract, and any type can adopt it. With an extension I can give every conforming type a default implementation, so I get shared behaviour without a base class, and structs and enums can use it too. I use this a lot for things like a Loggable or a reusable-cell identifier. The surprise is dispatch. If the method is declared in the protocol itself, calls go through the conforming type's version even when the variable is typed as the protocol. But if the method only lives in the extension and isn't a requirement, Swift picks the version from the static type. So if my variable is typed as the protocol, it calls the extension version even though the concrete type has its own. The fix is to declare it in the protocol."

"By default a closure captures the variables it uses, not a snapshot, so if the variable changes later the closure sees the new value, and any class instance it touches is held strongly. A capture list lets me change that. Writing a variable in square brackets copies its value at the moment the closure is created, and writing weak self means the closure won't keep self alive. I need weak self when there's a cycle: self owns something that stores the closure, and the closure uses self. Stored completion handlers, timers and notification blocks are the usual cases. A non-escaping closure like the one passed to map can't outlive the call, so it can't cause a cycle. A one-off async call doesn't cause a cycle either, it just keeps self alive a bit longer."

"ARC keeps a count of strong references to every class instance. The compiler inserts the retains and releases, and when the count drops to zero the object is freed and deinit runs. It doesn't find cycles for you, so if a view controller holds a closure and that closure holds the view controller, neither ever goes away. I break a cycle by making one side not count. A weak reference is always optional and is set to nil automatically when the object is freed, so it's safe when the other object might go away first, which is why delegates are weak. Unowned doesn't make it optional, but if I touch it after the object is gone, the app crashes. I only use unowned when the other object is guaranteed to live at least as long, and weak whenever I'm unsure."

"At my last company, QA noticed memory climbing each time they opened and closed the chat screen, and sometimes old screens were still reacting to incoming messages. I added a log in the view controller's deinit and it never printed. Then I opened Xcode's memory graph debugger after closing the screen a few times and saw several copies of the controller still alive. The graph showed a shared socket manager holding a message handler closure, and that closure captured the controller strongly. So the singleton kept every chat screen alive. I changed the closure to capture self weakly and removed the handler when the screen closed. To prove it, deinit started printing, the memory graph showed one controller at a time, and I added a small test that checks a weak reference to the controller becomes nil after it's dismissed."

"At my last company our product feed stuttered badly on older phones, and it was the first screen people saw. I reproduced it on the oldest device we supported and ran Time Profiler while scrolling. Two things stood out on the main thread. We were decoding full-size product photos, several times larger than the cell, and each cell was creating a new date formatter. I moved image decoding and downsampling to a background task, so we only decoded an image at the size it's actually shown, cached the results, and made the formatter a shared static. I also used the prefetching API to start loading images a few rows ahead. Then I profiled again on the same phone, and the long main thread spikes were gone and scrolling felt smooth. I kept that old phone in our release checklist after that."

"The question I ask is who owns the data. If it's a small value that only this view cares about, like whether a sheet is showing, I use State, and SwiftUI keeps it alive even though the view struct is recreated all the time. If a child needs to read and change a parent's value, the child takes a Binding and the parent passes it with a dollar sign. For a reference type model, if this view creates it, it's StateObject, which is created once for the view's lifetime. If the object is created somewhere else and passed in, it's ObservedObject. The classic bug is creating a model inside a view with ObservedObject. Every time the parent redraws, the model can be recreated and the screen loses its data, like a half-filled form resetting."

"With ObservableObject, any change to any Published property fires objectWillChange, and every view observing that object redraws, even if it only shows one field. With the Observable macro, SwiftUI records which properties a view actually reads in its body and only redraws when one of those changes, so big shared models get much cheaper. I also drop all the Published wrappers. Ownership changes too. A view that creates the model holds it in State instead of StateObject, children just take it as a normal property, and if a child needs a binding to one of its fields, it marks the property Bindable. For app-wide models I use the environment with the type as the key. One thing to watch: the model's initializer can run again whenever the parent rebuilds the view, even though SwiftUI keeps the first instance, so the init should stay cheap."

"At my last company we had a large UIKit app and wanted new screens in SwiftUI without a rewrite. I proposed going screen by screen, starting with settings and profile, which were simple and rarely broke. Navigation stayed in UIKit, and each new SwiftUI screen was wrapped in a hosting controller, so the rest of the app didn't know the difference. For the networking layer we moved from callbacks to async/await in the same way. I added async versions next to the old methods using checked continuations, being careful to resume exactly once on every path, and moved callers over a few at a time. Each migrated screen went out behind a remote flag so we could switch back without a new release. We deliberately left the complex chat screen in UIKit, because moving it would have cost a lot and fixed nothing users felt."

"First the controller is created, then loadView creates its view, and viewDidLoad runs once after that. That's where I add subviews, set constraints and wire up bindings. The bounds aren't final yet, so I don't do frame math there. Every time the screen is about to show, viewWillAppear runs, which is where I refresh data that might have changed while it was hidden. viewDidAppear runs once it's on screen, so I start animations or log the screen view there. Layout callbacks like viewDidLayoutSubviews can run many times, for rotation or size changes, so anything in them has to be cheap and safe to repeat. When it leaves, viewWillDisappear and viewDidDisappear run, where I pause timers or stop observing. Finally deinit runs when nothing holds it anymore."

"UIKit isn't thread-safe, and the main thread runs the loop that handles touches and draws the screen. If I update views from another thread I get random glitches or crashes, and if I do slow work on the main thread the app freezes. So the pattern is to send heavy work like parsing a big file or resizing images to a global queue with a suitable quality of service, and when it's done, dispatch back to the main queue to update the UI. The main queue is serial, so UI updates happen in order. One classic mistake is calling sync on the main queue while already on the main thread, which deadlocks because it waits for itself. In debug builds Xcode's Main Thread Checker flags UI calls made off the main thread, which catches most of these early."

"With completion handlers, the flow jumps around, every path has to remember to call the handler exactly once, and errors are passed as optionals. With async/await the code reads top to bottom, errors are thrown and caught normally, and the compiler makes sure every path returns or throws. An await is a suspension point: the thread is freed for other work while we wait, and the function may resume on a different thread unless it's isolated to an actor like the main actor. To load a profile and its posts together, I use async let for both and then await both results, so they run in parallel. Cancellation is cooperative. If the parent task is cancelled, the children are too, and URLSession's async methods throw when cancelled, but my own long loops need to check for cancellation themselves."

"Actors protect mutable state from data races. Only one task runs on an actor's state at a time, and code outside the actor has to await to reach it, so the compiler catches unsafe access instead of me finding it in a crash log. The catch is reentrancy. When an actor method hits an await, it gives up the actor, and other calls can run in between. So anything I checked before the await might be different after it. A classic example is an image loader: two callers ask for the same URL, both see it's not cached, and both download it. The fix is to store the in-flight Task before awaiting, so the second caller awaits the same task. MainActor is a global actor tied to the main thread, and I mark view models and UI code with it so updates always land on main."

"I'd keep a reference to the current search task. Every time the text changes, I cancel that task and start a new one. The new task sleeps for a short delay first, and if the user types again during that time, it gets cancelled and never reaches the API. That's the debounce. The subtle part is stale results. A slow response for an old query could arrive after a newer one, so after the network call I check again whether this task was cancelled, and only then assign the results. Because the whole view model is on the main actor, the task it creates runs there too, so the results update on the main thread. The service protocol is Sendable so it's safe to call from the task. Passing it in also makes this easy to test with a fake."

"I'd make a struct that conforms to Decodable, with a property for each field I need. If the API sends snake case, like full underscore name, I either add a CodingKeys enum that maps each property to its JSON key, or set the decoder's key strategy to convert from snake case. Fields that might be missing become optionals, and the synthesized decoder then treats a missing key as nil instead of failing. For the request, I use URLSession's async data method, check the response is an HTTP status in the 200 range, and only then decode. If decoding fails, the DecodingError tells me which key or type was wrong, which I log in debug builds because it saves a lot of guessing. Dates need their own strategy, like ISO 8601, set on the decoder."

"Core Data has a model, which describes the entities, a persistent store, usually SQLite, and managed object contexts, which are like scratchpads where I fetch objects, change them and then save. NSPersistentContainer sets all of that up. The rule that matters most is that a context and its objects belong to one queue. The view context runs on the main queue for the UI. For a big import I create a background context, or use performBackgroundTask, and do all the work inside perform so it runs on that context's queue. I never hand a managed object to another thread. If I need it elsewhere, I pass its object ID and fetch it again in the other context. I turn on automatic merging on the view context so the UI picks up background saves, and set a merge policy for conflicts."

"I'd start by reproducing it with the Network Link Conditioner, and I'd bet the form only lives in memory, so a failed request or the app being suspended wipes it. First, I'd save the draft locally as the user types, with a short debounce, and again when the scene goes to the background. Second, submit would write the item to a small local outbox before sending. If the request fails, it stays there and I retry with backoff when the network path monitor says we're back online. Third, each item gets a unique ID that the backend uses to ignore duplicates, because a request can succeed on the server while the response is lost on the way back. In the UI I'd show a clear pending state and a failed state with retry, so people trust that their work is safe."

"An app can be not running, inactive, active, in the background or suspended. Inactive is when it's in the foreground but not getting events, like when Control Center is pulled down. Background means it can still run code for a short time, and suspended means it's in memory but not running at all. Since scenes came in, the scene delegate handles each window's foreground and background changes, and the app delegate handles process-level things like launch setup and push registration. In SwiftUI I read scenePhase from the environment. When the app goes to the background, I save drafts and state, pause timers and media, and if I need to finish a short task like an upload, I ask for extra background time. I never rely on the will-terminate callback, because the system can end a suspended app without calling anything."

"I'd start with our own analytics, because the answer depends on how many active users, and especially paying users, are on older versions. If most people are on the new version, I'd build the feature with the new API behind an availability check, and give older versions either a simpler fallback or no feature at all with nothing broken. If a big group is still on older versions, I'd look at whether the feature can be built with older APIs at an acceptable cost. I'd be honest with the product owner that two code paths means more testing and more bugs, so I'd put a date on dropping the old path, usually when we next raise our minimum iOS version. Whatever we pick, I'd test on a real device running the oldest version we support."

"The main thing is not letting the view model reach out to a singleton network client. I define a small protocol for what it needs, like fetch profile, and pass it in through the initializer. In the app I pass the real client, and in tests a stub that returns whatever I tell it to, a success or a specific error. Then I test the states a user would see: that it shows loading, that on success the title is set, that an empty list shows the empty message, and that an error shows a retry option instead of crashing. Tests can be async, so I just await the load call and assert. I keep UI tests for a few critical flows like sign-in and checkout, because they're slower and more fragile than unit tests."

"After one release at my last company, our crash reporting tool showed a new top crash: index out of range inside a table view data source. It only happened on the orders screen, mostly when people pulled to refresh while a background update was coming in. The stack trace was symbolicated, so I could see the exact line. The cause was that a network callback changed the orders array on a background thread while the table was reloading on the main thread, so the count and the rows didn't match. I moved all updates to the list onto the main actor and switched the screen to a diffable data source, which applies changes as one snapshot. I added a test that fires refreshes from several tasks at once, and I turned on Thread Sanitizer in one of our CI test runs so data races like this get caught earlier."

"First I'd read the rejection message closely and look at any screenshots, because a lot of rejections are the reviewer not being able to get in or not finding a feature. If that's the case, I reply in App Store Connect with a working demo account and clear notes on where to find things. If it's a real issue, like a permission prompt without a clear purpose string or a missing way to delete an account when we let people create one, I make the smallest fix that addresses it and resubmit. If the deadline really matters, I can request an expedited review, though that's never guaranteed. In parallel I tell the product owner straight away, with a realistic view of the risk, so marketing can plan. Going forward I'd submit earlier and set the release to manual so approval and launch day are separate."

"My first goal is to stop more people getting the bad build. If we used a phased release, I'd pause it straight away, which limits new automatic updates. If the crashing code is behind a remote flag, I'd switch it off, which can fix things for users who already updated, without waiting for review. Then I'd look at the crash reports grouped by stack trace, OS version and device, and compare with what changed in this release. Once I know the cause, I'd ship the smallest possible fix, not a bundle of other changes, and request an expedited review. I'd keep support and the product owner updated so they can answer users. Afterwards we'd do a blameless review and ask why this wasn't caught, and whether risky features should always ship behind a flag."