Native or cross-platform: how to choose, and how React Native differs from Flutter
This choice gets argued as if one technology were better than the other. In practice context decides: what the app does with the hardware, what your team already knows, and how fast you need to ship. Here is how we work through it, without campaigning for a favourite framework.
Three questions that settle it
Before comparing frameworks, answer three questions. More often than not, the argument ends there.
- What does the app do with the device? Lists, forms, cards, payments and push — anything will do. Video processing, AR, Bluetooth peripherals or precise background location — native code becomes hard to avoid.
- Who maintains it in a year? A cross-platform project is maintained by one team. Two native apps need two, and they drift: a fix in iOS does not reach Android by itself.
- How important is launching on both platforms at once? If the business needs iOS and Android on the same date, cross-platform gives you that almost for free.
What "one codebase" means in practice
Not everything is shared. Logic, networking, data models and most of the interface are. What is tied to the platform is not: push setup, in-app purchases, permissions, deep links and system dialogs still have to be handled per platform.
So the saving is not "half the cost". A realistic view is that you save on the client interface, while the platform plumbing stays.
Where cross-platform genuinely breaks down
An honest list of situations where a shared codebase creates more problems than it solves:
- Heavy graphics and games: frame budgets, shaders, custom rendering.
- Real-time camera and audio work: filters, recognition, stream processing.
- Background modes and battery: both platforms restrict background work aggressively, and the workarounds are platform-specific.
- New platform APIs: widgets, system integrations and fresh iOS and Android features reach cross-platform frameworks with a delay.
- Apps whose interface must follow each platform's guidelines closely and differ between iOS and Android.
One caveat: cross-platform frameworks let you write native modules. The question is not whether you can, but how many you will end up with. If half the project is native inserts, the shared codebase has stopped paying for itself.
React Native and Flutter: the differences that matter
Both are mature, both are production-ready, and the choice rarely decides a project's fate. What does matter:
- Language. React Native uses JavaScript and TypeScript; Flutter uses Dart. If you already have a React web team, React Native saves months of learning and lets you share both code and people between web and mobile.
- How the interface is drawn. React Native uses the platform's native components, so an app looks closer to the system by default. Flutter draws its own interface, giving an identical result everywhere — useful for strong branded design, but system details have to be recreated by hand.
- Who is behind it. React Native is developed by Meta, Flutter by Google. Both are actively maintained; React Native has been through a large architecture rework in recent years, Flutter through a rendering engine change.
- Ecosystem. React Native inherits more libraries from the JavaScript world, with uneven quality. Flutter has fewer, but they tend to follow one style.
The fourth option people forget
Sometimes the right answer is not to build a mobile app. If the product does not need the camera, offline mode or push as its main channel, the web solves the problem faster and cheaper, and nobody has to install anything.
Two practical routes here: a progressive web app (PWA), installed to the home screen straight from the browser, and a Telegram Mini App if your audience is already on Telegram. The second is especially underrated — it removes installation, store review and sign-up in one move.
We build mostly web products and Telegram integrations ourselves: in Rivopost and Beatway, working with the Telegram API is part of the product core rather than an add-on.
How we make the call
The order is: list everything the app does with the device and mark the risky items. Then ask whether each is needed in the first version or can wait. Then work out who maintains the project a year from now.
If heavy graphics, background work or deep hardware access survive that filter, we go native for those parts. If not, cross-platform — and the choice between React Native and Flutter comes down to the team and the design requirements, not to abstract performance.
Changing this decision mid-project is expensive. Half an hour on the three questions above is worth more than a week of comparing benchmarks.
Questions people ask
Which is better, React Native or Flutter?
Both are production-ready. React Native suits teams already working in React and TypeScript. Flutter suits products that need an identical branded interface on every device. There is no abstract winner.
Are cross-platform apps slower than native ones?
For typical product apps the difference is not noticeable. It shows up where there is heavy graphics, animation or real-time data processing — games and media-heavy apps.
Can we start cross-platform and move to native later?
You can, but it effectively means rewriting the client. The backend and data survive, so migration is realistic — just do not plan it as "we'll rewrite it later".
Do we need a mobile app at all?
Not always. Without a need for the camera, offline use or push as the primary channel, a web app or a Telegram Mini App solves the problem faster and with no install step.
