Mobile Engineer Interview Guide: iOS, Android, and Cross-Platform Loops

Mobile engineering loops look superficially like web engineering loops but ask a very different question under the surface. Where a web interviewer wants to know whether you can ship a feature reliably to a browser fleet, a mobile interviewer wants to know whether you can ship a feature reliably to a device that is sometimes offline, sometimes low on battery, sometimes under memory pressure, and always being reviewed by a platform store. The constraints shape every round. A design that ignores cold start, memory pressure, or background execution limits is treated as incomplete regardless of how elegant it looks.

The discipline has consolidated in 2026. SwiftUI and Jetpack Compose are the default UI paradigms on their respective platforms, async-first concurrency is now table stakes, and the debate between fully native and cross-platform has settled into a pragmatic middle. Teams pick native when product differentiation and platform integration matter, and pick Kotlin Multiplatform, Flutter, or React Native when shared business logic dominates the value prop. Interviews reflect this reality: candidates are expected to be deeply fluent in at least one platform and conversant in the alternatives.

Table of Contents

• Loop Structure Across iOS, Android, and Cross-Platform Roles
• Platform Fundamentals Under the Hood
• Coding Rounds with Platform APIs
• UI System Design (Photo and Chat Apps)
• Memory, Performance, and Battery
• Offline-First Architecture and Sync
• Release, Rollout, and Launch Readiness
• Common Mistakes That Sink Loops
• Sample Questions with Answer Scaffolds
• Behavioral Themes Specific to Mobile Teams
• FAQ
• Conclusion

Loop Structure Across iOS, Android, and Cross-Platform Roles

A typical mobile loop spans a phone screen, two coding rounds in the platform language, a UI system design round, a broader mobile system design round, and a behavioral round. Some companies add a debugging round where you open a sample project with a planted bug and trace the issue live.

The phone screen filters for platform fundamentals. Expect questions about the Swift or Kotlin language, the lifecycle of the main app container, how backgrounding works, and the rendering model. Answer these precisely. A candidate who says "the view controller is like a component" signals weak fundamentals; the interviewer wants to hear specific APIs and lifecycle phases.

The coding rounds differ from web or backend interviews in a crucial way: they test whether you can write idiomatic code against the platform SDK, not just solve an algorithm. Expect a prompt such as "build a small screen that fetches a list, handles errors and loading, and allows pull to refresh," and be prepared to do it in a style that matches modern SwiftUI or Jetpack Compose best practices. A data structures question may appear but is rarely the sole filter.

The UI system design round is the most specialized. You may be asked to design a photo gallery with infinite scroll, a chat application with typing indicators and read receipts, or a maps view with pinned annotations over a large region. The interview focuses on memory management, reuse, caching, threading, and correctness under rapid state changes.

The broader mobile system design round zooms out. Expect prompts about offline sync architecture, authentication on mobile, feature flag delivery, or crash reporting pipelines. This is where you show that you understand the mobile runtime as one node in a distributed system.

Platform Fundamentals Under the Hood

On iOS, the foundational knowledge is the app lifecycle, the scene-based multi-window model, the run loop, the role of the main thread, the memory model with ARC, and the dispatch system. Know the difference between async let, TaskGroup, actor, and structured concurrency patterns in Swift. Understand why the main actor matters for UI updates and how task priorities interact with the scheduler. Be fluent in Combine or the async sequence equivalents for streaming data.

On Android, the fundamentals are the Activity and Fragment lifecycle (still relevant even in Compose-first apps), process lifecycle and process death, the main thread, the lifecycle-aware components, work manager for deferrable work, and the view system and Compose runtime model. Know coroutines deeply: structured concurrency, CoroutineScope, Dispatchers, Flow versus StateFlow, and the supervisor job pattern.

On both platforms, the question behind the question is: what happens when the system kills your process. Senior candidates answer with confidence about state restoration, background execution budgets, foreground services versus background tasks, and the user-visible implications. Candidates who describe Android work as if it always runs to completion, or treat an iOS background task as if it had unlimited time, reveal that they have not operated a real app at scale.

Memory models deserve attention. ARC in iOS creates predictable deallocation but introduces retain cycles in closures and delegate patterns. Know when to use weak, unowned, and capture lists. On Android, the garbage collector hides allocation costs until the application reaches memory pressure, at which point the cost becomes visible as jank. Know how to reason about allocation rate, the generational collector, and the implications of Compose's stability model for recompositions.

Cross-platform candidates need to be explicit about which platform they know more deeply. Pretending to be equally fluent across both usually backfires. Say which platform you lead on, be excellent there, and speak credibly about the other.

Coding Rounds with Platform APIs

A typical coding prompt looks simple but contains several hidden tests. "Build a screen that fetches users from an API, shows a loading indicator, shows an error with a retry button, and displays the users in a list with avatars."

The tests packed into this prompt include concurrency hygiene, error handling, dependency injection, testability, resource management, and list performance. Candidates who produce a hundred-line view with network calls and state mixed together fail the hygiene test even if the UI renders correctly.

On SwiftUI, a strong solution separates a view model that exposes published state, a repository that owns networking, and a view that binds to the view model. Use @Observable or @MainActor @Observable classes with async methods and explicit loading and error states. Image loading uses AsyncImage with a caching layer if the interviewer pushes for memory awareness. Show that you think about cancellation when the user navigates away.

On Jetpack Compose, the equivalent is a ViewModel with a StateFlow exposing a sealed hierarchy for Loading, Error, and Success states, a collector in the composable using collectAsStateWithLifecycle, and a LazyColumn with stable keys. Coil or Glide handles image loading with a memory cache. Use LaunchedEffect with the right key set to trigger the fetch.

Expect follow-ups. "What if the user rotates the device during a request." "What if the network is flaky." "What if the list has ten thousand items." Have crisp answers: process death survival with saved state, retry with exponential backoff, and virtualization through LazyColumn or SwiftUI's LazyVStack with stable identities and explicit item sizing hints.

Tests matter. Senior candidates write at least one test for the view model or repository during the coding round and mention how they would integration-test the screen with a UI testing framework. If the interviewer does not prompt for tests, offer to add them and explain what you would cover.

UI System Design (Photo and Chat Apps)

UI system design rounds drop you into a prompt with intentionally scary scale. "Design a photo feed that supports millions of users, each with thousands of photos, and must scroll at sixty frames per second on a three-year-old device." The interviewer is testing whether you can make concrete architectural choices under constraints.

Start with the rendering model. On iOS, the display link runs at the device's refresh rate, and each frame must complete rendering and commit within the budget. On a 120 Hz device, that is a little over 8 ms. On Android, the Choreographer runs the same budget. Call out the budget explicitly. It frames the rest of the discussion.

Lay out the memory story. For a photo feed, each full-resolution image can be 20 megabytes or more when decoded. A visible window of six images plus a few off-screen for prefetch can exceed one hundred megabytes quickly. Downsampling to the visible size before decoding is mandatory. Disk cache, memory cache, and an LRU policy that accounts for image dimensions rather than count is the right mental model. Image format matters: prefer HEIC on iOS and WebP or AVIF on Android for better compression at equivalent quality.

Walk through scrolling. Diffable data sources on iOS or DiffUtil-backed list adapters in the view system, or lazy columns with stable keys in Compose and SwiftUI, give the platform the hooks it needs to reuse cells instead of recreating them. Talk about prefetching the next page when the user approaches a threshold and about canceling image loads for cells that have scrolled off.

For a chat application, the interviewer is probing a different set of concerns. Ordering guarantees, optimistic send and reconciliation, typing indicators via ephemeral signals, read receipts, media uploads, message pagination from both ends, and offline composition. Draw the local store as the source of truth, with the network as a synchronization layer. Explain how you would handle clock skew, out-of-order delivery, and retries without message duplication (idempotency keys on the wire, deterministic client-generated IDs in the local store).

For a maps view, the interview centers on clustering, overlay performance, tile caching, and the boundary between the main thread and background work. Vector tiles and level-of-detail rendering are the default for modern maps. Explain how you would keep the main thread free of the work of geometry simplification and label layout.

The common thread across these prompts is that you make the constraints visible, you choose specific data structures, and you walk through the worst-case behavior under pressure. Interviewers score the explicit reasoning, not the final diagram.

Memory, Performance, and Battery

Performance rounds test instrumentation fluency. Know how to open Instruments on iOS or the Android Profiler, identify a hot thread or an allocation spike, and describe the fix.

Startup performance is the single most-tested area because it is user-visible and under platform scrutiny. Know the cold, warm, and hot start distinctions, understand the Android baseline profile and startup tracing APIs, and know how dyld and launch closures affect iOS launch. Name specific levers: defer initialization of SDKs that are not needed at first screen, use Baseline Profiles or AOT compilation, avoid synchronous disk I/O on the main thread during startup.

Frame performance is the second area. Understand why sixteen milliseconds is the traditional budget and eight milliseconds is the new target on high refresh rate devices. Know the typical causes of jank: main thread I/O, layout thrashing, excessive recompositions in Compose, over-redraw in the view system, and synchronous image decoding. Know how to measure. A candidate who says "I'd profile it" without naming the tool and the specific signal loses points.

Battery and thermal are becoming more prominent, especially for roles at companies shipping media-heavy apps or always-on features. Understand the major drains: GPS, wake locks, high-frequency sensor reads, network chatter, and aggressive background work. Know how Doze, App Standby, and the iOS background task budget interact with your app. Interviewers appreciate candidates who can describe a background sync strategy that batches work, respects the scheduler, and uses platform-provided APIs rather than attempting to bypass them.

Memory rounds probe leak detection and retain cycles. On iOS, be able to show how to spot a retain cycle in a closure using Instruments Allocations or the memory graph debugger. On Android, be able to interpret a LeakCanary report and reason about whether a leak is a genuine bug or a platform artifact. Compose-specific questions include recomposition loops caused by unstable parameters and the role of remember with correct keys.

Offline-First Architecture and Sync

Mobile system design rounds almost always include an offline component. Networks drop, users commute through tunnels, and enterprise deployments run on rough wireless. An app that falls apart offline loses users and review scores.

Start from a local store as the source of truth. Core Data or SQLite on iOS, Room on Android. Talk about the schema, the primary keys (client-generated UUIDs with server reconciliation), and the local queue of pending operations. A strong scaffold describes the enqueue, send, acknowledge, and reconcile steps with failure modes at each transition.

Conflict resolution deserves explicit treatment. Last-writer-wins is the default for most consumer apps but is wrong for collaborative editing. Operational transforms and CRDTs are the serious options for collaborative data. Know which category your target product falls into and argue for the right approach with tradeoffs.

Sync protocols matter. Long polling, Server-Sent Events, WebSockets, and MQTT all have a place. For chat apps, a persistent WebSocket with heartbeat and reconnect-with-backoff is standard. For feeds, polling with delta pagination is often fine. For presence, ephemeral signals over a lightweight channel such as MQTT work well. Match the protocol to the freshness SLA.

Background sync is a frequent trap. On Android, WorkManager is the default. On iOS, BGTaskScheduler provides deferrable background tasks but no guarantees about exact timing. Candidates often underestimate how aggressive the OS is about killing or deprioritizing these tasks. Show that you understand the budget and design the critical user-visible freshness to survive without it.

Release, Rollout, and Launch Readiness

Mobile launches are public and irreversible in ways web launches are not. Once a binary ships to the store, it is in the hands of users on schedules the user controls. That shapes the expected rigor around release engineering.

Feature flags are mandatory. Remote configuration services, typed client SDKs, and progressive rollouts with health-based auto-rollback are the baseline. Expect questions about how you would gate a risky feature behind a flag, how you would roll it out to one percent then ten percent then fifty, and what signals would trigger rollback. Crash-free session rate, retention impact, and a handful of custom business metrics are the usual triggers.

Crash reporting pipelines come up frequently. Know the difference between pre-crash tracing, breadcrumbs, symbolicated stack traces, and grouping heuristics. Be able to describe how you would investigate a spike in a specific crash on a specific device model in a specific country. Senior candidates mention the interplay with the store's internal crash metrics and the thresholds the platforms use to demote or warn about unhealthy apps.

A/B testing on mobile has more complexity than web because of the install base's staggered update schedule. An experiment running for two weeks sees wildly different user populations depending on whether it fires on app launch, on first screen, or on deep link handling. Account for the device fleet distribution, OS version distribution, and the long tail of users on old versions.

Store review is a real operational constraint. An urgent fix can take up to a week to reach all users. Teams with high release cadence invest in remote configuration and staged rollouts so they can mitigate issues without waiting for a new build. Expect at least one behavioral question about a time you handled a post-launch issue under store review constraints.

Common Mistakes That Sink Loops

The top mistake is demonstrating weak platform fundamentals in favor of generic system design patter. Mobile loops are not backend loops with a UI twist. If you cannot confidently explain the rendering model and the lifecycle, you will not recover.

The second is ignoring the device fleet. Solutions that work on the latest flagship often break on three-year-old mid-range devices that still make up a majority of the global user base. Mention specific device classes and constraints.

The third is over-indexing on a framework-specific answer. If you are asked about list performance, "use LazyColumn" is incomplete. Explain why LazyColumn helps, what a stable key is, why unstable parameters cause recomposition, and how item size hints affect scrolling smoothness.

The fourth is hand-waving about networking. A modern mobile app has at least request deduplication, retry with backoff, offline queuing, authentication token refresh, and certificate pinning. Describing those layers clearly signals maturity.

The fifth is skipping tests. Mobile code is easy to make hard to test. Candidates who design with testability in mind (interface-driven repositories, injected clocks, abstracted image loaders) separate themselves clearly.

Sample Questions with Answer Scaffolds

Sample one: design the feed for a photo-sharing app. Scaffold: state the frame budget, describe the data flow from paginated API to local store to view, choose the list component with diffable sources or lazy columns with stable keys, describe image loading with a memory plus disk cache, prefetch one page ahead, cancel in-flight loads for off-screen cells, and quantify the memory budget for visible and off-screen items.

Sample two: the app crashes on cold start on some devices. Debug the issue. Scaffold: ask for the crash signature, whether it reproduces on a specific OS version, whether it correlates with a recent deploy, open Instruments or the Android Profiler on a matching device, check for main thread I/O during startup, check for missing baseline profile entries for the hot path, look at dyld or linker errors in the logs, and suggest a staged rollback via remote config while the root cause is isolated.

Sample three: design a chat app with typing indicators, read receipts, and optimistic sends. Scaffold: local store as source of truth, client-generated IDs, optimistic send with pending state, persistent WebSocket with heartbeat, ephemeral typing indicator signals with a debounce, read receipts as a separate channel, pagination from both ends of a conversation, and a reconciliation strategy for messages that arrive after a client has sent optimistic updates.

Sample four: the app's battery drain has doubled in the last release. Debug. Scaffold: compare energy logs between versions, identify new high-frequency operations such as location, Bluetooth, or network, check for wake locks held across backgrounding, inspect any new background task schedules, correlate with a specific screen or feature, and describe the remediation and a remote flag to disable the drain vector immediately if the root cause cannot be shipped in the next build.

Sample five: write a Compose screen that loads a paginated list of items and handles refresh. Scaffold: create a ViewModel exposing a StateFlow<UiState> with Loading, Success, and Error states, use a Paging 3 source for incremental fetch, collect with collectAsStateWithLifecycle, use a LazyColumn with stable keys, show a shimmer during loading and a retry card on error, cancel pending loads when the screen leaves composition, and structure the repository behind an interface for testability.

Sample six: design the authentication flow for a banking app, including biometric unlock and secure storage. Scaffold: OAuth 2.1 with PKCE against the bank's identity provider, refresh token stored in the Keychain or Keystore with a biometric gate, access token in memory only, device binding with attestation, a liveness check for biometric enrollment, and a fallback to PIN on a rate limit that survives app death.

Behavioral Themes Specific to Mobile Teams

Mobile teams see a specific set of recurring tensions. Expect behavioral questions that target them.

One theme is shipping to a store versus shipping continuously. Prepare a story about a time you managed a high-risk launch with staged rollouts and feature flags, explaining your decision criteria for advancing each stage.

Another theme is cross-platform disagreement. At many companies, the iOS and Android teams diverge on implementation details for the same feature. Prepare a story about how you reached alignment without flattening the differences that genuinely matter.

A third theme is device-specific issues. The on-call experience on mobile often involves reproducing bugs on a specific manufacturer's firmware or a specific regional carrier configuration. Prepare a story about investigating such a bug without the device in hand.

A fourth theme is platform policy changes. Apple and Google adjust their policies and APIs on schedules you do not control. Prepare a story about a time you adapted to a breaking policy change, such as new privacy manifest requirements, new background execution rules, or a new storage scope model.

FAQ

Q1: Should I learn SwiftUI and Compose before interviewing?

If you have been shipping UIKit or View-system code, yes. SwiftUI and Compose are now the default expectations for new feature work at most companies. Interviewers expect you to code in these paradigms during the coding round, and falling back to UIKit or XML layouts without a reason signals that you are not current.

Q2: How much cross-platform tooling should I know?

Have a working opinion on Kotlin Multiplatform, Flutter, and React Native. Know when each is the right answer. If the role is explicitly cross-platform, you should be able to implement a small feature in the specific toolchain the team uses and discuss its tradeoffs against native.

Q3: Is networking code worth deep prep?

Yes. Networking bugs are disproportionately common and interviewers know it. Understand URLSession or Ktor plus OkHttp configuration, request deduplication, retry with backoff, certificate pinning, and token refresh races. Be able to name specific failure modes such as thundering-herd refresh.

Q4: How do I prepare for performance rounds if I have not done intense profiling?

Pick a non-trivial open-source app, run Instruments or the Android Profiler on it, and write a short teardown for yourself. Aim for at least one time-based bottleneck, one allocation spike, and one battery or thermal observation. The exercise itself produces stories you can bring into interviews.

Q5: What if I have only shipped on one platform?

Be excellent there and speak credibly about the other. Most hiring managers prefer depth on one platform over thin breadth across both. If the role requires both platforms, say clearly where your secondary platform expertise ends and what you would need to ramp up.

Q6: How important are algorithmic rounds in mobile loops?

They appear but are weighted less than in pure backend loops. Expect at most one algorithm-focused round and many more platform-flavored coding rounds. Do not skip algorithms, but do not over-index on them either.

Conclusion

Mobile engineer loops reward candidates who can hold the full lifecycle of a user's experience in their head, from the first frame after tap through weeks of offline behavior and store review cycles. Practice coding in SwiftUI or Compose with a clean separation of concerns. Build mental models for the rendering pipeline, the memory budget, and the battery profile of your target platforms. Rehearse one complete UI system design prompt end to end until the scaffold is automatic.

Treat every round as a test of your ability to ship software you will be on call for. Candidates who articulate constraints, name specific APIs, and show restraint about over-engineering finish their loops with strong signal and clear offers.