In short
For most apps, cross-platform is the right default: one codebase, one team, both platforms at the same level. Native pays off when every millisecond counts, when a freshly released system feature is needed straight away, when the hardware itself is the point of the app, or when the interface has to feel native down to the last detail.
- The normal case
- Cross-platform
- Four clear exceptions
- Native
- Our stack
- React Native
-
The old kind: a website in an app shell
Cordova, Ionic and their relatives show a web page inside an embedded browser. You can feel it when you use one, and that is where the poor reputation of hybrid apps comes from.
-
Today's kind: the system's real controls
React Native and Flutter produce the platform's actual controls. There is no embedded browser. When people say cross-platform today, this is almost always what they mean.
-
Why this distorts the debate
A large share of the arguments against hybrid apps comes from the first kind and gets carried over to the second. The comparison below refers exclusively to today's kind.
| Cross-platform and native development compared by criteria | Cross-platform | Native |
|---|---|---|
| One for iOS and Android | One per platform | |
| One pass for both platforms | Two passes | |
| Maintain one codebase | Maintain two codebases | |
| Reach both platforms at once | One after the other, versions drift apart | |
| One team covers both | Separate iOS and Android developers | |
| Possible from the same codebase | Built separately | |
| Full, deeper access through native modules | Direct, with no intermediate layer | |
| Indistinguishable for the vast majority of apps | Everything the device can give | |
| Close, but not in every detail | Exactly the platform's conventions | |
| Only once the framework catches up | From day one | |
| Fully possible | Fully possible | |
| The same mechanisms of the system | The same mechanisms of the system |
-
Applications for running a business
Customer portals, sales tools, bookings, administration. What matters is the domain logic, not the last percent of performance out of the device.
-
A first product that still has to prove itself
While nobody knows whether the idea works, a double codebase is the most expensive risk in the project. One pass for both platforms gets you to real users faster.
-
Both platforms have to behave the same
When iOS and Android have to be at the same level, a shared codebase is the direct route there. Separate teams otherwise drift apart, and support notices first.
-
The team is small
Two native codebases need people for both platforms permanently. This is settled less by the project budget than by staffing across years.
-
Every millisecond counts
Games with demanding graphics, processing video or audio signals in real time, anything with a sustained high frame rate.
-
New system features from day one
When an app needs to build on a freshly released iOS or Android feature before the frameworks have caught up.
-
The hardware is the point
AR, 3D rendering, continuous sensor processing. You are coding close to the system here anyway, and the intermediate layer stops helping.
-
The interface has to feel native to the platform
When an app should feel like an Apple or Google app down to the last detail, the platform's own tools are the shorter path.
What does "hybrid" actually mean today?
The term covers two very different things. Older hybrid apps wrapped a website in a container, and you could tell from using them. Today's cross-platform frameworks such as React Native and Flutter use the system's real controls. When people talk about the drawbacks of hybrid apps, they usually still mean the first kind.
Do users notice whether an app is built cross-platform?
As a rule no, as long as each platform's interaction patterns are respected. It shows at the edges: in unfamiliar transitions, in gestures that feel different from usual, or when a native element was rebuilt instead of used.
How big is the performance difference really?
For lists, forms, maps and media playback it is not noticeable in everyday use. It becomes noticeable with sustained high frame rates, demanding graphics and heavy computation on the device. If you do not fall into that category, performance is not what decides this question.
Can cross-platform apps use every device function?
Yes. Whatever the framework does not provide, you add through a native module. The saving shrinks as you do, because for that piece you need knowledge of both platforms again.
Which framework do you recommend?
We work with React Native and Expo. What decided it was less the technology than the surroundings: plenty of people know JavaScript and TypeScript, so roles can be filled and held over years. Flutter is technically a good choice, but it requires Dart.
Can an existing native app be moved over?
Yes, and usually step by step: individual areas get replaced while the rest stays native. That is the lower-risk path, because the app stays shippable throughout.
What about App Store review?
Both kinds go through the same review. Cross-platform is not a reason for rejection. What gets rejected is what breaks the guidelines, regardless of what it was built with.
What does the difference cost?
The part of the sum that holds up is structural: one codebase instead of two, one team instead of two specialisations, and not only during development but across the whole lifetime. How large the saving turns out in a given case depends on the share of platform-specific features.