Hybrid frameworks were supposed to be the shortcut. Write once, ship everywhere, save a ton of dev time. On Android in 2026, that shortcut is starting to cost real money.
Google Play cares about the feel now. Buttons working isn't enough anymore. Jank costs installs. And the apps making the most money on the platform are rewriting their most important screens straight in Kotlin because of it.
This shows up far outside the engineering Slack channel. Teams see it in App Store rankings, revenue reports, and the kind of teardown posts that get shared around dev Twitter when a big app ships a native rewrite of its checkout flow.
_____________________________________________________________________
Android Vitals used to be a dashboard nobody checked outside a bug triage meeting. Now it's tied directly to how discoverable an app is. Here's what Google's docs lay out as the lines you can't cross:
- ANR rate: 0.47% of daily users, max 8% on any single phone model.
- Crash rate: 1.09%.
- Frozen frames: any frame that takes longer than 700ms to render, per Firebase.
- Slow rendering: 16ms per frame, the ceiling for a smooth 60fps.
Blow past these, and the Play Store buries the app a little deeper in search. Some apps even get a warning label slapped right on their store listing.
The Rules Just Got Tighter
Google tightened these rules again in August 2026, and more thresholds kick in come February 2027. This is the exact math Play runs before deciding who shows up in “you might also like.”
React Native's Bridge Problem
React Native's whole selling point was one codebase for two platforms. Talking to native code means crossing a bridge, though, and that thing is slow.
Frame budgets blow past 16ms right there, and things start to feel janky. It's also a big part of why Kotlin keeps winning the go-to language debate for Android work these days.
Meta knows this. Its New Architecture ditched the old bridge for something called JSI, which lets JavaScript talk to native code directly. It genuinely helps. Yet a lot of apps in the wild are still running the old bridge, and they don't get any of that benefit.
Flutter's Rendering Tax
Flutter dodges the bridge problem completely, since it compiles straight to native ARM code. That's why it usually benchmarks closer to native.
But it's got its own tax. Flutter's rendering engine, Skia, or the newer Impeller, draws every single pixel itself instead of handing that job to the OS. A screen with a camera feed or a map runs into the same frozen-frame problem anyway.
Neither framework gets a free pass here. Both sit between the app and the screen in a way pure Kotlin just doesn't.
The Measurement Blind Spot That Hides Hybrid Jank
Here's the part that catches teams off guard. Firebase's performance tool, for Flutter apps specifically, only measures the native chunk of app startup. The time it takes to boot up the Flutter engine and widget tree? That part's invisible in the dashboard.
So a team can be staring at clean-looking Firebase numbers while the real app feels slow to real users.
Nobody notices until Play's field data catches it and search ranking slips. By then, it looks like some mystery ranking drop, when really it's just a metric that was never telling the whole story.
What the Adoption Numbers Say
Developer buzz and where the money lands can pull in different directions. Looking at both side by side makes that pretty clear.
- Flutter's crushing it on GitHub stars, about 178,000 versus React Native's 126,000 as of mid-2026.
- Both frameworks are stuck in the high single digits among pros, per Stack Overflow's survey, year after year.
- Global in-app purchase revenue hit $167 billion in 2025, up 10.6%, with 5.3 trillion hours spent in apps worldwide, according to Sensor Tower's State of Mobile 2026.
Teams keep reaching for hybrid anyway because it's cheap to prototype with, and that's a completely reasonable call for an MVP. The problem shows up later, once an app has real traffic and the Play algorithm starts scoring it.
Why Revenue Makes This Personal
At scale, a laggy checkout screen turns straight into lost revenue that shows up on a spreadsheet.
Airbnb is still the poster child here. The company walked away from React Native years ago and went full native once the app got big and complex enough that shared code stopped paying for itself.
Smaller teams are doing the same math now, since Play turns “jank” into a real number on a dashboard.
Is There a Middle Ground? Kotlin Multiplatform
Nobody's saying hybrid is dead. What's shifting is where teams draw the line.
Kotlin Multiplatform (KMP) shares the boring stuff between platforms, business logic, networking, that kind of thing, but keeps the UI itself fully native on each side. No bridge. No shared rendering engine burning through frame budget.
Teams new to native Android work can start with the basics of how to develop an Android application before layering KMP on top.
It's a real departure from what React Native or Flutter offer. Adoption is picking up steam fastest among teams that already got burned by a hybrid app they couldn't fully explain.
The Surgical Fix, Not a Full Rewrite
Going full KMP or full native isn't the only option on the table. The move most teams are making is way more surgical than “rewrite the whole app”:
- Find the exact screens causing ANR spikes or frozen-frame complaints in Play Console
- Rebuild just those in native Kotlin
- Leave everything else alone
Usually that's the checkout flow, onboarding, or a main content feed, whatever screen gets hit the hardest. A 700ms freeze there costs way more installs than the same freeze buried three menus deep.
Teams without that kind of native expertise in-house often turn to designrush.com/agency/mobile-app-design-development/us to compare agencies with real native chops against generalist shops that'll build in whatever framework is fastest to quote.
Finding the Right Team for the Job
Android Vitals turned performance into an ongoing cost teams have to keep watching well past kickoff. Figuring out whether a rewrite is worth it, or which screens deserve the Kotlin treatment first, takes developers who've shipped native Android at the level Play rewards now.
A team like that can look at an ANR spike in Play Console and tell you which screen, which interaction, and which fix closes it. A generalist shop building whatever framework is trendy that quarter usually can't.
Takeaway
Plenty of hybrid apps are still doing just fine. The ones winning on Play Store discoverability right now just know exactly which screens can't afford to feel slow, and they put their engineering budget exactly there.
