Cross-Platform interview questions
Cross-Platform questions a Mobile developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A Flutter screen rebuilds the whole tree on every keystroke. What is the first fix?
The strongest answer: Lift only the state that must change, rebuild the leaf (or use a targeted widget), and keep expensive work out of build()
Why it works: Exactly. build() should be cheap and local. Rebuild the thing that changed.
- Keep build() cheap.
- Rebuild the smallest widget that needs it.
- Do not parse or decode in build().
- Profile a release build before you rewrite the app.
A React Native list reshuffles items and several rows show the wrong image. What do you look at first?
The strongest answer: The key / identity of each row — if I used the index, recycled views will keep the wrong child state
Why it works: Exactly. Identity is how reuse stays honest. Index keys are a classic RN (and React) miss.
- Stable keys, not indexes.
- Virtualized lists reuse views — identity matters.
- Do not “fix” it by mounting everything.
- Same rule as React on the web.
How do you treat the Android system Back button versus iOS’s interactive pop?
The strongest answer: Back is a platform contract: it should leave the current task the way the user expects — usually pop, sometimes dismiss a sheet, never invent a custom “next” — and I test both platforms
Why it works: Exactly. Respect the platform’s exit gesture. Sameness of marketing copy is not sameness of navigation.
- Back / swipe-back means leave, not advance.
- Sheets and dialogs dismiss; stacks pop.
- Do not trap the user.
- Test Android Back and iOS pop separately.
Flutter needs a platform API the plugin ecosystem does not cover. How do you reach it?
The strongest answer: A small platform channel (or FFI where it fits) with a clear boundary, errors surfaced to Dart, and a test on both OS versions you claim
Why it works: Exactly. One boundary, typed errors, tested on both sides.
- Keep the native surface small.
- Surface errors; do not swallow them.
- Test iOS and Android.
- Prefer a maintained plugin when it exists.
A React Native app is still on the old bridge. When do you move to the New Architecture?
The strongest answer: When the libraries we depend on are ready and we have a perf / interop reason — I migrate on a branch, measure startup and lists, and keep a rollback; I do not flip it in a store hotfix
Why it works: Exactly. Default ≠ “flip on Friday.” Dependencies, measurement, rollback.
- Audit native modules first.
- Measure the lists and startup you care about.
- Ship behind a train you can roll back.
- Do not mix this with an unrelated hotfix.
A Flutter screen parses a large file and the UI freezes for about a second while it does. Why, and what do you do?
The strongest answer: Dart runs your code and the UI on one isolate, so a long parse blocks the frame loop. Move that CPU work to another isolate; making it async alone changes nothing because nothing is waiting
Why it works: Right — async helps when you are waiting on something; here the CPU itself is busy, so the work has to move.
- One isolate runs UI and code.
- CPU work blocks the frame loop.
- Move heavy parsing to an isolate.
- Async does not free the CPU.
A cross-platform codebase has is-iOS / is-Android checks scattered through the screens, and a fix for one platform keeps breaking the other. How do you organise it?
The strongest answer: Put the difference behind one interface the shared code calls, with the platform implementations at the edge, so a screen reads the same on both and each platform has exactly one place to change
Why it works: Exactly — shared code stays platform-blind, and the platform detail lives where the platform team can own it.
- Hide platform detail behind an interface.
- Shared code stays platform-blind.
- Implementations live at the edge.
- Never fork the screen.
A Flutter upgrade enables Impeller everywhere. What do you do before the store push?
The strongest answer: Exercise the GPU-heavy screens on the oldest devices you claim, watch for shader / precision bugs, and keep a measured rollback to the previous engine flag if the project still has one
Why it works: Exactly. Engine changes are device-matrix work. Measure, then ship.
- Test the visual-heavy flows on old GPUs.
- Compare jank and correctness.
- Know the rollback flag / version.
- Do not certify on a desktop only.
A native app will host one React Native flow. What do you insist on?
The strongest answer: A clear native ↔ RN boundary, one navigation owner, a shared design-token story, and a rollback that is “turn the screen back to native” — not a rewrite of the host
Why it works: Exactly. Brownfield works when the seam is boring and reversible.
- One seam, one nav owner.
- Shared tokens or an honest visual delta.
- Kill-switch back to native.
- Do not boil the host in the same PR.
An RN screen is slow and the team wants to “rewrite in native.” What do you do first?
The strongest answer: Profile: JS thread vs UI thread vs list bind vs images — many RN wins are the same as web (keys, memo, fewer crossings) and do not need a rewrite
Why it works: Exactly. Profile, then choose. Rewrite is a last mile, not a first reflex.
- Profile JS vs UI vs bind.
- Fix list and image costs first.
- Reduce bridge / native crossings.
- Rewrite only the hotspot you can name.
You will migrate a native app toward RN (or the other way) over a year. What does the programme look like?
The strongest answer: Seam by seam, with a kill-switch, a shared design language, and a definition of done per screen — not a freeze and a big-bang cutover on a holiday weekend
Why it works: Exactly. A programme is seams, switches, and done-definitions. Big-bangs are how you lose a year.
- Migrate a seam at a time.
- Keep a kill-switch.
- Define done per screen.
- Do not freeze the product for a rewrite.
Frontend web engineers will contribute to RN. What ownership model actually works?
The strongest answer: A mobile platform owner for native seams, store, and performance budgets; web engineers own JS features inside those rails — I do not pretend RN deletes native ownership
Why it works: Exactly. Rails and seams stay owned. Product JS can be shared. RN is not “just React.”
- Platform owns seams, store, budgets.
- Product owns JS inside the rails.
- Teach the store path; do not hand over the keystore on day one.
- RN is a team design, not a slogan.