Mobile Fundamentals interview questions
Mobile Fundamentals questions a Mobile developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
The interviewer asks what happens when the user backgrounds your app. Which answer is strongest?
The strongest answer: The process can be paused, then killed at any time — I persist anything I would be sad to lose, and I do not assume timers or network calls finish
Why it works: Exactly. Lifecycle events are hints, not guarantees. Persist early; treat death as normal.
- Backgrounding is not a promise the process lives.
- Persist anything you cannot recreate the moment you leave the screen.
- Do not start unbounded work in a pause callback.
- Use the platform's background APIs when work must outlive the UI.
A web teammate asks you to “just shrink the website” into the app WebView. What do you say?
The strongest answer: A phone has different input, density, offline, and platform chrome — we adapt layout and touch targets; we do not pinch a desktop page and call it an app
Why it works: Exactly. Responsive is not a scaled desktop. Touch, safe areas, and offline still apply.
- Design for the handset, not a scaled desktop.
- Touch targets and safe areas are required.
- WebView can host a flow; it is not a substitute for platform basics.
- Same judgement a frontend engineer should already have.
VoiceOver / TalkBack lands on a toolbar icon that is only a glyph. What is missing?
The strongest answer: An accessibility label (and trait) that names the action — “Search”, not “image” — so a VoiceOver user can use the control
Why it works: Exactly. If a control does something, it needs a name. Glyphs are not names.
- Every action needs a spoken name.
- Hide true decoration from the a11y tree.
- Do not rely on colour or icon alone.
- Check the order, not only the label.
The user opens the app on a train with no signal. What should they see?
The strongest answer: The last good data I persisted, clearly marked if it may be stale, and a way to retry when they are back online
Why it works: Exactly. Offline is a first-class state: last good data, honesty about freshness, a retry.
- Show the last good data.
- Say when it may be stale.
- Offer retry; do not block the whole UI.
- Never let a network miss crash the process.
Marketing wants myapp://product/42. What do you warn them about?
The strongest answer: Custom schemes are easy to hijack and do not verify the domain — prefer verified App Links / Universal Links, and keep the scheme only as a fallback you control
Why it works: Exactly. Verified HTTPS links are the 2026 default. Schemes are a compatibility fallback.
- Prefer verified HTTPS app links.
- Treat custom schemes as fallback.
- Claim the domain in the well-known file.
- Test from a cold start on both stores.
A marketing link should open a specific product screen. What must be true?
The strongest answer: The app claims the URL (App Links / Universal Links or a documented custom scheme), the OS can route it, and the app maps that path to a real screen — including when the app was cold
Why it works: Exactly. Claim, route, map — and handle a cold start, not only a warm one.
- Claim the domain or scheme.
- Route on cold start as well as warm.
- Map path → screen with the ids you need.
- Test the link from Notes / Messages, not only from your own app.
The OS killed the app overnight. The user returns via a notification to a checkout screen. What should happen?
The strongest answer: I restore enough navigation and form state to put them back in checkout — or I land them somewhere honest if the session or cart is gone — and I tested process death, not only backgrounding
Why it works: Exactly. Death is common. Restore what you persisted, fail honestly, and test the kill.
- Test process death, not only onPause.
- Persist the back stack or a route + ids.
- If session/cart is gone, say so.
- Notification → dead process is a required path.
TalkBack reads the price, then the image, then the title, then a decorative star. What do you change?
The strongest answer: Traversal order and headings so the name comes first, hide the decorative star, and group the price with the product — I verify on a device, not only in a layout preview
Why it works: Exactly. Order, grouping, and hiding decoration are the work. Confirm with a screen reader.
- Name, then details.
- Hide decoration.
- Group related bits.
- Test with TalkBack / VoiceOver, not a screenshot.
The ad click happens before the app is installed. How do you still open the right screen after install?
The strongest answer: A deferred / install-referrer path: the store or a measured first-open handshake carries the context — I do not invent a unique device fingerprint to stitch the click
Why it works: Exactly. Use the official referrer / deferred-deep-link product. Do not rebuild IDFA with fingerprints.
- Use Play install referrer / the vendor’s deferred API.
- Do not fingerprint around ATT.
- First open must read the context once.
- Have a graceful miss if context is absent.
The cart badge in the tab bar says two items. The cart screen shows three. Each reads its own copy.
Why does this keep happening, and how do you structure the state?
The strongest answer: Each screen keeps its own copy, so they drift. Hold the cart in one place both screens observe, and let screens send actions to it instead of editing a copy
Why it works: Exactly — one owner of the state, many observers. Drift is impossible when there is only one copy to read.
- One owner of state; screens observe.
- Name the single source of truth.
- Screens send actions, not edits.
- Observe the state; never copy it.
The app module is a 20-minute compile. When do you split?
The strongest answer: When we can draw a real boundary (feature / data / design system) and CI will cache the modules — I do not “split” into circular modules that still compile as one blob
Why it works: Exactly. Modules are for boundaries and cache. Circles are theatre.
- Split on a real boundary.
- Make CI cache work.
- Avoid circular feature modules.
- Measure the compile, then split.
A designer’s card truncates at the largest Dynamic Type / font-scale. What is the bar?
The strongest answer: The task still works: wrap or reflow, do not clip essential text, and do not require a horizontal pan to read a price — I test the largest size we claim
Why it works: Exactly. Largest type is a supported configuration. Reflow beats pixel-perfect Figma.
- Reflow; do not clip the task.
- Test the largest font scale.
- Do not lock type to match a mock.
- Same bar as a responsive web page.
You are designing a checkout that must survive process death and a language change. What is the spine?
The strongest answer: A persisted, versioned UI model + a navigation restorer + idempotent checkout APIs — views are disposable; the model and the server are the source of truth
Why it works: Exactly. Disposable views, persisted model, idempotent pay. Language change is just another recreation.
- Persist a versioned model.
- Restore navigation from that model.
- Make pay idempotent.
- Treat recreation (death, rotate, locale) as one problem.
A deep link opens a paid screen. The user is logged out. What is the contract?
The strongest answer: Park the intent, authenticate, then resume — or refuse with a reason — and never leak the paid payload on a lock screen or in an unauthenticated WebView
Why it works: Exactly. Links are intents, not credentials. Park, auth, resume — or say no.
- Treat the link as an intent.
- Resume after auth.
- Explain a refuse.
- No secrets in the URL.
An App Clip / Instant App must do one job. What do you cut?
The strongest answer: Everything that is not that job — no unused SDK, no “while we are here” account graph — size and review are the product constraints
Why it works: Exactly. A clip is a scalpel. Weight and purpose are the design.
- One job, tiny binary.
- No souvenir SDKs.
- Same security bar as the app.
- Measure size on every clip build.
Leadership asks “native or Flutter / RN — pick one for the company.” How do you answer?
The strongest answer: With the portfolio: which apps, which hiring market, which native seams we already own, and a 3-year cost — not a slogan, and not a rewrite of a healthy native app to chase a tweet
Why it works: Exactly. Stack choice is a portfolio and a hiring plan. Slogans are how you pay twice.
- Name the apps and the seams.
- Count hiring and upgrade cost.
- Do not rewrite a healthy app for fashion.
- Write the 3-year cost, not a slogan.
You are writing the mobile interview loop. What must a senior still show besides syntax?
The strongest answer: Lifecycle and death, store / permission judgement, and a performance or offline story they actually owned — I do not hire only on a leetcode list adapter
Why it works: Exactly. Judgement on death, stores, and a real production story. Syntax is table stakes.
- Probe death, permissions, store.
- Hear a production story they owned.
- Do not make the loop a puzzle contest.
- Stack can be learned; judgement less so.
Marketing, growth, and three apps mint links that 404 after a refactor. What is the fix?
The strongest answer: A versioned link contract (hosts, paths, required params) with ownership, deprecation, and cold-start tests in CI — links are an API, not a spreadsheet in a brand deck
Why it works: Exactly. Links are a public API. Own them, version them, test them.
- Publish a link contract.
- Own deprecation.
- CI cold-starts the money links.
- Do not leave this in a brand deck.
What does “we are accessible” mean when you own several apps?
The strongest answer: A written bar (WCAG-inspired, platform a11y APIs, Dynamic Type, TalkBack / VoiceOver on the money paths), a gate, and time in the plan — not a vendor badge on the marketing site
Why it works: Exactly. A bar, a gate, and a plan. Badges without a gate are ads.
- Write the bar.
- Gate the money paths.
- Budget the work.
- Do not outsource this to a badge.
Should the iOS, Android, and RN packs live in one repo?
The strongest answer: When we share a design system, link contract, or CI paved road and we can isolate builds — a monorepo is a tool, not a virtue, and a junk drawer is worse than three repos
Why it works: Exactly. Share what is real. Isolate what is not. Do not cargo-cult a monorepo.
- Monorepo if the shared surface is real.
- Isolate builds so one app does not compile six.
- A junk drawer is a fail.
- Do not use the repo to force a rewrite.
Google / Apple deprecate a permission or a background API your product depends on. How do you run the year?
The strongest answer: A dated programme: replacement API, product change if the replacement is weaker, a min-OS story, and a comms plan — I do not “see what happens at the deadline”
Why it works: Exactly. Deprecation is a programme with a date. Hope is not a plan.
- Date the migration.
- Change the product if the new API is weaker.
- Do not freeze the toolchain.
- Communicate early to support and users.
You are asked for a 2-year mobile platform strategy. What are the first three pages?
The strongest answer: The product surfaces we owe, the store / privacy / security bars, and the paved road (CI, modules, flags, observability) — not a tool-by-tool shopping list
Why it works: Exactly. Surfaces, bars, paved road. Tools follow. Rewrites and vendor tables are appendices.
- Name the surfaces you owe.
- Write the bars (store, privacy, perf, a11y).
- Describe the paved road.
- Put tools and rewrites in the back, if at all.