How do you approach performance optimisation in a mobile app?

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.

How do you handle offline-first functionality in a mobile app?

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.

How do you manage state in a complex mobile application?

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.

How do you approach the app store submission and release process?

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.

Tell me about a significant performance issue you identified and fixed in a mobile app.

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.

Describe a time you had to support multiple platform versions and how you managed the complexity.

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.

Give an example of a difficult bug you tracked down in a mobile app. What was your debugging process?

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.

How do you approach testing in a mobile application?

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.

How do you handle push notifications across iOS and Android and what are the main implementation challenges?

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.

How do you structure the architecture of a React Native application for long-term maintainability?

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.

Mobile Developer

Mobile Developer interviews have layers that web interviews don't. You need to show you understand the constraints of the platform (battery, network, memory), that you know how to navigate app store submissions and the delays they bring, and that you've thought about testing across a device ecosystem that's messier in practice than it looks in documentation. This guide covers the questions that come up most often and what good answers actually look like.

For general interview preparation tips, read our guide to common interview questions.

Prepare further

How to ace the behavioural interview (STAR method)How to prepare for a technical interview

Common Mobile Developer Interview Questions

Behavioural Interview Questions for Mobile Developer Roles

Technical Questions for Mobile Developer Candidates

What Hiring Managers Look for in Mobile Developer Interviews

What hiring managers really look for in Mobile Developer candidates:

Platform depth over breadth. Being expert in one platform and competent in another is much more useful than being mediocre at both, and most interviewers will probe for real depth in their primary platform rather than surface knowledge across all of them.
Performance instincts that kick in before the problem gets bad. Mobile hardware is constrained and users notice slowness immediately, so candidates who profile first and optimise based on evidence rather than guessing at bottlenecks tend to be far more useful in practice.
Real familiarity with the app store process. Rejections, privacy manifests, entitlements, and review guidelines are operational concerns that slow teams down when candidates don't know them, and interviewers know this.
A clear-eyed view of mobile testing. Mobile UI testing is brittle in ways that server-side testing isn't, and candidates who've thought through what to test, what to mock, and what to let slide show a level of maturity that stands out.
A collaborative relationship with backend teams. Mobile development rarely happens in isolation, and candidates who describe working closely with API teams, negotiating contracts, and managing version compatibility give a much more complete picture of how they actually work.

Questions to Ask Your Interviewer

→What is the current split between iOS, Android, and cross-platform work on the team?
→How does the team handle the release process and what is the current cadence for app store submissions?
→What is the biggest technical debt item in the mobile codebase right now?
→How closely does the mobile team work with the backend team and how are API changes communicated?
→What does the testing infrastructure look like and what is the current coverage of the critical user journeys?

Practise These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free to start. No commitment.

Related Roles