★ 176,899DartBSD-3-Clauseupdated Jun 2026
best for teams who want one codebase and pixel-identical UI on both platforms
Flutter is the only framework here that refuses to touch native widgets at all — it draws every pixel itself through its own rendering engine, which is why two phones running the same app look identical down to the font kerning. Hot reload keeps state between edits in a way React Native's version doesn't reliably manage, and Impeller finally killed the shader-compile stutter that embarrassed early Flutter apps.
The cost shows up in two places you won't notice until you're committed. Pub.dev is a much thinner ecosystem than npm — plenty of packages are maintained by one person and quietly stop getting updated after a Flutter release breaks them. And if that app ever needs to also be an indexable web page, don't: Flutter web renders through a WebAssembly canvas blob that search crawlers can't read and screen readers choke on.
A hello-world APK also starts around 7MB compressed, which matters if any of your users are on a slow connection — something uni-app's mini-program targets never have to think about.
Our full take →GitHub ↗
★ 126,740C++MITupdated Oct 2026
best for teams with existing React/JS skills who want to reuse them for mobile
React Native is the pick if your team already knows React and wants that investment to carry over, full stop. The New Architecture — Fabric, TurboModules, JSI — is real now, not a roadmap promise: native calls are synchronous instead of going through the old bridge's JSON serialization, which used to be the first thing you'd blame for jank.
What the pitch glosses over is how much native work you still end up doing. Anything animation-heavy still fights the JS thread, and most non-trivial RN apps end up with a hand-written native module somewhere, quietly undercutting 'learn once, write anywhere.' Upgrading between versions is still a real tax if you're not on Expo — native project files drift from what the CLI expects, and the upgrade tool only gets you partway there.
If that upgrade pain sounds like a dealbreaker, that's exactly the problem Expo exists to paper over.
Our full take →GitHub ↗
★ 49,998TypeScriptMITupdated Jun 2026
best for the fastest path to a shipped React Native app without touching Xcode or Android Studio
Expo is React Native with the parts that make RN teams miserable already handled: provisioning profiles, signing certificates, native module bridging. The Expo Modules API makes writing a Swift or Kotlin module far less painful than raw RN bridging, and Expo Router brings Next.js-style file-based routing to mobile, a real time-saver once you stop fighting its conventions.
The tradeoff is that the managed workflow is a cage with nice wallpaper. Need a native dependency the Expo SDK hasn't wrapped yet? You either eject to bare workflow and lose the managed perks, or wait. EAS Build — the piece that makes the whole CI/CD story actually pleasant — costs money at any real scale, so the open-source framing undersells how much of the good experience depends on a paid hosted service you don't control.
Compared to plain React Native, you're trading some ceiling for a much lower floor. Most teams should take that trade.
Our full take →GitHub ↗
★ 23,267C#MITupdated Jun 2026
best for .NET shops already writing C# who want mobile and desktop from the same codebase
MAUI is the obvious answer if your team already writes C# and wants four platforms — Android, iOS, macOS, Windows — without four codebases. Unlike Flutter or Ionic, it isn't drawing its own widgets or wrapping web components; the handler architecture maps to real native controls, so you're not stuck with a lowest-common-denominator look.
What you trade for that native-control access is build speed and reliability. A clean build on a modest machine can take several minutes, hot reload is unreliable enough that you'll still do full rebuilds more often than the marketing suggests, and the platform abstraction leaks constantly — expect `#if ANDROID` blocks more often than you'd like. Documentation thins out fast past the happy path, and a lot of the real answers still live in old Xamarin.Forms Stack Overflow threads that may or may not still apply.
If Flutter's hot-reload reliability matters more to you than staying in C#, that's the actual decision here, not raw performance, which is comparable for most app types.
Our full take →GitHub ↗
★ 25,545TypeScriptMITupdated Jun 2026
best for teams who want real native API access without a bridge, in Angular, Vue, or plain TypeScript
NativeScript's trick is that there's no bridge at all — it generates TypeScript bindings straight from the iOS and Android SDKs, so you can call any native API from a .ts file with real autocomplete, something React Native still can't offer cleanly. If you want native access without writing a plugin first, this is the most direct route on the list.
The catch is everything downstream of that trick. The community is a fraction of React Native's size, so Stack Overflow answers are sparse and plenty of npm packages that assume a browser just don't work. The build toolchain — webpack 5 plus the NS CLI — has long been the framework's weak point: slow incremental builds, hot reload that's flaky next to Expo's, and layout bugs that require understanding two layout systems at once.
Supporting five UI frameworks — Angular, React, Vue, Svelte, Solid — sounds generous but means uneven maintenance: the Angular docs are thorough, while the Solid and Svelte ones read like afterthoughts.
Our full take →GitHub ↗
★ 52,510TypeScriptMITupdated Jun 2026
best for web teams who want to ship the same app as a PWA and a native wrapper
Ionic is the pick for a web team that wants one codebase shipped as both a PWA and an app-store app, not just a native app. Everything is a real web component under the Stencil hood, so bug fixes land once and propagate to the Angular, React, and Vue bindings automatically — a cleaner setup than most 'supports every framework' tools manage.
The weak point is that Ionic doesn't fully own its native layer — that's Capacitor's job, a separate project on its own release schedule. When Capacitor lags a new OS release, your app is blocked on their timeline, not yours. Performance on older Android hardware still shows the web-component tax as scroll jank that Flutter or MAUI's native widgets don't have.
The CSS custom-properties theming system is flexible but turns into hundreds of undocumented variables at scale, with no tooling to figure out which one touches which component.
Our full take →GitHub ↗
★ 19,123KotlinApache-2.0updated Jun 2026
best for Android teams already on Jetpack Compose extending to iOS without a rewrite
This is the right call specifically if your team is already on Jetpack Compose for Android and wants iOS without a rewrite — the API is close enough to Android Compose that you're adding `expect`/`actual` blocks for platform bits, not learning a new framework. Like Flutter, it draws its own UI through Skia rather than bridging to native widgets, so you get similar rendering control.
The honest asterisk is that iOS builds still require a Mac with Xcode, which breaks the 'one team, any OS' pitch Flutter actually delivers on — a Windows or Linux developer on your team cannot build the iOS target. Web support through Kotlin/Wasm is still Beta, and binary sizes are large enough that a hello-world app feels noticeably slower to load than an equivalent React app.
Most popular Android Compose libraries — navigation, image loading — only have multiplatform forks maintained by one or two people, lagging behind the Android originals they're forked from.
Our full take →GitHub ↗
★ 41,539Objective-CApache-2.0updated Jun 2026
best for Vue developers shipping to China's mini-program ecosystems alongside native apps
uni-app exists for one job none of the other seven frameworks do at all: shipping the same Vue codebase to WeChat, Alipay, Douyin, and the rest of China's mini-program ecosystems alongside a real iOS and Android app. If that's on your target list, there's no second-best option here — it's uni-app or nothing.
Outside that use case it's a harder sell. The toolchain assumes you're using DCloud's own HBuilderX IDE, and the CLI experience outside it is noticeably worse. Documentation is overwhelmingly Chinese, and the English docs lag well behind. Even the repo's listed language, Objective-C, is a hint about how the project is organized: the real framework is JS/TS, and the mismatch points to a monorepo of platform shells rather than one clean codebase.
If your targets are just iOS, Android, and the web, React Native or Flutter will give you a much bigger English-speaking community and better tooling outside the DCloud ecosystem.
Our full take →GitHub ↗
// questions people ask
Before you choose
Is Flutter or React Native the better default for a new app?
If your team already knows React, React Native (or Expo on top of it) gets you moving faster on day one. If you want one rendering engine, pixel-identical output on both platforms, and don't need to reuse existing JS code, Flutter is the stronger long-term bet.
Which of these gets closest to real native performance?
NativeScript and Compose Multiplatform skip the bridge entirely and call native APIs directly, which helps. Flutter's own renderer is fast but adds real binary size. React Native is still bottlenecked by JS-thread work for anything animation-heavy, which is why serious RN apps end up with at least one native module anyway.
Do I need Expo, or should I use React Native directly?
Start with Expo. It's React Native with signing, provisioning, and native module authoring already handled, and you only lose anything by ejecting to bare workflow if you hit a native dependency the Expo SDK doesn't cover yet.
What if I need to target WeChat or other Chinese mini-programs?
uni-app is the only framework on this list built for that at all — it's the one or none option. If your targets are just iOS, Android, and the web, skip it and use React Native or Flutter instead, both of which have far bigger English-speaking communities.
None of these are wrong choices for the right team, only for the wrong one. If you'd rather have repos like these flagged for your specific stack instead of ranked in a general list, that's what the weekly finds.dev email is for.