Scenario-Based Mobile App Development Interview Questions

I would ask about team skills, timeline, budget, required features and long-term plans. If the team knows JavaScript and has a web app, React Native allows code and skill sharing. If they want a consistent custom UI and fast development from scratch, Flutter is strong. Heavy background location and maps work well in both with plugins, but if the app depends deeply on platform features, native may be safer. I would prototype one key screen first.

Identify which elements truly need platform-specific behaviour: navigation transitions, back gestures, date pickers, switches and dialogs. In Flutter, use adaptive constructors like Switch.adaptive or Cupertino widgets based on Theme.of(context).platform. In React Native, many components are native already, and Platform.select handles differences. Keep shared business logic and most layout common, and limit platform branches to a component library so they stay manageable.

Check whether orientation is locked, layouts use fixed widths, and screens assume phone dimensions. Make layouts adapt by width breakpoints with two-pane layouts on wide screens, handle configuration and size changes without losing state, and avoid hardcoding aspect ratios. Recent Android versions ignore orientation locks on large screens, so locking is no longer a fix. Test with resizable emulators, foldable postures and split-screen mode.

The most common cause is a missing NSCameraUsageDescription key in Info.plist. iOS terminates the app when it requests a protected resource without a usage description string. Add descriptions for camera, photo library, microphone and location as required by the plugin, written clearly for the user. Also verify the plugin's iOS setup steps, run pod install, and test on a real device since simulators lack cameras.

The overflow stripe means content exceeds the available space, often a Row with long text or a Column taller than the screen. Wrap text in Expanded or Flexible with overflow ellipsis, make the screen scrollable with SingleChildScrollView or a ListView, use LayoutBuilder to adapt for narrow widths, and avoid fixed heights. Also handle the keyboard by allowing the content to scroll when it opens.

The user left the screen before the Future completed, so the widget was unmounted. Before using context or calling setState after await, check if (!context.mounted) return; or if (!mounted) return; in State. Better still, move async logic out of widgets into a state management layer that the UI listens to, and cancel subscriptions or timers in dispose so no callbacks run on a dead widget.

JSON decoding is CPU-bound and runs on the main isolate, blocking frames. Move it to a background isolate with Isolate.run(() => parseProducts(jsonString)) or compute. Also consider whether the API can paginate or return less data, and parse lazily. Test in profile mode with DevTools performance view to confirm the frame time improvement, since debug mode exaggerates slowness.

Each screen probably holds its own copy of cart data. Move cart state into a single shared state object, such as a Riverpod notifier or a Cubit provided above both screens, and have both screens watch it. All mutations go through that object, which emits a new immutable state. Derived values like total should be computed from the state, not stored separately, so they can never become inconsistent.

Agree on one approach with the team, for example Riverpod for app state and setState only for local widget state, and document examples. Migrate gradually, starting with the most buggy or most changed features, and write tests before moving logic. Add lint rules and pull request checklists so new code follows the standard. Avoid a big-bang rewrite that blocks feature work for weeks.

Bloc and Cubit skip emitting a state that is equal to the current one. If you mutate a list inside the existing state and emit the same object, equality holds and nothing rebuilds. Always emit a new state with copied collections, for example state.copyWith(items: [...state.items, newItem]), and implement equality with Equatable or freezed. Avoid mutable fields in state classes.

Centralise session state in an auth provider or bloc that other state depends on. On logout, clear secure tokens, wipe local databases or caches for that user, reset or invalidate dependent providers, for example by Riverpod providers watching the auth state, and redirect with the router guard to login. Cancel ongoing requests and background jobs. Test that no previous user's data appears after logging in as someone else.

Use go_router's StatefulShellRoute.indexedStack, which creates a separate navigator branch for each tab and keeps their stacks alive with an IndexedStack. The scaffold shows a NavigationBar and switches branches with navigationShell.goBranch(index). This preserves scroll positions and nested pages when switching tabs, and deep links can open a specific tab and page. Handle tapping the active tab to pop to its root.

Split the app into feature packages in a monorepo managed with Melos or pub workspaces, plus core packages for networking, design system, analytics and security. Pick one state management approach, such as Bloc for strict traceability, with clear layer boundaries. Use code generation consistently, enforce lints and architecture tests in CI, and assign feature ownership. Add integration tests for critical journeys and strict security reviews for storage and network code.

Keep the onboarding data in one state object owned by a notifier or cubit scoped to the flow, with each step updating its part. Validate per step before moving forward and again on final submit. Save progress locally so users can resume if they leave. Keep validation rules in pure functions that are unit tested. Dispose the state when the flow completes so data does not leak into later sessions.

Use FlatList or FlashList rather than ScrollView with map. Provide a stable keyExtractor, memoise row components with React.memo, avoid inline functions and heavy computation in renderItem, and use getItemLayout or fixed item sizes where possible. Tune windowSize and maxToRenderPerBatch, compress and cache images with a library like expo-image, and test a release build, since dev mode is much slower.

Check the library's documentation and the React Native directory for New Architecture support, and update to the latest version, since many libraries added support. The interop layer often lets old-architecture modules work, so read the error carefully. If unsupported, look for a maintained alternative, contribute a fix or patch with patch-package, or temporarily keep the old architecture only if your version still allows it, while planning a replacement.

Keep the search text state local to the search input component so only it re-renders, debounce the query before updating the list or calling the API, and memoise the list and row components. Avoid storing frequently changing values in a global store that many components subscribe to. Use the React DevTools profiler to confirm which components render, and useDeferredValue to keep typing responsive.

Business logic, API clients, validation, state management, types and utility hooks can be shared through a monorepo package. UI components usually cannot be shared directly because web uses DOM elements and mobile uses native components, unless you adopt React Native for Web or a universal design system. Navigation and storage differ too. Plan a shared core package and platform-specific UI to avoid forcing awkward compromises.

React Native requires every string to be inside a Text component. The error usually appears when a string or a number is placed directly inside a View, or when a conditional like {count && <Badge />} renders 0 as text when count is zero. Wrap text in Text and use explicit conditions like {count > 0 ? <Badge /> : null} so falsy values are not rendered as raw strings.

The operating system may kill the app process in background, and in-memory state is lost. Save draft form data to local storage, such as shared_preferences, Hive or a SQLite table, as the user types with a short debounce, and restore it when the screen opens. Flutter's RestorationMixin and restorationScopeId can restore simple UI state like scroll position and text fields. Clear the draft after successful submission.

Measure time to interactive on a release build first. Make sure Hermes is enabled, remove unused dependencies and heavy libraries like full date or icon packs, and lazy-load screens and modules with inline requires. Defer non-critical SDK initialisation until after the first screen. Keep the initial screen light, avoid large synchronous storage reads at startup, and use the New Architecture for faster native module loading.

The animation likely runs on the JS thread, and data parsing or re-renders block it. Move the animation to the UI thread with Reanimated or Animated with useNativeDriver, reduce the work done when data arrives by memoising components and normalising state updates, and delay heavy processing with InteractionManager or requestIdleCallback-style scheduling until the animation finishes. Profile with React Native DevTools to confirm.

First check whether a maintained wrapper package exists. If not, create a native module using the Expo Modules API or a TurboModule with a typed spec, add the SDK through Gradle and CocoaPods or Swift Package Manager, and expose a small JavaScript API with promises and events. If using Expo, write a config plugin to apply native setup during prebuild. Test on both platforms and document the setup.

Components are probably selecting large parts of state or creating new objects in selectors. Select only the fields each component needs with useSelector, memoise derived data with createSelector, and keep state normalised. Move server data to RTK Query or TanStack Query and local UI state back into components. Verify improvements with the React profiler, checking which components render after each action.

Check that the link configuration maps the URL path to the right screen name, including nested navigators, and that path parameters match. Verify verified link setup on both platforms: assetlinks.json for Android and the associated domains entitlement plus the site association file for iOS. Test with adb shell am start and xcrun simctl openurl. Also handle links when the app is cold started versus already running.

With React Native, Expo with Expo Router and React Native Web lets one codebase target Android, iOS and web, with file-based routes working as URLs. With Flutter, the web target exists but suits app-like experiences more than SEO-heavy pages. I would share business logic and most screens, keep SEO landing pages on a web framework, and plan for platform-specific tweaks like hover states and keyboard navigation.

A common cause is a race condition: several requests receive 401 at once and each triggers a refresh, so later refreshes use an already rotated refresh token and fail, logging the user out. Fix it by allowing only one refresh at a time and queueing other requests until it completes, then retrying them with the new token. Also check device clock issues, token expiry settings and secure storage read failures.

Check that the push notifications capability and background modes are enabled in Xcode, that an APNs authentication key is uploaded to the push provider, and that notification permission was granted. Verify the app gets an APNs token and the provider token, and that the right environment, development or production, is used. Test on a real device, since simulators have limited push support, and check payload format.

Find screens that listen to large collections or re-read data on every rebuild. Paginate queries with limits, listen only to needed documents, detach listeners when screens close, and avoid starting listeners inside build methods. Denormalise data to reduce reads per screen, cache data locally with offline persistence, and use aggregate count queries instead of reading all documents to count. Monitor usage per collection.

The app is probably treating the SDK's success callback as final and the verification call failed or was never sent, for example when the app was killed. Make the backend the source of truth: verify payments with the gateway's signature on the server and use webhooks to update orders even if the app never reports back. The app should poll order status after payment and show a pending state until confirmed.

The partner app sends location updates every few seconds through a foreground service to the backend, which publishes them to a real-time channel like WebSockets or Firestore documents. The customer app subscribes only while the tracking screen is open and smoothly animates the marker between points. Throttle updates, reconnect on network changes, and fall back to polling. Stop tracking when the delivery completes to save battery.

Ask for pagination with sensible page sizes, gzip or brotli compression, removing unused fields or providing screen-specific endpoints, and aggregated endpoints to avoid multiple sequential calls. Request proper cache headers and ETags so the client can reuse responses. Ask for resized images through a CDN and HTTP/2 or HTTP/3 support. Share measured timings from real devices to justify the requests.

Choose a strategy based on data. Last write wins, using server timestamps, is simple but can lose edits. Field-level merging keeps non-conflicting changes. For lists, treat each item as a separate record with its own version so edits rarely clash. For collaborative content, CRDT-based approaches merge automatically. Always let the server decide final order, and show users when their change was overwritten.

Profile on the budget device in profile mode. Common fixes: wrap frequently repainting areas in RepaintBoundary, avoid expensive effects like Opacity on large subtrees, clipping and shadows in scrolling lists, use AnimatedBuilder with child so static parts do not rebuild, precache images and decode them at display size, and move heavy computation to isolates. Reduce animation complexity on low-end devices if needed.

Flaky tests usually come from timing assumptions, shared state, network dependence or slow emulators. Replace fixed delays with waiting for specific conditions, mock or stub network calls with predictable responses, reset app data between tests, and use stable selectors like keys or test IDs instead of text that changes. Give CI emulators enough resources, retry only as a temporary measure, and track flaky tests separately to fix them.

Pause the staged rollout to limit impact. Filter crash reports by OS version and device to find the top stack trace, and check behaviour changes for that version, such as permission, background or edge-to-edge rules. Reproduce on an emulator of that version, fix it, add a regression test and resume rollout with a hotfix. Add that OS version to the regular test device matrix.

Measure cold start on a release or profile build and trace what runs before the first frame. Defer non-critical SDK initialisation such as analytics and ads, avoid large synchronous storage reads and network calls before showing UI, load the first screen with cached data, and lazy-load other features. In Flutter, keep main() light; in React Native, use Hermes and inline requires. Use a native splash screen to avoid a blank screen.

Start where bugs hurt most: write unit tests for business logic like pricing, validation and state transitions, and a few end-to-end smoke tests for login, checkout and payment flows with Maestro or integration tests. Run them in CI on every pull request so failures block merges. Require tests for bug fixes going forward. Show reduced regressions after a few sprints to build team support.

Move tokens to secure storage backed by Keychain on iOS and Keystore on Android, such as flutter_secure_storage or expo-secure-store. Migrate existing users by reading the old value once, writing it securely and deleting the plain copy. Shorten access token lifetime, use refresh tokens, exclude sensitive files from backups, and clear tokens on logout. Retest with the audit team to confirm the issue is closed.

Use analytics from the existing app or market data to identify the most common manufacturers, OS versions, screen sizes and RAM levels among your users. Cover a budget device with 3 to 4 GB RAM, a mid-range phone, a recent flagship, an older OS version you still support, and at least one iPhone and tablet. Use cloud device farms for wider coverage and add devices that generate many crashes.

This suggests a memory leak or growing work. Reproduce by repeating a flow many times while profiling memory and CPU. Look for listeners, timers or subscriptions that accumulate, caches without limits, lists that keep growing, or screens kept in the navigation stack. Fix by disposing resources, limiting cache sizes and replacing screens instead of pushing endlessly. Confirm memory returns to baseline after fixes.

Read the reviewer's message in App Store Connect carefully. Guideline 5.1.1 issues often involve requesting permissions without clear purpose strings, requiring sign-up for features that do not need an account, or missing account deletion. Fix the specific problem, for example improving usage description text or adding in-app account deletion, and reply in Resolution Center explaining the changes. Ask for clarification if the rejection is unclear.

Identify the SDK and what it collects using its documentation and the Play SDK Index. Update the data safety form to declare that data accurately, or configure the SDK to stop collecting it, or replace it if its behaviour is unacceptable. Update the privacy policy too. Then submit a new build if code changed. Keep an inventory of SDKs and their data practices to avoid future surprises.

If the bug is in JavaScript, fix it, test on a preview channel, and publish an over-the-air update to production with a staged rollout, keeping it compatible with the current runtime version. If it needs native changes, build a hotfix release, submit it, and request expedited review on iOS if justified. Meanwhile disable the feature with a remote config flag if possible, and halt the store rollout.

Keep one codebase and create a configuration per client with app ID, name, icons, colours, API base URL and feature flags, using Android flavours and iOS targets or schemes, or dynamic Expo app config. Automate builds for each client in CI with fastlane or EAS. Each client usually needs its own store account or listing, so document signing keys and access per client and automate metadata uploads.

The update probably used a native module or API that the older binary did not have, so JavaScript called missing native code. Prevent this by setting runtime versions tied to native code fingerprints, so updates only reach compatible builds. Roll out updates gradually, monitor crashes per update ID, and keep a rollback by republishing the previous update. Test updates on the oldest supported build before release.

Submit builds early, a few days before the planned date, and use manual release so you can publish the approved build at launch time. Ship the code behind a remote feature flag so the feature can be enabled on launch day without a new review. Keep a pre-approved build ready, follow store guidelines closely and include clear review notes and demo login details for reviewers.

The app may not be available for their device because the minimum OS version is higher than theirs, the device lacks a required hardware feature declared in the manifest, the app is not released in their country, or the device architecture is excluded. Check the device catalogue in Play Console and the deployment target on iOS. Decide whether supporting that segment is worth lowering requirements.

Release to internal testers and beta users first and collect feedback. Then roll out to 5 percent of production users, monitoring crash-free rate, ANRs, key conversion metrics and reviews for a few days, before moving to 20, 50 and 100 percent. Keep the redesign behind a remote flag to switch back without a release. Define rollback criteria in advance and communicate the plan to support teams.