Flutter vs React Native vs Native in 2026: What We Ship and Why

Flutter vs React Native comes down to what your app does, not which framework is better. React Native fits teams already writing React and products that lean on web code. Flutter fits design-heavy apps that must look identical on both stores. Native still wins for deep hardware, camera and OS integration work.

That answer is boring, and it is also the one we give clients every week. The interesting part is the reasoning behind it, because in 2026 both frameworks are healthy, both ship every eight weeks or so, and the framework you pick matters less than whether you can keep the app current with two store deadlines that now arrive every year.

Here is how we make the call, with the version facts, the store rules and the India-specific constraints that actually move the decision.

Flutter vs React Native: where both stood in mid 2026

Both projects shipped a release within a day of each other in August 2026. That is the single most useful fact for anyone worried about backing a dying framework.

Flutter 3.47

Google shipped Flutter 3.47 as the stable channel release in August 2026. The changes worth knowing before you scope a build, per Google’s release announcement:

• The Material and Cupertino design systems moved out of the core SDK into standalone material_ui and cupertino_ui packages, both at version 1.0. Design updates now ship on their own schedule instead of waiting for an SDK release.
• Impeller became the default renderer on macOS, Windows and Linux. It was already default on mobile. Impeller compiles shaders at build time, which is what removed the first-run animation stutter Flutter was criticised for.
• Minimum platform support rose: iOS 13 to iOS 15, macOS 10.15 to macOS 12. If your analytics still show meaningful iOS 14 usage, that is a migration item, not a footnote.
• Widget Previews reached stable, and 92 of the top 100 iOS plugins have migrated to Swift Package Manager.
• WebAssembly output for Flutter web is available behind a --wasm flag and heading toward default.

React Native 0.87

React Native has been on a roughly two-month cadence, and the last twelve months changed the platform more than the three years before it. From the official React Native release blog:

• 0.82 (October 2025) was the first release running entirely on the New Architecture. The old bridge is gone, not deprecated.
• 0.83 (December 2025) moved to React 19.2.
• 0.84 (February 2026) made Hermes V1 the default engine.
• 0.85 (April 2026) introduced a new animation backend.
• 0.86 (June 2026) brought edge-to-edge handling and DevTools work, with no breaking changes.
• 0.87 (August 2026) added a strict TypeScript API, a Metro update, Swift Package Manager support and Android Gradle Plugin 9 support.

The practical consequence: if you inherit a React Native codebase built before late 2025, the upgrade is not a version bump. Any native module that was never migrated to Turbo Modules and Fabric has to be replaced or rewritten. We have seen that alone consume several weeks on apps that looked fine from the outside.

Where native still wins

We do not treat native as a legacy option. There are builds where writing Swift and Kotlin separately is the cheaper path over two years, not the more expensive one:

• Deep OS surface area. Home screen widgets, Live Activities, background location, Wallet passes, health data, accessibility services. Cross-platform wrappers exist for most of these, but you are one OS release away from waiting on a maintainer.
• Camera, video and AR. High frame rate capture, custom pipelines, on-device vision models. Anything where you care about frame timing at the sensor level.
• Vendor SDKs that ship native first. Many payment, KYC and device SDKs in India publish an Android AAR and an iOS framework, and a community wrapper months later, if at all.
• One platform, seriously. If you are launching Android only, and India makes that a defensible choice, a Kotlin app has no cross-platform tax at all. StatCounter put Android at 92.79 percent of Indian mobile traffic in August 2026, against 7.15 percent for iOS.
• An existing native codebase. Adding a cross-platform layer to a mature native app usually creates two problems instead of solving one.

Side by side: Flutter, React Native, native

Flutter vs React Native for Indian apps

Most Flutter vs React Native comparisons are written for a market where the median user has a recent iPhone on good Wi-Fi. Indian products face a different set of constraints, and those constraints tend to decide the framework more than any benchmark does.

Android-first, and low-end Android at that

When 92 percent of your traffic is Android and a large share of it sits on entry-level devices, two numbers matter more than frame rate benchmarks: install size and cold start. Flutter ships its own rendering engine, so the floor for app size is higher. React Native ships a JavaScript bundle and the Hermes engine. Neither is disqualifying, but on a 2 GB RAM device with a metered data plan, a 20 MB difference in download size shows up in install conversion. Measure it on the devices your users actually own, not on a test bench.

Payment and identity SDKs

UPI flows, card tokenisation, Aadhaar-based verification and video KYC are the parts of an Indian app most likely to need native code. Before committing to a framework, list every third-party SDK the product needs and check, one by one, whether an actively maintained plugin exists for it. A single unmaintained payment wrapper can cost more than the framework decision saves. If the product is a marketplace with a buyer app and a supplier app, that list doubles, which is one of the points we make in our guide to two-sided marketplace development.

Language and text rendering

Apps serving Hindi, Tamil, Bengali or Marathi users hit complex script shaping, longer strings and font fallback. Flutter draws text with its own engine, which gives consistent output but means you own the font fallback chain. React Native uses the platform text stack, which handles Indic scripts the way the rest of the phone does. Both work. They fail differently, and you should test with real content early.

Offline behaviour

Patchy connectivity is a design requirement in most of India, not an edge case. This is genuinely framework-neutral. What matters is whether you budget for a local database, a sync queue and conflict handling from the start. We built the Epicircle recycling app with field agents in mind, and the offline and sync layer was a larger piece of work than the UI in either framework.

The 2026 store deadlines that break old builds

This is the part that catches product owners off guard, and it applies whichever framework you chose.

1. Google Play, 31 August 2026. New apps and app updates must target Android 16, API level 36, or higher to be submitted. Wear OS and Android Automotive must target API 35 or higher; Android TV and Android XR must target API 34 or higher. Developers who need more time can request an extension to 1 November 2026 through Play Console. Details are on the Play Console target API level policy page.
2. Apple, since 28 April 2026. Every app uploaded to App Store Connect must be built with Xcode 26 and the iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK. Apple’s SDK minimum requirements notice has the full list.

Read those together and the real risk becomes clear. It is not that you picked the wrong framework. It is that an app nobody has upgraded for eighteen months cannot ship a bug fix, because the toolchain it was built with is no longer accepted. Budget a maintenance window every year. Roughly one to two developer-weeks per platform per year is the smallest honest number we would plan with, and it is more if you have many native dependencies.

Cost and hiring in India

Cross-platform saves money in a specific way, and it is worth being precise about it. It does not halve your build. It lets one team own most of the product surface instead of two teams owning the same features twice.

On rates, Clutch’s published app development pricing directory puts app development firms broadly in the 25 to 49 US dollars per hour band, with India averaging under 25 dollars per hour. Treat those as market ranges, not quotes. For rupee ranges by feature and stage, our breakdowns of mobile app development cost in India and what an MVP costs at each stage go module by module.

Three things people underestimate when they model the saving:

• Platform-specific work never goes to zero. Push notifications, deep links, permissions, store review responses and background execution all behave differently on each platform, whatever the framework promises.
• Hiring depth differs by city. In Delhi NCR the React and TypeScript hiring pool is deeper than the Dart pool, simply because web hiring feeds it. If you expect turnover, that matters more than a benchmark.
• Upgrade cost is recurring. Six releases a year on React Native and several on Flutter means you either upgrade regularly in small steps, or infrequently in painful ones.

What about Kotlin Multiplatform?

It has stopped being an experiment. JetBrains declared Compose Multiplatform for iOS stable and production ready with the 1.8.0 release in May 2025, and shipped Compose Multiplatform 1.12.0 in August 2026.

The reason to consider it is different from Flutter or React Native. Kotlin Multiplatform lets you share business logic, networking, storage and validation while keeping native UI on each platform, or share the UI too with Compose if you want. For an Android-first Indian product that will add iOS later, and where the Android team already writes Kotlin, that shape fits well. The trade-off is a smaller library ecosystem and a smaller hiring pool than either of the two mainstream options.

A six-question checklist before you pick

1. What does your team already write? A React web team picking Flutter pays a learning cost twice, first to build and again to maintain.
2. List your third-party SDKs. Payments, KYC, maps, analytics, chat. Any one of them without a maintained plugin pushes you toward native modules or native builds.
3. How custom is the UI? Pixel-identical, heavily animated, brand-led interfaces favour Flutter. Interfaces that should feel like the host OS favour React Native or native.
4. Which platform launches first? Android-only for the first year makes native Kotlin or Kotlin Multiplatform genuinely competitive.
5. What are your device and network floors? Decide the minimum device and connection you support before you choose, then test install size and cold start against it.
6. Who maintains it in year two? If the answer is an agency you have not chosen yet, pick the stack with the deeper local hiring pool.

Answer those six honestly and the Flutter vs React Native question usually answers itself. In our experience the teams that regret their choice did not pick the wrong framework. They picked without listing their SDKs, or without budgeting for the annual upgrade the stores now force.

If you are choosing a stack for a new build, or you have inherited an app that cannot pass the current store requirements, our mobile app development team in New Delhi will review the codebase and the SDK list and tell you which of the three paths is cheapest over two years. Send us the details and we will come back with a written recommendation.