Choosing the wrong mobile tech stack is one of the most expensive mistakes a product team can make — not because any of the options are bad, but because switching is brutal. The choice that's right for a fitness tracker is wrong for a banking app, and the choice that's right at MVP is sometimes wrong at scale. Here's how to think about it pragmatically, without the framework wars.
The four real options in 2025
Cut through the noise and you're really choosing between four paths:
- React Native — one JavaScript/TypeScript codebase, native UI components, shared with your web stack. Mature, massive ecosystem.
- Flutter — one Dart codebase, rendered with Skia (not native components). Excellent design fidelity, strong performance.
- Native (Swift + Kotlin) — two codebases, two teams, maximum platform fit.
- PWA / responsive web — no native app, just a great mobile web experience. Underused, often the right call.
The first three are the "real apps." The fourth is the one most teams should consider harder than they do.
When each one is right
React Native is right when…
- You already have a TypeScript web stack and want code, types, and people to overlap.
- You need both iOS and Android with a small team.
- The product is mostly business logic + screens + APIs, not heavy graphics or platform-specific hardware features.
We pick this path for a lot of mobile app builds because it lets a small senior team ship two platforms at near-native quality with far less code than building twice.
Flutter is right when…
- Pixel-perfect, custom design that looks identical on iOS and Android is a competitive feature.
- Your team genuinely doesn't have a JS background and can adopt Dart.
- You want strong animation/graphics performance without going fully native.
Flutter's design fidelity is excellent and its widget model is delightful. The trade-off is that you're not using native UI components, which a small subset of users will subtly notice on iOS.
Native (Swift + Kotlin) is right when…
- Your product is deeply integrated with platform-specific features: HealthKit, complex camera/AR, on-device ML, advanced background processing.
- The cost of "doesn't quite feel native" is higher than the cost of two codebases.
- You're a large team where the duplication tax is small relative to throughput.
Native gives you the best possible feel and the longest path to obscure bugs. It also gives you the biggest team and timeline cost. For most startups it's the wrong default; for the cases where it's right, it's clearly right.
PWA / responsive web is right when…
- Most usage will be one-off or shallow, not daily-driver.
- The product is a service or workflow that benefits from URLs and shareability.
- App-store gatekeeping isn't worth the friction (no discovery, no compliance overhead, instant updates).
This is the most underrated option. A great mobile web experience can be the right product, and you can always add a native shell later if usage data demands it.
The decisions that should drive your choice
Frameworks are downstream of these. Think about these first:
1. Performance and graphics
Is your app mostly screens + lists + forms? Anything modern handles that. Is it heavy on real-time graphics, physics, complex animation, or on-device ML? That tilts you toward native or Flutter.
2. Platform features
Do you need deep integration with platform APIs that change every iOS/Android release? React Native and Flutter cover most of them through plugins, but the deepest territory — advanced camera, AR, low-level networking, certain background tasks — is still smoother on native.
3. Team and hiring
A two-developer team will out-ship a four-developer team if the smaller team can share code. React Native gives the biggest hiring pool (TypeScript devs); native gives the smallest. This matters more than people admit.
4. Cadence and reuse with the rest of your stack
If you already have a TypeScript web app, React Native makes sharing logic, types, and even some UI realistic. If your back end and web are TypeScript and you pick Flutter for mobile, you've split the org in two languages forever. (For the web side of this, see our modern web stack post.)
5. Compliance and security posture
For regulated products (finance, health, government) certain native APIs and platform protections matter and your security review will be smoother on native. For most consumer apps it's a non-issue.
What to ignore in this decision
- "Native feels better." Mostly true a decade ago, mostly noise now. A well-built React Native or Flutter app is indistinguishable from native to almost every user. If you're shipping at 60fps with platform-correct interactions, you're fine.
- "Cross-platform is slower." Not on a serious team. On a sloppy team, every stack is slow.
- "Framework X has X% market share." Adoption tells you about hiring pool and ecosystem maturity; it doesn't tell you what's right for your product.
- "We'll start cross-platform and rewrite native later." Sometimes works, often doesn't. The decision tree is the same whichever direction you're going.
A representative recommendation
For a typical startup mobile build — B2C or B2B SaaS companion app, modest hardware requirements, small team, web app already in TypeScript — we'd default to React Native with TypeScript. It gets you to App Store + Play Store fastest, with a codebase a small senior team can actually maintain, and the engineers are findable.
For a design-led consumer product with custom animations and graphics? Flutter is worth a serious look.
For a product where the platform-native experience is the moat — a banking app, a deep camera/AR product, anything where iOS/Android differences are visible in the value? Native.
For a workflow-heavy B2B product where most usage is occasional and shareability matters? PWA, with a native shell only when usage justifies it.
The build matters more than the stack
Whichever you pick, the difference between "users love this app" and "we have to rewrite the app" is usually not the framework. It's whether the team had the discipline to keep the screens simple, the data layer clean, and the release cadence honest. We've built mobile products on all four of the paths above; the ones that succeeded had the same underlying engineering discipline. (Our post on MVP to scale is most of that discipline, applied to mobile.)
If you're trying to make this call for a specific product — and want a senior mobile team's honest read on the trade-offs — book a call. We'll give you a recommendation in plain English, not in framework slogans.
