React Native vs Flutter: What 12 Cross-Platform Builds in One Portfolio Show

Which builds in the portfolio use React Native or Flutter?

Of the 26 portfolio entries, twelve name a cross-platform mobile framework in their tags or tech stack: six React Native and six Flutter. That structured-field rule matters at the edges. Dooz Inspected Cars lists Angular and NestJS in its tech stack and React Native only in its tags, so it counts. The remaining thirteen entries name no mobile framework, which is not the same as having no app: Pastel and LoopedIn link app store listings, yet neither entry names the framework behind its app.

The table below is therefore the entire comparison set. It carries the context of each build, because context turns out to separate the two groups more cleanly than anything technical does.

How is each framework attribution 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. Nine of the twelve builds name their framework in both tags and tech stack. Three do not. Dooz Inspected Cars is React Native in tags only, because its tech stack lists the Angular web client and the NestJS backend instead. Digital Power of Attorney is Flutter in tags only, its tech stack naming Node.js and Express. JUJU Streaming is the reverse, Flutter in tech stack only, with its tags describing the backend.

The category label is less consistent still, which is why it is not used 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 six, but it explains why every count here names the fields it reads.

Which framework's builds link to public app stores more often?

Store presence is read from each entry's web, Android and iOS links. Two of the six Flutter builds link to both Google Play and the Apple App Store: Food Magnet and TAL. One of the six React Native builds does, Dooz. React Native is not absent from the stores; it is the more store-present group overall. Four of six React Native builds link at least one store listing, against three of six Flutter builds. Of those four, Koor and CEDMAT are on Google Play only and Three28 is on the App Store only.

The builds with no link at all split evenly and for different reasons. Two Flutter builds have no public link: JUJU, which has none listed, and WOD Pro League, whose site and store listings no longer resolve. Two React Native builds, the FinTech Mobile App and AgroBridge, have no client and no public link.

What backends did each framework pair with?

One rule governs every row below: a technology counts when it is named in the entry's category label, tags or declared tech stack. Under that rule the sharpest split is NestJS, named behind four of six React Native builds and one of the six Flutter builds. Express appears once, behind the Flutter-based Digital Power of Attorney platform; the project descriptions of WOD Pro League and TAL name a Node.js and Express backend on both, which those entries' fields do not record. Node.js itself is named in four of six React Native entries and four of six Flutter entries, so the runtime is not a point of difference.

AWS is named in five of six Flutter entries and three of six React Native entries. Serverless AWS Lambda appears only on the Flutter side, in Food Magnet, and Elasticsearch only on the React Native side, in Koor. Firebase appears in two React Native entries and one Flutter entry.

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 entries say so directly: Koor, Three28 and Dooz carry the category React Native & Node.js while their tech stack names NestJS. The two descriptions sit at different levels rather than in conflict. Counted that way, five of six React Native builds name a Node-family backend, NestJS four times and plain Node.js once, and four of six Flutter builds name Node.js outright. AgroBridge names only Firebase; Food Magnet names AWS Lambda functions without naming a runtime. Hear With You names NestJS.

What differs is the shape above the runtime: the React Native builds used the opinionated NestJS structure, the Flutter builds mostly used Express, plain Node services and, on Food Magnet, AWS Lambda, with NestJS only behind Hear With You. Because four of the six Flutter builds were employer work and no React Native build was, that split describes different teams and contexts, not the frameworks.

Did the two frameworks land in the same verticals?

No, and this is the most important limit on the comparison, alongside context. No vertical in the portfolio was built twice, once in each framework. React Native carried a banking app, an agricultural marketplace, food delivery, a roller-shutter installer app, creator monetisation and a used-car marketplace. Flutter carried food-truck discovery, media streaming, digital power of attorney, workforce welfare, fitness competition and AI storytelling. Two React Native entries carry a FinTech tag, the FinTech Mobile App and Dooz; no Flutter entry does. Three of the six Flutter products centre on live location or live competition data: Food Magnet tracks food-truck locations, TAL helps mobile workers find nearby facilities and WOD Pro League runs real-time leaderboards.

Because the workloads never overlap, and because most of the Flutter builds came from Sameem's employers while none of the React Native builds did, any difference in store presence between the two groups is confounded with what the apps were asked to do, who commissioned them and what the work covered. There is no like-for-like pair anywhere in these twelve builds.

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

In this portfolio, yes. Four of six Flutter entries name a React-family web surface in their tags or tech stack: Food Magnet pairs its Flutter app with a React.js admin dashboard, TAL Workforce and the Digital Power of Attorney platform both carry a React.js tag, and Hear With You names Next.js for its admin dashboard and landing page. On the React Native side, one of six names a companion web client: Dooz Inspected Cars, which lists Angular for its web interface. The link fields point the same way independently, with three of six Flutter builds linking a web address against one of six React Native builds.

The likeliest reading is that these Flutter products were multi-surface products, with the mobile app as one surface among several. That is a statement about these particular projects, not about what either framework can do.

Why is this portfolio evidence rather than a benchmark?

Because nobody ran the experiment that would make it one. No screen was built twice, no frame times, cold starts, memory or binary sizes were measured, and neither framework was instrumented under load. Team composition, employer, brief, budget and year all differed between projects, and none of those variables is captured in the fields being counted. The counting has soft edges worth naming: framework attribution rests on hand-maintained tags and tech stack lists, and three of the twelve builds name their framework in only one of the two. Every number published here was counted from the 26 portfolio entries with a script, not taken from any precomputed summary.

Limitations

• n=12 mobile builds from one portfolio of 26 entries. This is far too small and too self-selected to support any industry-wide claim.
• The portfolio is not a record of DevoraX client work. 4 of the 6 Flutter builds were employer projects at Zencloud or Webrange Solutions, and JUJU and Hear With You were direct client work; of the 6 React Native builds, 2 were direct client work, 2 have no named client and 2 have no client at all.
• 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 store presence is confounded with brief, employer, budget and year.
• Framework attribution depends on hand-maintained tags and tech stack lists. Only 9 of the 12 builds name their framework in both; 3 name it in one only, and the category label is too inconsistent to use for attribution.
• Store presence is read from stored links. Absence of a link is not proof that an app never reached a store, and a link that resolves today may not resolve tomorrow.
• Two entries outside the comparison set, Pastel and LoopedIn, link app store listings without naming a mobile framework, so store presence across the portfolio is wider than these 12 builds.
• Free-text descriptions were not counted, so technologies named only in prose, such as Express on WOD Pro League and TAL, are missing from the backend table.

What this data cannot answer

• Which framework renders faster, starts faster, or uses less memory. No performance test of any kind was run.
• Which framework produces smaller app binaries. Bundle size is not recorded for any entry.
• Which framework is cheaper to hire for, or what either skill set costs in any market.
• Which framework took fewer developer-hours or reached release sooner. No effort or timeline data exists in the portfolio.
• Whether the NestJS-versus-Express difference reflects any technical fit with either framework. The entries show which stack each product used, not why.
• Whether either framework affected any product's commercial results. The portfolio holds no outcome data, and the workloads and businesses never overlap.
• Which framework produces more crash-free sessions or better store ratings at scale. No crash or rating data is counted here.
• How either framework behaves on older Android hardware, on tablets, or offline. Device-level data is not captured.
• Whether builds with no store link were cancelled, released privately, or released and later delisted.
• Which framework the Pastel and LoopedIn apps use. Their entries name no mobile framework.