10 Best Hybrid App Frameworks in 2026,Ranked

"Should we build this in Flutter or React Native? And what about that new one TikTok made?"

That's a paraphrase of a question I hear on discovery calls roughly once a month. The founder usually has two or three browser tabs open with listicles that disagree, and none of them say when they were written.

So here's the claim, with a date on it. On September 29, 2026 I pulled live numbers from the GitHub API for thirteen cross-platform frameworks: stars, every release in the last twelve months, the latest stable tag and its date, and the license. I checked each project's official docs for the platforms it targets and who backs it.

Three didn't make the cut. The other ten are ranked below on a five-part rubric you can re-run in about twenty minutes with a terminal.

The top of the list is Flutter, with 179,152 stars and 40 stable releases in a year. The surprise is who comes second, and why that should make you suspicious of every ranking built on stars, including this one.

To be clear about my own bias: we build most client apps in React Native with Expo, and I'll say why in its own section. React Native ranks fourth here. I didn't move it.

Most framework rankings pick a winner from a benchmark nobody can reproduce, or from the author's favorite stack, and neither survives a second look.

The wrong model goes like this: there is a best framework, it's the fastest one, and a chart of frames per second will tell you which. So you pick the winner and you're done.

The trouble is that performance benchmarks for cross-platform frameworks are almost always published by someone with a stake. A benchmark app written by a Flutter fan will be idiomatic Flutter and clumsy React Native, and the reverse. I looked for an independent benchmark I could fetch and re-run, and I didn't find one I trusted, so this ranking doesn't score speed at all.

The real model is that a framework is a long-term dependency, like a landlord. You aren't choosing the nicest apartment on the day you tour it. You're choosing who will fix the boiler for the next five years. The questions that matter are whether the project is actively released, whether it runs on the platforms you need, who pays the maintainers, and whether you can hire people who know it.

Therefore: score the landlord, not the apartment. Release cadence, freshness, official platform support and backing are all things you can check yourself in public data. Stars are in the rubric too, but capped, because they measure attention.

Why does that last point matter so much? Because stars are bookmarks. A repository that trended on a news site once in 2021 keeps those stars forever, whether or not anyone ships an app with it today. Stars favor older projects and projects popular with web developers. They are a crowd, not a verdict.

If you want the longer case for hybrid development in general, it's in our hybrid app development guide. This piece assumes you've already decided to go cross-platform and want to know with what.

Thirteen candidates went in. To be ranked, a framework had to ship stable releases in the last year, target both iOS and Android officially, and be a framework rather than a layer on top of another one.

• Expo: folded into React Native: React Native's own Get Started page says most developers benefit from using a React Native framework like Expo, and Expo's FAQ calls itself an open-source framework for Android, iOS and the web. It's a distribution of React Native with routing, build services and libraries, not a rival runtime. Ranking it separately would count React Native twice. Its expo/expo repo had 52,501 stars on the check date, and the expo npm package published SDK 58.0.0 on September 29, 2026.
• Apache Cordova: maintenance mode: Not dead. The Cordova blog announced Cordova Android 15.1.0 on July 22, 2026 and a plugin update on August 10, 2026. But cordova-android shipped one release in twelve months, and the parent apache/cordova repo holds 710 stars. It keeps existing apps alive; it's not where I'd start a new one.
• Snap's Valdi: public beta: Its README labels it beta and says Snap has used it in production apps for years. Its latest non-prerelease tag was beta-0.1.1 from July 1, 2026, with 16,376 stars. It's MIT licensed and interesting. It hasn't earned a place in a ranking that scores release history.

That left ten: React Native, Flutter, Kotlin Multiplatform with Compose Multiplatform, Ionic, Capacitor, .NET MAUI, NativeScript, Tauri, Lynx and Uno Platform.

One judgment call needs saying out loud. Ionic and Capacitor come from the same team, and they're often used together. I ranked them separately because they do different jobs: Ionic is a UI kit, and Capacitor is the native runtime that wraps any web app. Plenty of teams use Capacitor with React or Vue and no Ionic components at all. We do, as you'll see.

A second one: Kotlin Multiplatform is the code-sharing technology, and Compose Multiplatform is the optional shared UI layer on top. Kotlin itself lives in the JetBrains/kotlin repo with 53,462 stars, but most of those are for the language, not the multiplatform story. So I scored the compose-multiplatform repo (19,395 stars), which is the cross-platform piece. That choice costs KMP a star point, and I think it's the fair one.

Five criteria, ten points maximum, all pulled from public sources on September 29, 2026 (about 06:40 UTC on September 30).

• Stars, 3 points: 3 for 100,000 or more; 2 for 25,000 to 99,999; 1 for 10,000 to 24,999. Measures attention only. Capped at 3 of 10 so it can't dominate.
• Release cadence, 2 points: Stable (non-prerelease, non-draft) releases published in the 12 months before the check. 2 for 20 or more; 1 for 8 to 19; 0 below 8.
• Freshness, 1 point: 1 if the latest stable release is dated within 30 days of the check.
• Platform reach, 2 points: From the project's own docs. 2 for iOS and Android plus desktop or web; 1 for iOS and Android only.
• Backing, 2 points: 2 for a company, or a company-funded foundation, that employs maintainers; 1 for a community foundation or conservancy. Not a judgment of quality, a judgment of who pays for the boiler.

Ties break on stars. The data calls were the GitHub repo endpoint for stars and license, and the releases endpoint with per_page=100 and pagination for every release.

Three frameworks needed adjustments, and each one is a place you could disagree with me.

Flutter stopped publishing GitHub releases years ago (its last one there is a 2024 prerelease), so I counted stable entries in Flutter's official release manifest instead: 40 in the year, latest 3.47.5 on September 18, 2026. Tauri's repo tags every sub-package, which inflates its count to 201 stable releases. I counted only core tauri-v tags: 22. NativeScript's repo mixes core, webpack and Vite tags, so I counted stable versions of @nativescript/core on npm: 24.

What I left out on purpose.Performance benchmarks, because none I found was independent and reproducible. Developer survey rankings, because I didn't fetch a survey page I could cite for this date. npm or pub download counts, because they're inflated by CI pipelines and hard to compare across ecosystems. Company adoption logos, because every framework site shows its best ones.

Here is the raw data, then the scores. Every number in the first table came from the GitHub API or an official page on September 29, 2026.

Now the scores.

Do the arithmetic. The ten totals add to 79, so the average is 7.9 of 10. That's high, and it should be: I already cut the three weakest candidates. The spread from first to last is 4 points, which means the gap between the healthiest project and the least healthy one on this list is smaller than most listicles imply.

Look at the stars column against the cadence column and a pattern appears. Flutter has about 1.4x React Native's stars (179,152 divided by 126,760) and about 1.4x its stable releases (40 against 28). React Native has about 7.5x Capacitor's stars but fewer stable releases (28 against 31). Attention and activity aren't the same thing.

React Native lost its freshness point by four days. Its latest stable tag, v0.87.1, was dated August 26, 2026, which is 34 days before the check. It shipped 28 stable releases in the year, so this is a quiet month, not a quiet project. I left the rule as written because bending it for the stack we use would make every other cell less believable.

And here is what each one officially targets, per its own docs.

Each entry gives the score, the verified facts, who it suits, and the cost nobody puts on the homepage. The scores are vital signs. The paragraphs are where the decision gets made.

Top ranked

1

Flutter

the most stars and the busiest release train

Score: 10 of 10. The flutter/flutter repo had 179,152 stars on the check date, BSD-3-Clause license, backed by Google. The release manifest shows 40 stable releases in twelve months, latest 3.47.5 on September 18, 2026. Flutter's docs cover Android, iOS, web, Windows, macOS and Linux.

Suits: products where the design has to look identical on every phone, teams willing to learn Dart, and apps that may later want a desktop build from the same code.

The cost:Flutter draws its own interface instead of using the phone's native controls. That's why it looks consistent, and it's also why a Flutter app can feel slightly off to an iPhone user when Apple changes its design language. Dart is also a language almost nobody on a web team already knows, so hiring and onboarding cost more than the star count suggests.

Visit Flutter

2

Tauri

a desktop giant that also ships mobile

Score: 9 of 10. tauri-apps/tauri had 111,496 stars, Apache-2.0 license, and 22 core releases in twelve months, latest tauri v2.12.0 on September 26, 2026. The README says the project is a Programme within the Commons Conservancy, funded through Open Collective. Its official site says it builds for Linux, macOS, Windows, Android and iOS from one codebase, with a web frontend and application logic in Rust.

Suits: teams that already ship a Tauri desktop app and want phones next, and products where a small, secure Rust core matters more than a large mobile plugin catalog.

The cost: this is the entry that should make you distrust star-based rankings. Almost all of those 111,496 stars were earned as an Electron alternative on desktop. Mobile is the newer half of the project, and the pool of mobile examples, plugins and developers is much smaller than for the frameworks ranked below it. Second on vital signs. Not second for a phone-first product.

Visit Tauri

3

Ionic

the web developer's UI kit for app stores

Score: 9 of 10. ionic-team/ionic-framework had 52,689 stars, MIT license, 39 stable releases in the year, latest v9.0.5 on September 23, 2026. OutSystems acquired Ionic in November 2022, and SD Times reported that Ionic would keep operating independently. Ionic runs on the web and ships to iOS and Android through Capacitor.

Suits: internal tools, field apps and business apps built by teams who know Angular, React or Vue and want native-looking components without learning a new language.

The cost:everything renders in a webview. For forms, lists and dashboards that's fine. For heavy animation, large scrolling feeds or camera work, you'll feel it before your users complain, and you'll spend time tuning what a native-rendered framework gives you for free.

Visit Ionic

4

React Native

the default for JavaScript teams

Score: 8 of 10. The repo now lives at react/react-native, with 126,760 stars, MIT license, and 28 stable releases in the year (patches across the 0.79 to 0.87 lines), latest v0.87.1 on August 26, 2026. Its README points to the React Foundation for governance. Its site describes it as a framework for native apps on Android, iOS and more using React.

Suits: startups with a React web app, consumer apps that need native controls, and any team that wants to hire from the largest JavaScript talent pool. Its Get Started page recommends a framework such as Expo, which is how we use it.

The cost: it scores 1 on platform reach because its core officially targets Android and iOS; Windows, macOS and web come from partner projects. And upgrades are the tax. A new React Native version every few months means native modules and third-party libraries have to keep up, and one abandoned library can hold your whole app back a version.

Visit React Native

5

.NET MAUI

Xamarin's successor for C# shops

Score: 8 of 10. dotnet/maui had 23,322 stars, MIT license, 21 stable releases in the year, latest 10.0.110 on September 22, 2026. Microsoft Learn describes it as the evolution of Xamarin.Forms for Android, iOS, macOS and Windows from one codebase. Xamarin itself lost support on May 1, 2024.

Suits: companies with C# engineers and Microsoft tooling, enterprise line-of-business apps, and anyone still carrying a Xamarin app that has to move.

The cost:the mobile community and third-party plugin catalog are smaller than JavaScript's or Flutter's, so you'll write more platform code yourself. Outside .NET shops, it's hard to justify.

Visit .NET MAUI

6

Capacitor

wrap the web app you already have

Score: 8 of 10. ionic-team/capacitor had 16,752 stars, MIT license, 31 stable releases in the year, latest 8.5.2 on September 11, 2026. Capacitor's site calls it a native runtime for web apps targeting iOS, Android and Progressive Web Apps, and offers a migration path from Cordova.

Suits:products that are already a good web app and need a store listing, push notifications and a few device APIs. It's the lowest-cost route from web to phone that I know.

The cost:same webview ceiling as Ionic. It also takes discipline: a web app that ignores safe areas, keyboard behavior and offline state will feel like a website in a costume, and Apple's reviewers notice that too.

Visit Capacitor

7

NativeScript

JavaScript straight to native APIs

Score: 7 of 10. NativeScript/NativeScript had 25,662 stars, MIT license, and 24 stable @nativescript/core releases in the year, latest 9.1.2 on September 14, 2026. Its README places the project under the OpenJS Foundation.

Suits: teams that want JavaScript with direct access to every iOS and Android API, without writing a bridge module for each one.

The cost:a smaller community than React Native's, fewer people to hire, and foundation stewardship rather than a large company paying a full-time team. I checked for a company that employs its core maintainers and couldn't confirm one on the pages I read, which is why it scores 1 on backing.

Visit NativeScript

8

Kotlin Multiplatform

share the logic, keep native

Score: 7 of 10. JetBrains/compose-multiplatform had 19,395 stars, Apache-2.0 license, 11 stable releases in the year, latest v1.12.1 on September 22, 2026. JetBrains' stability page lists Android, iOS and desktop as Stable for both the core technology and Compose Multiplatform UI, with web on Kotlin/Wasm still Beta.

Suits: companies with Android engineers who write Kotlin, apps where business logic is the hard part, and teams that want to share code without forcing a shared UI.

The cost:iOS developers have to meet Kotlin halfway, and the iOS side of the community is younger than on the JavaScript frameworks. Its lower score comes from cadence and stars, not from JetBrains' commitment, which is as strong as anyone's on this list.

Visit Kotlin Multiplatform

9

Lynx

ByteDance's multithreaded newcomer

Score: 7 of 10. lynx-family/lynx had 15,141 stars, Apache-2.0 license, 16 stable releases in the year, latest 4.0.3 on September 11, 2026. Its NOTICE file credits ByteDance and TikTok. Its official site says it renders natively on iOS, Android, HarmonyOS and the web.

Suits: teams with web skills who need HarmonyOS, and teams willing to adopt early for a multithreaded architecture built at very large scale.

The cost:it's young in public. The libraries, tutorials and hiring pool that React Native built over a decade don't exist yet, and your team becomes part of the early adopter crowd that finds the rough edges.

Visit Lynx

10

Uno Platform

C# and XAML almost everywhere

Score: 6 of 10. unoplatform/uno had 10,062 stars, Apache-2.0 license, 16 stable releases in the year, latest 6.6.184 on August 6, 2026. The Uno Platform site lists Windows, iOS, Android, WebAssembly, Linux and macOS, and the organization describes the project as open source and professionally supported.

Suits: .NET teams that need the widest reach from one C# codebase, including the browser through WebAssembly, and WPF or Silverlight shops migrating old apps.

The cost: the smallest community on the list by stars, and it lost the freshness point on the check date. For a consumer phone app with no .NET history, there are easier roads.

Visit Uno Platform

Under the brand names, these ten frameworks draw your app in one of three ways, and that choice explains most of their trade-offs better than any score.

The webview family: Ionic, Capacitor and Tauri.Your app is a web page running inside the phone's built-in browser engine, with a bridge to native features like the camera and notifications. The upside is enormous: your web developers can build it, and a lot of your web code comes along. The downside is the ceiling. A webview is a browser, and browsers on phones are good but not free. Long lists, complex gestures and heavy animation are where you start fighting it.

Think of it as a food truck parked inside a restaurant. It serves the same menu you already know how to cook, which is cheap and fast. It can't use the restaurant's full kitchen without asking.

The native-views family: React Native, NativeScript, .NET MAUI and Lynx.You write in JavaScript or C#, and the framework creates real iOS and Android controls. A button is the platform's button. Scrolling feels like the platform because it is the platform. The cost is that every platform difference leaks through eventually, and you'll write some code per platform.

The own-renderer family: Flutter, Compose Multiplatform and Uno in its Skia mode.The framework paints every pixel itself, the way a game engine does. You get identical visuals everywhere and tight control of animation. You give up automatic platform look and feel, so when Apple or Google changes its design language, your app doesn't change with it until you do the work.

Kotlin Multiplatform sits slightly apart, because it lets you share code without sharing UI at all. You can keep fully native screens and share only the logic underneath, which is the most conservative option on this list and the one many established companies prefer.

Why does this matter for picking? Because it tells you what will hurt later. A webview app hurts when the product gets animation-heavy. A native-views app hurts during upgrades, when libraries lag behind. An own-renderer app hurts when users expect the platform's look. Choose the pain you can afford, based on what your product will look like in two years, not what the demo looks like this month.

There's a second question the architecture answers: what happens when you need something the framework doesn't offer. In all three families the answer is the same in principle (write a small piece of native Swift or Kotlin and call it), but the effort differs. JavaScript frameworks have the largest catalog of modules someone already wrote. Flutter's package catalog is large too. The C# and Rust options have smaller ones, so budget more hours for custom native work there.

And a third: who can review the app in two years. A framework your future hires already know is cheaper to maintain than a better one they don't. That's not glamorous, but it's the line item that shows up every month after launch, long after the build invoice is paid.

The rank tells you which projects are healthy. Your team tells you which one to use.

The single best predictor of a smooth build isn't the framework's score. It's whether the people writing the app already know the language. A strong React team on React Native will beat the same team learning Dart, every time, for the first year.

Two rows deserve more words.

The web-app row. If you already have a responsive web app that users like, Capacitor is often the cheapest path to both stores, because you reuse almost the whole codebase. The mistake is assuming that makes it a phone app. Budget time for native navigation feel, offline behavior and push notifications.

The Kotlin row.Kotlin Multiplatform is the only option here that doesn't ask you to give up native UI at all. You can share the networking, data and business rules and still write SwiftUI on iOS. For a company with a strong Android team and a thin iOS one, that's often the best trade.

If you're also deciding who builds it, that's a separate question with its own trade-offs, covered in consultant vs agency vs freelancer.

We build most client mobile apps in React Native with Expo. It ranks fourth on this rubric, and I'd still pick it for most of the founders who call us.

The reason is people, not frames per second. Most of our clients have, or will have, a React web app. React Native lets the same developers and a lot of the same logic cover the phone. Expo handles builds, over-the-air updates and the native configuration that used to eat days per project. Our React Native development service lists both Expo and bare workflow experience, because some apps outgrow the managed setup.

A shipped example: we built GameOn as a React Native app with matchmaking, real-time game coordination and social features, on Firebase, Node.js, Socket.io, Stripe and Google Maps.

But I'd be misleading you if I said React Native is all we ship. Fighter Cut and its coach companion The Corner are React 19 web apps wrapped with Capacitor 8 for iOS, on a shared Supabase backend. For those products the web app came first and needed to work offline in a gym basement, and wrapping it was faster than rewriting it. Same team, different tool, because the product was different.

The downsides of our default, stated plainly.React Native upgrades are real work, and a third-party library that stops being maintained can pin you to an old version. Expo's managed conveniences are wonderful until you need a native SDK that doesn't fit them, and then you're maintaining native projects anyway. And the JavaScript bridge era left a lot of old blog advice that no longer applies, which confuses new hires.

When I'd pick Flutter instead.When the brand is the product: a design-led consumer app where every pixel has to match across devices, animation is central, and the client doesn't already have a React team to reuse. Or when a desktop build from the same code is on the roadmap.

When I'd pick Kotlin Multiplatform instead. When the client has Android engineers in-house, an existing native Android app, or a regulated product where native UI and native security APIs are non-negotiable and only the business logic should be shared.

When I'd pick Capacitor. When there's a good web app already, the budget is tight, and the phone app is mostly the same screens. That's the kind of project our hybrid app development service scopes most often.

This is a scenario, not a client.

Consider a fitness startup with a React web dashboard for coaches, two React developers and no mobile developer. It wants an athlete app on iOS and Android with workout logging, offline use, push reminders and in-app purchases. Its budget sits in our single-workflow band of $28,000 to $70,000, which runs 4 to 9 weeks.

Step one is the team. Two React developers means React Native or Capacitor keep them productive on day one. Flutter or KMP means both learn a new language before they're useful. At a senior-led rate of $150 to $225 an hour, even two weeks of ramp for two people is 160 hours, or about $24,000 to $36,000. That's roughly 0.35x to 0.5x of the top of the budget band spent before any feature ships.

Step two is the product. Offline logging and push reminders are well supported in both React Native and Capacitor. There's no heavy animation. So both survive.

Step three is reuse. The coach dashboard already exists in React. If the athlete screens are mostly new, React Native with Expo gives native controls and a store-ready build pipeline. If the athlete app is mostly the existing web screens, Capacitor wins on cost.

Step four is the vital signs check: React Native at 8 of 10, Capacitor at 8 of 10. Both healthy. The rubric doesn't decide this one, the product does, which is the usual outcome. If the startup needs an MVP scoped before it commits, that's what our MVP development engagements are for.

Several numbers come up constantly in framework comparisons, and I didn't print them.

Market share percentages.Claims that some percentage of apps or developers use a given framework usually trace to a developer survey whose sample is self-selected, or to a vendor blog that doesn't cite one at all. I didn't fetch a survey page for this date, so no share figures appear here.

Performance benchmarks. Startup time and frame rate comparisons exist in abundance. None that I found was independent, recent and reproducible with published code, so none is scored.

Adoption logos and user counts.Every framework site lists famous apps and large user numbers. Those are the projects' own claims about their users. Compose Multiplatform's page, for example, cites apps by download and active user counts. I report nothing like that as a fact.

Valdi's production history.Its README says Snap has used it in production for years. That's plausible and I have no reason to doubt it, but it's Snap's statement, not something I could check.

Maintainer employment.I scored backing from what official pages and READMEs say. Who exactly is on each payroll isn't public for most projects, so the backing column is the least precise one in the table.

Every method has a blind spot. Here are this one's, so you can correct for them.

Star inflation from other uses.Tauri's stars are mostly desktop. Kotlin's main repo has stars for the language, which is why I used the Compose repo instead. A project that serves several audiences looks bigger than its mobile community is.

Release counting is uneven.Some projects tag every patch; others batch. Flutter counts come from a different source than everyone else's. A project that releases twice as often isn't twice as healthy. That's why cadence is capped at 2 points.

A one-day snapshot. React Native would have scored 9 a few days earlier. Uno would have scored 7 in early August. Freshness is the noisiest point on the scale.

No weight for hiring.The rubric doesn't measure how many developers you can hire in your city, which is often the most expensive variable in the whole decision.

So what's the worst case if you trust this ranking too much? You pick a healthy framework your team doesn't know. That's survivable, but it costs weeks. The fix is cheap: use the score to rule out unhealthy options, then decide on team fit.

You can make this decision in a week without a single benchmark.

• 1. Write down your team's languages: List who will build and maintain the app and what they already write. Cross off every framework whose language nobody knows unless you're prepared to pay for the ramp.
• 2. Re-check the two survivors: Open each repo's releases page and note the latest stable date and how many releases shipped this year. Read the official platform support page for the exact platforms you need.
• 3. Build the hardest screen first: Spend two or three days building the riskiest screen (the camera, the offline sync, the big animated feed) in your top pick. If it fights you there, it'll fight you everywhere.

If you'd like a second opinion on the shortlist, that's the kind of thing we sort out on a discovery call. Time to pick a landlord.