Mobile developer interview questions, with worked answers

How to use these questions

Say each short answer out loud, then tie it to an app you worked on: the screen, the problem, the figure that moved. Interviewers for app roles like to open your own app on a phone and ask about it, so know its weak spots before they find them.

What a mobile developer is expected to know

• The platform: SwiftThe language of modern iOS: value types, async and await, and SwiftUI or UIKit for the screens. and SwiftUI on iOS, KotlinThe language of modern Android: coroutines for background work, null safety, and Jetpack Compose for the screens. and Jetpack Compose on Android, or a cross-platform tool such as Flutter or React NativeReact Native builds iOS and Android apps from one JavaScript or TypeScript code base; know where it needs native code., with Xcode and Android Studio as daily tools.
• The app's life: what the system does when the user leaves, comes back or runs out of memory, and how state survives it.
• Data and network: REST APIsCall the backend well: timeouts, retries, paging, caching and errors a person can understand. or GraphQLSome backends offer it: queries for exactly the fields a screen needs, and a cache on the device., caching, offline storage and sync, and errors a user can act on.
• Quality: unit testsTests for view models, parsing and business logic that run in seconds on every change., UI tests on devices, crash reporting, performance and battery use.
• Shipping: the build pipelineEvery change built, tested and signed by the pipeline; store uploads and test builds without manual steps., signing, the two stores' review rules, staged releases and feature flags.

Platforms and the app lifecycle

Native or cross-platform: how would you choose between Swift and Kotlin apps and one code base in Flutter or React Native?

What they check: that you weigh the product's needs and the team, and do not argue from taste.

Short answer: "Native means one app per platform in the platform's own language and tools; cross-platform means one shared code base that runs on both. I ask what the app must do with the phone, such as camera, sensors, background work or widgets, how much the two apps differ, and who is on the team. Heavy device features and a platform look favour native; a mostly forms-and-lists app with a small team favours a shared code base."

The full answer: Both paths ship good apps. Native gives the newest platform features on day one and the most direct debugging, at the cost of building features twice. Flutter draws its own screens and behaves the same on both platforms; React Native uses the platform's own screen parts and suits teams that already write TypeScriptThe usual language of React Native teams; typed props, state and API calls keep a shared code base safe.. Either way some native code remains for payments, notifications or hardware, so a cross-platform team still needs someone who knows each platform. Many companies also share only the business logic, for example with Kotlin Multiplatform, and keep native screens.

A weak answer: "Cross-platform is always cheaper." Follow-up: "Our app records video and uploads it in the background." Name the platform features involved and where native code would be needed in each approach.

The user switches to another app in the middle of a form. What happens to your app, and how do you handle the lifecycle on iOS and Android?

What they check: that you know the system, not your app, decides when it runs.

Short answer: "The app moves to the background and may be stopped at any time to free memory, without warning. So I save what the user typed as it changes or when the app leaves the foreground, restore it when the screen comes back, and never rely on a background task finishing unless I asked the system for that time."

The full answer: Both platforms move apps through states such as active, in the background and stopped, and both send events at each change. On Android, a screen is also rebuilt when the phone rotates or the language changes, so state belongs in a view model or saved state, not in the screen. Long work goes to the system's own schedulers, which respect battery and data limits. Test it on purpose: turn on the developer setting that stops background apps, rotate, switch language, and see what survives.

A weak answer: "The app keeps running in the background, so the form is still there." Follow-up: "A user returns after an hour and the app opens on the home screen." Explain the stopped process and how saved state and deep links bring the user back.

Architecture, state and offline work

How do you structure an app's architecture and its state so that a team can keep changing it?

What they check: clear layers, one source of truth, and code others can test.

Short answer: "I keep three layers: screens that only draw state, view models that hold the screen's state and react to the user, and a data layer that talks to the network and the database. State flows one way, from the data to the screen, and every screen has one source of truth. Features live in their own modules so teams do not collide."

The full answer: Declarative screens, SwiftUI and Jetpack Compose, redraw from state, so the question is where state lives and who may change it. Patterns such as MVVM or unidirectional data flow give the answer a name; the name matters less than being consistent. Dependency injection makes the data layer replaceable in tests. In a large app, modules per feature speed up builds and let teams own their part, with a small shared core for design and networking.

A weak answer: "I put the logic in the screen, it is faster to write." Follow-up: "Two screens show the same basket and disagree." Move the basket to one shared source and let both screens observe it.

The app must work offline on a train and catch up later. How do you design offline storage and sync?

What they check: that you plan for conflicts and failure, not only the happy path.

Short answer: "The app reads from a local database first and shows that data at once. Changes the user makes are saved locally and queued; when the network returns, the queue is sent in order, with retries. I decide with the backend team what happens on a conflict, and I show the user what is waiting to sync."

The full answer: Offline first means the local database is the truth for the screen, and the network refreshes it. Each change needs an id so a retry does not create it twice. Conflicts need a rule: the last write wins, the server wins, or the user chooses; pick it per kind of data. The platforms' background schedulers can run the sync when the phone has a connection and enough battery. Test with the network off, flaky and slow, not just on office wifi.

A weak answer: "We show an error when there is no connection." Follow-up: "Two technicians edit the same job offline." Explain the conflict rule you would agree and how the app tells them.

Performance, crashes and testing

Users say the app is slow, hot and drains the battery. How do you find and fix the performance problem?

What they check: that you measure with the platform's profilers before you change code.

Short answer: "I reproduce it on a mid-range phone, not my own, and profile it: Instruments in Xcode, the profilers in Android Studio. I look at the main thread for slow work, at memory for leaks and large images, at the network for repeated calls, and at the battery for location or background work that never stops. Then I fix the largest cause and measure again."

The full answer: Start time, smooth scrolling and battery are what users feel. Keep disk, network and image decoding off the main thread; load images at the size they are shown; reuse list cells; batch network calls; and stop location updates and timers when the screen goes away. Memory leaks often come from screens that are never released. Track start time and slow frames in production too, because test phones are rarely the phones users have.

A weak answer: "It runs fine on my phone." Follow-up: "The app starts in four seconds on older Android phones." Show how you would measure the start, delay work that is not needed for the first screen, and check the result.

How do you track crashes, and what crash-free rate do you aim for?

What they check: that you treat stability as a number the team owns.

Short answer: "A crash reporting tool collects every crash with its stack trace, device and app version, grouped by cause. The crash-free rate is the share of sessions or users without a crash; most teams aim very close to all of them, and I watch it for every new version. I fix the groups that hit most users first."

The full answer: Upload the symbol files with each build so crashes read as function names, not addresses. Both platforms also report app-not-responding cases and out-of-memory stops, which count as failures to the user even without a crash. A rising crash rate after a release is a reason to stop a phased release. Write a test for each crash you fix, so it cannot come back unnoticed.

A weak answer: "We look at the reviews in the store." Follow-up: "A crash happens only on one phone model." Filter by device and system version, borrow or rent that device, and check what that maker changes in the system.

How do you test a mobile app, from unit tests to real devices?

What they check: a balance of fast checks and real-device checks, run by the pipeline.

Short answer: "Most tests are unit testsTests for view models, parsing and business logic that run in seconds on every change. for view models and business logic; they run in seconds on every change. A smaller set of UI tests covers the key journeys on simulators and emulators in the pipeline. Before a release, a few journeys run on real devices, old and new, through a device farm or by hand."

The full answer: Architecture decides testability: logic outside the screens can be tested without a phone. UI tests are slower and flakier, so keep them few and stable, with test automationUI tests on simulators, emulators and real devices for the journeys that must never break. tools of each platform. Snapshot tests catch layout changes. Real devices find what simulators hide: memory pressure, camera, notifications, the maker's own system changes. Test accessibility and large text sizes as part of the journeys.

A weak answer: "The testers test it before release." Follow-up: "The UI tests fail at random." Find the cause, such as waits on network or animations, fix or remove the test, and keep the suite trusted.

Privacy, permissions and security

How do you protect user privacy and ask for permissions such as location or the camera the right way?

What they check: respect for users and knowledge of what both platforms and stores require.

Short answer: "I ask for a permission only when the user starts the feature that needs it, with a sentence that says why, and the app still works if they say no. I collect only the data the feature needs, and I keep the store privacy labels and the privacy policy in step with what the app and its third-party libraries really do."

The full answer: Both platforms let users give approximate location instead of precise, allow a permission only once, and remove unused permissions. Apple's store asks for a privacy label and a privacy manifest for some data uses; Google Play asks for a data safety section. Libraries for analytics or ads collect data too, so review them. In the EU the GDPR, the EU data protection law, adds consent and purpose rules for personal data; other countries have their own laws.

A weak answer: "We ask for all permissions at first start, so it is done." Follow-up: "A user refuses location." Show the fallback, such as typing a postcode, and how to ask again later in context.

What does security mean for a mobile app, for the data on the phone and the connection to the backend?

What they check: that you assume the phone and the app can be inspected by an attacker.

Short answer: "No secret goes into the app, because an app can be taken apart. Tokens live in the Keychain on iOS and the Keystore on Android, sessions expire, and every call goes over encrypted connections to a backend that checks each request itself. Sensitive screens hide their content in the app switcher."

The full answer: The backend is the real gate: the app only holds what one user may see. Use the platforms' secure storage and biometric prompts, keep logs free of personal data, and update libraries with known flaws. For banking or health apps, add checks against tampered phones and certificate pinning where the risk justifies the extra upkeep. The OWASP Mobile Application Security guide is a common checklist for app securityKeep secrets out of the app, store tokens in the platform's secure storage and check what leaves the device..

A weak answer: "We hide the API key in the code." Follow-up: "A security test finds the key." Move it to the backend, rotate it, and check what it could reach.

Releases, stores and feature flags

Walk us through a release, from the last merge to the app in both stores, including review.

What they check: that you can ship safely and plan around both stores.

Short answer: "The pipeline builds, tests, signs and uploads the release candidate. Testers and a group of beta users try it through TestFlight and Google Play's testing tracks. We submit both versions for review with release notes and any new privacy details, then release in steps: a phased release on the App Store and a staged rollout on Google Play, watching crashes and ratings before going to everyone."

The full answer: Apple checks each version against its App Store Review Guidelines and Google Play against its Developer Program Policies; both cover privacy, in-app payments, content and permissions, and each may ask for changes. Review times vary, so leave room before a fixed launch date. A phased release spreads an update over several days; a staged rollout sends it to a share of users that you raise step by step. Both can be paused when the crash rate rises. A release train, such as every two weeks, keeps both platforms in step.

A weak answer: "We upload it and hope review passes." Follow-up: "Review rejects the iOS version the day before launch." Read the cited rule, fix or explain, reply through the review channel, and decide with product whether Android waits.

Old app versions stay on phones for months. How do you use feature flags and forced updates?

What they check: that you design for many versions in use at once.

Short answer: "A feature flag is a switch the server controls, so a feature ships hidden and is turned on, for some users or all, without a new release; it can be turned off if it breaks. For old versions, the backend keeps its APIs working for them, and a minimum-version check asks users to update only when an old version can no longer work safely."

The full answer: Users update late or never, so every API change must keep old versions working for an agreed time. Flags let a team test a feature with a share of users and compare results; remove each flag after the decision, or the code fills with dead branches. A forced update is a last resort, for security or a broken API, because it blocks users at a bad moment.

A weak answer: "Everybody updates automatically." Follow-up: "Ten percent of users are on a version from last year." Explain how the backend and the minimum-version check handle them.

Accessibility, notifications and deep links

How do you make an app accessible, and how do you test it?

What they check: that accessibility is part of how you build, not a late fix.

Short answer: "Every control has a label the screen reader can read, touch targets are large enough, text grows with the user's settings, colours have enough contrast, and nothing depends on colour alone. I test with VoiceOver on iOS and TalkBack on Android, and with the largest text size."

The full answer: The platform components are accessible by default; custom ones need labels, roles and a sensible focus order. The Web Content Accessibility Guidelines are the common international reference for apps too. In the EU, the European Accessibility Act makes many consumer apps, such as banking and shopping, a legal duty to make accessible since June 2025; each country names its own authority to enforce it.

A weak answer: "Our users do not need it." Follow-up: "A screen reader user cannot complete the checkout." Walk the flow with TalkBack or VoiceOver, fix labels and focus, and add the journey to the tests.

How do push notifications and deep links work, and what goes wrong with them?

What they check: that you know the path from a server to a screen in the app.

Short answer: "The backend sends a push notification through Apple's push service for iOS and Firebase Cloud Messaging for Android, addressed to a device token. The user must allow notifications. A deep link is an address that opens a given screen in the app, from a notification, an email or a web page; universal links on iOS and app links on Android tie it to the company's website."

The full answer: Tokens change, so the app sends the new one to the backend each time. Notifications that arrive while the app is open, closed or stopped are handled in different places, and each case needs a test. Deep links break when the screen needs a login, data that is not loaded yet, or an app version that does not know the address; plan each path. Too many notifications make users turn them off, so agree their purpose with product.

A weak answer: "Push just works once it is set up." Follow-up: "Users tap a notification and land on the home screen." Trace the link handling for a cold start and a logged-out user.

Lead mobile developer, mobile architect and head of mobile engineering

These questions come up for senior mobile developer, lead mobile developer, mobile architect and head of mobile engineering roles, where the work spans teams, platforms and years.

As lead mobile developer or head of mobile engineering, how would you run iOS and Android across several teams?

What they check: that you can keep many teams fast and both apps consistent.

Short answer: "I set a shared architecture and module rules, a design system both apps follow, one release train with automated checks, and a small platform team that owns the build, the pipeline and shared libraries. Feature teams own their screens on both platforms where they can. I watch build times, crash-free rates and release frequency, and fix the slowest part first."

The full answer: At this level the questions are structure and trade-offs. Decide what is shared and what stays native; keep feature parity where users notice it; plan migrations, such as a move to SwiftUI and Compose, in steps that never stop releases. A mobile architect writes the decisions down and reviews them; a head of mobile engineering also hires, grows leads and holds the budget for devices, tools and the pipeline.

A weak answer: "Each team decides for itself." Follow-up: "Builds take forty minutes." Show how you would measure them, split modules, cache builds and set a goal.

Your CV for these questions

Each line of your CV is a question waiting to be asked: which app, what you changed, how you measured it. Write lines you can talk about for five minutes, under the job where the work happened:

Run your CV against a real mobile developer job before the interview: the gaps it shows are the lines most worth preparing.