Flutter, React Native, or Native? Choosing Mobile App Technology for Your Business

Once you decide your business needs a mobile app, the next question almost always comes from a vendor or technical team: should it be built with Flutter, React Native, or natively for Android and iOS separately? To a business owner this sounds highly technical. Yet the answer affects upfront cost, release speed, the quality of the user experience, how easily you can hire developers, and maintenance costs for years to come.

This article does not try to crown one technology the winner. Every approach has its place. What matters more is understanding what you actually trade off when you choose one, so you can assess a vendor's recommendation critically and make a decision that fits your business needs rather than the development team's preferences.

Summary

• Native means two separate codebases, Swift for iOS and Kotlin for Android, with full access to device features and the experience that best matches each platform
• Flutter and React Native use one codebase for both platforms, so they are usually more economical for business apps with the same features on Android and iOS
• Flutter draws its own interface so it looks consistent on every device, while React Native uses each platform's built in interface components
• Kotlin Multiplatform is a middle path: business logic is shared, while the interface can stay native
• The best decision depends on the device features you need, the team that will maintain the app, integration with other systems, and the app's long term plans

Questions to answer before choosing a technology

Before comparing technologies, make sure a mobile app really is the right answer. For some needs, a web app or progressive web app is enough and far cheaper to maintain. An app installed from an app store makes sense when users open it repeatedly, need reliable notifications, make heavy use of the camera or location, or must work without a connection.

If a mobile app is needed, answer these questions first. The answers will narrow your options far more effectively than reading general technology comparisons.

• Who are the users: the general public, partners, or internal employees?
• Which devices do they use: mostly Android, mostly iPhone, or a mix?
• Which device features are needed: camera, barcode scanning, background GPS, Bluetooth, NFC, or other sensors?
• How important is it that the app feels exactly like each platform's built in apps?
• Must the app [work offline](/blog/kapan-aplikasi-perlu-bekerja-offline) and synchronise data later?
• Who will maintain the app after release: the vendor, an internal team, or both?

The native approach: two apps, full control

Native apps are built with each platform's official languages and tools: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. That means two codebases developed, tested, and maintained separately, usually by two groups of developers with different skills.

Native's strength is direct access to every capability of the device and operating system. When Apple or Google releases a new feature, native developers can use it right away without waiting for support from a third party framework. The user experience also matches each platform's conventions most closely, from navigation and gestures to accessibility.

The drawback is obvious: cost and time. Every feature is built twice. Every bug fix needs checking in two codebases. There is a risk the two versions slowly drift apart in behaviour if team coordination is not disciplined. For business apps made mostly of forms, lists, and reports, this extra cost often outweighs the benefit.

When native makes the most sense

• The app depends heavily on complex device features, such as real time camera or audio processing, Bluetooth with specialised hardware, or intensive background work
• Performance and smooth animation are the product's main differentiator
• The app targets only one platform, for example company issued Android devices for a field team
• The company already has established iOS and Android teams

Flutter: one codebase, consistent visuals

Flutter is an open source framework developed by Google that uses the Dart language. Its defining feature is that it does not use the platform's built in interface components. It draws every button, piece of text, and animation itself through its rendering engine. The result is an app that looks highly consistent across devices and operating system versions.

For business apps this consistency is often an advantage. The design agreed at the start looks the same on a low end Android phone and the latest iPhone, which simplifies visual testing. Flutter is also known for hot reload, which speeds up the development cycle, and a wide package ecosystem for common needs such as camera, maps, payments, and notifications.

There are a few things to weigh. Flutter apps tend to have a larger file size than simple native apps, which matters if your users have low end phones with limited storage. Because the interface is self drawn, it does not automatically follow changes in operating system styling; the team must adjust it deliberately. Dart is also rarely used outside the Flutter ecosystem, so its developers generally do not move across from web work.

React Native: building on the JavaScript ecosystem

React Native is developed by Meta and uses JavaScript or TypeScript with the React patterns widely used in web development. Unlike Flutter, React Native displays the platform's own interface components, so buttons and other elements feel like they belong to iOS or Android respectively.

Its biggest advantage lies in the ecosystem and the team. If your company or vendor already builds websites and dashboards with React, some knowledge, tooling, and even logic code can be shared. Hiring developers who understand JavaScript and TypeScript is also relatively easier because the talent pool is large. React Native's newer architecture also improves communication between JavaScript and native code, which used to be a frequent source of performance issues.

On the other hand, React Native apps rely more on third party libraries for device features. The quality and maintenance of those libraries vary. When React Native or the operating system is updated, some libraries may lag behind and need replacing or patching. Discipline in choosing dependencies matters, in line with the principles of software supply chain security.

Kotlin Multiplatform: shared logic, native interface

An option discussed more and more is Kotlin Multiplatform from JetBrains. Its approach is different: what is shared between Android and iOS is the business logic, such as data validation, price calculation, synchronisation, and server communication. The interface can still be built natively on each platform, or shared as well with Compose Multiplatform.

This approach suits apps whose logic is complex and must be identical on both platforms, while the user experience should still feel native. The trade off is that the team still needs iOS skills for the iPhone interface, so the savings are smaller than with a fully cross platform framework.

A business comparison

Upfront cost and release speed

For apps with the same features on Android and iOS, Flutter and React Native generally require less effort than building two native apps. But the savings do not mean the cost is halved. Design, backend, integration, testing on real devices, and the App Store and Google Play release process still have to be done for two platforms. An honest estimate counts all of these, as explained in our article on the real cost of a software project.

User experience quality

For most business apps, such as ordering apps, customer apps, sales team apps, or attendance apps, users will not tell a well built Flutter or React Native app apart from a native one. Differences only show in apps with complex animation, very intensive interaction, or advanced device features. The team's quality of execution matters far more than the choice of framework.

Long term maintenance

A mobile app is never truly finished. Operating systems update every year, app stores change their requirements, and libraries need upgrading. A single cross platform codebase means one place to update, but also dependence on the framework's release cycle. Native apps do not depend on a third party framework, but updates have to be done twice. Budget for maintenance after launch from the start, whichever you choose.

Developer availability and vendor lock in

Consider who could continue the work if your current vendor were no longer available. A technology that is popular in the local and international job market reduces the risk of being locked into one vendor. Make sure your contract states that the source code, app store developer accounts, and app signing keys belong to your company, as discussed in key points of a software development contract.

A short selection guide

• A business app with standard features on two platforms and a limited budget: Flutter or React Native
• A team or vendor already strong in React that wants to share knowledge with a website or dashboard: React Native
• A custom visual design that must look identical on every device, including low end Android: Flutter
• Complex business logic that must be identical, with a native interface: Kotlin Multiplatform
• Very specific device features, critical performance, or a single platform: native

What matters more than the framework

Many app projects run into trouble not because of the wrong framework but because of everything around it. A rushed backend and API make the app slow and hard to extend. There is no testing on real devices over slow networks. The initial scope is too big, so the first release keeps slipping. An MVP approach that starts small helps validate needs before a large investment.

Also make sure the app connects properly to existing systems such as the ERP, CRM, or point of sale. A standalone mobile app without integration often adds double data entry. Plan a notification and retention strategy too, so the app is actually used after it is downloaded.

Questions for prospective vendors

1. 01Why is this technology recommended for our needs, and what are its weaknesses in our case?
2. 02Which device features need extra native code or third party libraries?
3. 03How is the app tested on real devices, including low end phones and slow networks?
4. 04What is the update process when the operating system or framework version changes, and roughly what does it cost?
5. 05Who owns the source code, the app store accounts, and the signing keys?
6. 06Could another team continue development with the documentation handed over?

Conclusion

Flutter, React Native, Kotlin Multiplatform, and native can all produce good business apps. The right choice depends on your users, the features you need, the team that will maintain it, and the app's long term plans. Start from business needs, ask the vendor to explain the reasons and weaknesses behind their recommendation, and budget for maintenance from day one. That way your technology decision becomes a business decision you can stand behind.