React Native, Native, or Flutter: How We Actually Choose.
A practical decision framework for picking a mobile stack, based on what the product does rather than which framework is fashionable.
Most stack debates are argued as if one option is universally correct. It is not that kind of question. Each of these is the right answer for a specific shape of product, and the useful skill is recognising which shape you have before writing code.
React Native, the default for most products
One codebase, both platforms, and a genuinely native feel when the architecture is right. For the majority of products, the things that determine whether an app feels good are navigation, state handling and list performance, and all three are solvable in React Native.
It is the right default when your product is primarily screens, data and flows: marketplaces, booking, social, commerce, dashboards, most SaaS companions. We shipped PaceFyndr on it, and it reached number 31 in App Store Health and Fitness.
The team argument matters too. If your web product is React, a React Native app shares language, patterns and often logic, and the same engineers can move between them.
Fully native, when the platform is the product
Go native when you are leaning hard on platform-specific capability: sustained background processing, deep hardware access, heavy on-device media or ML work, complex widgets and extensions, or anything where you need the newest OS feature the week it ships.
The cost is real. Two codebases, two sets of platform knowledge, two release cycles. That price is worth paying when the platform capability is the product. It is not worth paying because native is assumed to be faster in the abstract, which is rarely where perceived slowness comes from.
Flutter, and why we reach for it less
Flutter is good technology with a strong rendering model and consistent cross-platform output. Our hesitation is not technical quality, it is ecosystem fit. Dart is a separate language from the rest of most product stacks, so code and people stop being shared with the web side, and the native module ecosystem is smaller when you need something specific.
If your team already works in Dart, or you need pixel-identical rendering across platforms, it is a reasonable choice. For the teams we typically work with, React Native keeps more of the stack and the people in one place.
The question that actually decides it
Ask what your app does that could not be done on a website. If the answer is mostly about convenience, reach and being on the home screen, React Native is almost certainly right. If the answer names a specific platform capability, you are in native territory, or at least native modules inside a React Native shell.
That last option is underused. React Native does not have to be all-or-nothing: you can drop to a native module exactly where the platform demands it and keep the shared codebase everywhere else.
What this does not decide
Stack choice does not rescue a product nobody wants, and it does not fix unclear scope. Most apps that feel bad feel bad because of architecture and product decisions, not because of the framework underneath. Choose deliberately, then spend your attention on the flows people will actually use.
If you are weighing this for a specific product, we will tell you which case you are in before you commit to anything.