Flutter vs React Native is the right question if you need one app on both Android and iPhone, built by one team on one budget. Choose React Native if your developers already work with JavaScript and React, for example on your web app. Choose Flutter if you want a consistent, custom-designed interface on every device and one toolkit that covers most needs out of the box. Go native, with Swift for iOS and Kotlin for Android, when the app depends heavily on device features or the newest operating system capabilities.
For typical business apps in Indonesia, such as ordering, field sales, membership, booking or delivery tracking, either cross-platform framework is a sound choice. The bigger risks usually sit elsewhere: performance on the entry-level Android phones your users actually carry, payment integration, and maintenance after launch.
Before choosing a framework, it is worth confirming that you need a custom app at all; our guide to custom software vs off-the-shelf covers that decision. If you do, here is how the options compare.
How the three approaches work
All three can produce fast, polished apps. The difference is in how your code becomes what users see, and that drives cost, hiring and long-term maintenance.
Native: Swift for iOS, Kotlin for Android
Native apps are written with each platform's own language and tools: Swift with SwiftUI or UIKit for iPhone, Kotlin with Jetpack Compose or Android Views for Android. You get full access to every device feature, and new platform features as soon as Apple and Google release them. The price is two codebases, usually two specialist skill sets, and most features built and tested twice.
Flutter: one codebase, its own rendering engine
Flutter, created by Google, uses the Dart language and draws every pixel of the interface with its own rendering engine instead of the platform's built-in components. The app therefore looks and behaves the same on every device, which suits brand-led designs. Device features are reached through plugins, and when no plugin exists, developers write a small piece of native code.
React Native: JavaScript with native components
React Native, created by Meta, lets developers write the app in JavaScript or TypeScript using React, the same library behind many web front ends. It renders real native interface components, so the app follows each platform's conventions by default. It can use the very large JavaScript package ecosystem, and toolchains such as Expo simplify building, testing and releasing.
There are middle paths as well. Kotlin Multiplatform lets teams share business logic between Android and iOS while keeping native screens, and a responsive web application can be enough when users only need occasional access.
Flutter vs React Native side by side
| Factor | Flutter | React Native |
|---|---|---|
| Language | Dart | JavaScript or TypeScript with React |
| How the interface is drawn | Its own rendering engine, identical look on every device | Native platform components, follows each platform's style |
| Device features | Official and community plugins, plus custom native code | Community and Expo modules, plus custom native code |
| Sharing with the web | Can target the web, better for app-like tools than for content pages that need search visibility | Shares skills and some logic with React web apps |
| Shipping fixes | Through app store releases | Some JavaScript fixes can ship over the air, within store rules |
| Hiring | Fewer developers know Dart before Flutter, though it feels familiar to Java, Kotlin and JavaScript developers | Draws on the large pool of JavaScript and React developers |
| Strongest fit | Custom, brand-led interfaces; one team covering several platforms | Teams with React experience; apps that should feel native on each platform |
In practice, the deciding factor is often your team rather than the framework. If React developers already maintain your web app, React Native lets them contribute to mobile with less retraining. If you are hiring a new mobile team or working with a vendor, Flutter's all-in-one toolkit and consistent rendering reduce the number of device-specific surprises.
Both frameworks are mature, backed by large companies and supported by large developer communities. Neither is a risky choice for a typical business app. Switching later is what gets expensive, so decide once, with the people who will maintain the app in mind.
Whichever you pick, plan for yearly upkeep. Apple and Google release major operating system versions every year, and both app stores periodically raise the minimum SDK versions required for updates. Framework upgrades, plugin updates and a round of retesting are part of owning any app, native or cross-platform.
When native Swift and Kotlin are worth the extra cost
Native development costs more because most features are built twice. It is still the right choice when:
- The camera, Bluetooth, NFC, sensors or background location are central to the app, not occasional extras
- You need home screen widgets, smartwatch apps or deep operating system integrations, which require native code even inside cross-platform apps
- Performance is the product: heavy graphics, real-time audio or video processing, or augmented reality
- The app mainly targets one platform, such as an iPhone-only service for a premium customer segment
- You already employ experienced Swift or Kotlin developers who will maintain it
A common middle path is to build the app in Flutter or React Native and write native modules only for the one or two features that need them. Our breakdown of what drives development cost applies to mobile too: device features and integrations, more than screen count, are what move the estimate.
What changes the decision in Indonesia
Android first, but not Android only
Android phones make up the large majority of smartphones in Indonesia, and many users carry entry-level or mid-range devices with limited memory and storage. Whatever you choose, test on those phones, not only on a developer's flagship. iPhone users are a smaller group overall but can be a big share of customers in premium segments, so check your own customer data before launching on one platform only.
App size and data costs
Many users manage phone storage carefully and buy mobile data in packages, so they notice large downloads and heavy updates. Compress images, avoid bundling large assets and check the download size during development, not just before launch.
Payments and login
Indonesian customers expect QRIS, e-wallets such as GoPay, OVO, DANA and ShopeePay, and bank virtual accounts. Check early whether your payment gateway offers an SDK for your framework or a web checkout that works smoothly inside the app. Do the same for phone-number login with one-time passwords sent by SMS or WhatsApp.
Connectivity in the field
Sales and delivery staff outside big cities often work with weak or patchy signal. If the app must record orders or proof of delivery offline and sync later, plan it from the start, because it shapes the data design far more than the choice of framework.
A practical decision checklist
Answer these questions with your team or vendor before anyone writes code:
- Which devices do your users really have? Pull the data from website analytics or customer records rather than guessing
- Which device features are must-haves, and do mature packages exist for them in each framework?
- Who will maintain the app in two years, and which languages do they know?
- Do you also need a web version, and how much could it share with the app?
- Which payment, login and map services must work on day one?
- Can the budget support two codebases, including maintenance after launch?
Your answers usually point to one of these starting points:
| Situation | Sensible starting point |
|---|---|
| Business app with forms, lists, maps and payments on Android and iOS | Flutter or React Native |
| You already have a React web team | React Native |
| Brand-led custom interface that must look identical everywhere | Flutter |
| Heavy camera, Bluetooth, AR or background work | Native, or cross-platform with native modules for those parts |
| iPhone-only premium product or deep Apple ecosystem features | Swift |
| Occasional use, no need for an app store listing | A responsive web app |
Whatever the answer, prototype the riskiest feature first. A short proof of concept on real devices is cheap insurance against finding a blocker halfway through the build.
How Weaveward can build this for you
Weaveward's mobile app development service starts with a short technical discovery: we list your must-have device features, payment and login methods, target devices and the people who will maintain the app, then recommend Flutter, React Native or native with the trade-offs written down. Before the full build, we prototype the riskiest piece, such as camera scanning, offline sync or the e-wallet checkout, and test it on entry-level Android phones as well as iPhones.
The first release focuses on one core user journey, shared through the Google Play internal testing track and TestFlight so your team can try it on their own phones before customers do. If you are weighing frameworks right now, talk to our team.
