Choosing a Mobile App Tech Stack: Flutter, React Native, or Native

I build mobile apps at CloudAnts, and the question I get most often isn't "Flutter or React Native?" It's some version of "which one is correct?" — as if there's a single right answer waiting to be looked up. There isn't. The framework is downstream of three things: what your app actually does, who's going to maintain it, and how much you want to spend doing it twice.

So this post is the conversation I'd have with you across a table. We've shipped apps in all three approaches: a Flutter companion app for Mitsubishi Motors PH that runs across their dealerships, our own Flutter dental platform, and a React Native healthcare app for reach52. I'll tell you how we'd actually pick.

Start with the decision, not the framework

The first fork is not "which cross-platform tool." It's "cross-platform or native at all?" Everything else follows from that.

Native means two codebases: Swift/SwiftUI for iOS, Kotlin for Android. You get the best platform fidelity, the newest OS APIs the day Apple or Google ships them, and the deepest access to hardware. You also pay for two of everything: two builds, two sets of bugs, two release cycles, two engineers (or one engineer context-switching, which is slower than it sounds). As a rough planning number, native roughly doubles the mobile build versus a single shared codebase.

Cross-platform means one codebase that compiles or renders to both stores. You trade a small slice of platform-edge access for writing the app once. For most product apps, that trade is heavily in your favor, and I'll defend that below.

The three real choices

Native iOS and Android

Pick native when the app is the device: heavy camera/AR pipelines, Bluetooth Low Energy with finicky peripherals, background processing the OS guards tightly, or a UX that needs to match each platform's newest design language pixel-for-pixel on day one. Native is also the right call when you already have separate strong iOS and Android teams and the duplication isn't a budget problem.

The cost is real and ongoing: every feature is built and tested twice, and the two apps drift over time unless you're disciplined.

Flutter

Flutter is our default for most product apps. It's one Dart codebase rendering to both stores, it draws its own UI so screens look identical across devices, and the development loop is fast. Hot reload makes building and tuning interfaces genuinely quick. It's strong for apps that are mostly screens, forms, lists, data, and flows: the bulk of what businesses actually need on a phone.

We chose Flutter for the Mitsubishi Motors PH companion app and for our own dental product, Denti. Both are data-and-flow heavy apps where one codebase, one design system, and a fast UI loop mattered more than bleeding-edge native access.

React Native

React Native is also one codebase, but it leans on JavaScript and React. That's the deciding factor: if you have a web team already writing React, or a web app whose logic and types you want to share, React Native lets your existing people build mobile without learning a new language. We used it on the reach52 offline-first healthcare app, where the JS/React fit made sense for the team and the problem.

Where Flutter draws its own widgets, React Native maps to real native components and bridges to JS. Both are mature. The choice between them is more about your team than about raw capability.

When native is genuinely worth it

I don't want to talk you out of native when it's right. It's right when:

• The app's core value is a hardware or OS capability. Think serious AR, real-time audio/video processing, complex BLE device integration, or anything depending on APIs Apple/Google just announced. Cross-platform frameworks wrap these eventually, but "eventually" can be months, and you can't ship against a wrapper that doesn't exist yet.
• You need same-day support for the newest OS features as a product differentiator: a Live Activity, a widget, a platform integration that's part of your pitch.
• You already run mature, separate iOS and Android teams. If the duplication is already staffed and the apps are deep, forcing them into one codebase can cost more than it saves.

If none of those describe your app, native is usually you paying double for fidelity your users won't notice.

When cross-platform wins (most product apps)

Here's the unglamorous truth: most apps are CRUD with a good interface. Log in, see your data, do a thing, get a confirmation. Appointments, orders, dashboards, profiles, messaging, payments. A dealership companion app, a clinic app, a healthcare field tool: these live or die on clear flows and reliable data, not on exotic device access.

For that entire category, cross-platform is the better business decision. One codebase means a feature is built once, fixed once, and shipped to both stores together. The apps can't drift apart because there's only one of them. Your maintenance surface, which is where most of an app's lifetime cost lives, is cut roughly in half.

This is also why our mobile work is fixed-scope: written scope, fixed price, fixed timeline, typically an 8 to 16 week band depending on complexity. Cross-platform is a big part of what makes that band predictable. Two codebases make estimation noisier because you're estimating two of everything.

Cross-platform myths vs. reality

A few things clients worry about that mostly don't hold up:

"It'll feel non-native and users will notice." They won't, if it's built well. The apps that feel off are the ones that ignore platform conventions: wrong navigation patterns, wrong gestures, animations that fight the OS. That's a craft problem, not a framework problem. We build to each platform's expectations regardless of the tool underneath.

"Performance won't be there." For product apps, performance is a non-issue on modern devices. Flutter compiles to native ARM code; React Native runs a tuned JS engine with native components. Janky cross-platform apps are almost always doing something wrong, like rebuilding too much, loading images badly, or blocking the main thread, and the same mistakes make native apps janky too.

"We'll hit a wall and have to rewrite in native." Rare for product apps, and even then both frameworks let you drop into native code for the one screen that needs it. You write 95% once and reach for platform code only where it earns its keep. A full rewrite because you "outgrew" cross-platform is the exception, not the rule.

The real ceiling isn't performance or feel. It's access to the very newest OS APIs the moment they ship. If that's central to your product, that's your native signal. If it isn't, the myths are just myths.

What this means for budget and timeline

The number worth internalizing: a cross-platform codebase doesn't double your mobile cost versus building for one platform. It adds roughly 30 to 40 percent on top of a single-platform build, because the shared code is written once and only the platform-specific edges (store setup, a few native integrations, per-store release work) cost extra.

Compare that to true native: two codebases is closer to a 2x multiplier on the mobile portion. So the practical math for most teams is: cross-platform gets you both stores for not much more than one, while native gets you both stores for roughly double. That gap is the whole argument, and for CRUD-shaped products there's usually no offsetting benefit on the native side to justify it.

If you want the full picture of how mobile fits into a project budget, we wrote a general breakdown of what custom software actually costs with stated assumptions. Mobile is one line item in that, and the framework choice is one of the bigger levers on that line.

What we'd tell you across a table

Strip away the framework names and the decision is short:

• Is your app's core value a deep hardware or brand-new OS capability? If yes, go native and budget for two codebases. If no, go cross-platform.
• Do you already have a React/web team or codebase you want to share? Lean React Native.
• Is it a fresh, mostly-screens-and-flows product app and you want a fast UI loop and one design system? Lean Flutter. This is most apps, and it's where we usually land.
• Will you maintain this for years? Weight that heavily. One codebase is the gift that keeps giving; two is the cost that keeps costing, because maintenance is where the lifetime money goes.

We've shipped Flutter and React Native to real users, and we'll tell you plainly when an app should be native rather than sell you the cross-platform we'd rather build. That's the same instinct behind how to choose a software development partner: you want someone who'll talk you out of the expensive option when it's wrong, not just price whatever you ask for.

If you've got an app in mind and you're not sure which way it leans, tell us what it does and we'll give you a straight read on the stack, the band, and the trade-offs. Start a project and we'll take it from there. You can also browse our mobile and product work to see what we've already put in front of real users.