Mobile app developer interviews cover the platform you build for (Android, iOS or a cross-platform framework like Flutter or React Native), app architecture, offline support, performance and security. These questions suit both native and cross-platform roles.
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
An Activity moves through onCreate, onStart, onResume (now in the foreground), then onPause and onStop when it leaves the screen, and onDestroy when it is finished; onRestart runs when a stopped Activity comes back. Configuration changes such as rotation destroy and recreate the Activity by default, so UI data should live in a ViewModel and small state in saved instance state.
Native development in Kotlin or Swift gives the best performance and full access to platform features, but means two codebases. React Native uses JavaScript or TypeScript with real native components and the large JavaScript ecosystem. Flutter uses Dart and its own rendering engine, giving a very consistent UI on both platforms. I choose based on the team's skills, performance needs and how much platform-specific functionality the app needs.
A StatelessWidget is immutable and is built only from its configuration, like a label or an icon. A StatefulWidget has a separate State object that holds data that can change over time; calling setState tells Flutter to rebuild it. For larger apps, state is usually moved out of widgets into a state-management solution such as Provider, Riverpod or Bloc.
Small key-value settings go in SharedPreferences on Android, UserDefaults on iOS, or AsyncStorage in React Native. Structured data goes in SQLite, usually through Room on Android or Core Data and SwiftData on iOS. Sensitive data such as tokens belongs in the Keychain on iOS or the Android Keystore, never in plain preferences. Large media goes in files.
Applied problems, trade-offs and questions about your own projects.
I store data locally in a database and show cached data first, then refresh from the network. Changes made offline are queued and synced when the connection returns, using WorkManager on Android or background tasks on iOS. I decide how to resolve conflicts, such as last write wins or a server-side merge, detect connectivity changes, and make the offline state clear in the UI.
The Model is the data layer: repositories, the database and the API. The View is the UI. The ViewModel holds UI state and presentation logic, survives configuration changes, and exposes observable state such as StateFlow, LiveData or Combine publishers. The View only observes state and sends user actions, which keeps logic out of the UI and makes it easy to unit test.
The app registers with Firebase Cloud Messaging or Apple Push Notification service and receives a device token, which it sends to the backend. To notify a user, the backend sends a message to FCM or APNs with that token, and the operating system delivers it. Both iOS and Android 13+ need runtime permission from the user. The app must handle notifications in the foreground and background and update the token when it changes.
I measure first, with Android vitals and Macrobenchmark or Xcode Instruments. Then I defer non-critical initialisation such as analytics and SDKs, avoid disk and network work on the main thread, lazy-load features, reduce app size, and show cached content for the first screen. On Android, Baseline Profiles noticeably speed up cold starts.
System design, deep internals, leadership and tough follow-ups.
Anything shipped in the app can be extracted, so no secret API keys belong in it; sensitive operations go through the backend. I use HTTPS everywhere, with certificate pinning where the risk justifies it. Tokens are stored in the Keychain or Keystore, kept short-lived and refreshed. I obfuscate with R8 or ProGuard, add root and jailbreak detection for high-risk apps such as banking, and validate everything on the server.
Signs are memory that keeps growing, slowdowns and out-of-memory crashes. On Android I use the Memory Profiler and LeakCanary; on iOS, Xcode Instruments (Leaks and Allocations) and the memory graph debugger. Common causes are holding an Activity context in a static or long-lived object, listeners that are never removed, and retain cycles in Swift closures, which I fix with [weak self].
I keep payloads small with pagination and compressed images, cache aggressively, and show cached data immediately. Requests have timeouts and retries with backoff, and writes use optimistic UI with a sync queue. Large downloads can wait for Wi-Fi, and loading and error states are designed, not left blank. I test with network throttling tools.
Builds and signing are automated in CI. I release with staged rollouts (a percentage rollout on Google Play, phased release on the App Store) and hide risky features behind feature flags. Crash reporting such as Crashlytics is watched closely after each release. Because old versions stay installed for a long time, APIs must stay backward compatible, with a forced-update mechanism for unavoidable breaking changes.