Gym or coach app: booking, memberships, programmes and app store commissions
10 min read
Key takeaways
- Cross-platform is the reasonable default choice: it comfortably covers 80% of mobile projects.
- Native becomes relevant again as soon as hardware, latency or system integration are at the heart of the product.
- React Native is the best choice if your web team already exists; Flutter if the interface must be highly crafted and identical everywhere.
- The real cost of the technical choice is not initial development but hiring and maintenance over three years.
- None of these technologies will rescue a poorly scoped product.
This is the question that triggers the most debate in scoping workshops, and almost always for the wrong reasons. It gets answered out of technical conviction when it is an economic and organisational decision.
Here is how we actually decide, with the criteria we use and the cases where we recommend each approach.
What each approach really costs
| Criterion | Native (Swift + Kotlin) | React Native | Flutter |
|---|---|---|---|
| Initial cost iOS + Android | 1.6 – 1.8 × | 1 × | 1 – 1.1 × |
| Codebases to maintain | 2 | 1 | 1 |
| Immediate access to new OS features | Immediate | A few weeks to a few months | A few weeks to a few months |
| Reuse with a web team | None | Strong (TypeScript, React) | Low (Dart) |
| Hiring pool in France | Medium, expensive | Large | Medium, growing |
| Identical rendering on both platforms | Not by nature | Close | Yes by design |
The most important line is not the initial cost: it is the number of codebases to maintain. Over three years, maintaining two native apps structurally costs more than maintaining one, for the same scope.
Our decision tree
We ask four questions, in this order.
1. Does the product depend heavily on hardware?
Bluetooth Low Energy, real-time image or video processing, augmented reality, high-frequency sensors, watchOS, CarPlay, advanced system widgets. If so, native regains the advantage: otherwise you will spend your time writing native bridges, which amounts to doing native while paying for the abstraction.
2. Do you already have a React web team?
If you have TypeScript/React developers in-house, React Native opens up mobile to them within a few weeks, and you share business logic, types and part of the tests. It is often the decisive argument for SMEs and scale-ups: the subject is not the technology, it is not creating a second team.
3. Must the interface be highly crafted and rigorously identical everywhere?
A branded, heavily animated app, where the pixel matters and where a gap between iOS and Android is unacceptable: Flutter is made for this. It draws everything itself, so the rendering is the same everywhere, and its animation engine is excellent.
4. Is there a strong compliance or security constraint?
Healthcare, regulated payments, defence: native simplifies audits, reduces the surface of third-party dependencies and speeds up adoption of new security APIs. It is not mandatory, but it is a real argument in front of an auditor.
In practice, on our 2025-2026 projects: about 65% in cross-platform (two thirds of them React Native), 25% native, 10% openly hybrid — a cross-platform base with one or two native modules. "Pure" native remains a minority, but it has never gone away.
The false good reasons
"Native is faster." True on a test bench, invisible in a business app. The perceived slowness almost always comes from poorly handled network calls, unoptimised images and badly virtualised lists — three problems that native does not solve on its own.
"Cross-platform is a hack." That was not untrue in 2016. In 2026, React Native's modern architecture and Flutter's rendering engine have settled most of the historical grievances.
"We'll take Flutter, it's Google." The sponsor is not a guarantee. The real criterion is: will you find someone to take over this code in three years, at a rate you are willing to pay?
The best technical choice is the one your team — current and future — will be able to keep alive. Everything else is personal preference disguised as an engineering argument.
A strategy that almost always works
For a new product whose market is not yet validated:
- Start in cross-platform. You are going to throw away half of what you write anyway: you may as well throw it away only once.
- Isolate the business logic in a layer independent of the interface. That is what will let you change your mind without rewriting everything.
- Rewrite in native only what deserves it, when a specific need appears — and not before.
This approach is the one that minimises total cost over three years in the vast majority of cases we see. It also has the advantage of being reversible, which is rare in IT.
And the budget in all this?
The technical choice moves the budget by 20 to 40%, which is significant but less decisive than the functional scope. We detail the full breakdown in our article on the cost of a mobile app in 2026.
If you are unsure about your specific case, describe the product to us: we reply with a reasoned recommendation, including when it amounts to telling you that the question does not arise.
Sources
- About the New Architecture · React Native — React Native (Meta)
- Impeller rendering engine — Flutter (Google)
- Flutter architectural overview — Flutter (Google)
