Mobile Developer Interview Questions

Performance on mobile is non-negotiable because users will uninstall an app that feels slow, and unlike a web app, you cannot push a fix instantly. My approach starts with measurement: I use Xcode Instruments for iOS and Android Profiler for Android to identify the actual bottlenecks before writing a single line of optimisation code. The most common issues I find are main thread blocking, excessive re-renders in React Native, and inefficient image loading. For main thread work, I move any computation or I/O off the main thread using async operations or background queues. For image loading I use lazy loading with a cache layer, sized images to the display resolution rather than downloading full-resolution assets and scaling them down. I also profile startup time separately because it disproportionately affects retention: I target sub-2 second cold start on a mid-range device. I include performance metrics in my pull request descriptions so regressions are visible before they reach production.

Offline-first is a design decision that has to be made at the architecture level, not added as an afterthought. The core idea is that the local device is the source of truth for reads, and the network is used to synchronise state, not to serve every request. I use a local database, SQLite via Room on Android or Core Data or SQLite on iOS, to persist all data that users might need offline. Write operations are queued locally with a status flag and a retry mechanism, and they are replayed against the server when connectivity is restored. The hard problem is conflict resolution: when a user edits data on one device while offline and the server has a more recent version, I need to decide which wins. My preference is a last-write-wins strategy with a server timestamp, with a manual conflict resolution UI for cases where data integrity is critical. I also test offline behaviour explicitly in CI, simulating network loss with Charles Proxy or the Android emulator's network throttling, not just assuming it works.

State management complexity scales quickly in mobile apps as the number of screens and data flows grows. My approach depends on the platform: on iOS I use a combination of SwiftUI's built-in state management for local UI state and a Redux-style unidirectional data flow pattern for shared application state, using a library like TCA (The Composable Architecture) for larger apps. On React Native I use Zustand or Redux Toolkit depending on the team's existing conventions, and I am deliberate about separating server state from client state, using React Query or TanStack Query for the former. The most common mistake I see is putting everything into a single global store, which makes testing difficult and causes unnecessary re-renders. I structure state into modules that correspond to features, and I keep component-local state local unless it genuinely needs to be shared. I also maintain clear rules about what triggers a state update and from where, because undisciplined state mutations are the most common source of hard-to-reproduce bugs.

App store submissions are slow and reversals are painful, so I invest heavily in the review process before submitting. My checklist covers: running the full test suite including UI tests on real devices, checking for any deprecated API usage that might trigger rejection on future OS versions, verifying all privacy manifest declarations match the permissions the app actually uses, and testing on the minimum supported OS version. I use TestFlight for iOS and the internal testing track on Google Play to give stakeholders a build to review before the public release, and I never submit a build that has not been signed off by at least one non-developer. For phased rollouts I use App Store's gradual rollout feature and Google Play's staged rollout, starting at 5% and monitoring crash rates and reviews before expanding. I also keep a rollback plan: if a critical bug appears, I need to know within 24 hours based on crash reporting, and I have a pre-tested rollback build ready to submit immediately.

I was working on a React Native app where the home screen took 4.2 seconds to become interactive on a mid-range Android device. Users were dropping off before the content appeared. I started with the React Native performance profiler and quickly identified that we were making six sequential API calls on mount, each waiting for the previous to complete, before rendering any content. The first fix was to parallelise the API calls, which brought the time down to 2.8 seconds. The second issue was that we were rendering the entire list on mount even though only the first five items were visible: switching to a FlatList with proper key extraction and item height estimation brought the time to 1.9 seconds. The third issue was image loading: we were downloading full-resolution images and letting the component scale them, which consumed significant memory. After switching to appropriately sized images with caching, interactive time was 1.1 seconds. The lesson was to use profiling data to find the real bottleneck rather than guessing.

I worked on an iOS app that needed to support iOS 15 through iOS 17, which introduced significant SwiftUI differences between versions. The challenge was that several APIs we wanted to use were only available on iOS 16 or later, while 30% of our users were still on iOS 15. I used a feature flags approach combined with OS version checks to provide two implementations for the affected features: a full implementation for iOS 16+ using the new APIs and a fallback using the older approach for iOS 15. I also set up a matrix of devices in our CI pipeline covering the oldest and newest supported OS versions and ran the full UI test suite against each. The most important decision was agreeing with the product team on a sunset timeline for iOS 15 support: by communicating that we would drop iOS 15 in a future release, we were able to plan the simplification of the codebase rather than accumulating legacy paths indefinitely. I track the OS version distribution of our users monthly in Firebase Analytics to make this decision with real data.

I had a crash that appeared in Crashlytics affecting about 0.3% of sessions, but only on specific Samsung devices running Android 11. The crash was in our image caching library, but the stack trace was not reproducible on any device we had in the office. My debugging process started with isolating the conditions: I ordered a Samsung A32 (the most commonly reported device) and reproduced the crash on the third attempt. The stack trace pointed to a memory allocation failure during a bitmap decode. I looked at the memory usage at the point of the crash and found that the affected devices had significantly less available heap memory than our test devices because Samsung's Android 11 implementation had tighter memory constraints in the background. The fix was to add a memory check before attempting large bitmap allocations and to gracefully degrade to a lower-resolution image when memory was constrained. After the fix, the crash rate dropped to zero on affected devices within two weeks. The learning was that device fragmentation on Android requires testing on real mid-range devices, not just emulators or flagship devices.

Testing in mobile requires a layered strategy because the test pyramid looks different from server-side development. The largest and fastest layer is unit tests for business logic and state management, which I write with XCTest on iOS or JUnit on Android. These cover pure functions, view model logic, and data transformation without any UI involvement. The second layer is integration tests that verify the interaction between modules, particularly the local database and the networking layer. The third and smallest layer is UI tests, which I keep to a minimum because they are slow and brittle, and I focus them on the critical user journeys rather than every screen. For React Native I use Jest for unit tests and Detox for end-to-end tests. I also include snapshot tests for core UI components to catch unintended visual regressions. The key metric I track is not coverage percentage but rather "can we catch regressions in the most critical flows before they reach production?" which is a harder but more meaningful question.

Push notification implementation has different complexity on each platform, and the main challenges are device token management, notification permission states, and handling notifications when the app is in different states (foreground, background, killed). On iOS I use APNs directly via Firebase Cloud Messaging, which abstracts the platform differences. Device tokens change when users reinstall the app or restore from backup, so I always refresh the token on every app launch and sync it to the backend, not just on first registration. Permission handling is the most user-facing complexity: iOS requires explicit permission, which I request at a contextually appropriate moment rather than on first launch, because first-launch permission requests have poor acceptance rates. I implement a pre-permission dialogue that explains why notifications are valuable before showing the system prompt. On Android, POST_NOTIFICATIONS permission became required from Android 13, so I handle the three states: granted, denied, and permanently denied (which requires directing users to settings). I also handle notification categories and priority correctly so that important notifications are not silenced by battery optimisation on Android.

React Native architecture choices made early in the project are very expensive to change later, so I invest time in getting the structure right. My preferred architecture is a feature-based folder structure where each feature contains its own components, screens, services, and state, rather than a type-based structure that spreads feature code across many folders. This keeps related code co-located and makes it easier to delete a feature cleanly. For navigation I use React Navigation with typed routes, which catches navigation errors at compile time rather than runtime. For API integration I create a typed API client layer that abstracts the HTTP calls, so screens and components never call fetch directly. I use environment variables for API endpoints and feature flags, managed through a configuration module, so that the same codebase can target different environments. For native modules I write a JavaScript interface that wraps the native functionality, so the rest of the application code is decoupled from the native implementation and can be tested with mocks. I document architectural decisions as ADRs (Architecture Decision Records) in the repository so new team members understand the reasoning, not just the current state.