Originally published on salari.dev, where the full series on senior mobile interviews lives.

Your interview is in nine days. You have a concurrency article open, a system design course, three Reddit threads, a list of behavioral questions, a half-watched YouTube video and twenty coding problems marked “must redo.” If you are on iOS, add Swift, SwiftUI, persistence and whatever WWDC session suddenly looks urgent. If you are on Android, add Kotlin, coroutines, Flow, Compose, lifecycle and another argument about whether the company will ask architecture or algorithms.

Everything looks useful. That is the problem.

You do not have an information shortage. You have more material than the remaining calendar can support, and every evening spent deciding what to study is one less evening actually preparing.

Prioritisation is uncomfortable because it admits you cannot cover everything. The calendar already admitted that for you.

“What could they ask?” is a terrible question

They could ask almost anything. That question creates infinite preparation.

What if they go deep on concurrency? What if system design dominates the loop? What if there is LeetCode? What if they ask persistence, performance, platform internals or the framework you have not touched in two years?

You can keep adding material forever. The useful question is narrower:

What can still materially change the outcome before the interview?

If the interview is three months away, build depth. If it is three weeks away, prioritise. If it is next Tuesday, triage. If it is tomorrow, stop pretending you are going to rebuild your engineering career overnight.

The closer the interview gets, the smaller the preparation surface should become.

Your last interviews are better data than another generic checklist

If you have interviewed recently, use the evidence.

Where did the process end? Did you fail before the technical rounds started? Did you pass coding and fall apart in system design? Did the interviewer keep drilling into concurrency because your first answer never became precise? Did your behavioral answers get weak the moment the question moved from what happened to what you personally decided? Did you survive the loop and still get downlevelled?

Those patterns matter more than another “Top 100 interview questions” page.

You can spend weeks making your strongest round even stronger because it is the part you enjoy practising. A candidate who likes algorithms keeps solving algorithms. An architect keeps reading system design. Someone comfortable with platform trivia keeps collecting more trivia.

It feels productive because you are getting better at something.

It may not change the outcome at all.

Preparation should react to the failure you actually have, not the one you prefer working on.

Stop studying subjects. Start repairing failures.

“I need to learn Swift concurrency” is too big.

“I cannot explain cancellation, isolation and ordering once the interviewer changes the happy path” is useful.

“I need Android architecture” is too big.

“I get confused about state ownership across Compose, ViewModel, process death and persistence” is useful.

“I need system design” is too big.

“I can draw the happy-path architecture, but I fall apart when offline state, retries and conflict resolution enter the conversation” is useful.

The first version gives you a syllabus. The second gives you something you can attack tonight.

Good preparation gets narrower as you learn more about the weakness. That is how you stop opening new tabs and start closing them.

With days left, the 24-Hour iOS Interview Answer Book is the highest-frequency questions as spoken answer cards.

A real preparation plan has casualties

Engineers hate deleting topics because removing something feels irresponsible. You cut one subject and immediately imagine the interviewer asking exactly that question, so you put it back. Soon the plan contains everything, which means it contains no priorities at all.

Maybe system design is weak, the role is Senior, and you know there is a dedicated design round. That deserves time. Maybe you have passed coding comfortably in your last five loops but still spend every evening on coding puzzles because the progress is easy to measure. That probably does not.

Maybe your interview is in four days and you discover a platform area that would take two weeks to understand properly. You may have to accept that risk and spend those four days repairing something you can actually move.

That is not laziness. It is what engineers do everywhere else when resources are limited and a deadline is real.

The goal is not to finish the syllabus. The goal is to change the hiring decision.

The night before is not for heroics

This is where otherwise sensible engineers start behaving strangely.

The interview is tomorrow, so at 11:30 PM one Reddit comment sends them into a topic they have never studied before. Two hours later they are tired, anxious and still do not understand it.

There is a point where another hour of study produces less value than sleep. There is a point where reviewing five strong answers is better than discovering twenty new weak ones. There is also a point where the correct preparation decision is closing the laptop.

A deadline should force those decisions earlier, not at 2 AM.

When the interview is close, your job is not to become a different engineer. It is to make the engineer you already are easier to retrieve under pressure.

This is why the 24-Hour books exist

I built The 24-Hour iOS Interview Answer Book and The 24-Hour Android Interview Answer Book for a different problem from a full interview curriculum.

The 24-Hour books are for the point where time itself has become part of the problem. You need current questions, useful answer depth, follow-ups and a way to concentrate on what can still change the room you are about to enter.

Each book includes its own Study Room online. Every card is there, and the book’s answer stays hidden until you have written yours, so you find out which answers you can actually give before the interviewer does.

They will not make you an expert overnight. Nothing will.

What they can do is stop you wasting the remaining hours pretending every weakness deserves equal time. For iOS, that means getting quickly to the questions and follow-ups that matter in the modern iOS loop. For Android, it means doing the same across the current Android interview surface.

You do not need another forty tabs. You need a decision about what deserves the next hour, and the discipline to let the rest wait.

Your interview date should delete things from your study plan.

Where to go from here

I write these books from the same side of the table. Each has a free sample, and the price adjusts to your country at checkout.

• iOS interview this week: The 24-Hour iOS Interview Answer Book, the highest-frequency questions as spoken answer cards.
• Android interview this week: The 24-Hour Android Interview Answer Book, the highest-frequency Android questions as answer cards.

Mike Salari is a Staff Mobile Engineer & Tech Lead with 15 years in mobile and 500+ technical interviews from the hiring side. He writes interview tools from the hiring side at salari.dev.

A senior iOS interview can go badly even when every answer is technically correct.

I’ve seen candidates explain ARC, actors, SwiftUI and dependency injection confidently, then struggle when the discussion moves from definitions to decisions.

The difference often becomes obvious in the follow-up.

Knowing that actors protect isolated mutable state is useful. Knowing which parts of your application should own that state, how cancellation affects the workflow and what you would do when the design starts failing under load is a different level of understanding.

Here are ten questions I would use to prepare for that kind of conversation.

1. When would you choose an actor over @MainActor?

A basic answer explains actor isolation.

A stronger answer starts with ownership. Is the data UI-bound? Does it represent an independently mutable service? What work needs to happen without blocking UI responsiveness?

An actor serialises access to its isolated state, but it does not automatically make an entire business workflow atomic across suspension points.

The follow-up I would prepare for:

What can change while your actor-isolated method is suspended at an await?

2. How would you stop an old network response from changing a new screen?

Cancellation is part of the answer.

It isn’t the whole answer.

The engineer needs to consider task ownership, whether the underlying operation cooperates with cancellation, and whether the result still belongs to the current screen or session when it returns.

Ask yourself:

If a user signs out and another user signs in before the response arrives, what prevents the first user’s data from appearing?

That is a much better test of production reasoning than merely knowing how to call cancel().

3. Why is this SwiftUI view updating so often?

Don’t begin by suggesting EquatableView or extracting a subview.

First establish what is happening.

Is the body being evaluated frequently? Is layout expensive? Is the rendering pipeline missing frames? Is an observed dependency changing? Is the expensive work somewhere else entirely?

Apple’s SwiftUI Instruments can help distinguish these causes.

The follow-up:

How would you demonstrate that your optimisation improved user-visible performance?

4. What happens to your application’s data when the process is terminated?

An engineer should distinguish a view update, navigation, scene lifecycle and process termination.

In-memory state has different guarantees from persisted state. A restored interface does not prove that the underlying business data survived.

The interesting question is:

Which state must survive termination, and which state would be dangerous to restore?

A search query can often be rebuilt. An unsent payment operation needs much more careful treatment.

5. How would you design offline writes in a mobile app?

“Caching” is not enough.

A reliable answer needs an explicit write model, durable local intent, retry behaviour and conflict policy.

If two devices update the same record while disconnected, what happens when both reconnect?

There is no universal answer. The interviewer is looking for a policy that fits the product and can be explained and tested.

6. How would you migrate a large UIKit screen to SwiftUI?

I’d be interested in the boundary, not a promise to rewrite everything.

Which components can move safely? What happens to existing navigation? Where does state live? How do you compare performance and accessibility before and after?

The follow-up:

What evidence would make you stop the migration?

Being able to stop a technically fashionable project is part of senior engineering judgement.

7. How would you investigate a memory leak after dismissing a screen?

ARC is the starting point.

I would expect the candidate to investigate ownership: closures, subscriptions, coordinators, UIKit bridges and long-lived services.

Then I would ask:

If you remove the retained objects and the screen is still slow, what do you measure next?

Fixing an ownership bug does not necessarily fix an independent performance problem.

8. How do you decide where to place module boundaries?

A module boundary is a cost as well as an organisational tool.

It can isolate ownership and improve build behaviour. It can also create unnecessary interfaces, dependency friction and coordination overhead.

A convincing answer explains which changes should be independent and why.

The follow-up:

What would make you merge two modules you previously separated?

9. How would you roll out a risky persistence migration?

I’d want to hear about compatibility between app versions, data integrity checks, backups where appropriate, observability and recovery.

Mobile apps are unusual because older binaries can remain in the wild long after a new release.

The question isn’t simply whether the migration runs successfully on your machine.

What happens when an older client encounters data written by a newer one?

10. What makes an engineering decision a senior-level decision?

Scope, uncertainty, consequences and accountability.

A senior engineer should be able to describe the constraints, compare credible alternatives, identify failure modes and choose evidence for evaluating the result.

That can happen in a single difficult feature. It doesn’t require claiming ownership of an entire platform.

A good interview answer usually starts plainly.

Then it becomes stronger as the constraints become harder.

How I would prepare

Pick any three of these questions and answer them aloud.

Give yourself two minutes for the first answer.

Then change a constraint: your app must work offline, your team has four engineers rather than forty, the rollout cannot interrupt existing users, or a dependency cannot be replaced.

If your answer still consists mainly of framework names, you have found something worth practising.

My iOS Interview Blueprint goes further into how answers differ across career levels, from technical foundations to senior engineering judgement, architecture and leadership.

https://mikesalari.gumroad.com/l/ios-interview-blueprint

The goal isn’t to memorise what an interviewer wants to hear.

It’s to become better at explaining decisions you can genuinely defend.

Originally published on salari.dev, where the full series on senior mobile interviews lives.

A React Native interview rarely ends with the JavaScript answer. The first answer only gives the interviewer somewhere to push.

They ask what crosses the native boundary, which thread is blocked, what survives a process restart, what happens during an over-the-air update and how you would know whether the problem belongs to React, the native module, the renderer or the product design.

That is where a question bank becomes useful. Not as a list to memorise, but as a map of boundaries you must be able to defend. This page gives you the boundaries, ten questions senior loops actually ask, and the follow-up each one leads to.

Name which system owns the failure

A weak answer says React Native is slow. A useful answer identifies the work, the thread, the data crossing the boundary and the measurement that would separate JavaScript cost from native rendering cost.

Separate three layers out loud. The JavaScript engine, Hermes by default, executes your code. React’s reconciler decides what changed. The native layer turns that into real platform views and platform calls. A slow screen lives in one of them first.

The same rule applies to navigation, storage, networking and background work. Start by naming the owner of the state and the lifecycle that may invalidate it. Then explain what evidence would move the investigation somewhere else.

Know what the New Architecture changed and what it did not

Current React Native runs on the New Architecture. Since 0.82 it is the only runtime you can select, and the old asynchronous bridge is gone. Interviewers expect you to name the parts, not say “it is faster”.

• JSI is a C++ interface that lets JavaScript hold references to native objects and call them directly, including synchronously, without serialising every message into a queue.
• Fabric is the renderer. Its core is shared C++ across platforms, and it can measure layout synchronously when a screen needs it.
• TurboModules are native modules defined by a typed spec. Codegen produces the glue, and modules load lazily instead of all at startup.
• Hermes ships precompiled bytecode, which removes parse and compile work from startup. It does not fix a slow network call or a heavy first render.

The senior part is the cost model that remains. JSI changes the transport. It does not remove CPU, memory or thread limits. Large buffers can still be copied, a synchronous native call can still block JavaScript, and a chatty interface ported to a TurboModule keeps its original performance problem.

Do not hide platform knowledge behind the framework

Cross-platform engineering does not remove iOS and Android behavior. It concentrates the risk at the places where the abstraction stops matching them.

A senior answer can descend one layer when the constraint requires it. That does not mean implementing every module in Swift or Kotlin. It means recognising when permissions, background execution, memory pressure, accessibility or release behavior cannot be reasoned about from JavaScript alone.

Design the native boundary as a contract

When a question turns to native modules, the interviewer wants a designed interface, not a pass-through of a vendor SDK. Keep the contract small and typed. Use a promise for a one-shot result, events for a stream with explicit cleanup, and one coarse call for what is logically one operation.

// NativeImageTools.ts: a TurboModule spec. Codegen reads this file.
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';
 
export interface Spec extends TurboModule {
  // One coarse, async call: disk and decode work never block JS.
  resizeBatch(uris: string[], maxEdge: number): Promise<string[]>;
}
 
export default TurboModuleRegistry.getEnforcing<Spec>('NativeImageTools');

Say why it looks like this. The work touches disk, so it is asynchronous. The batch crosses the boundary once instead of once per image. The spec is the contract that catches a mismatch at build time instead of in production.

Top 300 React Native Interview Questions goes through these boundaries question by question, from junior to staff.

Release strategy is part of the architecture

A JavaScript update can change application behavior faster than a store release. That power creates compatibility questions. Which native versions can run the bundle? What happens to persisted state? How is a bad update stopped? Which change still requires the stores?

An answer that names only delivery speed misses the operating cost. The senior signal is the rollback and compatibility model: a bundle targets a specific native runtime version, persisted data carries a schema version, and a bad update has a kill path that does not depend on the broken code.

React Native interview questions senior loops ask

These are the questions that separate a mid-level answer from a senior one. For each, the point is what the interviewer is testing and where they push next.

• What does the React Native runtime actually do? Testing: whether you separate the JS engine, the reconciler and the native integration. Follow-up: which of the three you would profile first for a slow screen, and why.
• What is JSI, and what did the New Architecture replace? Testing: whether you can name JSI, Fabric and TurboModules and what each owns. Follow-up: what costs remain now that the bridge is gone.
• When would you make a native method synchronous? Testing: thread judgment. Synchronous is only for trivial, predictable work. Follow-up: what happens to the JS thread if that call touches disk.
• How do you optimise a FlatList that drops frames? Testing: whether you treat row cost as the cause and props as tuning. Follow-up: when getItemLayout is correct, and what it breaks on variable-height rows.
• Your screen is janky. How do you find which thread is responsible? Testing: measurement before fixes. Follow-up: why memoisation will not fix UI-thread jank from native layout or a JS-driven animation.
• Where should a gesture-driven animation run? Testing: whether you keep it on the UI thread, typically with Reanimated and Gesture Handler, so it stays smooth while JS is busy. Follow-up: what still has to come back to JS, and how often.
• How would you wrap a third-party native SDK? Testing: contract design. Follow-up: how you keep an SDK upgrade from leaking into every screen.
• How do you decide whether a library is ready for the current architecture? Testing: dependency risk. A successful compile is the start. Follow-up: what you exercise on real devices before you trust it.
• What can an over-the-air update change, and what can it not? Testing: the native compatibility boundary. Follow-up: how a user on an old binary with new persisted state is protected.
• Why does Hermes improve startup, and what does it not fix? Testing: whether you know it removes parse and compile cost only. Follow-up: how you would measure where the rest of cold start goes.

A list re-render bug interviewers like to show

A common live exercise is a list that re-renders every row on each keystroke. The row is wrapped in React.memo, and it still re-renders.

// Before: a new function and a new style object every render.
// React.memo sees changed props, so every row renders again.
<FlatList
  data={items}
  keyExtractor={(item, index) => String(index)}
  renderItem={({ item }) => (
    <Row item={item} style={{ padding: 12 }} onPress={() => open(item.id)} />
  )}
/>
 
// After: stable identities and a real key.
const rowStyle = { padding: 12 };
const onPressRow = useCallback((id: string) => open(id), [open]);
const renderItem = useCallback(
  ({ item }: { item: Item }) => (
    <Row item={item} style={rowStyle} onPress={onPressRow} />
  ),
  [onPressRow],
);
 
<FlatList data={items} keyExtractor={(item) => item.id} renderItem={renderItem} />

The index key is the second bug. When items are inserted or removed, rows keep the wrong identity. Name both, then say what you would measure to confirm the fix. If each row is still expensive to render, stable props only hide the real cost.

Recovery lines when you are unsure

Every senior loop reaches a question you cannot fully answer. The recovery is to state the boundary you do know and the evidence you would gather.

• “I have not measured that on this version. I would check which thread is busy before choosing a fix.”
• “I would expect that call to cross into native once. If it crosses per item, that is the first thing I would change.”
• “I am not sure the update system allows that without a store release. I would check the runtime version rule before promising it.”

A clear boundary with a named next step scores better than a confident guess. Interviewers remember the guess when the follow-up exposes it.

Prepare answers as decisions

For each topic, rehearse four sentences: the boundary, the default choice, the condition that changes it and the evidence you would measure.

That structure turns a list of framework facts into a production answer. It also makes the follow-up easier, because you already stated where your first choice stops being safe.

Where to go from here

I write these books from the same side of the table. Each has a free sample, and the price adjusts to your country at checkout.

• React Native: Top 300 React Native Interview Questions, questions from junior to staff, with the production depth.
• Mobile system design: Mobile System Design Blueprint, scenarios and exercises with answer keys.

Mike Salari is a Staff Mobile Engineer & Tech Lead with 15 years in mobile and 500+ technical interviews from the hiring side. He writes interview tools from the hiring side at salari.dev.

The only developer who passed was the one who didn’t use it. Here’s what I noticed from the other side of the interview.

This week, I interviewed 13 software developers.

Twelve used AI during their technical interviews. Only one admitted it. The other eleven tried to hide it.

The only developer who didn’t use AI was also the only one who passed.

I’ve been interviewing engineers for years, and I’ve seen candidates arrive unprepared, get nervous, forget things they clearly knew, or struggle with questions outside their experience. None of that is unusual.

What caught my attention this week was something different.

The second screen

Some candidates had ChatGPT open on their phones.

I’d ask a technical question. Their eyes would move away from the laptop. There would be a pause while they typed a few keywords into the phone, followed by an answer that sounded remarkably polished.

It happened during ordinary technical questions and even during system design.

They seemed to think I wouldn’t notice.

After 500+ technical interviews from the hiring side, you become familiar with how people communicate when they’re thinking through a problem.

You notice when someone who was speaking naturally suddenly starts using language that sounds like documentation. Or when a candidate struggles to explain a relatively simple idea but can recite an elaborate definition without hesitation.

Of course, looking away or pausing doesn’t prove anything. People get nervous. Some need time to translate their thoughts into English. Others simply think better when they’re not staring at a camera.

I’m not interested in judging candidates by their eye movements.

I’m interested in what happens when I ask them to explain their answers.

System design exposed the gap

This was especially noticeable during system design discussions.

You can ask ChatGPT how to design a messaging system and get a convincing architecture in seconds. Load balancers, databases, caches, message queues. Everything in the right place, at least on paper.

But a list of components isn’t a design.

Why did you choose that database? What happens if your queue falls behind? Which part of the system would you change first if the requirements doubled?

I don’t need a candidate to know every answer immediately. I want to understand how they approach the problem.

The difficulty with repeating an AI-generated answer is that the explanation often stops where the generated text stops. Once the conversation moves away from the original question, the candidate has to reason independently.

That’s where the difference becomes visible.

A good engineer might choose the wrong approach initially. That’s not necessarily a problem. If they recognize the limitation, explain the trade-off, and adjust their decision, I’m learning something valuable about how they work.

A perfectly structured answer that someone can’t explain tells me very little.

The one who passed

The only developer who didn’t use AI passed both the technical questions and system design.

His answers weren’t always perfect.

He worked through the problems himself, explaining what he understood and how he reached his decisions.

And that was enough to demonstrate the technical ability I was looking for.

I don’t expect engineers to remember everything. I’ve worked with experienced developers who need to look up APIs, revisit documentation, or spend time understanding an unfamiliar concept.

I do the same.

What matters is whether they understand the decisions they’re making.

When someone can explain why they chose an approach, where it might fail, and what they’d reconsider, I have something meaningful to evaluate.

That’s very different from hearing a correct answer without knowing whether the person understands a word of it.

AI isn’t the problem

I use AI in my own engineering work. I think it’s valuable, and I expect its role in software development to keep growing.

But using a tool and depending on it to think for you are two different things.

In real engineering work, AI can suggest an implementation, help investigate a bug, or propose an architecture. You still have to decide whether its suggestions make sense.

You still own the code, the design, and the consequences.

If a production issue appears tomorrow, you can’t defend a bad architectural decision by saying ChatGPT recommended it.

And if you’re using AI during an interview where you’re expected to demonstrate your own technical reasoning, hiding that fact creates another problem: trust.

I’m not suggesting that every technical interview should prohibit AI. An interview designed to evaluate how developers work with these tools can be perfectly reasonable.

But the expectations need to be clear.

When I’m assessing someone’s independent technical ability, I need to hear their thinking, not a response generated on a second screen.

After those 13 interviews, what stayed with me wasn’t how easily candidates could get convincing answers from AI.

It was that the person who passed didn’t need to pretend he knew more than he did.

AI can generate an answer. It cannot give you the understanding behind it.

That’s the difference I was looking for.

If you’re preparing for a technical interview

I’ve spent years on the hiring side of technical interviews, and that experience has shaped how I write my interview preparation books.

For iOS engineers, there’s The iOS Interview Blueprint. For Android engineers, The Senior Signal.

Both focus on the knowledge and reasoning you need to explain technical decisions, not just memorize answers.

You can find them at salari.dev.

Mike Salari has conducted 500+ technical interviews from the hiring side and writes about software engineering, technical interviews, and engineering judgment.

Originally published on salari.dev, where the full series on senior mobile interviews lives.

The API is only one timer

Mobile teams often start a performance conversation with backend latency. The endpoint is 180 ms, the payload is cached at the edge, the database query is fine. Then somebody opens the app on an older phone and the screen still feels heavy.

That is not a contradiction. On iOS, the user does not experience API latency in isolation. They experience launch work, navigation state, JSON decoding, image loading, view invalidation, layout, diffing, persistence, main-thread contention and the timing of all of those things together.

A fast backend can still feed a slow app. The client can take good data and turn it into a bad experience. Most of the iOS performance optimization that matters happens after the response arrives.

The main thread tells the truth

If a screen stutters, freezes during navigation or ignores taps for a beat, start by asking what is happening on the main thread. It is common to find work there that nobody considers expensive because each piece looks harmless alone.

Date formatting in a cell. JSON mapping that grew over time. Image decoding after download. A large diff. A synchronous database fetch. A SwiftUI body invalidating more of the tree than expected. A logging call that does disk work. None of these needs to be dramatic to hurt the feel of the app.

The fix is not to move everything to background queues randomly. The fix is to identify the user-visible lane and protect it. Rendering, input and navigation need room. Expensive transformation, decoding, persistence and precomputation should happen where they cannot block touch and animation.

Decoding is the most common offender I see in code reviews. A view model receives Data, decodes it in a property setter, and the setter runs on the main actor. On a small payload nobody notices. On a large one, the tap that triggered the load freezes the screen. Decode away from the main actor and hop back only to publish:

@MainActor
final class FeedModel: ObservableObject {
    @Published private(set) var items: [FeedItem] = []
 
    func load() async throws {
        let (data, _) = try await URLSession.shared.data(from: FeedAPI.url)
 
        // Decode and shape the rows off the main actor.
        let rows = try await Task.detached(priority: .userInitiated) {
            let dtos = try JSONDecoder().decode([FeedItemDTO].self, from: data)
            return dtos.map(FeedItem.init)   // formatting happens here, once
        }.value
 
        items = rows   // back on the main actor, one assignment
    }
}

Two details matter. The mapping into display values happens in the same background step, so the view never formats anything. And the result lands in one assignment, so SwiftUI sees one change, not a stream of them.

Images are usually a system, not an asset

A feed can have excellent API latency and still feel slow because images are treated as an afterthought. Large images arrive, get decoded at the wrong time, fight for memory, get requested again, or pop into cells after the user has already scrolled past them.

A real image pipeline has several decisions: request sizing, disk cache, memory cache, downsampling, cancellation, placeholder behavior, prefetch distance and eviction policy. The right answer depends on the product. A shopping app, banking app, chat app and media feed do not all need the same image behavior.

Downsampling is the decision most apps skip. A decoded bitmap costs memory by pixel count, not by file size. A 4000 pixel photo shown in a 300 point cell is decoded at full size unless you say otherwise. ImageIO lets you decode straight to the display size, without building the full bitmap first:

import ImageIO
import UIKit
 
func downsampledImage(at url: URL, to pointSize: CGSize, scale: CGFloat) -> UIImage? {
    let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary
    guard let source = CGImageSourceCreateWithURL(url as CFURL, sourceOptions) else {
        return nil
    }
 
    let maxPixels = max(pointSize.width, pointSize.height) * scale
    let options = [
        kCGImageSourceCreateThumbnailFromImageAlways: true,
        kCGImageSourceShouldCacheImmediately: true,   // decode now, not at first draw
        kCGImageSourceCreateThumbnailWithTransform: true,
        kCGImageSourceThumbnailMaxPixelSize: maxPixels
    ] as CFDictionary
 
    guard let cgImage = CGImageSourceCreateThumbnailAtIndex(source, 0, options) else {
        return nil
    }
    return UIImage(cgImage: cgImage)
}

Call it off the main thread, cache the result keyed by URL and target size, and cancel the work when the cell leaves the screen. kCGImageSourceShouldCacheImmediately moves the decode cost to the moment you create the thumbnail, which is on your background task, instead of the first time the image is drawn on the main thread.

The mistake is thinking of images as UI decoration. In many mobile products, images are the performance profile. They decide memory pressure, scroll smoothness, perceived loading and how quickly the screen becomes useful.

SwiftUI Under Load is the long version of this: list stutter, stale requests and slow rendering, with labs you can break and fix.

SwiftUI performance is about what gets re-evaluated

SwiftUI does not redraw everything on every change. It re-evaluates the bodies of views that read the state that changed. That makes dependency reads the main performance lever. A view that reads one wide object is invalidated by every change to that object, and so is everything it builds below it.

The second lever is identity. ForEach and List track rows by their id. If the id is an array index, an insertion at the top renumbers every row, and SwiftUI treats them all as changed. If the id comes from the domain, a reorder is a reorder and nothing else is rebuilt.

The third is what the row body costs. A row body runs during scrolling, so whatever it allocates, it allocates at scroll rate. Here is a row that looks fine in review and stutters on a long feed:

// Before: sorts in body, keys on index, builds a formatter per row.
struct FeedView: View {
    @ObservedObject var model: FeedModel
 
    var body: some View {
        let sorted = model.items.sorted { $0.date > $1.date }
        List(sorted.indices, id: \.self) { i in
            let formatter = DateFormatter()
            formatter.dateStyle = .medium
            Text(formatter.string(from: sorted[i].date))
        }
    }
}
 
// After: the model holds the presented order and the display string.
struct FeedItem: Identifiable {
    let id: String          // the server's stable id
    let dateText: String    // formatted once, when the data arrived
}
 
struct FeedView: View {
    @ObservedObject var model: FeedModel
 
    var body: some View {
        List(model.items) { item in
            Text(item.dateText)
        }
    }
}

The fixed version hands SwiftUI a collection that only changes when the data changes, rows keyed on a stable id, and a body that renders a value instead of computing one. Moving formatting into the model when the data arrives is the single change that most often removes a list stutter, and it is usually the last thing people try.

On List versus LazyVStack: both create rows on demand. List reclaims rows the user has scrolled past, the way a collection view does. LazyVStack keeps rows it has created, so memory grows with how far the user scrolls. For an unbounded feed, List is the default. Switching a slow List to LazyVStack is often the wrong direction.

State can make a fast screen feel unstable

Performance is not only frame rate. A screen feels slow when it keeps changing shape. Content flashes in, disappears, reorders, shows stale values, then corrects itself. The user reads that as slowness even if every individual operation is technically fast.

This usually comes from unclear state ownership. The view loads cached data, then network data, then derived data, then an optimistic update, then a server correction. If those transitions are not designed, the screen feels nervous.

A better approach is to define the states explicitly: cached, refreshing, empty, failed, partial, pending action, synced. The app should not merely have data or not have data. It should know what kind of truth it is showing.

Ownership also decides invalidation. When one store holds balances, the feed and the form, a balance tick re-evaluates all three. Split them so each store owns one kind of truth, and a change reaches only the views that read it. Paging has the same rule: new pages append, they never reorder rows the user has already seen, or rows jump under the thumb and no rendering work fixes it.

How to measure iOS performance

Guessing is the anti-pattern. The workflow is short: measure on a real device, fix the biggest thing the data shows, measure again. Profile a release build on the oldest device you support. The simulator and a debug build both lie.

• Name the symptom first. Slow launch, a hitch while scrolling, a freeze after a tap, and memory growth are four different problems with four different instruments.
• Time Profiler for CPU. It samples call stacks, so you can see which of your functions own main-thread time during the slow moment. Filter to the main thread and look for your code, not the system frames around it.
• Hangs for freezes. It flags periods where the main thread was unresponsive long enough for the user to notice, and shows what it was doing.
• The SwiftUI instrument for view updates. It shows which view bodies were evaluated and how often. A count that scales with the number of rows, when one value changed, points to a wide dependency or unstable identity.
• Allocations for memory. Mark a generation before and after a flow, such as pushing and popping a screen, and look at what survived that should not have.
• Signposts for your own spans. Wrap a suspect region with OSSignposter intervals and it appears on the timeline, which turns "the feed feels slow" into "decode took most of the load".
• Change one thing, then re-record. Stack five fixes and measure once, and you will not know which one worked or which one regressed something else.

Instruments answers why it is slow on your desk. The field needs different tools. MetricKit delivers daily aggregated payloads from real users, covering launch time, hang rate, memory and disk writes, plus diagnostic payloads with call trees for hangs and crashes. Xcode Organizer shows the same signals per release, so a launch regression shows up as a trend line instead of a support ticket.

Beyond the tools, measure the path the user feels: time to first meaningful content, scroll hitches, image cache hit rate, main-thread stalls, launch time, pagination delay, and how often the user sees a full-screen loading state. The useful question is not whether the system is fast somewhere. It is where the user waits, where they lose trust and where the app blocks the next action.

Once you measure that path, performance work stops being mystical. You can decide whether to precompute, cache, cancel, paginate earlier, reduce payload size, split state, defer work, or change the product behavior.

What interviewers ask about iOS performance

I have asked some version of “the app is slow, what do you do?” in hundreds of interviews. The question is open on purpose. Weak answers jump straight to a fix: use LazyVStack, add caching, move it to a background thread. Strong answers ask what slow means, pick the matching instrument, and only then discuss causes.

The shape I listen for is a story with numbers: a baseline, one targeted change, a re-measurement. “I made scrolling smoother” tells me nothing. “Time Profiler showed most of the frame time in JSON decoding on the main thread, I moved it to a background task, and the hang rate in MetricKit dropped” tells me the candidate has done this for real.

The follow-ups separate levels:

• “You have ten thousand rows and scrolling stutters.” Mid-level: lazy container, stable ids, cheap rows. Senior: List over LazyVStack because it reclaims rows, formatting moved into the model, no sorting in body. Staff: the list is a window onto data you do not fully hold, so page the source, keep a bounded working set, and derive identity from the server id across pages.
• “Why is this image-heavy screen using so much memory?” The answer I want mentions decoded size versus file size and downsampling to the display size at decode time.
• “How would you know this is slow for users, not just for you?” MetricKit and Organizer, and at senior level, hang rate and launch time as release criteria rather than dashboards someone checks occasionally.
• “Which state change here invalidates the most views?” A candidate who can point at one wide dependency read and propose a narrower one understands SwiftUI performance. One who says SwiftUI redraws everything does not.

Red flags are consistent: a formatter created inside a row body, sorting or filtering in body, rows keyed on array index, and "we only have a few hundred items". That last one holds until the account with forty thousand arrives.

Where to go from here

I write these books from the same side of the table. Each has a free sample, and the price adjusts to your country at checkout.

• Production SwiftUI: SwiftUI Under Load, races, stale requests and slow rendering, with failure labs.
• Mobile system design: Mobile System Design Blueprint, scenarios and exercises with answer keys.

Mike Salari is a Staff Mobile Engineer & Tech Lead with 15 years in mobile and 500+ technical interviews from the hiring side. He writes interview tools from the hiring side at salari.dev.

SwiftUI dismiss closes the wrong screen: why it happens and how to fix it

Subtitle: If your sheet’s Done button does nothing, or closes the screen behind the sheet too, check where you read dismiss.

If a Done button inside a SwiftUI sheet does nothing, or closes the sheet and the screen under it, the cause is usually one line: the dismiss action was read in the screen that opened the sheet, not inside the sheet. dismiss acts on the place where it was read. Move it into the sheet’s own view and the problem goes away.

That is the short answer. Below is the code, why it behaves this way, the fix, and the test that lets this bug ship.

The code that breaks

struct HostView: View {
    @Environment(\.dismiss) private var hostDismiss
    @State private var showingEditor = false

    var body: some View {
        Button("Edit") { showingEditor = true }
            .sheet(isPresented: $showingEditor) {
                Button("Done") { hostDismiss() } // wrong scope
            }
    }
}

hostDismiss is read in HostView. The sheet calls it. The sheet is not the thing being dismissed.

Why it happens

Apple documents that the dismiss action applies to the environment where it was declared, not to the view that calls it.

So hostDismiss belongs to HostView. When the sheet calls it, SwiftUI tries to dismiss HostView.

What that does depends on where HostView sits. Apple also documents that dismiss can pop a view from a navigation stack. With HostView inside a NavigationStack, UI tests on an iOS 27.2 simulator recorded two results:

Where HostView sits What happens when you tap Done First screen of the stack Nothing to pop. The sheet stays open. Pushed from a list HostView is popped. The sheet closes with it.

One mistake, two symptoms. That is why it is hard to spot: from one screen it looks like a dead button, from another it looks like a navigation bug.

These results come from one tested setup. Other hierarchies or OS versions may behave differently, so test yours.

The fix

Read dismiss inside the view that the sheet shows.

private struct PresentedSheet: View {
    @Environment(\.dismiss) private var dismiss

    var body: some View {
        Button("Dismiss sheet") { dismiss() }
            .accessibilityIdentifier("dismissSheet")
    }
}

Present PresentedSheet from the parent’s sheet modifier. Its dismiss now comes from the sheet’s environment, and in the same tests only the sheet closes.

If the parent needs to do something before the sheet closes, like save, pass the sheet a closure from the parent that updates the parent’s state. Keep one owner for closing the sheet. Mixing dismiss, a binding change and a callback without a clear order is how this kind of bug comes back.

The test that misses it

The usual UI test taps Done and checks that the sheet is gone.

When HostView was pushed, that test passes, because the whole screen is gone. The bug ships with a green test.

Check the screen that should still be there instead. After Done, HostView must still be visible. Wait a moment before the check: a check made right after the tap can pass while the closing animation is still running.

How this comes up in interviews

A common follow-up: a sheet contains a pushed detail, which dismiss closes what?

A mid-level answer: any dismiss closes the sheet.

A senior answer: it depends where the action was read. Then it says how to prove it, by checking the screen that should remain, and what has not been tested.

Where this is from

This is one of 12 cases in Debugging SwiftUI, a short field guide to real SwiftUI bugs. Each case has the symptom, how to find the cause, the fix, and how it was checked.

The book is in a free private beta. Read it online, tell me where it is wrong or unclear, and if your feedback leads to a fix, your name goes in the acknowledgements. You also get the final book free.

Apply here: https://salari.dev/beta/debugging-swiftui

Originally published on salari.dev, where the full series on senior mobile interviews lives.

Swift 6 rejected the unsafe program exactly where I expected it to.

I had a small reference-type experiment with state shared across concurrency boundaries. In Swift 6 language mode, the negative control failed with concurrency diagnostics. Good. That part was boring in the best possible way.

Then I fixed the concurrency problem.

I moved the state behind actor isolation. I tested Sendable variants. I also tested an @unchecked Sendable case where I was explicitly taking responsibility for the safety guarantee.

The code compiled.

Then I looked at what ARC was doing.

I expected the generated code to change.

It did not.

In the Apple Swift 6.3.3 cases I tested, the runtime still went through the normal:

swift_retain
swift_release

Actor isolation had changed what Swift could prove about access to the program state.

It had not changed the ARC runtime entry points I was observing.

That was the interesting part.

The question

Swift 6 has a much stronger concurrency model than earlier Swift versions.

The compiler can reject code that moves non-Sendable state across isolation boundaries. Actors provide isolation. Sendable describes values that can safely cross concurrency domains. Strict concurrency checking catches classes of mistakes that previously survived compilation.

So I wanted to test a fairly simple question:

If Swift 6 can prove that some object access is isolated from concurrent mutation, can ARC use cheaper non-atomic reference counting for that object?

That sounds plausible.

If the compiler knows an object is actor-isolated, why pay synchronization costs for reference-count updates that should not race?

The problem is that two different questions are being mixed together.

Swift concurrency asks whether program state is being accessed or transferred safely.

ARC asks how object lifetime is accounted for.

Those are related, but they are not the same contract.

I wanted to see where that distinction showed up in generated code rather than stopping at the language model.

The experiment

I ran the experiment using Apple Swift 6.3.3 from Xcode 26.6, explicitly compiling in Swift 6 language mode.

The test environment was:

Apple Swift 6.3.3
Xcode 26.6
macOS 26.6.2
arm64
Swift language mode 6
iPhone 17 Simulator for simulator validation

The repository contains a negative control plus several valid cases, including actor isolation and Sendable variants.

The negative control matters.

Without it, seeing a successful Swift 6 build tells us almost nothing. I wanted a case where the compiler demonstrably rejected unsafe sharing, then closely related cases where the concurrency problem had actually been addressed.

The unsafe case failed as expected.

The valid cases compiled.

Then I looked at multiple stages of compiler output.

That distinction matters because SIL ownership instructions are not the same thing as the final ARC runtime calls.

At the SIL level you can see ownership operations and retain/release behaviour represented in Swift’s intermediate representation.

But if the question is:

Which runtime reference-counting entry point does this build actually use?

then LLVM IR and assembly are the more interesting places to look.

In the ordinary Swift 6 builds I tested, I continued to find:

swift_retain
swift_release

That remained true when the concurrency model around the object changed.

Actor isolation did not turn the observed calls into non-atomic ARC operations.

Neither did the Sendable or @unchecked Sendable cases I tested.

Then I changed one compiler assumption

There is a compiler option that makes this experiment much more useful:

-Xfrontend -assume-single-threaded

The name is refreshingly direct.

Instead of asking the compiler to infer from actor isolation that some individual object’s reference counting can be cheaper, this flag changes a much broader assumption about the program.

The compiler is being told to assume single-threaded execution.

I compiled the controlled case again.

This time, the output changed.

Instead of the ordinary ARC runtime entry points, I observed:

swift_nonatomic_retain
swift_nonatomic_release

And that happened in both the unoptimized and optimized configurations I tested.

The clean A/B looked like this:

• normal -Onone. Retain: swift_retain; Release: swift_release
• single-threaded -Onone. Retain: swift_nonatomic_retain; Release: swift_nonatomic_release
• normal -O. Retain: swift_retain; Release: swift_release
• single-threaded -O. Retain: swift_nonatomic_retain; Release: swift_nonatomic_release

That gave me the selector I wanted.

The same general reference-counting operation could be lowered differently when the compiler was explicitly told to assume a single-threaded program.

But Swift 6 actor isolation by itself had not produced the same result in my experiment.

Why this distinction matters

It would be easy to look at Swift 6 concurrency and reason like this:

• An actor guarantees isolated access.
• Therefore this reference cannot be touched concurrently.
• Therefore ARC for this reference does not need atomic operations.

The first statement can be valid.

The jump from the first statement to the third is where things become much less obvious.

Actor isolation is a source-level concurrency guarantee about access to isolated state.

ARC lifetime operations may happen for references that move through code outside the isolated body, through calling conventions, temporary values, captures, ownership transfers, bridging, optimizer transformations, and other parts of the generated program.

A proof that some mutable state is actor-isolated is not automatically the same thing as a whole-program proof that every relevant lifetime operation for an object can use non-atomic accounting.

The experiment does not prove why every individual retain or release remains on a particular runtime path.

What it does show is narrower and more useful:

In the Apple Swift 6.3.3 cases I tested, making the program concurrency-safe through actor isolation, Sendable, or @unchecked Sendable did not change the observed ARC calls from swift_retain / swift_release to their non-atomic counterparts.

Explicitly switching the compiler to a single-threaded assumption did.

This is compiler/runtime implementation evidence for the tested toolchain, not a Swift language guarantee.

That distinction matters.

Following the compiler

I also traced the relevant compiler path instead of treating the runtime symbol names as magic.

For the toolchain path examined in the repository, the single-threaded assumption flows roughly like this:

frontend option
↓
CompilerInvocation
↓
SILOptions::AssumeSingleThreaded
↓
SILModule::isDefaultAtomic()
↓
IRGen Atomicity
↓
GenHeap runtime call selection

That is useful because it connects the frontend assumption to the ARC lowering decision.

The interesting part is what I did not find in that path.

I did not find a corresponding rule that says:

actor-isolated object
↓
non-atomic ARC

or:

Sendable
↓
non-atomic ARC

And the generated output from the experiment matched that.

That does not mean such an optimization could never exist.

It means I could not demonstrate it in these cases, with this toolchain, and the compiler path I traced points to a broader default-atomicity decision rather than a simple mapping from Swift concurrency annotations to ARC atomicity.

There is one additional limitation worth stating clearly: the open-source Swift source revision inspected in the repo is not proven to be the exact source revision Apple used to build Swift 6.3.3.

So the compiler-source tracing is supporting evidence, not a claim of exact source-build identity.

Sendable is not an ARC annotation

This is also a useful reminder about Sendable.

Sendable is frequently discussed as if it were a general "thread safe" marker.

That is too vague.

Its job is about whether values can safely cross concurrency boundaries under Swift’s concurrency model.

It does not say:

Use non-atomic reference counting for this instance.

Likewise, @unchecked Sendable does not unlock an ARC optimization.

It tells the compiler that you are taking responsibility for a guarantee it cannot verify itself.

In my tested cases, neither changed the ARC runtime calls I was looking at.

That separation is important because otherwise it becomes very easy to assign performance properties to concurrency annotations that the language never promised.

The ARC question, three answers deep, is in The iOS Interview Blueprint: what most candidates say, the senior answer and the staff answer.

Actor isolation is still doing real work

None of this makes actor isolation less valuable.

The negative control was rejected.

The isolated version compiled.

That is a meaningful change in the program.

Swift 6 was enforcing a concurrency contract and preventing a class of unsafe access.

What did not happen was a second, independent assumption:

Because this code is now accepted by the concurrency checker, ARC can use non-atomic lifetime accounting.

Those are two different decisions.

That distinction is probably the main thing I took away from the experiment.

Swift’s concurrency model can become more precise without every other subsystem automatically inheriting those proofs.

Why not just look at SIL?

Because SIL can easily tempt you into making claims one level too early.

Ownership operations in SIL tell you something about Swift’s ownership representation and optimization pipeline.

They do not necessarily tell you which reference-counting runtime function survives into the final generated program.

Optimization makes this even more complicated.

A retain may disappear. Two operations may be combined. A lifetime can be shortened or extended. Something visible at -Onone may not exist at -O.

For this question, I wanted to check SIL, then continue down to LLVM IR and assembly rather than infer the final runtime behaviour from one intermediate stage.

That also makes the experiment easier to falsify.

You do not have to trust my interpretation of a SIL ownership instruction.

You can inspect the generated IR or assembly and search for the actual runtime symbols.

What this experiment does not prove

There are several conclusions I would not draw from this.

It does not prove:

Swift ARC is always atomic.

It does not prove:

Actor-isolated objects always use atomic refcounts.

It does not prove:

Sendable can never influence ARC optimization.

It does not prove:

Atomic reference counting protects your mutable program state.

It does not prove:

-assume-single-threaded is a production optimization you should enable.

And it does not prove that the behaviour observed in this toolchain is a permanent Swift language rule.

Those claims are much broader than the evidence.

The result is specifically about the compiler configurations and source cases I tested.

The defensible claim is:

In these Apple Swift 6.3.3 experiments, actor isolation, Sendable, and @unchecked Sendable changed the concurrency validity of the program but did not change the observed ARC runtime entry points. Explicitly compiling with -assume-single-threaded did.

That is the claim I am comfortable publishing.

The practical lesson

Most application developers will never choose ARC entry points manually.

That is not really the point.

The useful lesson is about how to reason about compiler guarantees.

Swift 6 rejecting a data race does not mean every subsystem now gets to assume that the entire lifetime of every involved object is single-threaded.

Concurrency safety is one contract.

Object lifetime accounting is another.

Sometimes a compiler can connect proofs across those boundaries.

Sometimes it cannot, or deliberately does not.

And sometimes you need to stop looking at the language feature and inspect the generated program.

That is what happened here.

Swift 6 rejected the race.

ARC stayed on the ordinary path.

Only when I explicitly told the compiler to assume a single-threaded world did the reference-counting path change.

Reproduce it

The full experiment is public:

GitHub: https://github.com/salari-dev/swift6-arc-atomicity-lab

The repository includes:

• the Swift test cases;
• the negative concurrency control;
• generated SIL, LLVM IR and assembly evidence;
• the atomic versus non-atomic A/B;
• compiler-selection tracing;
• runtime-source mapping;
• claim auditing;
• simulator validation;
• reproduction scripts.

To regenerate the compiler experiment:

./run-experiment.sh

For simulator validation:

./run-simulator-validation.sh

The repository preserves the frozen evidence under Evidence/, while regenerated output is written separately.

The experiment currently uses one official Apple Swift toolchain. No second official Swift toolchain was installed and tested, so cross-toolchain reproduction remains unresolved.

I would encourage you to run it rather than take this article on faith.

Compiler behaviour is exactly the kind of thing where the interesting answer may change with a future toolchain.

And if a newer Swift compiler starts lowering one of these cases differently, that would make the experiment more interesting, not less.

References

• Swift, Actor
• Swift, Sendable
• Reproduction repository: salari-dev/swift6-arc-atomicity-lab

Where to go from here

I write these books from the same side of the table. Each has a free sample, and the price adjusts to your country at checkout.

• Production SwiftUI: SwiftUI Under Load, races, stale requests and slow rendering, with failure labs.
• You have weeks: The iOS Interview Blueprint, the full senior iOS loop, level by level.

Mike Salari is a Staff Mobile Engineer & Tech Lead with 15 years in mobile and 500+ technical interviews from the hiring side. He writes interview tools from the hiring side at salari.dev.

Originally published on salari.dev, where the full series on senior mobile interviews lives.

You have a live coding interview next week, so you do what seems reasonable. You search YouTube, find someone solving exactly the kind of problem you are worried about, and spend two hours following along.

They structure the code, make the tradeoffs, fix the mistake, add the test. Everything makes sense while you are watching. You can almost predict the next line before they type it.

The next morning you open an empty editor and try to do the same thing yourself.

Nothing comes out the way it did in the video.

The naming feels harder. The order disappears. You forget one API, then another. You start questioning architecture you understood perfectly twelve hours ago.

That does not mean the tutorial was bad.

It means recognising someone else’s thinking is not the same skill as retrieving your own.

I have seen this catch experienced engineers in live coding rounds. Give them their normal codebase and twenty quiet minutes, and they can do the work. Put another engineer on a call, start a timer and ask them to make the thinking visible while they code, and the experience changes.

Live coding is an unnatural version of a normal job

Think about how you actually write software.

You go quiet, stare at the same function, try one direction, delete half of it, check documentation and come back with a better idea. That is normal engineering.

Live coding removes most of that privacy. Now somebody is watching while you understand the task, choose a direction, write code, manage the clock, catch your own mistakes and expose enough reasoning for them to tell whether the mess on the screen is controlled or accidental.

For an introverted engineer, this can feel especially unnatural. Thinking silently may be how you have done good work for years. The interview suddenly asks you to do something you barely practise at work: speak while the thought is still forming.

That is why someone with ten years of production experience can look less comfortable than someone with three years who has trained for this exact room.

“Keep talking” is close to useless advice

A lot of live coding advice tells candidates to keep talking.

That is close to useless because it does not tell you what deserves to be said.

Nobody needs a radio commentary on your keyboard. “Now I am creating a variable. Now I am adding an if statement.” That gives the interviewer noise, not evidence.

What they need access to are the decisions.

“I’m going to get the happy path working before I abstract this.”

“I see two possible ownership models here. I’m choosing this one because the lifecycle is simpler for the exercise.”

“I don’t remember the exact API. I know the behaviour I need, so I’m going to sketch it and come back.”

“I could extract this behind a protocol, but with twenty minutes left that abstraction is not buying us anything.”

That is useful narration. It tells the interviewer where you are, what you are optimising for and whether your unfinished code is unfinished on purpose.

A Senior engineer does not need to look perfect during live coding.

They need to look in control of imperfection.

The strongest candidates recover in public

This is another place where polished tutorials can give you the wrong mental model. The person in the video usually knows the path. Your interview will not feel like that.

You will make a mistake.

Good.

The interviewer now gets to see something much more interesting than whether you remembered an API.

Do you panic and start apologising? Do you keep digging because changing direction feels embarrassing? Or do you stop, inspect what happened and say:

“This is getting more complicated than the requirement deserves. I took the wrong boundary. I’m going to simplify it.”

That sentence can tell me more than ten minutes of flawless typing.

Real engineers are wrong constantly. The valuable skill is recognising it before the mistake becomes architecture.

Live coding gives the interviewer a rare chance to watch that mechanism happen in real time.

Share Your Screen is built for exactly this gap: timed rounds, narrated out loud, with the recovery lines ready.

Watching helps until it replaces doing

YouTube, courses, books and walkthroughs are good ways to learn a pattern. The problem starts when consuming the pattern becomes the practice.

You can watch twenty implementations of pagination and still freeze when the empty file belongs to you. You can understand someone explaining state ownership and still struggle to choose a boundary without their finished code in front of you. You can follow a system design perfectly and discover that you cannot reconstruct it when one requirement changes.

The information needs another pass through you.

Your eyes see it. Your brain understands it. Your hands need to reproduce it. Your mouth needs to defend it.

That last half is where interview ability gets built.

Practise the ugly version

If you have a live coding round coming, stop trying to make practice comfortable.

Open an empty project. Set the actual interview timer. Put the tutorial away. Read the requirement once, decide what matters first and start.

Speak when there is a decision worth exposing. If you forget an API, say what behaviour you need and keep moving. If the architecture becomes too heavy, simplify it. If something is ugly but correct and the clock is running, leave it ugly and explain the tradeoff.

You do not need a studio setup. Talk out loud to an empty room and notice where you suddenly go quiet. If you record one practice round, listen back to the reasoning, not the code.

Where did you go silent because you did not know what to do? Where did nerves make you over-explain? Where did you build something the task never needed? Where did you spot the mistake but refuse to change direction?

That is live coding practice.

You are training retrieval under pressure

This is the distinction I wish more experienced engineers understood before their first serious loop in years.

You probably do not need another hundred hours of engineering knowledge. You may need to make what you already know available on demand.

Can you reach the idea without the video? Can you implement it without the finished solution? Can you explain the tradeoff before someone supplies the vocabulary? Can you recover when the first idea fails?

Those are trainable skills.

But you cannot train them entirely by watching somebody else succeed.

That is why I wrote Share Your Screen.

The article you just read is platform-neutral. The book is not. Share Your Screen is for Senior iOS engineers, because it goes directly into the live iOS rounds: coding while somebody watches, narrating the decisions that matter, code review, system design, managing the clock, recovering when you stall and holding a technical position when the interviewer pushes back.

Knowing iOS and showing how you think with iOS under pressure are different skills.

The first one built your career.

The second one may decide the next job.

YouTube gave you recognition. The interview requires retrieval.

Where to go from here

I write these books from the same side of the table. Each has a free sample, and the price adjusts to your country at checkout.

• The shared-screen round: Share Your Screen, senior iOS live coding and system design, solved out loud.
• You have weeks: The iOS Interview Blueprint, the full senior iOS loop, level by level.

Mike Salari is a Staff Mobile Engineer & Tech Lead with 15 years in mobile and 500+ technical interviews from the hiring side. He writes interview tools from the hiring side at salari.dev.

Originally published on salari.dev, where the full series on senior mobile interviews lives.

SwiftUI vs UIKit is not a universal verdict

SwiftUI gives teams a declarative state model, faster composition and strong alignment with current Apple platform direction. UIKit gives mature lifecycle control, deep ecosystem coverage and predictable behavior in large existing applications. Neither framework removes the need for architecture.

For a new isolated flow on supported operating systems, SwiftUI can reduce presentation code and make state transitions easier to test. For a mature application with complex navigation, specialized collection layouts or years of UIKit infrastructure, gradual interoperability is often safer than a rewrite.

The senior decision weighs product lifetime, supported OS versions, team experience, accessibility, performance measurement and migration risk. The answer is usually a boundary: where SwiftUI creates leverage now, where UIKit remains the lower-risk owner and how both exchange state without duplicating truth.

The architecture debate starts too late

Many SwiftUI architecture debates start with the wrong question: should we use MVVM, TCA, Clean Architecture or something custom? That question matters, but it is not the first question.

The first question is: who owns the state? Most SwiftUI problems that feel architectural are really ownership problems. A value changes in one place, the screen updates somewhere else, an effect returns late, identity changes unexpectedly, and the team starts blaming SwiftUI.

SwiftUI is not forgiving when ownership is vague. It will render exactly what your model says, even if your model has no clear source of truth.

A screen has several kinds of state

A production screen usually has more than one kind of state. There is server state, local persisted state, in-memory view state, form state, navigation state, loading state, optimistic state and derived state.

If those are all pushed into one view model without names, the model becomes a drawer for everything the screen might need. That is not architecture. It is storage.

A stronger design names the state and decides which layer owns each piece. The view can own short-lived presentation state. A model can own screen behavior. A repository can own persistence and remote refresh. A coordinator or router can own navigation. The exact names matter less than the ownership being explicit.

SwiftUI Under Load goes deeper on ownership, identity and effects in production SwiftUI, with labs you can break and fix.

Identity is not a cosmetic detail

SwiftUI identity decides whether state is preserved, reset or duplicated. A list row, tab, sheet or navigation destination can behave strangely when identity changes without the team noticing.

This is why production SwiftUI architecture needs rules for IDs, lifetime and view creation. If a view creates an object, it owns that object’s lifetime. If it receives an object, ownership lives somewhere else. If a task is tied to view identity, it may restart when identity changes.

The senior answer is not just which property wrapper to use. The senior answer explains what lifetime the property wrapper represents.

Effects need ownership too

Networking, search, image loading, analytics, persistence and sync are effects. If the effect belongs to what the user currently sees, it can often be tied to view lifetime. If the effect represents user intent or data integrity, it needs a more durable owner.

A search request can be cancelled when the query changes. A draft save should not disappear because the view navigated away. A payment confirmation should not depend on a transient view still existing.

Good SwiftUI architecture separates visual work from user-intent work. That distinction prevents many bugs that otherwise look like random async behavior.

The useful architecture question

When reviewing a SwiftUI architecture, ask this: if the app is backgrounded, the network returns late, the user navigates away, the same screen appears twice and cached data refreshes underneath it, does the state model still make sense?

If the answer is no, changing the pattern name will not save the feature. The ownership model has to become clearer.

SwiftUI rewards small, honest boundaries. Not because small files are magic, but because clear ownership makes rendering, testing and failure recovery easier to reason about.

Use the practical guide

Senior iOS interview preparation: Prepare for senior iOS interviews across Swift, concurrency, architecture, system design, debugging and staff-level judgment.

Where to go from here

I write these books from the same side of the table. Each has a free sample, and the price adjusts to your country at checkout.

• Production SwiftUI: SwiftUI Under Load, races, stale requests and slow rendering, with failure labs.
• Mobile system design: Mobile System Design Blueprint, scenarios and exercises with answer keys.

Mike Salari is a Staff Mobile Engineer & Tech Lead with 15 years in mobile and 500+ technical interviews from the hiring side. He writes interview tools from the hiring side at salari.dev.

Originally published on salari.dev, where the full series on senior mobile interviews lives.

The mistake

A lot of engineers prepare for mobile system design interviews by memorizing backend system design templates. They learn how to talk about databases, queues, caches, sharding, load balancers and service boundaries. That knowledge is useful, but it is not enough for a senior iOS interview.

A senior mobile interview is usually not asking you to redesign Twitter’s backend with an iPhone screen attached. It is asking whether you understand the system that exists between the server and the user. That system includes the app process, local persistence, memory pressure, background execution, network failure, platform APIs, push delivery, release risk and the user’s trust.

If your answer jumps straight to microservices, you may sound technically fluent while missing the part the interviewer is actually testing.

The backend template misses the hardest mobile constraints

A backend system design answer usually starts with services, databases, queues and load balancers. A mobile system design answer starts somewhere less comfortable: an unreliable device in somebody’s pocket.

The app can be killed. The network can disappear. Storage can fill up. The user can perform actions offline, then expect the app to reconcile them later without losing trust. A screen can render with stale data, duplicate data, partial data or no data. A task can be cancelled because the user scrolled away. A background job can be delayed or denied by the operating system.

That changes the order of the answer. You still need to talk about APIs and backend contracts, but only after you explain state ownership, latency perception, local persistence, sync boundaries, app lifecycle, memory pressure, battery, privacy and release safety.

A mobile app is not a thin client. It is a distributed node with a UI, cache, persistence layer, sync engine, background task model, notification surface, feature flags, analytics, crash reporting and platform constraints. The system succeeds or fails on the device before the user ever thinks about the backend.

The real design surface is state

Most mobile system failures are state failures. A feed shows stale data. A sync engine overwrites the wrong value. A cache keeps the app fast until it quietly becomes wrong. A button looks enabled even though the operation already failed in the background.

For most mobile features, state exists in several layers at once: server state, local persisted state, in-memory state, UI state, optimistic state and derived state. Bugs happen when those layers are unnamed. Senior design means naming them, assigning ownership and describing how they converge after failure.

Take a feed. A weak answer says: fetch posts, paginate results, cache images. A stronger answer asks: what is the source of truth when the user is offline? How long can cached feed data be trusted? What happens when the server sends an updated item that conflicts with a local optimistic action? If the user likes a post offline, where is that pending mutation stored? How do we avoid showing duplicate items across pages? How do we cancel image work when cells disappear? How do we measure whether the feed is healthy in production?

The Mobile System Design Blueprint turns this into practice: scenarios and exercises with answer keys.

Offline-first is not just caching

Caching answers the question: what can I show when I cannot reach the server? Offline-first answers a harder question: what can the user safely do when I cannot reach the server?

In an interview, say exactly what offline means for the feature. Can the user read existing data? Create new data? Edit existing data? Delete data? Queue actions? See pending status? Retry manually? Abandon failed work?

Then describe the pending operation model. Store mutations durably with stable IDs, timestamps, retry counts and idempotency keys. Make the UI show pending, failed and synced states. Make retries safe. Make conflicts visible when automatic resolution would damage trust.

Conflict policy should match the domain. Last-write-wins may be acceptable for low-value preferences. Server-wins may be right for permissioned data. Manual merge may be necessary for collaborative documents. Operation logs can preserve intent better than overwriting whole records.

Lifecycle changes the architecture

Backend services are usually designed to keep running. Mobile apps are designed to be interrupted. The user can background the app. The operating system can suspend it. Memory pressure can terminate it. A background task can be given a tiny execution window or no execution window at all.

That means important work needs a durable representation. If the app must eventually upload a draft, sync a note or complete a checkout step, that work cannot exist only as an in-memory Task. It needs to be stored, resumed and reconciled.

A vague answer says: we retry in the background. A senior answer says: we persist pending operations locally, include idempotency keys, resume sync on launch and foreground transitions, use platform background APIs where appropriate, handle expiration, and surface unresolved failures to the user instead of silently dropping work.

What interviewers want to hear

They want constraints before components. They want tradeoffs before patterns. They want to know whether you can design for battery, memory, app lifecycle, offline work, rollout risk and observability.

A good mobile system design answer says: here is the user promise, here are the device constraints, here is the state model, here is the data flow, here is what works offline, here is how failures recover, here is how the UI stays fast, and here is how we will know this works in production.

Backend architecture still matters. APIs, databases, queues and services matter. But in mobile system design, the phone is not just a client. It is the environment where the system is judged.

Use the practical guide

Mobile system design interview preparation: Prepare mobile system design interviews with a framework for offline data, synchronization, caching, performance, security and rollout.

Offline-first mobile architecture: Design offline-first mobile apps with a local source of truth, pending writes, conflict handling, sync state and honest UX.

Where to go from here

I write these books from the same side of the table. Each has a free sample, and the price adjusts to your country at checkout.

• Mobile system design: Mobile System Design Blueprint, scenarios and exercises with answer keys.
• Senior to staff: Altitude, the systems side of staff mobile engineering.

Mike Salari is a Staff Mobile Engineer & Tech Lead with 15 years in mobile and 500+ technical interviews from the hiring side. He writes interview tools from the hiring side at salari.dev.