React Native vs Flutter in 2027: what we actually pick

Flutter is taking Material and Cupertino out of its own SDK. The 3.47 release notes announce standalone material_ui and cupertino_ui packages at 1.0, and say the original design libraries inside the core SDK are "scheduled for formal deprecation" in the November stable release. That single change matters more to a React Native vs Flutter decision in 2027 than any frame-rate chart, and it is the first thing we check before quoting either framework.

We have shipped production apps in both, which is the part most comparisons skip. Flutter built the Škoda Auto dealer training platform across 100+ dealerships in 20 weeks. React Native built our dining super app, MakeMyLook and FlashNow. Below is what we verified from primary sources, what we could not verify at all, and where each framework is the wrong answer.

What is actually true of each framework right now

Every row below comes from a vendor release artefact, not from coverage of one. Dates are the ones the issuing body published.

Axis	React Native	Flutter
Current version	0.88, blog dated 19 Oct 2026	3.47.7 with Dart 3.13.5, released 8 Oct 2026
Last feature release	0.88 (0.87 on 11 Aug 2026)	3.47.0 on 12 Aug 2026
Rendering	Fabric, New Architecture default since 0.76	Impeller, now default on macOS, Windows and Linux too
Design system	Platform components, no bundled design library	Moving to standalone material_ui / cupertino_ui 1.0
iOS 27 scene lifecycle	SceneDelegate supported, single scene only	Minimums raised to iOS 15 and macOS 12 for Xcode 27
Swift Package Manager	Experimental in 0.88, default targeted for 0.89	Opt-in; 92 of the top 100 iOS plugins migrated
Web and desktop	Out of tree; 0.87 and 0.88 posts mention neither	First-party, with Wasm opt-in behind --wasm
UK permanent job ads, 6 months to 21 Oct 2026	195, median £90,000	23, median £75,000

The unbundling is a migration, not a footnote

Read the 3.47 notes closely and the change is staged rather than sudden. The core SDK still ships the design libraries "for this release", the standalone packages are opt-in today, and Flutter supplies a codemod: dart fix --apply --code=migrate_design_widgets. No removal version or date is given anywhere on the page.

What is given is the instruction to ecosystem maintainers to "treat this move to the standalone packages as a major release". That is the sentence with the budget attached. A Flutter app of any size depends on packages that import material, and each of those maintainers now has a major-version decision of their own to make on a timetable you do not control. The codemod fixes your code. It does not fix a dependency whose author has stopped answering issues.

If you are choosing Flutter for a 2027 build, this is survivable and arguably healthy — design libraries on their own release cadence can move faster than an SDK. If you are choosing Flutter for a platform you intend to leave alone for three years, price the migration now, because the deprecation lands in November 2026 and the ecosystem churn follows it.

Both frameworks hit the same iOS 27 wall

React Native's 0.88 notes put it flatly: "Starting with the iOS 27 SDK, Apple requires the UIScene lifecycle: UIKit apps built with Xcode 27 will fail to launch." That is not a framework problem, it is Apple's, and it reaches every UIKit-hosted app including both of these.

React Native 0.88 answers it additively. RCTReactNativeFactory gains SceneDelegate entry points while the AppDelegate path keeps working, so the upgrade is not forced in one step. The constraint worth knowing is that support is limited to a single scene, so UIApplicationSupportsMultipleScenes must stay false, and at launch React Native forwards only the first URL context or user activity from the scene's connection options. We wrote up the migration mechanics separately in our note on React Native 0.88 and the one iOS launch rule.

Flutter's answer to Xcode 27 is a floor rather than an API: minimum iOS moves from 13 to 15 and macOS from 10.15 to 12. It also starts winding down Intel Macs — automated test runs on Intel hardware are disabled and the CLI now warns when building on Intel hosts, warnings that "will become errors in a future release". If your build farm or your designers are still on Intel hardware, that is a 2027 capital line item, not a flag.

The strongest case for Flutter, put properly

Here is the argument we would make if we were arguing for Flutter, and we think it wins more often than our own default suggests.

Flutter owns its rendering path end to end. Impeller is now the default renderer on macOS, Windows and Linux, and Flutter says the Skia fallback will be removed in a future release. That means one renderer, one widget set and one language from phone to desktop. React Native has no equivalent story: web and desktop are out-of-tree community targets, and neither the 0.87 nor the 0.88 release post mentions either. If your product genuinely needs a Windows build, a Linux kiosk and a phone app from one team, Flutter is not the compromise choice — it is the only one of the two that ships that.

Flutter is also ahead on iOS packaging. It reports 92 of the top 100 iOS plugins already migrated to Swift Package Manager and describes CocoaPods as "now in maintenance mode". React Native is a release behind: SPM is still experimental and opt-in in 0.88, with 0.89 targeted as the default and CocoaPods removal only promised "in a later release". And Widget Previews reached stable in 3.47, which is a real daily-workflow win React Native has no direct answer to.

We answer that case with scope, not with scorn. Most of what we are hired to build is a phone app with a web admin panel behind it, and for that shape the desktop advantage is worth nothing while the hiring difference is worth a lot. When the shape changes, so does our answer.

Nobody has published a performance comparison worth quoting

The 2023 framing of this debate — a JavaScript bridge serialising every call — is dead, and anyone still using it is describing software that no longer exists. React Native's New Architecture has been default since 0.76, and 0.87 removed the useTurboModules flag outright because TurboModules are always enabled. Flutter compiles Dart ahead of time and never had a bridge.

So which is faster? We will not tell you, because we could not find a credible answer. The nearest peer-adjacent work is a September 2026 arXiv study that builds the same plant-management app in five stacks, guided by ISO/IEC 25010, with 2,000 completed runs per variant. Its abstract reports that native "records the lowest non-UI client subtotal on both operating systems" and that "operation and UI-wrapper rankings vary by task" — and it publishes no headline Flutter-versus-React-Native verdict. Its own conclusion is that each approach's costs "depend on the quality attribute, workload, platform, and measurement boundary". We read the abstract and methodology verbatim and did not read the result tables verbatim, so we are quoting no numbers from it.

Treat every agency blog post with a bar chart comparing the two as marketing until it states its device, its OS build, its run count and its measurement boundary. On current evidence, performance is not the axis your decision should turn on.

React Native vs Flutter hiring is the number that moves a budget

The statistic everyone cites for this comparison no longer exists. Stack Overflow's 2026 Developer Survey drew 30,903 valid responses from 169 countries, and dropped the other-frameworks question entirely — React Native appears nowhere in its technology results, and nowhere in 2025's either. The last published figures are 2024's: Flutter 9.4% against React Native 8.4%. Anyone quoting that spread as current is quoting a two-year-old number.

For live demand we use IT Jobs Watch, which counts advertised UK vacancies. In the six months to 21 October 2026, 195 permanent ads cited React Native at a £90,000 median, against 23 permanent ads citing Flutter at £75,000. Contract is closer in rate and still lopsided in volume: 77 React Native ads at a £500 day rate against 23 Flutter ads at £494.

The caveat matters more than the headline. Flutter's £75,000 median rests on just 13 quoted salaries, so the pay gap is statistically thin and we would not plan a salary band on it. The volume gap is far firmer: roughly 8.5 times as many permanent ads, and a direction of travel that is not close. Flutter ads fell from 53 to 40 to 23 across the three comparable periods while React Native went 241, 137, 195. One more detail from the same data: React Native is named in 9 of those 23 Flutter ads, so a third of the UK's Flutter demand is actually asking for both.

None of this says Flutter engineers are worse or scarcer in absolute terms — IT Jobs Watch counts UK job adverts, not developers, and our own teams are in India and the UAE. It says that if you are a UK or US company planning to hire in-house after we hand over, the depth of the market you are hiring into differs by nearly an order of magnitude.

What we pick, and when we are wrong

Our default for a new mobile app build is React Native, and it is a default about teams rather than about rendering. A React and TypeScript team ships React Native with a shorter runway, the hiring market behind it is deeper, and the 0.88 line has now gone three releases — 0.83, 0.86 and 0.88 — with no user-facing breaking changes, which is the kind of boredom you want in a dependency.

React Native is the wrong choice when you need a first-party Windows or Linux build, when your product is a pixel-exact design system that must look identical on every platform, or when your team already writes Dart. It is also the wrong choice if you want a settled iOS packaging story this quarter: SPM is experimental in 0.88 and CocoaPods is still the supported path.

Flutter is the wrong choice when your organisation intends to hire the maintenance team in the UK from job boards, when you cannot absorb the material_ui migration and the November deprecation of the in-SDK libraries, or when your existing engineers are a React web team and Dart would be a second language with no other use in the company. Choosing it to avoid writing two UIs, while leaving the staffing question for later, is the failure mode we see most.

Note what is not in either list. Performance is absent because the evidence is absent. Bridge architecture is absent because the bridge is gone. Both frameworks have reached the point where the framework is rarely what sinks a project.

The decision to make this week is narrower than "which framework". Pull your dependency manifest and count how many packages import Flutter's in-SDK material, or how many of your iOS pods have no SwiftPM equivalent. Whichever side that exercise frightens you on is the migration you will actually be paying for in 2027, and it is a far better basis for the choice than another feature matrix. We ran the same exercise before MakeMyLook went to market in 16 weeks, and it changed the answer.