Flutter, React Native, or native: choosing a mobile stack

Both frameworks are mature enough that framework choice is rarely what determines whether a project succeeds. Team familiarity, product scope, and API design matter far more, and we would rather build in either framework with a team that knows it than in the theoretically better option with a team learning it.

React Native runs JavaScript or TypeScript and renders real platform components. Its newer architecture removed the old asynchronous bridge that used to be the standard performance complaint, and the practical result is that most interaction-heavy business apps perform indistinguishably from native to users.

Flutter runs Dart and draws its own widgets through its own rendering engine. Because it controls painting rather than delegating to platform components, it delivers extremely consistent output across platforms and smooth custom animation.

That difference is the crux: React Native inherits platform look and feel; Flutter overrides it. Which one you want depends on whether you are building something that should feel like an iOS app on iOS, or something that should feel identical everywhere.

Your team already writes React or TypeScript. This is the single strongest argument and it usually settles the decision on its own. Existing developers become productive in days rather than months, hiring is straightforward, and validation logic, API clients, and types can genuinely be shared with a web app.

You want platform-native feel by default. Because it renders real platform components, controls behave the way each operating system's users expect without deliberate effort.

You need a specific native library and want the widest chance it already exists. The React Native ecosystem is large, and for payments, mapping, analytics, and device SDKs a maintained wrapper usually exists.

The trade-off to accept: you are running a JavaScript engine, and heavy computation on the JS thread still needs care. Move genuinely expensive work to native modules or the server.

You are building a heavily custom interface that must look identical on both platforms. Brand-led apps with bespoke components and rich motion are where Flutter's owned rendering pipeline is a genuine advantage rather than a stylistic preference.

Animation is central. Smooth, complex, continuous animation is easier to achieve reliably in Flutter, because there is no bridge between your code and what gets painted.

You value consistency in the toolchain. Dart's tooling, hot reload, and the framework's batteries-included widget set make for a coherent developer experience, and behaviour tends to match across platforms without per-platform fixes.

The trade-off to accept: Dart is a smaller talent pool than TypeScript in every one of our markets, you cannot share code with a web frontend in any meaningful way, and app binaries are somewhat larger because the engine ships with the app.

Cross-platform is the default, not the answer to everything. Four situations genuinely call for native, and recognising them early saves an expensive rewrite.

<strong>Sustained heavy graphics or compute.</strong> Games, real-time video processing, AR, and continuous camera analysis belong in native code with direct access to Metal, Vulkan, and the platform ML frameworks.

<strong>Deep platform integration.</strong> Complex widgets, watch and TV companions, advanced background processing, CarPlay or Android Auto, or intricate Bluetooth work are all easier native than fighting a plugin layer.

<strong>Day-one adoption of new OS features.</strong> If your product needs whatever was announced at WWDC as soon as it ships, cross-platform wrappers lag by weeks or months.

<strong>Genuinely divergent platform products.</strong> If the iOS and Android apps are meant to be substantially different, sharing a codebase mostly creates conditional complexity for no benefit.

Cross-platform is often pitched as halving cost. In our experience the saving on a typical business app is closer to 30% to 40% than 50%, because the shared part is business logic and screens while platform-specific work does not disappear: permissions, push notifications, deep links, biometric authentication, store compliance, and release management all still need per-platform attention.

Two native codebases means roughly double the feature work but each is simpler, and platform quirks are handled directly rather than through a plugin. Cross-platform means one feature implementation plus a plugin layer whose bugs you inherit and cannot always fix quickly.

The cost that dominates over years is neither of these — it is API design and release discipline. Apps that became expensive to maintain in our experience did so because the backend forced the client to do too much, or because nobody invested in automated release pipelines, not because of the framework.

Device mix should influence the decision more than it usually does. In South Africa and across much of the EU's price-sensitive segments, mid-range and older Android devices are a large share of real usage. Test on genuinely low-end hardware early, because both frameworks reveal their weaknesses there rather than on a current-generation flagship.

In the US and Australia, iOS share is high enough that iOS-first release strategies are defensible, which occasionally makes native iOS plus a later cross-platform Android build a sensible sequence.

For EU consumer apps, budget properly for consent, tracking transparency, and data-subject request handling. This is real product work that is easy to under-scope and has nothing to do with which framework you pick.