There is no universally right answer, and anyone who gives you one without asking about your app is telling you what they like building. Four questions usually settle it.
The four questions
- 01Is the app mostly screens, forms and data, or does it live or die on graphics, camera or sensors?
- 02Do you need both platforms from day one, or is one enough to start?
- 03Who maintains it in two years, and what do they already know?
- 04Does it need to feel unmistakably like an iOS app, or does consistent-across-platforms serve you better?
React Native
Right when the app is largely screens and data, you need both stores, and your team already works in React. Sharing knowledge and often code with a web front end is a real advantage that gets undervalued.
Wrong when the app is graphics-heavy or depends on platform-specific behaviour. You can reach native through modules, and if you are doing that constantly you have chosen the wrong tool and are paying for the bridge anyway.
Flutter
Right when you want pixel-identical UI across platforms and are building something visually custom. It draws its own widgets rather than mapping to platform ones, which is a strength for a distinctive design.
Wrong when you want the app to feel native to each platform, or when your team has no Dart experience and no appetite to acquire it. That is a real hiring and maintenance consideration, not a technical one.
Native
Right when performance or platform integration is the product. Heavy camera work, real-time graphics, deep OS integration, anything that needs a new platform capability the day it ships.
Wrong as a default. Two codebases means two of everything: two builds, two release cycles, two sets of bugs, and usually two developers.
Cost, honestly
| Build | Maintenance | Platform feel | |
|---|---|---|---|
| React Native | One codebase | Lowest | Good, not perfect |
| Flutter | One codebase | Low | Consistent, deliberately not native |
| Native | Two codebases | Highest | Perfect |
The question people skip
Does this need to be an app at all? A large share of apps we are asked to build are catalogues, booking flows or dashboards that would work as a good mobile website, with no install friction and no review process.
Apps make sense when you need offline behaviour, push notifications, hardware access, or genuinely repeated use. Wanting to be on the App Store is not, on its own, a reason.
Working on something like this?
We build websites, stores and custom applications, and we will tell you honestly if the thing you are describing does not need one.