Almost every cross-platform interview contains some version of "why React Native and not Flutter?" — and it is not a question about frameworks.
Interviewers ask it to find out whether you can make a technology decision for reasons that survive contact with a business, or whether you pick tools the way people pick football teams. The fastest way to lose the question is to answer it well from a purely technical angle, because the technical differences have narrowed considerably and everyone in the room knows it.
What genuinely differs
Strip out the marketing and the gap is narrower than a comparison article suggests, but it isn't zero.
| React Native | Flutter | |
|---|---|---|
| UI | Platform's own components, bridged | Draws everything itself with Skia |
| Consequence | Looks native because it is; platform updates arrive free | Pixel-identical across platforms; platform changes need Flutter to catch up |
| Language | TypeScript — most teams already have it | Dart — almost everyone learns it for this |
| Hiring | Any React developer is a partial hire | Smaller pool, usually more committed |
| Sharing with web | Real, if the web app is React | Possible, rarely the reason |
| Where it hurts | The native boundary — modules, upgrades, versions | Anything wanting to feel exactly like the OS, and app size |
The two rows that decide most real projects are language and hiring, and neither is about rendering. That's the insight the question is looking for.
The worked answer, React Native side
"We had a web product in React and four engineers who already wrote TypeScript every day. Choosing Flutter would have meant all four learning a language to ship the first version, and I'd have been trading three months of ramp for a rendering model that our app didn't need — we're a forms-and-lists product, not a graphics one.
What it cost us is real. The native boundary is where our time goes: two of our dependencies needed patching after an OS upgrade, and every native module is a small decision about whether to maintain it ourselves. If I'd known how much of that there'd be, I'd still have chosen the same, but I'd have budgeted for it instead of being surprised twice a year.
What would have changed my mind: if the design team had wanted a heavily custom UI identical on both platforms, the calculation flips — that's the thing Flutter is actually better at, and fighting it in React Native is miserable."
The worked answer, Flutter side
"We were starting fresh with no web codebase to share with, and two of the three engineers had no strong JavaScript background — so the 'you already know it' argument didn't apply to us.
The deciding factor was that our designers had built one system and wanted it to look the same everywhere, including the components that don't exist on both platforms. Flutter drawing its own widgets makes that the default rather than a fight.
The cost is that Dart is a hiring conversation every time — we've had good candidates hesitate because it's a language they'd only use here. And we waited on Flutter for one OS feature at launch, which we'd have had free with a native component.
If we'd had an existing React web app and a team already fluent in it, I don't think I'd have chosen Flutter, and I'd be suspicious of anyone who said they would without asking about the team first."
Both answers do the same three things, and that's what's being scored. They name a constraint that was specific to the situation rather than a property of the framework, they name what the choice cost, and they name the condition under which they'd choose the other one. An answer with all three reads as a decision; an answer with only the first reads as a preference that acquired a justification afterwards.
When you didn't choose it
Most candidates inherited the stack, and pretending otherwise is a bad trade — the follow-up questions will find it.
"It was chosen before I joined, so I can tell you the reasoning I was given and what I've concluded since. The reason was that the founding engineer knew React. Having worked in it for two years, I think it was right for the wrong reason — it did give us the ramp-up speed, but the actual benefit turned out to be that we share validation and API types with the web app, which nobody was thinking about at the time.
The thing I'd push back on today is our native module situation. We have four we maintain ourselves and two of them exist because someone needed a feature on a Friday."
That answers the question honestly and still demonstrates the judgement the question is testing, which is the point.
When you're moving between them
A common situation and an easy one to handle badly — usually by over-claiming transferable knowledge.
"I've written React Native for three years and I've been learning Flutter for the last few months. What transfers is most of it: the declarative model, thinking in components, state management as the actual hard part, the platform problems underneath. What doesn't transfer is Dart itself — I'm fluent in the syntax and I'm still writing it with JavaScript habits, particularly around streams and immutability. I'd expect to be slower than my RN self for a couple of months and I'd rather say that than claim otherwise."
Interviewers respond well to a specific, bounded admission. What they're wary of is someone who treats two years of one framework as two years of the other.
The comparison verdict
“Flutter's performance is better because there's no bridge, and the hot reload is much faster, so for any new project I'd pick Flutter.”
A stack-ranking with no situation attached. It also dates badly — the bridge argument has been partly overtaken by the new architecture — and betting an interview answer on a moving technical claim is avoidable risk.
The constraint, then the cost
“Four engineers already wrote TypeScript, and our app is forms and lists. Here's what that choice cost us, and here's what would flip it.”
Situation, trade-off, and a condition for changing your mind. The interviewer can now ask about the native boundary, the team, or the alternative — and all three are ground you've prepared.
The trap
Do not criticise the one you didn't choose beyond a specific, factual cost.
It's tempting, especially if the interviewer seems to agree, and it's a trap for two reasons. The person across the table may have built something substantial in it. And an engineer who is contemptuous about a mainstream tool is usually an engineer who will be contemptuous about the codebase they're about to join — which is a much more expensive problem than a framework preference.
The safe form is always about fit rather than quality: "it's better at the thing we didn't need" rather than "it's worse".
What to have ready
Three things, and they take about ten minutes to prepare:
- The constraint that actually decided it — team, timeline, design requirements, an existing codebase. Not a benchmark.
- The cost you've paid since. Something specific enough to have a date attached.
- The condition that would flip it. This is the sentence that makes the rest credible.
If you've only ever used one of them, that's fine and you should say so plainly — then answer the question about what you'd need to find out before choosing. An honest "I'd want to know the team's background and how custom the design is" is a better answer than a confident comparison built from blog posts.
The framework-specific loops themselves are separate, and both go deeper than this conversation does: React Native interview questions and Flutter interview questions. If the Dart half is what you're worried about, the language questions are here: Dart interview questions.
Practical target: write your "what would flip it" sentence first, then check it against reality — would that condition actually change your mind, or is it something that could never happen? A flip condition nobody could ever meet is the same as having none, and interviewers hear the difference immediately. The usable version names something that was genuinely close to being true on your last project.
