Mobile Developer Interview Questions (2026) and How to Answer
By FindAJobAI team Updated How we wrote this page
Mobile interviews start from the platform: Swift with SwiftUI or UIKit for iOS, Kotlin with Jetpack Compose for Android, or React Native or Flutter for cross-platform roles. Expect a coding exercise, an app architecture discussion and questions about releases and store review.
Interviewers check that you understand what makes mobile different: limited memory and battery, unreliable networks, offline use, and releases you can't instantly roll back.
Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.
Answering with STAR
Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.
Behavioural questions (1–10)
How you've handled real situations. Answer each with one true story, in STAR order.
1.Tell me about an app you shipped to the App Store or Google Play.
What they're really asking: Real release experience: store review, crashes and user feedback.
Answer outline (STAR)
- SituationThe app or major feature, its users and your role.
- TaskGet it into the store and keep it stable.
- ActionTesting, a beta through TestFlight or an internal track, a staged rollout, crash monitoring.
- ResultRatings, crash-free sessions or adoption after launch.
Full sample answer (fictional example)
I shipped a rebuilt checkout for a food delivery app on both stores, with a goal of keeping crash-free sessions above 99.5 percent. I tested with an internal beta, then TestFlight and Google Play's closed track with 300 users, and watched crashes in Crashlytics. We released with a staged rollout at 5, 25 and 100 percent over four days. The rollout paused once, at 25 percent, when a layout bug showed on small phones; we fixed it in a day. Orders per session rose 8 percent, and crash-free sessions stayed at 99.7 percent.
2.Tell me about a crash you tracked down in production.
What they're really asking: Can you debug without a debugger attached, from crash reports, logs and device quirks?
Answer outline (STAR)
- SituationA crash in Crashlytics or Sentry, limited to some devices or OS versions.
- TaskFix it fast, because users only get the fix when they update.
- ActionRead the symbolicated stack trace, reproduce on the affected OS, fix it and add a test.
- ResultThe crash rate before and after, and a guard against similar bugs.
Full sample answer (fictional example)
Crashlytics showed a spike on Android 12 phones from one manufacturer, around 2 percent of sessions. The stack trace pointed to a camera permission callback arriving after the screen had been destroyed. I reproduced it by rotating the phone while the permission dialog was open, on a device from that maker. I fixed it by checking the lifecycle state before touching the view and moving the logic into a ViewModel. The next release cleared the issue, and I added a test and a line in our review checklist.
3.Describe a time you improved app performance.
What they're really asking: Do you measure startup time, frame rate and memory instead of going by feel?
Answer outline (STAR)
- SituationA slow cold start, janky scrolling or high memory use.
- TaskMake it measurably smoother.
- ActionProfile with Instruments or Android Studio, then move work off the main thread and fix image loading.
- ResultStartup time or dropped frames, before and after.
Full sample answer (fictional example)
Cold start on our oldest supported Android phone took 5.5 seconds. I profiled with Android Studio and saw we initialised six SDKs and loaded a large config file on the main thread. I moved the config load to a background thread, deferred four SDKs until after the first screen, and added a baseline profile. Cold start fell to 2.4 seconds on that phone. I added a startup check against a reference device to CI, and a rule that any new SDK needs a measured startup cost before it is merged.
4.Tell me about agreeing an API with the backend team for your app.
What they're really asking: Mobile apps live with old versions in the wild; do you design for that?
Answer outline (STAR)
- SituationA new feature that needed API changes.
- TaskGet an API that works within mobile constraints.
- ActionAsk for pagination, small payloads, versioning and compatibility with older app versions.
- ResultThe API shipped, and older versions kept working.
5.Tell me about deciding whether to drop support for an old OS version.
What they're really asking: Pragmatism: users on one side, engineering cost on the other.
Answer outline (STAR)
- SituationA share of users on an older iOS or Android version.
- TaskDecide whether to keep supporting them.
- ActionCheck the usage data, estimate the cost, and propose a cutoff with product.
- ResultThe decision, and how it was communicated to those users.
6.Tell me about a design that didn't fit iOS or Android conventions.
What they're really asking: Do you respect the platform users already know?
Answer outline (STAR)
- SituationA custom navigation or control that felt wrong on one platform.
- TaskKeep the brand while following platform habits.
- ActionShow the standard pattern beside it, test with a few users, propose a hybrid.
- ResultThe adjusted design, and the feedback afterwards.
7.Tell me about a wave of one-star reviews and what you did.
What they're really asking: Do you read reviews as bug reports and answer professionally?
Answer outline (STAR)
- SituationA release after which ratings fell and reviews named a bug.
- TaskFind the cause and win users back.
- ActionMatch reviews to crash and device data, fix fast, reply, ask for updated ratings.
- ResultThe rating recovery, and the process you changed.
8.Tell me about a third-party SDK that caused problems.
What they're really asking: Do you vet dependencies you don't control?
Answer outline (STAR)
- SituationAn analytics, ads or payments SDK that crashed the app or slowed launch.
- TaskKeep the feature without hurting stability.
- ActionWrap it, measure its cost, update it, delay its start-up or replace it.
- ResultCrash and launch numbers afterwards, and your rule for new SDKs.
Full sample answer (fictional example)
A new advertising SDK caused a 1.2 percent crash rate and slowed launch by 400 milliseconds. Marketing wanted it for a campaign. I wrapped it behind our own interface so it could be removed, delayed its start-up until after the first screen, and updated to the vendor's latest version, which fixed one crash. Crashes fell below 0.2 percent. I also wrote a short rule: new SDKs need a startup and size measurement, a privacy review and an owner, and the interface lets us swap vendors without touching screens.
9.Tell me about reducing battery drain or app size.
What they're really asking: Do you care about resources users can't see directly?
Answer outline (STAR)
- SituationA report of battery drain, or a download size hurting installs.
- TaskCut the cost without losing features.
- ActionProfile energy use or the build, fix polling, compress assets, drop dead code.
- ResultThe measured change, and the budget you set.
10.Tell me about learning the other mobile platform.
What they're really asking: Can you adapt, and respect how the platforms differ?
Answer outline (STAR)
- SituationA project needing Android after years of iOS, or the reverse.
- TaskBecome productive without carrying over wrong habits.
- ActionStudy the platform guidelines, pair with a native colleague, rebuild a small feature.
- ResultWhat shipped, and the habits you had to unlearn.
Technical and role-skill questions (11–22)
Can you do the work itself? Think out loud and name the trade-offs.
11.Explain the lifecycle of a screen on your platform.
What they're really asking: Fundamentals behind real bugs: rotation, backgrounding and process death.
Answer outline
- On iOS, the view controller or SwiftUI view lifecycle and scene phases; on Android, the activity and fragment lifecycle, with a ViewModel surviving configuration changes.
- Save and restore state when the app is backgrounded or killed.
- Cancel work tied to a screen when it goes away, to avoid leaks.
Full sample answer (fictional example)
On iOS with UIKit a view controller loads, appears, disappears and is deallocated; with SwiftUI the view appears and disappears, and scene phases tell me when the app goes to the background. On Android an activity is created, started, resumed, paused, stopped and destroyed, and a ViewModel survives rotation. The practical point is that the system can destroy my screen, or the whole process, at any time. So I save state, cancel work tied to the screen, and never hold views in long-lived objects.
12.Which architecture do you use in your apps, and why?
What they're really asking: Can you structure an app so it stays testable as it grows?
Answer outline
- Name it (MVVM, MVI, the Composable Architecture, Clean Architecture) and why it fits the app.
- Separate the UI, state and data layers so the logic can be unit tested.
- Admit the trade-off: more structure means more boilerplate in a small app.
13.How do you make an app work offline?
What they're really asking: Data sync is one of the hardest problems in mobile.
Answer outline
- Store data locally (Core Data, SwiftData, Room or SQLite) as the source of truth for the UI.
- Queue writes and sync when back online, with a conflict rule such as last write wins or a merge.
- Show the user what's pending or out of date.
Full sample answer (fictional example)
I'd make the local database the source of truth for the UI: Core Data or SwiftData on iOS, Room on Android. The screen reads from the database, and a repository syncs with the server in the background. Writes go into a queue with a status, such as pending or failed, and are sent when the connection returns, with retries. I'd decide a conflict rule up front: last write wins for simple fields, or a merge for lists. And I'd show the user what is pending or out of date, so offline never looks like a bug.
14.How do you handle concurrency in a mobile app?
What they're really asking: Keeping the main thread free without creating race conditions.
Answer outline
- Never block the main thread with network, disk or heavy work.
- On iOS use async/await and actors; on Android, Kotlin coroutines with the right dispatchers.
- Tie work to the screen's lifecycle and avoid shared mutable state.
15.How do you test a mobile app?
What they're really asking: Do you test at the right levels on a platform where UI tests are slow?
Answer outline
- Unit tests for view models and business logic.
- A few UI tests (XCUITest, Espresso, or Detox for React Native) for the key flows.
- Device coverage from a cloud device farm or a small set of real phones.
16.How do you release safely when you can't roll back an app update?
What they're really asking: Do you plan for mistakes you can't instantly undo?
Answer outline
- Phased or staged rollouts, watching crashes and errors per version.
- Feature flags or remote config to switch a feature off without a new release.
- A minimum-version prompt for critical fixes.
Full sample answer (fictional example)
Because I can't roll back a binary, I put the safety elsewhere. I use staged rollouts, 1 percent then 10 and so on, and watch crashes and error rates per version before widening. New features sit behind remote config or feature flags, so I can switch one off without a release. I keep a minimum-version mechanism that can force an update for a critical bug, and a hotfix path with an expedited review. Before release I test upgrade paths from the previous two versions, not just fresh installs.
17.Native, React Native or Flutter: how would you choose for a new app?
What they're really asking: Do you understand the trade-offs beyond personal preference?
Answer outline
- Native gives the best performance and platform features, with two codebases.
- Cross-platform gives one codebase and faster delivery, but device features still need native work.
- Decide by the team's skills, performance needs and how platform-specific the UI must be.
18.How do you manage memory and avoid leaks in a mobile app?
What they're really asking: Memory limits get apps killed, so do you know where leaks come from?
Answer outline
- Know your model: ARC on iOS, garbage collection on Android, and the cycles each allows.
- Common leaks: retain cycles in closures, listeners never removed, large cached images.
- Find them with Instruments or the Android profiler by revisiting a screen repeatedly.
19.How do you store sensitive data on a device?
What they're really asking: Mobile security basics: what lives on a lost or rooted phone.
Answer outline
- Use the Keychain or Keystore for tokens and keys, never plain preferences or files.
- Use HTTPS everywhere, and consider certificate pinning for high-risk apps.
- Store as little as possible, clear it on logout and never log secrets.
20.How do push notifications work, end to end?
What they're really asking: A feature spanning your server, the platform vendors and the device.
Answer outline
- The app registers with APNs or Firebase and sends the device token to your backend.
- Your server messages the vendor's service, which delivers to the device.
- Handle permission prompts, opt-outs, expired tokens and deep links to the right screen.
21.How would you build a long, image-heavy feed that scrolls smoothly?
What they're really asking: A classic mobile design problem testing rendering and memory.
Answer outline
- Use a recycling list (RecyclerView, UICollectionView, LazyColumn) and paginate.
- Load images at display size, cache on disk and in memory, cancel off-screen loads.
- Keep cell work light and verify the frame rate on a low-end device.
22.How would you design login and token refresh in a mobile app?
What they're really asking: Do you handle expiry, concurrency and security in a real flow?
Answer outline
- Short-lived access tokens, with a refresh token held in the Keychain or Keystore.
- Refresh once when a request returns 401, and queue other requests meanwhile.
- Log out cleanly when refresh fails, and support remote revocation.
Take-home or live exercise: tips
Mobile interviews often include a take-home app, such as a list-and-detail screen with a network call, or a live exercise in Xcode or Android Studio.
- Handle loading, error and empty states, and rotate or background the app to check it survives.
- Keep the architecture simple but separated into UI, state and data, so logic is testable.
- Add a couple of unit tests, and note what you'd do for offline use and accessibility.
Skills employers test for
Technical rounds follow the job ad. These skills are named most often in the 402 newest mobile developer job ads we analysed (out of 1,289 live postings), shown as the share of ads that mention each. Expect questions on the top few.
- 1Android76%
- 2Kotlin57%
- 3iOS54%
- 4CI/CD39%
- 5Swift39%
- 6Code review33%
- 7Unit testing30%
- 8REST APIs30%
Full list: Mobile Developer resume keywords.
From live job ads · computed November 2, 2026 · refreshed daily
Situational questions (23–30)
Scenarios that test judgement: say what you'd do first, and why.
23.Crash reports spike right after a release. What do you do?
What they're really asking: Incident response when you can't roll back the binary.
Answer outline
- Halt the phased rollout and check which versions and devices are affected.
- Switch the feature off with remote config if you can.
- Ship a hotfix with an expedited review if needed, and tell support what to say.
Full sample answer (fictional example)
First I'd halt the staged rollout so no more users get the build. Then I'd look at which versions and devices are affected, and read the top crash stack. If the crashing feature is behind a flag or remote config, I'd switch it off, which fixes it for users already on the new version. Otherwise I'd ship a hotfix and request an expedited review. Meanwhile I'd tell support what to say to users, and afterwards run a short review on why the crash got through testing.
24.Apple rejects your update the day before a launch. How do you handle it?
What they're really asking: Calm handling of store review, a fact of mobile life.
Answer outline
- Read the guideline cited, then fix the issue or reply to the reviewer if it's a misunderstanding.
- Request an expedited review for a time-critical fix.
- Tell stakeholders early, and keep the launch flag off until the build is live.
Full sample answer (fictional example)
I'd read the rejection reason carefully and find the guideline it cites. If it's a real issue, I'd fix it and resubmit with a note explaining the change. If it's a misunderstanding, I'd reply in App Review with a precise answer and a screen recording. For a time-critical case I'd request an expedited review. At the same time I'd tell stakeholders early that the date is at risk, and keep server-side features switched off by flag until the build is actually live.
25.Product wants a feature on iOS and Android at once, but you only have iOS developers. What do you propose?
What they're really asking: Will you give an honest plan instead of an impossible promise?
Answer outline
- Lay out options: stagger the launch, bring in help, or reduce scope on one platform.
- Consider sharing logic for future features, for example with Kotlin Multiplatform.
- Agree a plan with dates rather than promise both.
26.Users on older phones say the app is slow. How do you investigate?
What they're really asking: Performance work across a wide range of devices.
Answer outline
- Get a low-end test device and profile startup and scrolling on it.
- Check memory, image sizes and the work done at launch.
- Set performance budgets and track them for every release.
27.A user says your app drains their battery. How do you investigate?
What they're really asking: Can you diagnose a problem you can't see?
Answer outline
- Ask for the device, OS and usage pattern, and profile background activity.
- Look for polling, location updates, wake locks or repeated network retries.
- Fix the cause, then check energy impact in the next beta.
28.The backend ships an API change that breaks app versions already in the store. What now?
What they're really asking: Do you contain damage when old versions can't be recalled?
Answer outline
- Ask the backend team to restore compatibility first; old binaries can't be recalled.
- Check analytics for the affected versions, and prepare a fix release.
- Add a minimum-version check and an API compatibility rule so it can't recur.
Full sample answer (fictional example)
I can't recall old binaries, so first I'd ask the backend team to restore compatibility, even temporarily, by re-enabling the old response shape. Then I'd check analytics to see which app versions are affected and how many users that is. If a fix release is needed, I'd ship one with an expedited review. For the long term I'd propose an API compatibility rule: no breaking change without a new version, plus a minimum-version check in the app that can show an update prompt.
29.Product wants an analytics SDK that tracks users across apps. How do you respond?
What they're really asking: Do you weigh privacy and store rules against a business request?
Answer outline
- Check what data it collects and whether it needs consent and a privacy label.
- Review the store's policies, since a violation can get the app pulled.
- Offer alternatives, such as first-party events, and document the decision.
30.A new OS beta breaks a feature in your app. What do you do?
What they're really asking: Do you test ahead of platform releases?
Answer outline
- Reproduce on the beta, identify the changed API or behaviour, and read the notes.
- Fix it behind a version check so older systems keep working.
- Ship before the public OS release, and add the beta to your test routine.
Red flags to avoid in your answers
Each one is quick to fix before the day.
Describing apps without mentioning crashes, reviews or releases.
Share a real release: the rollout, the monitoring and what you did when something went wrong.
Ignoring older devices and slow networks.
Say how you test on low-end phones and poor connections.
Choosing native or cross-platform by preference alone.
Compare team skills, performance needs and how platform-specific the UI must be.
Treating store review as an afterthought.
Show you know the guidelines and plan release dates with review time included.
How to prepare for a mobile developer interview in 7 days
An hour or two a day is enough; the order matters more than the length.
Day 1: Use their app
Note the platform, language and architecture in the ad, then install the company's app and note two improvements.
Day 2: Platform core
Revise lifecycle, memory and concurrency for your platform, explaining each aloud in two minutes.
Day 3: Build a screen
Build a list-and-detail app with a network call in two hours, with loading, error and empty states.
Day 4: Offline and security
Sketch the offline sync and token refresh flows, and list where sensitive data may be stored.
Day 5: Release stories
Write STAR stories on a release, a crash and a performance fix, with numbers before and after.
Day 6: Timed mock
Do a timed mock with a friend: one design question, one coding task, three behavioural questions.
Day 7: Device demo, then rest
Prepare to show an app on a real device, write three questions about release cadence, and rest.
Questions to ask the interviewer
Pick two or three; the answers tell you whether you want the job.
- What share of your users are on iOS and Android, and which OS versions do you support?
- How often do you release, and do you use phased rollouts?
- Are the apps native, cross-platform or a mix, and is that changing?
- What's the crash-free rate today, and who watches it?
- How does the mobile team work with backend and design?
Preparation tips
- Have an app in a store that you can show, even a small one; it proves you've been through review.
- Revise your platform's lifecycle, memory management and concurrency model in detail.
- Prepare the story of a production crash and how you fixed it.
- Use the company's app before the interview, and note one thing you'd improve and how.
Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.
How we wrote this page
The FindAJobAI team wrote the questions, outlines and sample answers for mobile developer interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.
The live skills section is based on 402 mobile developer job ads analysed, the newest we track, with the same deterministic skill matcher as our in-demand skills report: no AI model reads the postings. It was last computed on November 2, 2026 and refreshes daily.
Last reviewed on November 1, 2026.