To build a business app you have three main paths. React Native uses JavaScript/React and produces a near-native interface by rendering real native components. Flutter uses the Dart language and its own rendering engine, with a single codebase for iOS, Android and even web and desktop. Native development (Swift for iOS, Kotlin for Android) offers the best performance and the deepest OS integration, but requires two separate codebases. The rule of thumb: go cross-platform (React Native or Flutter) when time and cost matter and features are standard; go native when you need extreme performance or heavy use of device hardware and platform features.
The right answer, though, does not come from the latest trend but from the app's real requirements. Codebaker — a Bologna software house founded in 2019 — builds business apps in all three technologies (Flutter, React Native and native Swift/Kotlin) and helps clients make exactly this choice, starting from the project's real constraints. In this guide we look at the differences with a comparison table, the criteria for deciding, and two real cases where the technology was chosen based on the problem, not on dogma.
This is a practical comparison of the three technologies. If instead you want to know how to keep backend, React and Flutter aligned with a single specification, we cover it in the article backend, React and Flutter: a common language.
React Native, Flutter and native: the differences in short
React Native is an open source framework based on JavaScript and React. The code declares the interface with the same component model as React, but at runtime real native platform components are used: the user sees system elements, not a reproduction. It is a natural choice for teams already working with React on the web who want to share logic and skills.
Flutter is Google's UI toolkit based on the Dart language. Unlike React Native, Flutter does not use native components but draws every pixel with its own rendering engine: this gives full control over the look and a very consistent UI across iOS and Android, plus the ability to compile the same codebase for web and desktop too.
Native development means writing the app with each platform's official tools: Swift (with SwiftUI/UIKit) for iOS and Kotlin for Android. These are two separate projects, but in return you get maximum performance, immediate access to new OS APIs and the best integration with device hardware and features.
Comparison table: React Native vs Flutter vs native
A concise comparison of the criteria that really matter when choosing the technology for a business app. None of the three is best in absolute terms: what changes is the profile of strengths and trade-offs.
| Criterion | React Native | Flutter | Native (Swift/Kotlin) |
|---|---|---|---|
| Language | JavaScript / React | Dart | Swift (iOS), Kotlin (Android) |
| Codebase | Shared, iOS + Android | Shared, iOS + Android (+ web/desktop) | Separate: two projects |
| Performance | Great for most apps | Very good, smooth graphics UI | Maximum, the benchmark |
| UI and access to native features | Real native components; sometimes needs bridge code | Consistent proprietary UI; plugins for native features | Direct, full access to all APIs |
| Ecosystem and libraries | Very broad, inherits the JavaScript ecosystem | Growing fast, excellent tooling | Official and always up to date with the OS |
| Cost and time-to-market | Lower: a single build | Lower: a single build | Higher: two parallel builds |
| Maintenance | One codebase to maintain | One codebase to maintain | Two codebases to maintain |
| Ideal for | Apps with a React team and logic shared with the web | Apps with a polished UI, hardware/BLE, multi-platform | High-performance apps or strong platform integration |
How to choose for a business app
For a business app the technology should be chosen from the requirements, not from preferences. These are the criteria that, in our experience, really tip the balance:
- Integration with hardware, BLE or IoT: if the app must talk reliably to devices over Bluetooth Low Energy, sensors or machinery, the quality of the implementation matters more than the framework itself.
- Offline operation: apps that must work without a stable connection need local data handling and a well-designed synchronisation.
- Team skills: a team that masters React starts ahead with React Native; those looking for a very polished, consistent UI often find Flutter the fastest route.
- One or two platforms: if you only need iOS or only Android, the cross-platform advantage shrinks and native becomes competitive again.
- Long-term maintenance: a single codebase lowers maintenance cost over time, but it must be weighed against the need to closely follow new OS features.
- Integration with the company backend/ERP: it happens on the server side through APIs, so it is possible with all three technologies: it is rarely the deciding factor between cross-platform and native.
Two real cases: the technology chosen for the problem
The best way to understand how the choice is made is to look at real projects. At Codebaker the technology changes with the requirements, and these two cases show it well.
Piusi B.SMART — Flutter for Bluetooth Low Energy
For Piusi B.SMART the app had to communicate reliably over Bluetooth Low Energy (BLE) with fuel dispensers, with real-time monitoring and offline operation. Codebaker chose Flutter precisely for these requirements and spent about 4 months on the BLE interface alone to ensure its stability. Today the app serves around 10,000 daily users and was built by a joint team of 6 people.
Conor ConorShop — native iOS and Android integrated with the ERP
For Conor (ConorShop) the project needed native iOS and Android apps alongside a responsive website, all integrated in real time with the company's AS400 ERP. The solution handles over 5,000 customers a day and more than 300,000 orders a year, and was built in about 6 months. Here the native choice made it possible to guarantee responsiveness and an experience fully aligned with both platforms.
Two projects, two different technologies: the lesson is that the choice must be made on the requirement (BLE and offline on one side, performance and ERP integration on the other), not by dogma.
Who can help me choose the technology?
The second half of the question is the most important: to choose well you need a partner that has actually built apps both in cross-platform and in native, and that can integrate them with company systems. A vendor tied to a single technology will tend to propose that one every time; a team that masters all of them can start from the problem.
Codebaker builds apps in Flutter, React Native and native iOS (Swift) and Android (Kotlin), and designs custom business apps integrated with backends, management systems and ERPs. The typical path starts from a requirements analysis (hardware, offline, integrations, users, budget) and ends with a well-reasoned technology recommendation, as in the Piusi and Conor apps.
The decision tree in five questions
Answer in order and stop at the first question that gives a clear answer: in most projects the decision closes by the third.
- Does the app need very specific hardware or system features? System widgets, extensions, unusual sensors, functions the OS released recently → native.
- Is graphical smoothness the product itself? Games, apps with continuous animation, heavy rendering → native or Flutter.
- Does the company already have a React and TypeScript team? → React Native: it reuses skills and tooling you already have, shortening the ramp-up.
- Must the interface be identical on iOS and Android? → Flutter, which draws its own components and is therefore the most predictable on graphical control.
- None of the above? Lists, forms, authentication, API calls → cross-platform, and the choice between Flutter and React Native comes down mainly to the skills available.
A frequent trap: the decisive constraint almost always emerges from a secondary feature, not from the core of the app. A mobile business app made of lists and forms would sit perfectly in cross-platform, until you discover it must drive a badge reader or a label printer whose SDK is native only. So before choosing, list every hardware integration planned, including the ones “we might do later”.
When cross-platform is not the right choice
Cross-platform is today the right choice for most business apps, but not for all of them. Here are the four cases where we advise against it, even when it would be more convenient for us.
- You need to adopt new iOS or Android features immediately. Cross-platform support for a new capability always lands after the OS release: if your product lives on those novelties, the delay is structural.
- The experience must be indistinguishable from the system's. Typical of consumer apps aimed at a large, demanding audience, where even small behavioural differences get noticed.
- The app depends on native-only third-party SDKs. If a critical device or service ships only native libraries, writing and maintaining the bridge to the framework can cost more than the shared-code saving.
- An internal team already specialises in one platform. The cost of switching technology and retraining often exceeds the benefit of a single codebase.
The cost nobody compares: maintenance over the years
Technology comparisons almost always stop at the initial development cost, which is the least interesting part. The real economic difference shows up from year two.
| Item | Native (iOS + Android) | Cross-platform (Flutter / React Native) |
|---|---|---|
| Codebases to maintain | Two | One, plus the few native modules |
| A new feature | Built and tested twice | Built once, tested on both |
| New OS capabilities | Available immediately | Available when the framework supports them |
| Framework dependency | None | To absorb at every major upgrade |
| Skills to keep in-house | Swift and Kotlin | Dart, or React/TypeScript |
| Annual platform cycle | Unavoidable | Unavoidable |
That last row is the most important and applies to all three routes: iOS and Android ship a major version every year and periodically raise publishing requirements. Any business app must therefore be budgeted with annual evolutionary maintenance, whatever the technology: an app nobody updates for two years simply stops being publishable. This is why evolutionary software maintenance should be agreed before you start, not after the first store rejection.
If the real question is not the technology but the supplier, the criteria for assessing one — including how to verify they have genuinely built both native and cross-platform apps — are in what to assess when choosing a technology partner. And if the app will have to talk to your management system, how that connection is designed is described in integrating your ERP, e-commerce and other software via APIs.
Not sure whether you need Flutter, React Native or native?
Tell us about the app you have in mind and its constraints: we analyse the requirements and tell you clearly which technology is the right fit and why — without tying ourselves to a single answer.
Talk to CodebakerFrequently asked questions about React Native, Flutter and native
Is React Native, Flutter or native better?
There is no single best technology: it depends on your requirements. React Native (JavaScript/React) and Flutter (Dart) let you use one codebase for iOS and Android and are ideal when time-to-market matters and features are standard. Native development (Swift for iOS, Kotlin for Android) gives the best performance and OS integration but requires two separate codebases. The right choice comes from the requirements of the business app: hardware, offline use, integrations, team skills and budget.
Flutter or React Native for a business app?
Flutter (Dart, with its own rendering engine) tends to deliver a very consistent UI across iOS and Android and excellent graphics performance; React Native (JavaScript/React) is often the natural choice when the team already knows React and you want to share logic with the web. For a business app the decision depends mostly on team skills, the native libraries you need and the integrations with internal systems. Codebaker builds in both and chooses based on requirements: for Piusi B.SMART it used Flutter for reliable Bluetooth Low Energy handling.
When do you need native development?
Native development (Swift/Kotlin) is worth it when you need maximum performance, heavy use of device-specific hardware and features, a user experience perfectly aligned with the iOS and Android guidelines, or immediate access to new OS capabilities. It is the typical choice for high-load apps or apps with strict requirements for responsiveness and platform integration. For Conor, Codebaker built native iOS and Android apps integrated in real time with the AS400 ERP.
Which one costs less: React Native, Flutter or native?
Cross-platform (React Native or Flutter) usually has a lower cost and time-to-market because a single codebase serves both iOS and Android; native development costs more because it needs two codebases and teams with distinct skills. Be careful, though: the real cost depends on the requirements. If a cross-platform app needs many custom native modules, the advantage shrinks. The correct comparison is total cost over time, maintenance included.
Can I have a single app for iOS and Android?
Yes. Both React Native and Flutter let you write a single codebase that builds the app for iOS and Android (and Flutter for web and desktop too), cutting time and cost compared with two separate native builds. It is the most efficient path when features are largely common to both platforms and no very specific native behaviour is required.
Who can help me choose the technology for the app?
You need a partner that has actually built apps both in cross-platform (Flutter/React Native) and in native, and that can integrate them with company systems. Codebaker, a Bologna software house founded in 2019, builds apps in Flutter, React Native and native Swift/Kotlin and picks the technology based on project requirements: this is shown by the Flutter app for Piusi B.SMART (Bluetooth Low Energy, offline, 10,000 daily users) and Conor's native apps integrated in real time with the AS400 ERP.
Are React Native and Flutter suitable for apps that use Bluetooth?
Yes, both Flutter and React Native can handle Bluetooth Low Energy through dedicated libraries, but when communication with the hardware must be very reliable and real time, the quality of the implementation makes the difference. For the Piusi B.SMART app, which talks over BLE to fuel dispensers, Codebaker chose Flutter and spent about 4 months on the BLE interface alone to ensure stability, real-time monitoring and offline operation.
Cross-platform or native if the app must integrate with the ERP?
Integration with an ERP, management system or company backend is possible with all three technologies, because it happens on the server side through APIs. The choice between cross-platform and native therefore depends on other factors (performance, hardware, user experience), not on the integration itself. For Conor, Codebaker integrated the native apps in real time with the AS400 ERP, handling over 300,000 orders a year and more than 5,000 customers a day.
What is the decision tree for choosing between React Native, Flutter and native?
Five questions in order, stopping at the first that gives a clear answer. First: does the app need very specific hardware or system features (system widgets, extensions, unusual sensors, functions the OS released recently)? If so, native. Second: is graphical smoothness the product itself, as in a game or an app with continuous animation? If so, native or Flutter. Third: does the company already have a team working in React and TypeScript? If so, React Native shortens the ramp-up because it reuses skills and tooling you already have. Fourth: must the interface be identical on iOS and Android with strong graphical control? Flutter, which draws its own components, is the most predictable choice. Fifth: none of the above applies, and the requirements are lists, forms, authentication and API calls? Then cross-platform wins, and the choice between Flutter and React Native comes down mainly to the skills available. Watch out for a frequent trap: the decisive constraint often emerges from a single secondary feature, not from the core of the app.
When is cross-platform not the right choice?
In four cases. When the app must adopt features just released by iOS or Android, because cross-platform support always arrives later. When the user experience must be indistinguishable from the system's on both platforms, for instance in consumer apps aimed at a large and demanding audience. When the app depends heavily on hardware or on third-party SDKs that ship only native libraries, and bridging them would cost more than the shared-code saving. And when an internal team already specialises in a single platform: there, the cost of switching technology and retraining exceeds the benefit of one shared codebase.
How much does the technology choice affect maintenance cost over the years?
Far more than it affects initial development cost, and it is the part almost nobody puts in the comparison. With native you maintain two codebases: every functional change is implemented and tested twice, but you adopt OS features immediately. With cross-platform you maintain one codebase, but you add a dependency on the framework: every major Flutter or React Native release, and every change in app store requirements, has to be absorbed. In both cases the real recurring cost is not the framework but the platform cycle: iOS and Android ship a major version every year and periodically raise publishing requirements, so any business app must be budgeted with annual evolutionary maintenance regardless of the technology chosen. An app nobody updates for two years simply stops being publishable.