Mobile App Developer interview questions and answers

Native development means building the Android app in Kotlin with Jetpack Compose and the iOS app in Swift with SwiftUI, using each platform SDK directly. You get the best performance, the newest OS features on day one, and the most natural look and feel, but you maintain two codebases and often two teams. Cross-platform frameworks like Flutter and React Native let you share most of the code between platforms, so a smaller team can ship faster. They are a great fit for typical business apps like e-commerce or booking. I would choose native for apps that depend heavily on platform features, advanced graphics, or very tight performance, and cross-platform when time to market and team size matter more. Kotlin Multiplatform is a middle option that shares business logic but keeps native UI.

A screen goes through states as the user uses the app. On Android, an Activity goes through onCreate, onStart and onResume when it opens, and onPause, onStop and onDestroy when it leaves. iOS and SwiftUI have similar events like onAppear and scene phases for active, inactive and background. It matters because phones have limited resources. I must stop things like the camera, location updates or video when the screen is not visible, otherwise I waste battery. The OS can also kill the app while it is in the background, so I save important state, like form input, and restore it when the user returns. Lifecycle-aware tools, like collecting flows with repeatOnLifecycle, help do this correctly.

I always run network calls off the main thread, using coroutines with Retrofit or Ktor on Android, async/await with URLSession on iOS, or async functions in Flutter and React Native. Each screen has clear UI states: loading, success, empty and error. I treat errors differently: no internet shows a friendly offline message, a timeout offers a retry, a 401 sends the user to login, and a 5xx shows a generic error and is logged to monitoring. For safe requests I retry automatically with exponential backoff. I set sensible timeouts, and I cache the last good data locally so the screen still shows something when offline. I never show raw error messages or stack traces to users.

MVVM stands for Model, View and ViewModel. The Model is the data layer, such as repositories that talk to the network and local database. The View is the UI, a Compose screen or SwiftUI view, which only displays state and forwards user actions. The ViewModel sits in between: it holds the screen state, handles events like button taps, calls the repository, and exposes the result as observable state, such as a StateFlow or an @Observable object. The ViewModel never holds a reference to the View. This separation keeps UI code simple, makes business logic easy to unit test without a device, and on Android the ViewModel also survives rotation. Many teams combine it with unidirectional data flow, where state goes down and events go up.

Push notifications go through the platform services: Firebase Cloud Messaging for Android and Apple Push Notification service for iOS. When the app starts, it asks the user for notification permission, which is required on iOS and on Android 13 and later. It then registers with FCM or APNs and receives a device token. The app sends this token to our backend, linked to the user. When we want to notify someone, the backend sends a request with the token and payload to FCM or APNs, and they deliver it to the device even if the app is closed. In the app I handle token refresh, show the notification correctly in foreground, and when the user taps it I deep link to the right screen.

The main thread draws every frame and handles touches, so anything slow there causes jank or an ANR on Android. I use the async tools of the platform. In Kotlin I launch coroutines in viewModelScope and wrap blocking I/O in withContext(Dispatchers.IO). In Swift I use async/await, keep UI code on the main actor and let URLSession suspend instead of blocking. In Flutter, network calls are Futures, and heavy CPU work like parsing huge JSON goes to another isolate with compute or Isolate.run. In React Native I keep the JS thread free of long loops. I also tie the work to a lifecycle scope, so if the user leaves the screen the work is cancelled and nobody updates a dead view. Finally, I show loading and error states so the user always knows what is happening.

I pick storage by the shape and sensitivity of the data. Small settings like theme or onboarding done go in a key-value store: DataStore on Android, UserDefaults on iOS, shared_preferences in Flutter. Structured data that I need to query, sort or observe, like a list of orders, goes in a database such as Room, SwiftData, Core Data or SQLite through a library like Drift. Large blobs like images, PDFs or downloaded media go into files in the app sandbox, often in the cache directory if they can be re-downloaded. Secrets such as refresh tokens go in the Keychain or in storage encrypted with the Android Keystore, never in plain preferences. I also plan for schema migrations from day one and avoid storing more personal data than the feature needs.

I ask only when the user starts the feature that needs it, for example when they tap Scan, not at first launch. Before the system dialog, I show a short screen explaining why, because the system dialog can usually be shown only once or twice. I make sure the manifest entry or the Info.plist purpose string is there, since a missing purpose string crashes on iOS. If the user denies, the app must still work: I hide or disable the feature, or offer another way, like typing a code instead of scanning. If they denied permanently, I show a gentle message with a button that opens the app settings page. I also re-check the permission each time, because users can revoke it in settings at any moment.

I start with flexible layouts: rows, columns and constraints that fill available space instead of fixed pixel widths. Sizes use dp or points, and text uses sp on Android and Dynamic Type on iOS so it scales with the user font setting, which means layouts must allow text to wrap. For tablets and foldables I use window size classes or breakpoints to switch layouts, for example a list and detail side by side on wide screens. I respect safe areas and insets so content is not hidden behind the notch, home indicator or keyboard. Then I test on a small phone, a large phone, a tablet and landscape, plus the largest font size, using previews in Compose or SwiftUI and real devices for the final check.

In the imperative style, like Android XML views or UIKit, you build views once and then mutate them by hand: find the label, set its text, hide the spinner. It is easy to forget a step and leave the screen out of sync with the data. In declarative frameworks like Jetpack Compose, SwiftUI, Flutter and React Native, you write a function that describes the UI for the current state. When state changes, the framework re-runs that description and updates only what changed, through recomposition or diffing. This makes state the single source of truth and removes a whole class of sync bugs. The trade-off is that you must think about who owns each piece of state, and avoid expensive work or unstable inputs that cause too many rebuilds.

I would move to an offline-first design. First I add a local database such as Room on Android or SwiftData on iOS, and make it the single source of truth: the UI observes the database, not the API. A repository fetches from the network when possible and writes results into the database, so screens update automatically. For writes, I save the change locally right away, mark it as pending, and put it in a sync queue. A background job, like WorkManager or BGTaskScheduler, sends pending changes when the network is back, with retries. On the server side I need version numbers to detect conflicts and a clear merge rule. In the UI I show when data was last updated and which items are not synced yet.

First I reproduce it on a real low-end device using a release build, because debug builds are slower and misleading. Then I profile: Android Studio Profiler and system traces, Xcode Instruments Time Profiler, or Flutter DevTools frame chart. I look for frames that miss the 16ms budget (or 8ms at 120Hz) and what runs on the main thread during them. Common causes are decoding large images, JSON parsing or database queries on the main thread, deep or complex item layouts, and items re-rendering when nothing changed. Fixes include moving work to background threads, using an image library that downsamples and caches, giving list items stable keys, making item parameters stable or memoised, and simplifying layouts. Then I measure again to confirm.

I start by bumping the version name and the build number, which must always increase. CI builds a signed release, for example an Android App Bundle with Play App Signing and an iOS archive, usually automated with Fastlane or Xcode Cloud. The build first goes to internal testers and QA through Play internal testing and TestFlight, then to a wider beta group. After sign-off, I submit to the stores with release notes and any new screenshots, and wait for review. On release I use a staged rollout, starting with a small percentage, and watch Crashlytics, ANR rates and key business metrics. If something goes wrong I halt the rollout and use feature flags to disable the feature while a hotfix is prepared. We also keep a minimum supported version check for critical fixes.

Dependency injection means a class gets the objects it needs from outside, usually through its constructor, instead of creating them itself. For example, a ProfileViewModel receives a UserRepository rather than building its own Retrofit client. This makes the code loosely coupled and easy to test, because in a unit test I can pass a fake repository. On Android I have used Hilt, which generates the wiring at compile time and handles scopes such as singleton for the database and ViewModel scope for screen objects. In Swift I usually do plain initializer injection with protocols, and in Flutter I have used Riverpod. I try to avoid hidden global singletons, because they make tests depend on each other and hide what a class really needs.

I assume the app binary can be decompiled and the device can be rooted, so I never put real secrets in the app. Tokens are stored in the iOS Keychain or Android Keystore-backed storage. All traffic uses HTTPS, and for high-risk apps like banking I add certificate or public key pinning with backup pins. I use short-lived access tokens with refresh tokens and clear everything on logout. Most importantly, the server checks every permission and input, because the client can be modified. For extra protection I enable R8 obfuscation, use Play Integrity or App Attest to check the app is genuine, and avoid logging personal data. I also request only the permissions the app really needs and follow OWASP MASVS as a checklist.

I first split state into types. Local UI state, like whether a dropdown is open, stays in the widget or component with setState or useState. Shared app state, like the logged-in user or cart, goes in a dedicated layer: in Flutter I usually use Riverpod or Bloc, and in React Native Zustand or Redux Toolkit. Server data is really a cache, so in React Native I use TanStack Query, which handles loading, caching, refetching and invalidation, and in Flutter a repository with a provider that exposes async values. I keep data flowing one way: the UI dispatches events, logic updates immutable state, and the UI rebuilds. Business logic lives outside widgets so it can be unit tested. I also scope providers or selectors carefully so a change only rebuilds the parts of the screen that use it.

I follow the test pyramid. Most tests are fast unit tests for ViewModels, use cases, mappers and validation, with fake repositories and a test dispatcher so they are deterministic. Next are integration tests: Room or SQLite migrations, repository logic with a mock web server, and serialization of real API samples. On top is a small set of UI tests for critical journeys like login, checkout and onboarding, written with Compose testing or Espresso on Android, XCUITest on iOS, or Maestro or Detox for cross-platform apps, all against a fake backend. Screenshot tests catch visual regressions across themes and font sizes. Everything runs on CI for each pull request, and before release we run the UI suite on a device farm covering low-end devices and older OS versions.

I prefer verified https links: Android App Links with assetlinks.json and iOS Universal Links with the apple-app-site-association file on our domain, so the same URL opens the app or falls back to the website. In the app, one central router parses the URL into a typed destination, so screens never parse raw strings. I validate every parameter because links are untrusted input that anyone can craft. The router must handle cold start, when the app launches from the link, and warm start, when it is already running. If the destination needs login, I store it as pending and continue after sign-in. I also build a sensible back stack so Back goes somewhere useful. Finally, I add automated tests for each route and check links with adb and on real devices.

I build accessibility in from the start. Every interactive element gets a clear label and role, for example contentDescription or semantics in Compose and accessibilityLabel in SwiftUI or React Native, and decorative images are hidden from screen readers. Text uses scalable sizes so it follows the user font setting, and layouts wrap instead of clipping at the largest sizes. Colors meet contrast guidelines, and I never use color alone to show an error. Touch targets are at least 48 dp or 44 points, and related items are grouped so TalkBack and VoiceOver read them in a sensible order. To check, I use Accessibility Scanner and Xcode Accessibility Inspector, add automated checks in UI tests, and regularly walk through key flows with the screen reader turned on and the font at maximum size.

On every pull request, CI runs lint, static analysis, unit tests and a debug build for both platforms, and blocks merge on failures. For releases, a pipeline in GitHub Actions, Bitrise or similar builds signed release artifacts. Signing material never lives in the repo: the Android keystore and passwords are encrypted CI secrets, and iOS certificates and profiles come from fastlane match or App Store Connect API keys. Build numbers are generated automatically so every upload is unique. Fastlane lanes upload builds to TestFlight and Play internal testing so QA always has the latest version. The same lanes upload dSYMs and R8 mapping files to Crashlytics. Promotion to production is a manual approval followed by a staged rollout, and we watch crash-free rate before going to 100 percent.

The core is a local database of conversations and messages, and the UI only observes it. When the app is in the foreground, I keep a WebSocket connection for real-time messages, typing and receipts, with reconnect and backoff. In the background the OS limits sockets, so new messages arrive through push notifications, which can wake the app to fetch. When the user sends a message, I create it locally with a client-generated ID and status "sending", show it immediately, and put it in an outgoing queue. The server acknowledges with the same ID so retries never duplicate. Message history loads with paging. Media is uploaded separately with resumable uploads and thumbnails. I would also consider end-to-end encryption with keys in secure storage, and limit battery and data use.

I would split the app into modules: core modules for networking, design system, analytics and data, and feature modules for areas like login, search and payments. A strict rule is that feature modules do not depend on each other; they talk through interfaces in an API module or through a navigation router, so teams can work independently. On Android this means Gradle modules with convention plugins, and on iOS Swift packages. Smaller modules let Gradle and Xcode build in parallel and reuse build caches, so a change in one feature does not rebuild everything. I would add code owners for each module and dependency checks in CI. The migration should be gradual: extract the design system and core first, then move one feature at a time while measuring build time.

GPS and the network radio are the biggest battery costs, so I avoid using them at full power all the time. On Android I use the Fused Location Provider and on iOS Core Location, choosing accuracy and interval based on need: high accuracy during an active delivery, lower when the rider is idle. I adapt using motion detection, so when the rider stops, updates slow down. Android requires a foreground service with a visible notification for continuous tracking, and iOS needs the background location mode and Always permission, which must be justified clearly to the user. Instead of sending each point immediately, I store points locally and upload them in batches, which lets the radio sleep. I also test under doze and low power mode, and monitor battery impact in production.

I would wrap the native SDK in a plugin with a small, focused API. In Flutter I would use platform channels, ideally with Pigeon to generate type-safe code on both sides. In React Native I would write a TurboModule or an Expo module, which works with the New Architecture and gives typed bindings. The API should be async and high level, like startPayment(amount) returning a result, instead of exposing every SDK method. On the native side I handle threading, because many SDKs call back on background threads, and lifecycle events like the app going to background. Native errors are mapped to clear error codes in Dart or JavaScript. I keep the Android and iOS implementations behaving the same, write tests on both, and document which SDK versions are supported.

Test phones are usually fast and on good Wi-Fi, so I rely on production data. I track cold and warm startup time, slow and frozen frames, ANRs, crash-free users, app size and network request latency. Sources include Android vitals in Play Console, Apple MetricKit and Xcode Organizer, plus a tool like Firebase Performance or Sentry for custom traces such as time to load the home feed. I always look at percentiles like p90 and segment by device class, OS version and network type, because low-end Android phones on slow networks often show the real problems. Each release is compared to the previous one, with alerts on regressions. In CI I run Macrobenchmark or XCTest performance tests so regressions are caught before release, and I set clear budgets for startup and app size.

Unlike the web, I cannot redeploy every client, so every API change must assume old app versions are still out there. I prefer additive changes: new optional fields and new endpoints, never renaming or removing fields that old apps parse. Clients parse tolerantly, ignoring unknown fields and handling unknown enum values with a default. When a breaking change is unavoidable, I version the endpoint and keep the old one until usage drops. Each request sends the app version, so we can see adoption per version and remove dead paths with data. I keep two remote values: a soft minimum that shows a dismissible update prompt, and a hard minimum that blocks use, which I reserve for security issues or truly broken versions. On Android I use the Play In-App Updates API, and on iOS a screen linking to the App Store.

First I narrow it down with data: which version introduced it, which devices, and what breadcrumbs or screens appear before the crash. Rising OOMs after many minutes usually mean a leak, while instant OOMs on one screen point to huge allocations like full-size bitmaps. Then I reproduce the flow, for example opening and closing the product screen twenty times, while watching memory in Android Studio Profiler or Xcode Instruments. If memory climbs and never returns, I take a heap dump or use the Xcode Memory Graph to see which objects are retained and by what. LeakCanary helps catch Android leaks automatically in debug builds. Typical causes are closures capturing self strongly, unregistered listeners, static references to an Activity, unbounded caches and undecoded large images. After fixing, I watch the OOM rate in the staged rollout before releasing to everyone.

A mobile app is a public client, so it cannot keep a client secret. I use the authorization code flow with PKCE: the app creates a random code verifier, sends its hash with the authorization request, and proves possession when exchanging the code for tokens, so an intercepted code is useless. The login page opens in the system browser through ASWebAuthenticationSession or Android Custom Tabs, never an embedded WebView, so the app cannot see the password and the user gets shared sessions and password managers. I check the state parameter and use verified https redirects where possible. Libraries like AppAuth handle these details. Tokens are stored in the Keychain or Keystore-backed storage, access tokens are short-lived, and refresh happens in one place with a lock to avoid races. Logout revokes tokens on the server and clears local data.

I would never do a big-bang rewrite. Both frameworks have good interop: ComposeView and AndroidView on Android, UIHostingController and UIViewRepresentable on iOS, so old and new UI can live side by side. First I build the design system in the new framework, like buttons, text styles and list rows, because every screen needs them. Then the rule is that new screens use the new framework, and existing screens are migrated when we touch them for features or when they cause many bugs. Before converting a screen, I make sure its logic lives in a ViewModel that exposes state, so only the view layer changes. I add screenshot tests to catch visual differences and measure scroll performance, startup and app size, since adding a framework adds weight. Team guidelines, code review and shared examples keep the code consistent during the long transition.

Users can jump from any old version to the newest, so I keep an explicit migration for every version step and test the full chain, for example 3 to 7, not only the last step. Room MigrationTestHelper, Core Data or SwiftData lightweight migrations and SQL scripts for SQLite are verified in automated tests against databases created by real old builds with realistic data. I avoid destructive migrations unless the data is a pure cache that can be fully re-downloaded, because wiping offline edits loses user work. Each migration runs in a transaction so a failure leaves the old data intact. For big tables I watch the time it adds to startup and may migrate lazily or in the background. I log migration failures to telemetry, and I ship schema changes through a staged rollout so a bad migration reaches only a small group before we can halt it.