Mobile App Developer Interview Questions and Answers (2026)

The short answer: mobile developer interviews test whether you can build apps that stay fast, correct and reliable on real devices. Expect questions on lifecycles (what happens when the app goes to the background or the screen rotates), architecture (separating UI from data, unidirectional data flow), threading and memory, offline data and networking, performance, security, testing, and releasing safely when old app versions stay installed for months. Most loops also include a coding round, a mobile system design question (“Design a photo feed”) and behavioral questions. The questions below apply to iOS, Android and cross-platform roles; see our Android and iOS guides for platform-specific depth.

The typical interview loop

1. Recruiter or hiring manager screen: your apps, your platform and why the role.
2. Coding: data structures and algorithms, or a practical exercise such as building a small screen that loads and displays data.
3. Platform deep dive: lifecycles, concurrency, memory, UI frameworks.
4. Mobile system design: architecture for a feature or app.
5. Behavioral: crashes, releases, disagreements, ownership.

Lifecycle questions

“What happens to an app when it goes to the background?”

Apple’s documentation explains that a foreground app has the user’s attention and priority over system resources, while a background app “must do as little work as possible, and preferably nothing, because it’s offscreen.” So you save state, pause expensive work, and release resources when moving to the background, and the system may suspend or terminate the app. Since iOS 13, apps that support scenes get lifecycle events for each scene (each instance of the app’s UI).

“What happens on Android when the screen rotates?”

By default the activity is destroyed and recreated as a configuration change. UI state should live outside the activity, for example in a ViewModel (which survives configuration changes) and in saved instance state for process death.

“Why shouldn’t you put all your code in an Activity or View Controller?”

Android’s architecture guide calls separation of concerns “the most important principle” and notes that “it’s a common mistake to write all your code in an Activity.” UI classes should only handle UI and system interactions; business logic and data belong in other layers that are easier to test and survive lifecycle changes.

Architecture questions

“How would you structure a new app?”

A common answer, matching Android’s recommended architecture, is a UI layer that displays data, a data layer that holds business logic and exposes data (usually through repositories), and an optional domain layer for reusable logic. On iOS, the same ideas appear as MVVM or similar patterns with SwiftUI or UIKit.

“What are unidirectional data flow and a single source of truth?”

In Android’s words, with a single source of truth (SSOT), each type of data has one owner, and “only the SSOT can modify or mutate it.” With unidirectional data flow, state flows down to the UI and events flow up to the owner. The result: predictable state, fewer bugs and easier testing. Declarative UI frameworks such as Jetpack Compose and SwiftUI are built around this idea.

Threading and memory questions

• “Why must you not block the main thread?” It handles UI and input; blocking it causes frozen screens and, on Android, “app not responding” errors. Do network, disk and heavy work in the background (Kotlin coroutines, Swift concurrency with async/await), and update the UI on the main thread or main actor.
• “What’s a retain cycle in Swift, and how do you avoid it?” Two objects holding strong references to each other (often a closure capturing self) are never freed. Use weak or unowned references where appropriate.
• “What causes memory leaks on Android?” Long-lived objects holding references to an Activity, View or Context, such as a static reference or an unregistered listener. Use the application context where appropriate and scope work to lifecycles.

Data, networking and offline questions

• “How would you make an app work offline?” Make a local database the single source of truth (for example, Room on Android or SwiftData or Core Data on iOS); the UI reads from it, and a sync layer fetches from the network, writes to the database and queues changes made offline, retrying with exponential backoff.
• “How do you load a long list efficiently?” Paginate requests, reuse cells or use lazy lists, cache and downsample images, and prefetch the next page.
• “How do you handle API changes when users don’t update the app?” Old versions stay in the wild for a long time, so APIs must stay backward compatible, new fields should be optional, and you need a strategy for minimum supported versions and, rarely, forced updates.

Performance, security and testing questions

• “How do you improve app startup time?” Measure first, then defer non-essential initialization, avoid heavy work on the main thread at launch, and load data lazily. Profile with Android Studio’s profilers or Xcode Instruments.
• “A list scrolls with jank. What do you check?” Main-thread work during scrolling, expensive layouts or recompositions, large images decoded on the main thread, and overdraw.
• “How do you store sensitive data?” In the Keychain on iOS or with the Android Keystore, never hard-coded in the app; use TLS for all traffic and don’t log personal data. Assume anything shipped in the app binary can be extracted.
• “How do you test a mobile app?” Unit tests for view models and business logic, integration tests for data layers, UI tests for critical flows (Espresso or Compose testing, XCUITest), and testing on real devices with different screen sizes and OS versions.

Release questions

• “How do you release safely?” CI builds and tests, staged or phased rollouts to a small percentage of users first, feature flags to turn off risky features without a new release, and crash and performance monitoring watched closely after each release.
• “Tell me about a production crash you fixed.” Prepare a STAR story: how you found it (crash reports, logs, reproduction), the root cause, the fix, and what you changed to prevent similar crashes.

Cross-platform questions

“Native, React Native, Flutter or Kotlin Multiplatform?” There’s no single right answer; show you understand the trade-offs. Native gives the best platform integration and performance tuning but means two codebases. React Native and Flutter share most UI code across platforms, at the cost of an extra layer and sometimes slower access to new platform features. Kotlin Multiplatform shares business logic while keeping native UI. Choose based on team skills, performance needs, how platform-specific the UI is, and time to market.

Mobile system design: “Design a photo feed”

1. Clarify: features (scrolling feed, likes, comments, offline viewing?), scale, and which platforms.
2. Client architecture: a feed screen and view model, a repository, a local cache or database as the source of truth, an image loader with memory and disk caching.
3. API: cursor-based pagination, image URLs in several sizes.
4. Performance: prefetching, image downsampling, placeholders, and avoiding main-thread work.
5. Offline and errors: show cached content, retry with backoff, and optimistic updates for likes.
6. Trade-offs and metrics: freshness vs data usage, and scroll performance, crash-free sessions and time to first content.

See also our system design interview guide and software engineer interview questions.

Frequently asked questions

Sources

• Android Developers, Guide to app architecture. Read on 1 October 2026.
• Apple Developer Documentation, Managing your app’s life cycle. Read on 1 October 2026.