Every comparison of these three measures startup time, bundle size and frames per second. Those numbers are real and they will almost never be the reason your project succeeds or fails. The decision is made by four questions that have nothing to do with benchmarks.
First: how deep into the hardware does the app go? Most apps need a camera, notifications, location and payments — all four are solved, well, in both Flutter and React Native, and choosing native for them is buying two codebases to solve a problem that doesn't exist. But the moment you need continuous background processing, Bluetooth peripherals, serious on-device media manipulation, or a platform feature the week it ships, cross-platform turns into writing native modules with extra steps. If more than a little of your app is native modules, you have chosen native without deciding to.
Second: what does your team already know? This is the question people are embarrassed to weight heavily, and it is usually the most predictive. React Native lets a web team ship a mobile app using the language, the mental model and often the state logic they already have — that is an enormous, real advantage, and it is not a compromise. Flutter asks everyone to learn Dart, which is a small, pleasant language, but it is a genuine cost and it is paid up front. Native asks for two specialists, permanently.
Third: how much does the design want to be itself? Flutter draws every pixel, which is precisely why it is the strongest choice for a branded, opinionated interface that should look identical on both platforms — a designer's layout survives the trip intact. React Native uses real platform components, which is precisely why it is the strongest choice for an app that should feel like it belongs on the phone it's running on. These are opposite virtues and neither is better; they answer different briefs. A banking app usually wants the second. A product with a strong visual identity usually wants the first.
Fourth: how long does this need to live, and who maintains it? A cross-platform app carries a dependency on a framework someone else controls — every OS release is a wait, and a major framework version is a migration. Over two years this is a non-issue. Over seven, it is a real line in the budget. Ask honestly which one you're building.
Two things that are not deciding factors, despite being argued about constantly. Performance: both frameworks are far past the threshold where users notice, for anything that isn't a game or a heavy media tool. And 'native feel': it is achievable in both, it just takes deliberate work, and a team that skips that work produces an app that feels wrong in any of the three.
Where we land in practice: React Native when there is a web team and a shared product surface, Flutter when the design is the product and both platforms must match, native when the hardware or the lifespan demands it. What we won't do is pick one because it's the one we like — the wrong framework is cheap to choose and expensive to leave.