For most products in 2026, cross-platform (React Native or Flutter) is the right default. The question is not “cross-platform or native?” — it is “is your product one of the three specific cases where native genuinely earns its 70%+ time-to-ship premium?” This guide is the honest decision framework.
The short version: cross-platform delivers 85 to 90% of what native delivers at 60% of the cost and 50% of the maintenance burden. For that to be the wrong trade, you need to be in one of three specific scenarios: single-platform-only product, AR / video / gaming where every millisecond matters, or apps that lean heavily on day-one platform-feature parity. Outside those, cross-platform is the better engineering call — even when budget is not the constraint.
What “cross-platform delivers 85-90%” actually means
In 2026, both React Native and Flutter handle the workloads that 95% of mobile apps actually do: authentication, onboarding, lists, forms, real-time updates, push notifications, location, camera, biometrics, payments, deep links, in-app purchases, file uploads. All of this is solved, mature, well-supported.
What cross-platform delivers less cleanly: very low-level native APIs (HealthKit's deepest features, custom CoreML inference graphs, Android's newest Compose-only APIs in the months immediately after release), highly custom graphics work (real-time AR, 3D graphics, complex shaders), and platform-feature parity within weeks of an OS release. These represent a small fraction of typical apps.
So when we say “85-90%” we mean: 85-90% of features cross-platform handles cleanly; the remaining 10-15% either has good cross-platform support that works fine, has a small workaround via native modules / Pigeon for specific platform features, or genuinely cannot be done cleanly and pushes you toward native.
Scenario 1 where native wins — single-platform-only products
If your product is iOS-only or Android-only for a real strategic reason (target audience is exclusively on one platform, regulatory constraint, enterprise deployment on one OS, etc.), going native is simpler than dragging in a cross-platform layer for a single-platform target. You pay the cross-platform abstraction tax (extra runtime, JS bridge or Dart VM, occasional native-module integration) for zero benefit.
This is more common than people realise. Many premium consumer apps (Apple-ecosystem-first products), many enterprise tools (one company-issued device platform), and many regional apps target a single platform. For these, native is the correct call.
Scenario 2 where native wins — performance-critical use cases
Three categories of app genuinely benefit from native's performance edge:
Real-time AR / camera-heavy apps. ARKit on iOS, ARCore on Android, custom camera filters, advanced computer vision. The cross-platform abstractions exist but introduce friction; serious AR apps usually go native or use Unity. Examples: IKEA Place, Snapchat-style filter apps, professional camera apps.
Games. Cross-platform game engines exist (Unity, Unreal, Godot) but they are different beasts from React Native / Flutter. Mobile-first 2D games can be built in Flutter cleanly; anything more graphics-intensive should use a game engine, native, or both.
Video and live-streaming apps with custom codecs. Native gives you direct access to AVPlayer / ExoPlayer with the latest features, custom codec implementations, and hardware-accelerated video pipelines. Cross-platform video works for most cases (Vimeo, YouTube playback, simple streaming) but breaks down at the edges.
For typical business apps, dashboards, social products, e-commerce, or productivity tools, the “performance” objection to cross-platform almost always vanishes in practice. The team thought performance mattered; the user could not tell.
Scenario 3 where native wins — day-one platform feature parity
iOS 18 launches at WWDC in June; if your app needs to ship the new feature within weeks of release, native is usually the only path. iOS-native APIs reach Swift / SwiftUI on day one. React Native and Flutter typically need 3 to 12 months to add proper bindings for new platform features. Same for Android with Compose-only features in new Android versions.
This matters for: apps that compete on being first to new OS features, apps in regulated industries where compliance APIs change with OS releases, and apps that build deeply into platform ecosystems (widgets, watch apps, CarPlay, Android Auto, App Intents). If your competitive advantage is being on day one of the new OS, native is the architecture.
For most apps, lagging the OS release by 3 to 9 months on a specific feature is fine.
Where cross-platform legitimately wins (almost everything else)
Business apps, B2B tools, internal apps. Forms, lists, dashboards, workflows, notifications. Both React Native and Flutter handle these perfectly. The team velocity advantage is decisive.
MVPs and early-stage products. You do not know if the product will work yet. Spending 70% more on native engineering before validation is risk-stacking. Ship cross-platform, validate, scale, and if you ever genuinely need to go native later (rare), you have validated the product first.
B2C consumer products. The vast majority of consumer apps people use daily are written cross-platform. Slack, Discord, Bloomberg, Tesla, Shopify, Coinbase, Walmart — all React Native. Google Pay, BMW, Alibaba, eBay Motors — Flutter. Users cannot tell.
Apps where time-to-ship matters more than perfect platform parity. Most products. Ship faster, iterate based on real users, beat competitors to market. The “perfect native experience” is a longer-term investment that rarely pays back fast enough.
Teams without native iOS / Android engineering depth. Hiring a senior Swift engineer and a senior Kotlin engineer is genuinely expensive in most markets. Hiring senior JavaScript or Dart engineers and shipping cross-platform is dramatically cheaper.
The hybrid case — native plus cross-platform
There is a third path that often makes sense for serious products: cross-platform shell with native modules for the specific features that need them. Build the bulk of the app in React Native (90% of screens), drop into native code for the AR camera screen / the HealthKit integration / the watchOS extension / the widgets. Both React Native (Expo Modules, Turbo Native Modules) and Flutter (Pigeon, Method Channels) support this cleanly.
This gives you cross-platform velocity for the boring 90% and native depth for the strategic 10%. Most serious cross-platform apps we ship use some amount of native integration; this is normal and expected.
The honest decision framework
Three questions usually resolve the choice:
Question 1: Are you single-platform? Yes → native (or honestly evaluate why you are single-platform first). No → default to cross-platform.
Question 2: Is your product in AR / heavy 3D / video-with-custom-codec / day-one-OS-features? Yes → native, or hybrid with native for the specific feature. No → cross-platform.
Question 3: Can you validate the product with cross-platform first and migrate to native later if needed? Almost always yes. The migration cost is real but usually less than the cost of over-investing in native too early.
What we ship at Dream Steps
Roughly 70% of our mobile work is cross-platform (React Native more often than Flutter, depending on team fit). Roughly 20% is native (typically when clients have already committed to it, or when the product genuinely needs it). The remaining 10% is hybrid — cross-platform main app with native modules for specific features. When clients come to us with the decision unmade, we recommend cross-platform by default and explain when native earns the premium. We will tell you honestly when you actually need native; most of the time, you do not.
Common questions
Are cross-platform apps slower than native?
Marginally, in specific scenarios, on older hardware. For the workloads typical business apps run (lists, forms, navigation, network requests, simple animations), the difference is invisible to users. The cross-platform performance gap closed dramatically with React Native's New Architecture (Fabric, TurboModules, Hermes) and Flutter's Impeller renderer. We benchmark every mobile build against published native baselines — cross-platform apps we ship typically perform within 5 to 10% of native on real-world tasks.
What about App Store / Play Store approval — does cross-platform get flagged?
No. Both App Store and Play Store explicitly support cross-platform apps. Many top-100 apps in both stores are cross-platform. The approval process is identical to native; the same store guidelines apply. The one exception: very early React Native apps occasionally had crash issues during review that got them rejected, but those issues are resolved in modern React Native / Expo workflows. We have never had a cross-platform app fail store review for being cross-platform.
How much cheaper is cross-platform than building two native apps?
Roughly 40-50% cheaper end-to-end (build + first year maintenance), depending on app complexity. The build itself is typically 50 to 60% of the cost of two native apps because you maintain one codebase, one team, one language. Ongoing maintenance is closer to 50% cheaper because every feature ships to both platforms simultaneously rather than twice. The savings compound over the lifetime of the product — not just at launch.
Can we start cross-platform and migrate to native later if we need to?
Yes, and that is often the right strategy for early-stage products. Validate the product with cross-platform, scale to first 10-50k users, gather real performance and capability data, then if the data genuinely shows native is needed (it usually does not), migrate. Even better: migrate one screen at a time via native modules — you do not need to rebuild the whole app. Most successful cross-platform apps never need to migrate to native fully.
What’s the hybrid approach you mention — when does it make sense?
Hybrid is cross-platform main app + native modules for specific features. Examples: the main app in React Native, the AR camera screen written in Swift / Kotlin and exposed as a native module. The HealthKit integration in native Swift. The Android widgets in Kotlin. Both React Native (Expo Modules, Turbo Native Modules) and Flutter (Pigeon, Method Channels) support this cleanly. Most serious cross-platform apps we ship have some hybrid surface — usually 1-3 native modules for the features that need it. This is normal and expected.
Deciding between native and cross-platform?
Tell us about the product, the team, and the timeline. We will tell you honestly which architecture fits — and we will tell you when you do not need native, even if that is the easier sale.