You're starting a new app — walk through the decision framework for native vs React Native vs Flutter vs KMM
The strongest answer never opens with a favorite framework — it opens with the four axes that actually decide the tradeoff, then walks a real case through them.
LEARN BY DOINGPut your intuition to work3 steps
You're starting a new app — walk through the decision framework for native vs React Native vs Flutter vs KMM
Use the lesson’s examples and explanation to check your idea.
Personal reflection. Nothing is sent to an AI service.This is less a technical question than a judgment question: can the candidate reason about a real business tradeoff instead of reciting a personal favorite stack? The strongest answers do not name a winner up front — they name the axes that decide it, and only then walk a concrete case through them.
#The axes that actually decide it
Four things matter far more than which framework is currently trending. Depth of platform integration required on day one — background Bluetooth, ARKit/ARCore, CallKit, home-screen widgets, anything that leans hard on the newest OS APIs — pushes toward native, or at minimum toward a cross-platform framework with a mature native-module escape hatch. Existing team skill is not a soft factor, it is often the single biggest cost driver: retraining a strong React team on Flutter's widget model, or a strong native Android/iOS team on JavaScript, has a real, multi-month cost that shows up in missed deadlines more than in the eventual quality of the app. How much of the app is custom, brand-heavy UI versus how much should simply look and feel like the platform matters because Flutter and React Native solve that differently — Flutter gives you pixel-identical rendering everywhere at the cost of reimplementing platform conventions, RN leans on real native components so platform look-and-feel comes closer to free. Long-term maintenance reality — will both native apps keep getting maintained regardless, is the team's real pain duplicated business logic rather than duplicated UI — is exactly the case KMM is built for and the other three options are not.
#A comparison worth having ready
| Axis | Native | React Native | Flutter | KMM |
|---|---|---|---|---|
| UI consistency across platforms | Low (by design) | Medium (real native components) | High (Flutter draws it all) | Low (native UI on each side) |
| Reuses existing web/JS skill | No | Yes | No (Dart) | No (Kotlin, and mostly for logic) |
| Access to brand-new OS APIs day one | Immediate | Delayed / needs a native module | Delayed / needs a plugin | Immediate (UI stays native) |
| What's actually shared | Nothing | UI + business logic | UI + business logic | Business logic only |
| Two native codebases to maintain | Yes (by definition) | No | No | Yes, on purpose |
#Framing that lands well in an interview
A senior answer resists the urge to pick a personal favorite and instead names the real cost being optimized. React Native and Flutter both trade some platform-native feel for one shared codebase and faster iteration — RN by leaning on real native views under a JS layer, Flutter by owning rendering completely. KMM does not try to unify UI at all; it accepts two UIs and two teams, and only removes the duplication that was never platform-specific to begin with. Native is not "the safe default," it is the right call specifically when the app's value proposition depends on being first to use a platform capability, or when the org has no appetite for a shared-codebase migration risk at all.