Cross-Platform
React Native and Flutter — how each reaches the screen, what they genuinely share, and where the saving stops.
One Codebase, Two Platforms
The realistic saving is large but not total: most teams share 80–90% of the code and still keep native knowledge on hand for the last stretch, which is invariably the part users notice.
React Native
React Native runs your JavaScript or TypeScript and renders real native views — a Text becomes a UITextView or a TextView, not a canvas drawing. The result inherits platform behaviour for free: native scrolling physics, text selection, accessibility.
| Strength | Trade-off |
|---|---|
| React model and the npm ecosystem | You inherit npm's dependency churn too |
| Real native components | Small per-platform differences remain |
| Fast refresh, fast iteration | Heavy animation or list work can need native help |
| Shared skills with web teams | Debugging spans JS and native layers |
The obvious pick when you already have a React web team: the mental model, the state libraries and much of the logic carry straight across.
Flutter
Flutter takes the opposite route: Dart compiled ahead of time to native code, and every pixel drawn by its own rendering engine. It does not use the platform's widgets at all.
| Strength | Trade-off |
|---|---|
| Pixel-identical on both platforms | Nothing is free from the platform — it is all reimplemented |
| Smooth, consistent animation | Larger binary than a comparable native app |
| One rendering path, fewer surprises | Dart is another language for the team |
| Excellent for custom, branded UI | New OS UI conventions arrive when Flutter implements them |
Where the Saving Stops
Both frameworks let you drop to native through a module bridge, and every non-trivial app eventually does — for a sensor, a payment SDK, a media pipeline or a widget. At that point you are writing Kotlin and Swift again, plus the glue.
| Still per-platform | Even with one codebase |
|---|---|
| Permissions and privacy strings | Different models, different review scrutiny |
| Push notifications | Two services, two setups, two payloads |
| Background execution | Different rules, different limits |
| Store submission | Two accounts, two review processes |
| Deep links and widgets | Native configuration on both sides |
So the choice is not "one codebase or two" but how much of the work is the shared part. For a content or commerce app, most of it. For something built on the camera, sensors or tight platform integration, much less — and that is where native still wins outright.
Interview Questions
How do React Native and Flutter differ fundamentally?
React Native renders real platform views through a bridge, inheriting native behaviour. Flutter draws every pixel with its own engine, giving identical output on both platforms and using none of their widgets.
When is cross-platform the wrong choice?
When the app leans on the camera, sensors, heavy graphics or deep platform integration — the parts you would have to bridge anyway — or when platform-native feel is the differentiator.
What does a cross-platform team still need native skills for?
Permissions, push notifications, background execution limits, deep links, widgets, store submission, and any native module the app has to bridge.
Why might identical UI on both platforms be a downside?
Users expect their own platform's navigation, typography and gestures. An app that matches neither can feel foreign on both, even though it looks consistent to the team.
What makes React Native attractive to a web team?
It is React. The component model, hooks, state libraries and much of the business logic carry across, so the ramp for an existing web team is short.
How much code do teams actually share?
Typically 80–90% — logic, layout and most screens — with the remainder in native modules and per-platform configuration. The saving is large, but it is not the whole app.