Three years ago we picked React Native as the default for most mobile projects. We still pick it in roughly the same percentage of cases. But the arguments on both sides of the table have grown. This is a short summary of where things stand today — including the project where we got the call wrong.
Around 60–70% of the mobile work we ship at EliteTech still runs on React Native.
What's changed against React Native in three years
Apple and Google's first-party tooling got better. SwiftUI and Jetpack Compose are noticeably better than they were in 2023 — and, more importantly, more stable than a year ago. Native development hurts less than it used to.
RN's tooling also got better. New Architecture (Fabric + TurboModules) is now the default and stable. Expo SDK 52 made app builds practically painless. The performance gap that was a real argument three years ago is now measurable only with microbenchmarks in 90% of apps.
The 'native is faster' argument is still true, but mostly irrelevant. The 'JS bundle is fat' argument too. The 'crash reporting is a bit worse' argument has gone away — Sentry for RN is essentially identical to native today.
What hasn't changed in favour of React Native
One codebase across iOS and Android. That was always the headline argument. For most B2B apps and 80% of B2C apps that don't need bleeding-edge UI innovation, it means half the team, half the release cycle, and unified business logic. This argument ages like good wine — it doesn't weaken, it strengthens, because senior salaries keep going up.
Hot reload during development. No native technology has caught up to this. The 'change → compile → install → open the screen you're testing' cycle is 5–15× slower in native than in RN. For a team iterating on UI thirty times a day, that's a measurable difference in output.
Code sharing with the web. If the client also has a web app, most of the business logic is the same. RN + Next.js + monorepo consistently comes out around 30% less code than a parallel native + web stack. This hasn't changed in six years.
Two exceptions where we now reach for native
First exception: apps where graphics performance is the product. Camera apps, AR, games, anything with heavy video editing or real-time computer vision. There framerate and access to native graphics APIs matter. RN can do 90% of what native does — but the 10% gap is exactly where the feel lives.
Second exception: apps where Apple or Google have shipped platform-specific features that haven't reached the RN ecosystem yet. Live Activities on iOS, App Intents for Siri, certain Wear OS APIs. Native modules exist that cover most of it — but if those features are core to the product, native development will be faster.
The project where we got it wrong
In 2024 we recommended React Native to a client for a B2C app that depended heavily on Apple Wallet integration and Apple Live Activities for real-time updates. We slipped by two months — we'd spent six weeks writing custom native modules the community hadn't yet maintained. The app shipped and is live, but if we were starting again, we'd go Swift + Kotlin and save the client two months and ourselves sixty hours of dull native-module pull requests.
What we wrote into our own rules afterwards: if an app has three or more platform-specific features in its core feature set that don't have stable, actively-maintained RN packages, we switch to native without debating it.
The default should be the one that fits 80% of cases. The discipline is, when the remaining 20% knocks, you don't pretend not to hear it.
React Native isn't hype that passed. It's a boring, mature technology we know well. That's why it still fits most clients we ship mobile work for. If you want a second opinion on whether your project belongs in RN or native, send us a message — discovery for a mobile app takes two weeks and usually ends in a one-page memo where the recommendation is clear.