The moment a client says “we want a mobile app,” the second sentence out of their mouth is almost always “should it be native or hybrid?” It’s asked as if there’s a right answer independent of context. There isn’t.
There are four viable options in 2026. Each of them is the right answer for a specific kind of project. Picking the wrong one costs you six months and a re-architecture. Picking the right one is boring — which is exactly what you want.
The four options
- Native (Swift for iOS, Kotlin for Android). Two separate codebases, platform-idiomatic UI, full access to platform APIs, best performance and animation, biggest team.
- Cross-platform native (React Native, Flutter, .NET MAUI). One codebase, native rendering, near-native performance, medium team, some platform-specific work.
- Hybrid web (Ionic + Capacitor, Cordova). One codebase, web view rendering, web-technology skill set, smaller team, weaker platform integration, cheaper for CRUD-heavy apps.
- PWA (Progressive Web App). No app store, installable from the browser, offline-capable, iOS still slightly hobbled, cheapest to ship, weakest platform integration.
The five questions that decide
Skip the “which is better?” comparisons. Ask these instead.
1. What does the app do?
- Data entry, forms, dashboards, workflows, offline-capable CRUD → PWA, Ionic, or React Native. All three do this well. Pick based on team skills.
- Camera, computer vision, ARKit/ARCore, background sensors, complex gestures, video processing → Native or Flutter. Everything else adds friction.
- Real-time audio/video, WebRTC, VoIP → Native. Cross-platform frameworks catch up, but always a year late.
- Games, high-frame-rate animations, custom rendering → Native, or a game engine (Unity, Godot). Do not use a hybrid framework.
- Enterprise line-of-business apps — inspections, approvals, catalogues, field reports → Ionic, React Native, or PWA are all fine. Native is over-engineered.
2. How often does the UI need to change per platform?
- If the design mandates iOS-style navigation on iOS and Material Design on Android → native or Flutter (Flutter’s Material and Cupertino widget sets do both).
- If the design mandates one unified look across platforms (common in enterprise apps) → any of the four. Cross-platform actually helps here.
- If the design is web-first and mobile is a secondary channel → PWA or Ionic.
3. Who’s building it, and who will maintain it?
- You already have a React team. → React Native or PWA/Ionic (Ionic + React). Reuse skills.
- You already have a JS/TS team but no mobile experience. → PWA first, Ionic if you need app-store distribution or deeper device APIs.
- You have a small team and no ongoing mobile capacity. → PWA. Nothing else survives being neglected for six months.
- You have budget for two teams and the app is mission-critical. → Native. Never regret it.
- You have Java/Kotlin backend engineers who want to expand. → Kotlin Multiplatform is finally viable; consider it before Flutter.
4. Where will it be distributed?
- App stores are required (B2C consumer, procurement mandates) → any except pure PWA. iOS installs of PWAs still feel second-class.
- Enterprise MDM distribution, no app-store dependency → any of the four. PWAs pushed via MDM are surprisingly excellent for internal tools.
- China, or other markets with weak Play Store presence → native Android for regional stores + iOS native or Flutter. Hybrid frameworks struggle with vendor stores.
5. What’s the actual budget and timeline?
We keep these ratios in our estimates. They’re approximate but directionally right:
- Native (both platforms): 1.0x baseline — this is the reference cost.
- Cross-platform (React Native / Flutter): 0.55–0.7x — one codebase, some platform-specific work.
- Hybrid (Ionic): 0.4–0.55x — web skills, faster iteration.
- PWA: 0.3–0.45x — smallest team, no app-store overhead, no store review cycles.
The catch: these ratios assume the app fits the technology. Forcing a hybrid solution onto a native-scale problem gives you a project that costs 1.5x native and disappoints everyone.
Where each choice actually shines
Native — when the app is the product
Native is right when the mobile app is the primary user surface, the interactions are demanding, and the company can afford to invest in mobile long-term. Instagram, Uber, banking apps of any consequence. If a 40-millisecond animation drop is going to trigger a boardroom conversation, you need native.
Native is wrong when the mobile app is a channel for a web-first product, the interactions are workflow-heavy, and the team is stretched. Which is most enterprise use cases.
Cross-platform (React Native / Flutter) — the pragmatic default for the middle 60%
If the app is important, the interactions are moderate-to-high complexity, and the company wants one team instead of two, React Native or Flutter is almost always the right call. Discord, Shopify, Bloomberg, Airbnb (until they moved back to native — but their reasons don’t apply to most companies).
We default to React Native when the team is JS/TS-native and the app has significant business logic that could theoretically be shared with a web app. We default to Flutter when the team is willing to learn Dart and the design mandate is strong platform-idiomatic UI.
Hybrid (Ionic + Capacitor) — enterprise workflow apps
Ionic gets underrated. For a mid-market enterprise app that’s mostly forms, tables, approvals, and offline sync — where the design is functional rather than delight-driven — Ionic + Capacitor delivers on time, in budget, and stays maintainable. We’ve shipped several MPKV agri-advisory apps this way.
Ionic is wrong when the app has complex custom UI, heavy device integration, or demanding animation. It’s right for the huge middle class of enterprise mobile apps that nobody wants to admit exists.
PWA — start here more often than you think
Progressive Web Apps are the option that gets the least respect and deserves the most. They’re free (no store fees), fast to ship, easy to update, offline-capable, and now well-supported on both platforms.
PWAs are the right first move when:
- You’re not sure yet whether the app will get traction and want to iterate cheaply.
- The users are enterprise / internal, distributed via a link or MDM.
- The functionality is CRUD, dashboards, or a mobile view of an existing web app.
- You want to skip the app store review cycle for rapid iteration.
PWAs are wrong when you need heavy device integration, background execution, or app-store presence for credibility.
The framework we hand to clients
When a client asks “hybrid or native?” we walk them through this in ten minutes:
- Is the app the product, or a channel to the product? If channel — PWA or hybrid. If product — native or cross-platform native.
- Does it need deep device integration? If yes → native or Flutter. If no → any.
- How many people will maintain it in year two? If ≤1 → PWA. If 2–3 → cross-platform. If 5+ → any including native.
- How much of the value is in the animation and interaction? High → native. Medium → React Native / Flutter. Low → Ionic / PWA.
- What’s the timeline pressure? Six weeks → PWA. Three months → hybrid. Six months → cross-platform. Twelve months → native.
That’s it. Framework-choice becomes an emergent conclusion, not a starting-line debate.
Two things clients get wrong
One: they assume “hybrid” is a compromise, and default to native to be safe. This costs them 40% more budget and delivers something that doesn’t need the extra spend. If your app is a forms-and-workflows enterprise app, native is the wrong safe choice.
Two: they assume “PWA” means “second class.” iOS’s PWA implementation was legitimately weaker until 16.4 (2023). It’s now genuinely close to Android’s. Push notifications, badging, background sync — all working. If you dismissed PWAs three years ago, revisit.
What we ship most often
Looking at our last twelve mobile projects: 5 React Native, 3 Ionic + Capacitor, 2 native (both had specific reasons — one was consumer-scale, one had heavy Bluetooth/BLE integration), 2 PWAs.
That distribution isn’t ideology. It’s the distribution of what our clients actually need. It’s probably close to what your projects would look like too, if you gave each project the honest answer instead of the reflex one.
Related reading: React Native vs Flutter vs Ionic — the honest comparison for the deeper framework-vs-framework take.
If you’re at the “we need to pick a stack” moment, we’re happy to have a scoping call — no slide deck, one senior engineer, an honest recommendation.
