React Native vs Flutter: Evidence From 11 Production Apps

What exactly did we ship with React Native and Flutter?

Across 25 portfolio projects, 11 record a cross-platform mobile framework in their tags or techstack fields: six React Native and five Flutter. That structured-field rule matters at the edges. Dooz Inspected Cars lists Angular and NestJS in techstack and React Native only in its tags, so it counts. Waitmate Platform names React Native in its content and solution text but carries neither a tag nor a techstack entry, so it does not, which is why our React Native figure is six rather than seven. The remaining 14 projects record no mobile framework, which is not the same as being web-only. Outstride carries both a Google Play and an App Store URL, and Pastel Marketplace carries an App Store URL, yet neither record names the framework behind those apps. The table below is therefore the entire comparison set, and every column is read from the project records rather than inferred.

How is each framework attribution actually recorded?

Framework labels come from hand-maintained fields, so it is worth showing where each one sits before comparing anything built on top of them. Eight of the 11 builds name their framework in both tags and techstack. Three do not. Dooz Inspected Cars is React Native in tags only, because its techstack lists the Angular web client and the NestJS backend instead. Digital Power of Attorney is Flutter in tags only, its techstack naming Node.js and Express. JUJU Streaming is the reverse, Flutter in techstack only, with its tags describing the backend. The free-text category field is less consistent still, which is why we do not use it for attribution: Food Magnet's category is Food Industry, a vertical rather than a stack, and three Flutter builds carry the category Node.js Backend & AWS with no mention of Flutter. None of this changes the totals of six and five, but it explains why every count here names the fields it reads.

Which framework reached public app stores more often in our record?

Public store release is the outcome these records capture most consistently, because every project stores its own web, android and ios link fields. In our record, three of five Flutter builds are listed on both Google Play and the Apple App Store: Food Magnet, TAL Workforce and WOD Pro League. One of six React Native builds is on both, Dooz Inspected Cars. React Native is not absent from the stores. Four of six carry at least one public store listing, against three of five for Flutter. The difference is in how those listings are distributed. Of the four React Native builds with a listing, two are Google Play only, one is Apple only and one is on both; all three Flutter builds with a listing are on both stores. One data-hygiene note belongs here rather than in a footnote: Three28 Creator Platform stores an apps.apple.com URL in its android field, so we count it as an Apple listing filed in the wrong column.

What backends did each framework actually pair with?

One rule governs every row below: a technology counts when it is named anywhere in the project record, including the free-text category field and the written narrative, not only in tags and techstack. Under that rule the sharpest split is NestJS, named behind four of six React Native builds and none of the five Flutter builds. Express is close to its mirror image, named in two of five Flutter builds and none of the React Native builds. Node.js itself is named in four of six React Native records and four of five Flutter records, so the runtime is not a point of difference at all. Firebase leans React Native, three of six against one of five. AWS is named in all five Flutter records and three of six React Native records, while MongoDB and serverless AWS Lambda appear only on the Flutter side, and Elasticsearch and PostgreSQL only on the React Native side.

Is the NestJS split really a runtime difference?

No, and reading it as one would be the easiest mistake to make with this table. NestJS is a framework that runs on Node.js, so the four React Native builds behind it are Node.js services too. The records say so directly: Koor, Three28 and Dooz are all filed under the category React Native & Node.js while their techstack names NestJS. The two descriptions sit at different levels rather than in conflict. Counted honestly, five of six React Native builds name a Node.js-family backend, NestJS four times and plain Node.js once, and four of five Flutter builds name Node.js outright. AgroBridge names only Firebase; Food Magnet names AWS Lambda functions without naming a runtime at all. What differs is the shape above the runtime: our React Native work used the opinionated NestJS structure, our Flutter work used Express, plain Node services and, twice, AWS Lambda. That describes our staffing and architecture habits, not the frameworks.

Did the two frameworks land in the same verticals?

No, and this is the single most important limit on the comparison. Not one vertical in our portfolio was built twice, once in each framework. React Native carried banking, an agricultural marketplace, food delivery, industrial roller-shutter field tooling, creator monetisation and an automotive marketplace. Flutter carried food truck discovery, media streaming, digital power of attorney, workforce welfare and fitness competition. Two React Native projects carry a FinTech tag, the FinTech Mobile App and Dooz; no Flutter project does. Three of the five Flutter records centre on live location or live competition data: Food Magnet tracks food truck locations, TAL offers real-time location services and WOD Pro League runs real-time leaderboards. Because the workloads never overlap, any difference in release outcomes between the two groups is confounded with the difference in what the apps were asked to do, who the client was and what the contract covered. There is no like-for-like pair anywhere in these 11 builds.

Does either framework arrive with a companion web surface more often?

In our record, yes, and the gap is wide. Four of five Flutter builds shipped alongside a React or Next.js web surface described in the project record. Food Magnet pairs a Flutter app with a React.js admin dashboard. TAL Workforce pairs Flutter with a React.js admin dashboard and Next.js for the website. WOD Pro League pairs Flutter with a React administrative dashboard. The Digital Power of Attorney platform pairs Flutter mobile with React.js on the web. Only JUJU Streaming names no web surface. On the React Native side, one of six names a companion web client: Dooz Inspected Cars, which used Angular for its web interface. The link fields show the same pattern independently, with four of five Flutter builds carrying a public web URL against one of six React Native builds. The plain reading is that Flutter reached us on engagements already scoped as multi-surface products. That is a statement about the briefs we won, not about framework capability.

What do the client-reported outcome numbers actually say?

They say less about frameworks than their volume suggests. The portfolio carries 57 extracted outcome entries across 25 projects, 19 of which have at least one. Twenty-five of those entries belong to the 11 mobile builds: 11 spread across five React Native projects and 14 across four Flutter projects. AgroBridge and Food Magnet carry none, and Food Magnet is instructive, because it has the longest list of stored figures in the portfolio at 11 entries and every one is a stack or configuration label rather than an outcome. On the React Native side the record shows 120,000+ completed orders and a 4.8 out of 5 rating for Koor, 99.9% uptime and 50k+ daily transactions for the FinTech app, and 98% customer satisfaction across 20,000+ verified vehicles for Dooz. On the Flutter side, 128,540 users and 3.6M streams for JUJU, 5,000+ workers across 2,500+ partner venues for TAL, and 12,778 athletes for WOD Pro League. All are client- or project-reported and none was independently audited by us.

Why is this delivery experience rather than a benchmark?

Because we never ran the experiment that would make it one. We did not build the same screen twice, did not measure frame times, cold start, memory or binary size, and did not instrument either framework under load. Team composition, briefs, budgets and delivery years all differed between projects, and none of those variables is captured in the records we are counting. The counting itself has soft edges worth naming: framework attribution rests on hand-maintained tags and techstack fields, one project stores an Apple URL in its android field, and the source facts file disagrees with itself on two unrelated totals, listing React.js as both seven and eight and AWS as both eight and nine. The mobile framework counts of six and five reconcile in both passes, and we re-derived every published number directly from the raw project records, which is why this article rests on recounted values rather than on any precomputed aggregate.

Limitations

• n=11 mobile builds from one agency portfolio of 25 projects. This is far too small and too self-selected to support any industry-wide claim.
• No controlled comparison was run. No paired build, no benchmark harness, no instrumentation, no control group.
• The two framework groups cover completely different verticals, so release outcomes are confounded with brief, client, budget and delivery year.
• Framework attribution depends on hand-maintained tags and techstack fields. Waitmate Platform names React Native in its narrative and solution text but carries no tag or techstack entry, so it is excluded from the 6.
• Only 8 of the 11 builds name their framework in both tags and techstack; 3 name it in one field only, and the free-text category field is inconsistent enough that we do not use it for attribution.
• Store status is inferred from stored link fields, which can be stale, and absence of a link is not proof that an app never shipped.
• Three28 Creator Platform stores an Apple App Store URL in its android field, so raw per-platform counts need this manual correction.
• Two projects outside the comparison set, Outstride and Pastel Marketplace, carry app store URLs without any mobile framework recorded, so portfolio-wide store presence is wider than these 11 builds.
• All outcome metrics are client- or project-reported and were not independently audited. They measure product traction, not framework behaviour, and 2 of the 11 mobile builds carry none at all.
• The source facts file disagrees with itself on two totals (React.js as 7 and 8, AWS as 8 and 9), so every figure published here was recounted from the raw project records instead.

What this data cannot answer

• Which framework renders faster, starts faster, or uses less memory. We ran no performance test of any kind.
• Which framework produces smaller app binaries. Bundle size is not recorded for any project.
• Which framework is cheaper to hire for, or what either skill set costs in any market.
• Which framework took fewer developer-hours or shipped sooner. No effort or timeline data exists in these records.
• Whether the NestJS-versus-Express difference reflects any technical fit with either framework. The records show which team built what, not why.
• Whether either framework caused any of the client-reported outcome numbers. The workloads and businesses never overlap.
• Which framework produces more crash-free sessions or better store ratings at scale. Only one rating value exists in the entire mobile set.
• How either framework behaves on older Android hardware, on tablets, or offline. Device-level data is not captured.
• Whether apps with no recorded store link were cancelled, released privately, or released and later delisted.
• Which framework Outstride and Pastel Marketplace were built in, or whether Waitmate's described React Native app ever shipped. Those records name no framework and carry no matching store link.