The two options at a glance
| Native | Cross-platform | |
|---|---|---|
| What it is | Two apps, one in Swift for iOS and one in Kotlin for Android | One codebase, in React Native or Flutter, that produces both apps |
| Team | Two sets of platform skills | One team for both platforms |
| Shared work | Design and backend are shared. App code is written twice | Most app code is written once |
| Access to device features | Direct and immediate | Broad, through plugins. New or unusual features may need native code |
| Feel | Each platform's own controls and conventions, by default | Very close, with care. Some details need platform-specific work |
| Cost to build and maintain | Higher, since features are built twice | Lower for most apps |
When each one fits
Choose cross-platform when
- The app is built from screens, forms, lists, maps and media
- Both platforms must launch together
- One team will maintain the app for years
- You share logic or people with a React web product
- The budget must cover design, backend and the apps
Choose native when
- The app relies on heavy graphics, augmented reality or real-time audio and video processing
- You need a platform feature the day it is released
- The app works closely with hardware, such as Bluetooth devices with custom protocols
- The finest platform feel is itself the product
- You already have strong iOS and Android teams
The two can be mixed. A cross-platform app can include native modules for the one or two features that need them, and a native app can show cross-platform screens. Ask whether your hard feature can be isolated in this way before you choose native for the whole app.
Decide by your hardest feature
Most screens in most apps can be built well with either approach. The decision is made by the few features at the edge. List yours and check them against this table.
| Feature | Cross-platform | Notes |
|---|---|---|
| Sign-in, profiles, forms, lists | Well suited | This is the bulk of most apps |
| Push notifications, camera, maps, payments | Well suited | Mature plugins exist. Check store payment rules separately |
| Offline use with sync | Well suited | The difficulty is in the data design, not the framework |
| Background location or long-running tasks | Possible, with care | Platform rules differ, and testing on real devices is essential |
| Bluetooth devices | Possible | Standard profiles are straightforward. Custom protocols may need native code |
| Complex animation and custom drawing | Often suited | Depends on the framework and the effect. Prototype the hardest one first |
| Augmented reality, games, video editing | Usually native | These lean on platform graphics frameworks |
| Widgets, watch apps, system extensions | Native pieces | Commonly built natively and attached to the main app |
Frameworks move quickly. Treat the middle rows as questions to test with a short technical trial, not as fixed facts.
How the cost behaves over the life of the app
- The first release. Native means two builds of every feature. Cross-platform means one, plus a smaller amount of platform-specific work
- Every later feature. The same ratio repeats for as long as the app lives, which is where most of the difference accumulates
- Yearly system updates. Both approaches need testing and adjustment when Apple and Google release new versions. Cross-platform apps also wait for the framework and its plugins to catch up
- Dependencies. A cross-platform app relies on the framework and on community plugins. Choose well-maintained ones and budget for upgrades
- Hiring. Cross-platform skills overlap with web development. Native skills are more specialized on each side
If you already have a native app or a React web product
The comparison changes when you are not starting from nothing. An existing native app is an asset with tested code and users who know it. An existing React web product is an asset too, with developers and logic that a React Native app could share. The question becomes what to do with what you own.
Keep the native apps when
- They are stable, and the teams that built them are still in place
- The app leans on device features that took effort to get right
- New features arrive at a pace both teams can sustain
- A rewrite would deliver the same app, later
Move toward React Native when
- Every feature is being built twice, and the two apps drift apart
- One of the two native teams is hard to staff
- Your web product is in React and its developers could contribute
- The app is mostly screens and forms backed by your API
A move does not have to be a rewrite. React Native can be added to an existing native app one screen at a time, so new features are written once while proven screens stay as they are. The app in the stores remains a single app throughout, and the switch can stop at any point if it is not paying off.
Count the cost of running two technologies inside one app during the transition. It is real, and it is the reason to move in a planned order: new and frequently changed screens first, stable and device-heavy screens last or never.
A worked example
Three apps, three answers
The three products are invented to show how the hardest feature decides.
- A clinic booking appSign-in, booking, reminders, payment. Hardest feature, reliable notifications. Decision, cross-platform.
- A field inspection appForms, photos, offline work and sync. Hardest feature, conflict handling when two inspectors edit the same record, which is a data problem. Decision, cross-platform.
- A fitness app with live form analysisCamera frames analyzed in real time on the device. Hardest feature, sustained on-device processing. Decision, native for the analysis and its screens, with the rest shared where practical.
In two of three cases the hardest feature had nothing to do with the framework. In the third it decided the architecture.
A checklist to decide
Before you choose
0 of 8 checkedWhat to do next
List your features, mark the hardest and ask any company you speak with to explain its recommendation against that list. How to choose a mobile app development company covers the rest of that conversation.
We build both ways. See React Native development, iOS app development and Android app development, or send us your feature list and we will say which approach we would take and why.
Common questions
Are cross-platform apps slower than native apps?
For apps made of screens, lists and forms, users will not notice a difference when the app is built with care. Differences appear in demanding work such as heavy animation, real-time media or large computations. If your app has such a feature, test that feature early instead of relying on general claims in either direction.
React Native or Flutter?
Both are mature and widely used. React Native uses JavaScript or TypeScript and fits teams that also build for the web with React. Flutter uses Dart and draws its own interface, which gives consistent results across devices. Team skills and the libraries your features need usually decide between them.
Can we start cross-platform and go native later?
Yes. The backend, the design and what you learned about users all carry over. Individual screens or features can be moved to native code while the rest stays shared. A full rewrite is rarely needed and should be justified by a specific limit you have reached.
Does Apple or Google treat cross-platform apps differently?
The stores review the app you submit, not the tools that made it. Cross-platform apps are common on both stores. What matters to review is the same in either case, which is that the app works, respects privacy rules and follows the payment and content guidelines in force at the time.
