Why we build mobile apps with React Native and Expo in 2026

Where React Native stands in 2026

Software Mansion's State of React Native survey, run from December 2025 to January 2026 with 3,501 responses, puts the New Architecture at 80% adoption and finds that 88% of respondents think React Native is moving in the right direction. Expo is the framework the React Native team recommends, and the libraries that matter most are built and tested against its releases. For the apps we build, React Native with Expo is the default because it is the fastest way to a product that feels right on both platforms, and the safest way to keep it that way.

Native feel on both platforms, from one codebase

A React Native app renders the platform's own views and runs on the platform's own navigation stacks. That was always the pitch. What changed this year is how far it goes. Expo UI is now stable, so a form, a menu, a date picker or a bottom sheet written once in React becomes a SwiftUI component on iOS and a Jetpack Compose component on Android, with the inset grouped sections iOS users expect on one side and Material 3 on the other. Home screen widgets and Live Activities on iOS are covered too.

Under the surface, the new Hermes engine is now the default and the legacy architecture is out of iOS builds, and this year's Expo releases cut Android cold starts by roughly 40% and first render by 33% with no change to app code. The result is an app that behaves like an iOS app on iOS and an Android app on Android, from the same code, with platform differences handled where they belong and nowhere else.

Custom interfaces, by choice

Plenty of products should not look like the stock widgets. They have a brand and a motion language, and the interface is the product. On this stack that is a straightforward choice. Animations and transitions are written in a CSS style and run off the JavaScript thread, so a busy screen does not make them stutter, and on iOS they can already be handed to the platform's own animation layer so the system itself drives the frames. React Native gained a shared animation backend this year, built together with the maintainers of the main animation library, so the core and the library apply frames through one engine instead of two.

A designer's custom interface runs at native frame rates without a line of Swift or Kotlin. Native feel when you want it, your own feel when you want that, one codebase either way.

EAS is the biggest practical difference

The biggest practical difference between React Native a few years ago and React Native today is Expo Application Services. Builds for both platforms run in the cloud with signing credentials managed for you, so a release never depends on one laptop or one person. Submission to both stores runs from the same pipeline. Updates to the JavaScript and the assets reach installed apps over the air, without a store release, on channels that can roll out to a percentage of users first and roll back by republishing. EAS Workflows put builds, tests, submissions and updates in one YAML file, so the CI/CD for a mobile app is something you configure rather than something you build.

This year it got faster in ways that show up every sprint. Precompiled frameworks are now on by default for iOS, and Expo's June measurements put a clean iOS build about 65% faster than building everything from source once React Native, the Expo modules and the common third-party libraries all arrive prebuilt. Bytecode diffing is on by default for EAS Update, and in Expo's own measurement in May the diffed bundles it served were on average 58% smaller than the bundles they replaced. Smaller updates land faster, on worse connections, for more of your users.

A maintained library for almost everything

What makes the stack productive is what sits around it. The Expo SDK covers most of what a product needs from the device: camera, audio, location, notifications, secure storage and biometrics, files and a local database, media, sensors, haptics. It ships on a regular cadence, each release pinned to one React Native version, with every module tested against the same release, so an upgrade is a version bump rather than an excavation.

Beyond the SDK sit the community packages the survey ranks year after year: animation and gesture libraries, native navigation containers, fast lists for large data, and a long tail for payments, analytics, auth and everything else a product ends up needing. Expo UI's community layer now ships drop-in replacements for eight of the most used of these, so a third-party picker or bottom sheet can become a platform component with an import change. At the edges there are packages that run AI models on the device, and Expo Observe, in public beta since June, records real launch and render times per screen from production. Between the SDK and the community, we have not met a product requirement that could not be built.

Native modules when you need them

When something is genuinely missing, a vendor SDK, a piece of hardware, a platform feature nobody has wrapped yet, we write it in Swift or Kotlin with the Expo Modules API. The module can now live inline, right next to the app's own files, with the TypeScript interface generated from the Swift code, and the native projects stay generated from configuration, so nobody hand-edits an Xcode or Gradle project to add it. This year's releases also removed the Objective-C++ layer between Swift and the JavaScript runtime and replaced Android reflection with generated code, so calls into native are faster than they were a year ago. Native when needed, without giving up the workflow that makes everything else fast.

What it means for your product

For the products we build, this stack means a first version in both stores within the MVP timeline, a release process that runs every sprint without ceremony, and fixes that reach users at the speed of an update rather than a review cycle. It means the interface can be as native or as custom as the product needs. And it means the app stands on the same ecosystem the largest React Native apps run on, maintained by the people who make the framework and its core libraries, which is the strongest guarantee a small team can have that the code it ships today is still upgradeable in three years.