Mobile App Developer Interview Questions 2026 (Android & iOS)

Mobile app developer interview questions are shifting fast in 2026. Interviewers no longer just want to know if you can reverse a linked list — they want to see whether you understand how Android and iOS actually work under the hood: lifecycle, memory, rendering, offline data, and how your app behaves when the network drops or the OS kills your process in the background. Whether you are targeting a native Android role (Kotlin, Jetpack Compose), a native iOS role (Swift, SwiftUI), or a cross-platform role (React Native or Flutter), this guide walks through what interviewers actually test, the typical interview process, 12 realistic sample questions with answer guidance, a prep plan, common mistakes, and an FAQ section.

This guide is deliberately mobile-specific. If you are prepping for a web-facing role instead, see our companion piece on frontend developer interview questions — the concerns there (DOM, browser rendering, CSS) are different from what mobile interviewers probe (app lifecycle, OS memory pressure, app store review, mobile system design).

The mobile hiring landscape in 2026

Mobile hiring has bifurcated. On one side, native Android and native iOS roles at product companies and fintechs increasingly expect Kotlin with Jetpack Compose, or Swift with SwiftUI and structured concurrency (async/await, actors) — UIKit and the View-based Android world are treated as "still important to know" rather than "what we build new features in." On the other side, a large share of startups and mid-size companies hire specifically for cross-platform skills — React Native or Flutter — to ship one codebase across both platforms with a smaller team.

Recruiters are also probing app store operational knowledge more than they used to. Apple's App Store Review Guidelines were updated with stricter requirements around privacy manifests (PrivacyInfo.xcprivacy), declared "Required Reason APIs," and mandatory disclosure of AI-generated content — and Play Store review has similarly tightened around data safety declarations and Play Integrity checks. Interviewers at companies that ship consumer apps want engineers who have actually sat through a rejection and fixed it, not just written code that compiles.

Compensation reflects this specialization. According to Fueler's 2026 mobile developer salary breakdown, iOS developers in India command roughly a 15-25% premium over Android developers at equivalent experience levels, since iOS-qualified talent is scarcer — senior iOS developers with Swift/SwiftUI depth often land ₹18-28 LPA versus ₹15-22 LPA for equally senior Android developers with Kotlin/Compose. Entry-level mobile roles broadly span ₹4-8 LPA, mid-level ₹10-20 LPA, and senior roles ₹25-50+ LPA depending on whether you're at a services shop or a product company (product companies typically pay 40-60% more at the same experience band). Cross-platform skills (Flutter or React Native) are treated as a strong multiplier at smaller companies that can't afford two separate native teams.

What mobile interviewers actually test

Across native and cross-platform roles, mobile interviews consistently probe five things:

1. Platform fundamentals and lifecycle — do you understand activity/fragment lifecycle on Android, or view controller / SwiftUI view lifecycle on iOS, well enough to reason about state restoration, process death, and background execution limits?
2. Memory and performance — can you explain retain cycles, ARC, garbage collection pauses, and how to keep a scroll view or list at 60fps (or 120fps on ProMotion/high-refresh Android displays)?
3. Concurrency — coroutines and Flow on Android, async/await and actors on Swift, or JS-thread vs. native-thread bridging in React Native / the Dart isolate model in Flutter.
4. Data and offline-first architecture — local persistence (Room, Core Data/SwiftData, SQLite, or Realm), conflict resolution, sync strategies, and caching layers.
5. Mobile system design — the ability to design a full feature (chat app, image feed, ride-hailing map) accounting for battery, intermittent connectivity, and payload size — not just a generic backend system design answer.

Interviewers are also increasingly platform-agnostic in how they frame questions even when the codebase is native — for example, asking an Android candidate to reason about how they'd architect offline sync generally, then diving into Room-specific implementation only in the follow-up.

The interview process: what rounds to expect

Most mobile developer interview loops (FAANG-adjacent, high-growth startups, and Indian product companies) follow a similar shape, typically 3-5 rounds over 2-4 weeks:

1. Recruiter screen — role fit, platform preference (Android/iOS/cross-platform), notice period, compensation band.
2. Technical screen (45-60 min) — usually a live coding round in Kotlin, Swift, JavaScript/TypeScript, or Dart, often DSA-style but sometimes framed as a mobile-flavored problem (e.g., "implement a debounced search that cancels in-flight requests").
3. Platform deep-dive round — lifecycle, memory management, concurrency, and framework-specific questions (Jetpack Compose recomposition, SwiftUI view identity, React Native bridge, Flutter widget tree).
4. Mobile system design round — design a feature end-to-end: chat app, photo feed with caching, ride tracking, or an offline-first note-taking app.
5. Behavioral / cross-functional round — how you've handled app store rejections, crash triage, working with design and backend teams, and shipping under battery/network constraints.

Some companies compress rounds 2 and 3 into a single 90-minute session, and some senior+ loops add a "take-home mini project" instead of live coding. If you're also brushing up on general algorithmic interviewing alongside the mobile-specific rounds, our DSA interview roadmap is a useful parallel track.

12 realistic sample questions with answer guidance

1. Walk me through the Android Activity lifecycle and where you'd restore UI state.

Answer guidance: cover onCreate → onStart → onResume → onPause → onStop → onDestroy, and be explicit about the difference between configuration changes (screen rotation) and process death. Good answers mention ViewModel for surviving configuration changes, onSaveInstanceState/SavedStateHandle for surviving process death, and explain why storing large objects in onSaveInstanceState is a bad idea (it's serialized to a Bundle with a size limit).

2. Explain the iOS app lifecycle states and what happens when your app moves to the background.

Answer guidance: describe Not Running → Inactive → Active → Background → Suspended, and discuss the limited background execution time (roughly 30 seconds via beginBackgroundTask, longer via specific background modes like audio, location, or background processing tasks). Mention SceneDelegate vs. the older AppDelegate-only model, and how SwiftUI's scenePhase environment value surfaces these transitions declaratively.

3. What causes a memory leak in Android, and how would you detect one?

Answer guidance: talk about static references to Context/Activity, unregistered listeners, anonymous inner classes capturing an outer Activity, and long-lived coroutine scopes tied to the wrong lifecycle. For detection, mention LeakCanary, Android Studio's Memory Profiler, and heap dump analysis.

4. How does ARC work in iOS, and how do you avoid retain cycles?

Answer guidance: explain that ARC inserts retain/release calls at compile time based on strong/weak/unowned reference counting. Retain cycles commonly happen with closures capturing self strongly (fixed with [weak self] or [unowned self]) and delegate patterns (fixed by declaring delegate properties as weak). A senior-level answer also distinguishes weak (optional, becomes nil) from unowned (non-optional, crashes if accessed after deallocation).

5. What triggers recomposition in Jetpack Compose, and how do you avoid unnecessary recompositions?

Answer guidance: recomposition is triggered when a State object read inside a composable changes. Discuss stability (stable vs. unstable types), remember, derivedStateOf for computed values that shouldn't trigger recomposition on every frame, and using key() in lists. Mention that lambdas and unstable collection types (like plain List in some configurations) can cause avoidable recompositions.

6. SwiftUI vs. UIKit — when would you still reach for UIKit in a 2026 codebase?

Answer guidance: SwiftUI has matured a lot, but strong answers mention that complex custom gesture handling, tight pixel-level control (custom UICollectionViewCompositionalLayout), and large legacy codebases still lean on UIKit, and that UIViewRepresentable/UIViewControllerRepresentable are the standard bridges when you need to mix both in one app.

7. How do coroutines and Flow differ from RxJava, and when would you choose Flow's StateFlow vs. SharedFlow?

Answer guidance: coroutines are Kotlin's structured-concurrency primitive; Flow is the cold, coroutine-native reactive stream. StateFlow always holds a current value (good for UI state) while SharedFlow doesn't require an initial value and supports one-off events. Structured concurrency (scopes tied to lifecycle, e.g. viewModelScope) is the key differentiator interviewers want you to articulate versus manually managed RxJava subscriptions.

8. How does the React Native bridge (or the newer JSI/Fabric architecture) affect performance, and how would you debug a janky list?

Answer guidance: explain that the classic bridge serializes messages between the JS thread and native thread asynchronously, which can bottleneck under heavy traffic, while the New Architecture (JSI + Fabric + TurboModules) allows more direct, synchronous JS-to-native calls. For a janky FlatList, discuss getItemLayout, windowing props, avoiding anonymous functions in renderItem, and moving heavy computation off the JS thread.

9. In Flutter, how does the widget/element/render object tree work, and why does const matter for performance?

Answer guidance: widgets are immutable configuration; elements are the persistent tree that manages widget lifecycle; render objects handle layout and painting. const constructors let Flutter skip rebuilding a widget subtree entirely when nothing has changed, which is a cheap, high-impact performance habit interviewers like to see candidates apply by default.

10. Design an offline-first note-taking app that syncs across devices.

Answer guidance: this is a mobile system design question. Structure your answer around: (a) local-first writes to Room/Core Data/SQLite as the source of truth for the UI, (b) a sync engine that queues mutations (create/update/delete) with timestamps or vector clocks, (c) conflict resolution strategy (last-write-wins vs. operational transforms/CRDTs depending on how collaborative the app needs to be), (d) background sync via WorkManager (Android) or BGTaskScheduler (iOS), and (e) handling partial connectivity gracefully in the UI (optimistic updates, sync status indicators).

11. Design the image loading and caching layer for a photo feed app (like Instagram or Google Photos).

Answer guidance: cover the three-tier cache — in-memory (LRU cache keyed by URL + size variant), on-disk cache with eviction policy, and network fetch with request de-duplication so the same image isn't fetched twice concurrently. Mention real libraries as reference points: Glide/Coil on Android, SDWebImage/Kingfisher on iOS. Discuss downsampling images to the target ImageView/UIImageView size before caching to avoid holding full-resolution bitmaps in memory, and prefetching for smooth scrolling.

12. Design a mobile chat application that supports text, images, and delivery/read receipts.

Answer guidance: talk through the client architecture: a persistent connection (WebSocket) or push-based fallback for real-time delivery, local message store as the source of truth so the UI works offline, an outbox pattern for messages sent while offline (queued and retried), pagination/cursor-based history loading, and separate handling for media (upload to object storage, send a reference + thumbnail rather than the full file inline). Bonus points for discussing multi-device sync and how read receipts are batched to avoid a receipt-per-keystroke network storm.

A 6-8 week mobile interview prep plan

Weeks 1-2 — Language and fundamentals. Nail Kotlin (null safety, data classes, sealed classes, coroutines) or Swift (optionals, value vs. reference types, ARC, async/await) depending on your target platform. If cross-platform, get comfortable with both JavaScript/TypeScript idioms in React Native and Dart's async model in Flutter.

Weeks 3-4 — Framework depth and lifecycle. Go deep on Jetpack Compose or SwiftUI (or both, if you're cross-platform-adjacent). Rebuild a small app from scratch focusing on state management, navigation, and lifecycle-aware data loading.

Week 5 — Offline-first and persistence. Implement a small offline-first feature end-to-end: local database, background sync, conflict handling. This single project will let you answer at least three of the sample questions above with real, specific detail instead of textbook answers.

Week 6 — Mobile system design. Practice the chat app, image caching, and offline-sync design questions out loud, on a whiteboard or with a peer. Time yourself — most system design rounds are 45 minutes.

Weeks 7-8 (if you have them) — Mock interviews and app store readiness. Do timed mocks, and if you have a side project, actually attempt to publish it to TestFlight or an internal Play Store track so you've lived through the review checklist at least once.

Tools like ClavePrep's AI mock interview practice can help you rehearse the platform deep-dive and system design rounds with realistic follow-up questions, and the STAR builder is useful for turning your "handled an app store rejection" or "fixed a production crash" stories into tight behavioral answers.

App store review and publishing: what you should be able to speak to

Even mid-level candidates are increasingly asked whether they've shipped an app through review, because it signals real production experience beyond a tutorial project. Be ready to discuss:

• iOS: Apple's App Store Review Guidelines require a PrivacyInfo.xcprivacy manifest declaring "Required Reason APIs" your app touches, and explicit disclosure if your app displays AI-generated content — both are common 2025-2026 rejection reasons according to developers publishing through the process (see Cynoteck's 2026 App Store publishing guide).
• Android: Play Console's Data Safety section, target API level requirements that Google raises annually, and Play Integrity API checks for anti-abuse.
• Cross-platform specifics: Flutter and React Native apps still go through the same native review pipelines, so bundle ID mismatches, missing Info.plist entries, and CocoaPods/SwiftPM signing conflicts are common last-mile blockers — being able to describe a rejection you fixed is worth more than reciting the checklist.

Mobile system design: how to structure your answer

Whatever the prompt (chat app, image feed, ride tracking, offline notes), structure your response the same way every time so you don't freeze under pressure:

1. Clarify scope — Is this a 1:1 chat or group chat? Do images/video need to be supported? What's the target scale (thousands vs. millions of users)?
2. Client architecture — local data store, state management layer, networking layer.
3. Data flow — what's cached locally, what's fetched fresh, how conflicts are resolved.
4. Offline behavior — what still works with no network, and what's queued.
5. Performance and battery — batching network calls, avoiding wake locks, image downsampling, list virtualization.
6. Edge cases — process death mid-upload, clock skew for message ordering, low-storage devices.

Interviewers are typically less interested in a "correct" architecture diagram and more interested in whether you proactively raise the mobile-specific constraints (battery, intermittent connectivity, storage limits) that a backend-only system design answer would never mention.

Common mistakes candidates make

• Answering lifecycle questions abstractly instead of concretely. Saying "onPause is called when the activity loses focus" without discussing what you'd actually persist there is a weak answer. Tie every lifecycle answer to a real scenario (rotation, incoming call, backgrounding).
• Treating mobile system design like backend system design. If you don't mention battery, offline behavior, or payload size at all, interviewers will assume you haven't shipped a real mobile app at scale.
• Not knowing the difference between what changed and what's still relevant. SwiftUI and Jetpack Compose are the future, but plenty of production codebases are UIKit/View-based — dismissing the older frameworks as irrelevant reads as inexperience, not modernity.
• Skipping app store/publishing knowledge entirely. Even for engineering-only roles, "have you shipped through review" is a strong signal question, and a blank stare here costs more than it should.
• Under-preparing the cross-platform-specific bridge/rendering questions. If you're interviewing for React Native or Flutter roles, know how your framework actually talks to native code (JSI/Fabric, or the Dart-to-native platform channel) — "it just works" isn't a real answer.
• Ignoring concurrency depth. Coroutines/Flow and Swift's async/await/actors are consistently under-prepared relative to how often they come up; treat them as core material, not an advanced elective.

Frequently asked questions

Do I need to know both Android and iOS to get a mobile developer job?

No. Most native roles hire specifically for one platform. Cross-platform roles (React Native, Flutter) are the main path where knowing "both" in a meaningful sense (JS/Dart plus enough native awareness to debug platform-specific issues) is expected.

Is Kotlin Multiplatform or Flutter a better cross-platform bet for interviews in 2026?

Both show up in job postings, but Flutter has broader adoption and a larger interview-question corpus at this point, while Kotlin Multiplatform is growing fastest among companies with an existing Android-heavy engineering culture. Prepare based on the specific job description rather than a general market bet.

How technical is the mobile system design round for a mid-level (2-4 years experience) candidate?

Expect a scaled-down version — one clear feature (not "design Instagram" broadly) with more emphasis on client-side architecture and less on distributed backend infrastructure. Interviewers calibrate depth expectations to your level.

Will I be asked LeetCode-style DSA questions in a mobile interview?

Often yes, especially at larger companies, though the framing may lean mobile (e.g., "implement a debounced search" or "an LRU cache for image thumbnails") rather than pure abstract algorithm prompts.

What's the single highest-leverage thing to prepare if I only have one week?

Rebuild the offline-first project (Q10's sample answer) end-to-end in your target platform. It touches persistence, sync, conflict resolution, and background work — the four areas most consistently tested — and gives you specific, real answers instead of memorized theory for a large share of the interview.

Do interviewers expect me to have published an app to the App Store or Play Store?

It's not a hard requirement, but it's a strong positive signal. If you haven't, consider pushing a small side project through a TestFlight beta or an internal Play Store testing track before your interview cycle — living through one review cycle gives you real answers to publishing questions.

How is a cross-platform (React Native/Flutter) interview different from a native one?

Expect more questions about bridging to native modules, handling platform-specific UI differences, and performance tuning around the JS thread (React Native) or widget rebuild costs (Flutter), in addition to the same lifecycle/offline/system-design fundamentals native candidates face.

What should I say if I don't know the answer to a deep platform-internals question?

Be honest about the gap, then reason out loud from what you do know (e.g., "I haven't dug into how Compose's snapshot system detects state reads, but I know it's tracking reads during composition to know what to invalidate — let me reason through what that implies"). Interviewers weigh reasoning process heavily in mobile-depth questions.

Put this into practice

Reading sample questions only gets you so far — the gap that actually shows up in interviews is answering under time pressure with a real interviewer (or interviewer-like AI) pushing back with follow-ups. ClavePrep's AI-powered mock interview tool lets you rehearse Android, iOS, and cross-platform mobile rounds — including system design follow-ups — with instant feedback, and the ATS resume checker can help make sure your resume actually surfaces the mobile-specific keywords (Kotlin, Swift, Jetpack Compose, SwiftUI, offline-first, React Native, Flutter) that recruiters and applicant tracking systems are scanning for before you even get to the interview stage. Learn more about how ClavePrep's practice loop works on our how it works page.