Every quarter or so a founder in Nairobi asks us: React Native or Flutter?Both ship a single codebase to iOS and Android, both have mature ecosystems, both have teams in Kenya you can hire from. The honest answer is they are close enough that either will work — but the trade-offs do matter, and we will tell you when we'd choose one over the other.
The team you already have
This is the loudest signal. If your team is React on the web — and most Kenyan startups we meet are — React Native is the obvious answer. The learning curve is a weekend, the same JSX/hooks knowledge ports, and you can share UI primitives (with Solito) or business-logic packages (TypeScript) directly between web and mobile.
If your team is .NET or Java, or you're hiring fresh, Flutter is more accessible because Dart is straightforward and the framework feels more "batteries included." Kenyan universities increasingly teach Flutter — there's a strong local talent pool around Strathmore, JKUAT and Multimedia.
UI fidelity
Flutter renders everything itself with Skia. That means a Flutter app looks identical on iOS and Android — which is great for brand consistency, awkward when iOS users expect iOS-native gestures and animations.
React Native renders to actual platform views. The same code shows native iOS sliders on iPhone and Material switches on Android — which feels more "at home" on each platform but harder to make pixel-identical.
For a B2B internal tool, brand-consistent (Flutter) wins. For a consumer fintech where users expect platform conventions, native-feel (React Native) wins.
Install size — important on Kenyan data plans
Flutter apps are typically 15–25 MB on Android, React Native around 25–40 MB once you include Hermes and a normal dependency set. Both are fine for an installed app over Wi-Fi. Both are annoying for a user on a 1.5 GB monthly bundle deciding whether to download.
If you're targeting cost-sensitive users, profile aggressively, ship Hermes (React Native) or split per-ABI (Flutter), and consider lazy-loading screens. We have had React Native apps under 22 MB and Flutter apps under 14 MB — neither is impossible.
M-Pesa Daraja, SMS, and Kenyan integrations
Both have community packages for Daraja STK push. Neither is great. We always wrap the Daraja call server-side in a Node or Python API and have the mobile app call the API. This way:
- The Daraja consumer key never sits in the mobile bundle.
- You can switch payment provider (Pesapal, Flutterwave, KCB Buni) without an app-store update.
- Retry and idempotency logic lives in one place.
With this pattern, the mobile framework choice doesn't affect Daraja at all.
Code reuse with web
If you have a Next.js web app and want to share components, React Native + React Native Web is unbeatable. We share form-validation logic, API clients, types, and even some UI primitives between web and mobile in the same monorepo.
Flutter has Flutter Web but it is awkward for marketing pages (you ship a 1 MB JS bundle to render an HTML page) — most teams use Flutter for mobile only and a separate framework for web.
Performance
Flutter has a slight edge on heavy-animation, custom-rendering apps (think a media editor with custom timeline UI) because it bypasses the platform's view layer. React Native is plenty fast for 99% of business apps — list views, forms, dashboards, media playback all work well, especially with the New Architecture (Fabric + TurboModules).
What we choose, by use case
- Fintech, e-commerce, productivity for general consumers → React Native. Native feel, web-team carryover, mature M-Pesa community.
- Brand-led app where pixel-perfection matters → Flutter.
- Internal tools / B2B dashboards → React Native if web codebase exists, Flutter if greenfield with Kotlin/Java team.
- Heavy-canvas creative tool → Flutter, or go native.
We build in both. If you want our recommendation for your specific stack, our applications service page covers everything we do — or email us with your context.