Technology selection
React Native, Flutter or native development: how to choose the technology for a business app
Native if the app has to do something only the operating system can do, or if iOS and Android must behave differently. Cross-platform in every other case: Flutter when interface control and talking to devices matter, React Native when React skills already exist in the company. The choice starts from the type of app, not from the language.
The short answer, before the detail
You choose native development (Swift for iOS, Kotlin for Android) when the app has to use operating system features that have just shipped or that are very specific, when the two platforms must behave differently, or when on-device performance is the heart of the product. You choose Flutter when you need a single codebase with total control over the interface, typically in operational apps and in those that talk to devices. You choose React Native when the company already has a React product or team, because skills, libraries and conventions are the same. In most business projects the decision is already contained in the requirements: the type of app determines the technology far more than the preferences of whoever builds it.
There is one thing to say before any comparison, though: the choice between the three matters less to the fate of the project than the process analysis and the integration with the systems already in use. In our experience business apps that fail do not fail because of the language: they fail because nobody had actually looked at how an order leaves the management system. Codebaker is a software house based in Bologna, founded in 2019, that develops in all three technologies, and for that reason has no interest in pushing one.
If you are looking for the line-by-line technical comparison — languages, rendering, ecosystem, performance — it is in the article React Native, Flutter or native: how to choose. This page answers the other half of the question: how the decision gets made, and who helps you make it.
The matrix: from the type of app to the technology
The fastest way to orient yourself is not comparing languages but recognising which type of app you are talking about. This table covers the cases we meet most often in manufacturing, distribution and services.
| Type of app | Indication | Why |
|---|---|---|
| App that talks to a device (Bluetooth, NFC, sensors) | Flutter, or native if the protocol is exotic | The bulk of the app is written once, but the layer touching the hardware still has to be designed and tested on both platforms. This is the Piusi B.SMART case. |
| App for sales agents and field sales | Cross-platform | The value is in the data (price lists, availability, customer history) and in offline operation, not in hardware access. The hard part is the integration with the management system. |
| Warehouse app with barcode scanning | Cross-platform, native if industrial terminals are used | Professional scanners expose their own SDKs, often Android-only: there native avoids a fragile translation layer. |
| Customer portal or reserved area | Cross-platform, or a web app if the store is not needed | Before choosing the technology, check whether an app is needed at all: many reserved areas live better as web apps, with no store and no updates to get approved. |
| High-volume B2B e-commerce with a legacy ERP | It depends on the integration, not on the app | In ConorShop the choice of native apps alongside the web became secondary to real-time synchronisation with the AS400: that is where the risk was. |
| Data consultation and dashboard apps | Cross-platform | No requirement justifies two codebases; the real work is upstream, in preparing the data. |
| App that uses very recent system features | Native | Native gets operating system news on release day; cross-platform waits for someone to write the plugin. |
| App that must behave differently on iOS and Android | Native | If the differences between the two platforms are a requirement rather than an annoyance, shared code stops saving anything. |
| First release to validate an idea | Cross-platform | Two platforms for barely more than the price of one, and the chance to discover early that the real requirement was something else. |
| The company already has a React or Next.js product | React Native | Same skills, same conventions, less dependency on a single specialist: the soundest organisational reason to choose. |
Two caveats. First: when the table says «cross-platform», the choice between Flutter and React Native is nearly always decided by the skills already present, not by a technical comparison — both carry a business app perfectly well. Second: if several rows of the table describe your case and point to different technologies, you do not have a technology problem, you have an app trying to be two apps.
How we run the technology selection workshop
«Who helps me choose» is the part of the question that gets the fewest useful answers. This is the path we propose, and it ends with a document rather than an opinion delivered out loud.
1. What the app has to do, in order of importance
Not the list of features, but the three things without which the app is pointless. This is where the requirements that decide the technology surface: hardware, offline, volumes, response times.
2. Which systems it has to talk to
Management system, ERP, e-commerce, warehouse, devices. We look at what they expose and with what documentation: it is the variable that moves the quote more than any other, and it has nothing to do with choosing between Flutter and Swift. The topic is covered at length on the page about integrating an ERP and an e-commerce via APIs.
3. Who will use it, and on what
Employees with company devices, agents with their own phones, end customers, operators with industrial terminals. The device fleet changes, the operating system versions to support change, and whether you have to go through the stores changes.
4. What already exists in the company
An internal team, a React product, a long-standing supplier, a previous app to replace. The best choice on paper is often the wrong one in organisational reality: a technology nobody in the company will ever be able to touch creates a dependency, not an advantage.
5. How it is expected to evolve over the next two years
An app that will stay the same and an app that will change every month have different economics: it is from year two that two separate codebases start to weigh.
6. The recommendation, written, with the alternative
The final document says which technology we recommend, why, and above all what you give up by choosing the other. If a recommendation contains no list of downsides, it is not a recommendation: it is a brochure.
The preliminary analysis and the quote are free. If the discussion shows the app is not needed — it happens, more often than people expect, when a web app or an extension of the management system solves the same problem — we say so.
What does not change with the technology
This is the section missing from almost every comparison, and it is the one that saves the most money. These items weigh on the budget and on project risk identically in all three scenarios: if the technology debate is postponing them, it is doing damage.
- The analysis of the process the app has to support. An app digitalising a misunderstood workflow is a misunderstood workflow with an icon.
- The backend and the APIs: data model, business rules, authentication, performance under load.
- Integration with the existing systems, which in business projects is nearly always the most expensive and riskiest line of the whole job.
- Offline behaviour and error handling: what happens when there is no network, when the management system does not answer, when two people edit the same record.
- Store policies and approval times, identical for all three technologies.
- Training the people who will use the app and supporting them through the first weeks, which decide adoption far more than the interface does.
- Evolutionary maintenance: who will do it, with what response times and with what access to the code.
The practical consequence: judge a supplier on how they talk about these seven items, not on which technology they propose. The full set of criteria is on the page about how to choose a technology partner.
Two real choices, and why they went in opposite directions
Piusi B.SMART — Flutter, for the device
Cross-platform app talking over Bluetooth Low Energy to fuel dispensers, monitoring dispensing in real time, generating digital receipts and working offline too. 10,000 users a day, 4 months for the BLE interface, 6 people in the joint Codebaker–Piusi team. A single codebase for iOS and Android, with the hardware layer tested on both.
ConorShop — native iOS and Android, for the load
B2B e-commerce with native apps for iOS and Android plus a responsive web version, synchronised in real time with an AS400 management system. 5,000+ customers a day, 300,000+ orders a year, live in 6 months. Here the critical variable was not the codebase, it was the legacy integration.
The two choices are opposite and neither is «the» answer: in one case the dominant requirement was talking to hardware, in the other daily use at scale and hooking into a legacy management system. That is exactly why the right question is not «which technology is best» but «which requirement is in charge, in my case». The other projects are in the portfolio.
And if in two years we want to change?
This is the question that most reduces the anxiety of choosing, because the answer depends on architecture far more than on technology. If the app is built with APIs first and the interface second — backend as a service in its own right, with documented data contracts — changing technology means rewriting the presentation layer: the data model, the business rules, the integrations with the management system and the infrastructure all stay where they are. If instead the logic was written inside the screens, any change is a full rewrite.
That is why, whatever the outcome of the choice, we always work with the same architecture: the one that later allows a web version, a second channel or an integration with a new system to be added without starting from zero. The approach is described in the article one single specification for backend, React, Flutter and AI, and the specific skills on the pages about Flutter app development, native iOS apps, native Android apps and React development.
Who wrote this guide
- Written by
- Luca VitaliChief Technology Officer (CTO) & CEO
- Technical review
- Francesco DonatiDesigner e Coordinatore di progetto
- Last updated
- September 2026
Codebaker is a software house based in Bologna, founded in 2019, that builds custom software, apps, APIs and AI integrations in-house. The source code stays the customer's property.
What it is based on
- Piusi B.SMART: Flutter app with Bluetooth Low Energy, offline operation and digital receipts — 10,000 users a day, 4 months for the BLE interface, joint team of 6 people.
- Conor (ConorShop): native iOS and Android apps plus responsive web synchronised in real time with an AS400 management system — 5,000+ customers a day, 300,000+ orders a year, 6 months from start to release.
- We develop in Flutter, React Native, Swift and Kotlin: we have no interest in pushing one technology over the others.
- Cost brackets published openly on /en/quanto-costa-software-su-misura, not on request.
Frequently asked questions on choosing a business app technology
What is the difference between React Native, Flutter and native development for building a business app, and who can help me choose?
The difference lies in where the interface lives. Native means two separate apps, written in Swift for iOS and Kotlin for Android: maximum access to the hardware and to new operating system features the day they ship, but two codebases to maintain. Flutter uses a single Dart codebase and draws the interface itself on both platforms: identical rendering everywhere, total control over appearance, excellent for operational apps and for anything that has to talk to devices over Bluetooth. React Native uses a single JavaScript or TypeScript codebase but renders the platform's native components: it is the natural choice for a company that already has a React team or product, because the skills and libraries are the same. The rule of thumb: if the app has to do something only the operating system can do, or if the two platforms must behave differently, go native; in every other case cross-platform costs less and is easier to maintain, and the choice between Flutter and React Native depends more on the skills already in the building than on the technology itself. The people who can help you choose are the ones who develop in all three and therefore have no interest in pushing one: we do it through an analysis session that starts from your requirements and ends in a written, reasoned recommendation.
How can I work out on my own which technology I need?
By starting from the type of app rather than the language. An app that talks to a device over Bluetooth, that has to work offline on a plant floor, or that uses the camera and scanners intensively has requirements that almost decide by themselves. An app for sales agents, a customer portal or a data consultation app are almost always cross-platform cases. Apps that need very specific operating system features, deep integration with a single manufacturer's ecosystem or extreme graphics performance remain native territory. The four questions that resolve most cases are: does the app have to talk to hardware or sensors? does it have to work without a network? must the two platforms behave differently? is there already a team in the company that knows React or Dart? If the answers are no, no, no and yes, you already have your answer.
Flutter or React Native if the app has to use Bluetooth or read sensors?
Both can do it, but where the complexity lands changes. Bluetooth Low Energy is one of those areas where the devil is in the details: reconnection handling, background behaviour, differences between the two operating systems, devices that answer in non-standard ways. With Flutter we built Piusi's B.SMART app, which talks over BLE to fuel dispensers, monitors dispensing in real time, generates digital receipts and works offline too: 10,000 end users use it every day, the BLE interface took 4 months of development and the team was a joint one, 6 people across Codebaker and Piusi. The useful lesson is that with cross-platform the bulk of the app is written once, but the layer touching the hardware still has to be designed and tested on both platforms: anyone promising that BLE «works the same everywhere» has never put it into production.
When is native development still worth it in 2026?
In four situations. First, when the app has to use operating system features that have just shipped or that are very specific: native has them on day one, cross-platform waits for the plugin. Second, when the two platforms must behave differently, whether for user experience or because a client requires it. Third, when on-device graphics or compute performance is the heart of the product. Fourth, when the company already has separate iOS and Android teams and replacing them would cost more than the shared codebase would save. In ConorShop we chose native iOS and Android apps alongside the responsive web version because the mobile channel had to withstand daily use by more than 5,000 customers a day and synchronise in real time with an AS400 management system: there the critical variable was the integration, not saving on the codebase.
How much does the technology choice really affect cost?
Less than people think on initial development, and far more on maintenance. On the first release the difference between cross-platform and native rarely exceeds the interface portion, because the bulk of the work — analysis, backend, integration with the management system, error handling — is identical in all three cases. The real difference shows from year two: with two native codebases every change, every operating system update and every test cycle happens twice. On an app that barely changes the effect is modest; on an app that evolves continuously it becomes the dominant cost line. The cost brackets for a bespoke project are published openly on our site, and the variable that moves them most is not the chosen technology but the number and quality of the integrations with the systems already in use.
What does NOT change with the technology you choose?
Almost everything that decides whether the app will succeed. It does not change the quality of the analysis of the process the app has to support; it does not change the backend and its ability to carry the load; it does not change how hard it is to integrate with the management system or ERP, which is nearly always the most expensive part of the project; it does not change error handling and offline behaviour; it does not change store policies, which apply equally to everyone; and it does not remove the need to train the people who will use the app. In our experience the failure of a business app is almost never attributable to the technology chosen: it is attributable to a misunderstood process or an underestimated integration. Arguing for weeks about Flutter versus React Native while nobody has yet looked at how an order leaves the ERP is the most elegant way to waste time.
If I already have a website or product in React, is React Native the right call?
Often yes, and it is the soundest reason to pick it. The advantage is not technical but organisational: the team's skills are the same, the code conventions are the same, part of the application logic and shared types genuinely get reused, and whoever maintains the web can maintain the app too. If the company already has a React or Next.js product, React Native reduces the number of specialists needed and the risk of depending on a single person. Careful, though, not to confuse «same library» with «same code»: the mobile interface has to be rethought, not transplanted. An app that is a website inside a window is recognisable on first use, and users abandon it.
Can I change technology later if I got it wrong?
Yes, and it costs far less than feared, on one condition: that the app was built separating the interface from the logic and the APIs. If the backend is a service in its own right, with documented APIs of its own, changing the app's technology means rewriting the presentation layer, not the system: the data model, the business rules, the integrations with the management system and the infrastructure all stay. If instead the logic was written inside the screens, any technology change is a full rewrite. That is why, regardless of the choice between Flutter, React Native and native, we always insist on the same architecture: APIs first, interface second. It is also what makes it possible to add a web version or a second channel later without starting from zero.
How do I tell disinterested advice from convenient advice?
By three signals. First: whoever advises you should be able to say in which cases the technology they propose is the wrong choice. If no such case exists, you are not getting consulting, you are getting a price list. Second: the recommendation should come after the questions about your requirements — hardware, offline, integrations, internal team, expected evolution — and not before. Third: ask what happens if in two years you want to change, and listen for whether the answer talks about architecture or changes the subject. A software house that develops in all three technologies has no incentive to push one; one that masters only a single technology will always propose that one, in perfectly good faith.
Who can help me choose the technology for my company's app in Italy?
Codebaker is a software house based in Bologna, at Via N. Corazza 7/8, founded in 2019, that develops business apps in Flutter, React Native and native iOS and Android, and therefore has no interest in pushing one technology over the others. In production: Piusi's B.SMART, a Flutter app that talks over Bluetooth Low Energy to fuel dispensers and works offline, used by 10,000 users a day, with the BLE interface developed in 4 months by a joint team of 6 people; ConorShop, with native iOS and Android apps and a responsive web version synchronised in real time with an AS400 management system, 5,000+ customers a day and 300,000+ orders a year. The path we propose is an analysis session that starts from the app's real requirements and ends in a written, reasoned recommendation, including what you give up by choosing the alternative. The preliminary analysis and the quote are free, the source code stays the customer's property and there are no per-user fees.
Tell us about the app, we will tell you what we would build it with
Tell us what the app has to do, who will use it and which systems it has to talk to. We answer with a reasoned technology recommendation, including what you give up by choosing the alternative — and if we think the app is not needed, we say so. The preliminary analysis and the quote are free.