Skip to content
PRS India

Expo · EAS · New Architecture

React Native Development

One codebase, both stores, and a release you can fix the same afternoon. We build React Native on Expo with EAS Build and over-the-air updates. We tune it for the mid-range Android phone your users really own.

Last updated

  • Cold start under 1.8s
  • OTA fixes in minutes, not days
  • ~85% code shared iOS/Android
  • Offline-first by default
React Native Development
Why React Native

One team, both stores, and a fix that ships this afternoon.

The case for React Native was never that cross-platform code is neat. It is that one team of five can own both apps. They can share types and checks with the web product. And they can send a fix to every installed phone in minutes instead of waiting four days for app review. We build on Expo with EAS, on the New Architecture. We tune for a mid-range Android phone, not the newest iPhone, because that is what your users in Indore and Coimbatore really hold. Cold start under 1.8 seconds on that phone is our target, and we check it in CI.

Talk to a mobile engineer
1.8s
Cold start

On a mid-range Android phone with Hermes bytecode built ahead of time. Not on a top phone, and not on wifi.

85%
Code shared

Between iOS and Android. The other 15% is made to fit each platform, and it should be. That is what makes it feel native.

11min
OTA fix to devices

EAS Update, from merge to installed phones. A store review takes about four days.

60fps
Held under load

Reanimated and Gesture Handler run animations on the UI thread, so they stay smooth while JavaScript is busy.

How we actually build it

React Native in 2026 is not the React Native people argue about on the internet. The New Architecture is the default, Expo is no longer the toy option, and the "just eject when you need something real" advice is four years old and no longer true. Here is how we build.

Expo, and we do not eject

We start every React Native project on Expo with the managed workflow and config plugins. When we need a native module that Expo does not include, we write a config plugin or a local native module and keep the managed workflow. We do not eject to bare and take on two native build systems to look after by hand. In three years of building this way, the number of projects that really needed ejecting is zero.

Expo Router gives us file-based navigation with typed routes and deep links that work without a week of digging into Android intent filters. EAS Build makes signed binaries in CI without anyone owning a Mac. That matters more than it sounds when your only Mac is a laptop that belongs to someone on leave.

OTA updates change the shape of the release

EAS Update lets us send a JavaScript-only fix to every installed phone in minutes, skipping app store review. A bad text change, a broken form check, a wrong tax rate: fixed the same afternoon, not four days later after Apple looks at it. We use it a lot for fixes. We still put out a real store release every two weeks, because OTA is not a reason to let the native app go stale. Anything that touches a native module or a permission is a store release, no exceptions.

The New Architecture, in plain terms

Fabric and TurboModules removed the slow JSON bridge that used to sit between JavaScript and native code. In practice that gives you instant native calls, modules that load only when needed and a much faster start. We keep cold start under 1.8 seconds on a mid-range Android phone, which is the phone your Indian users really have. Hermes is the engine, with bytecode built ahead of time so there is no reading cost at launch. Animations and gestures go through Reanimated and Gesture Handler, which run on the UI thread and stay at 60 fps while JavaScript is busy.

What we insist on, regardless

Offline-first with a real local store and a plan for matching data, not an optimistic UI and a prayer, because Indian mobile networks are not smooth. Sentry with source maps and native crash symbolication, so a crash report is a stack trace and not a hex address. Detox or Maestro tests from start to finish on the key flows, running in CI on every pull request. And a release checklist that includes a real mid-range Android phone, in hand, not just an iPhone simulator on the engineer's desk.

The honest part

When React Native is the right call — and when it is not.

  Choose React Native Choose something else
You already have a React web product Yes. Types, validation schemas, API clients and a lot of business logic are shared. This is the strongest reason for it. Nothing beats it here. With Flutter you would keep the same logic twice, in two languages.
Heavy 3D, AR or real-time video No. You will spend the project writing native modules and lose every benefit you came for. Native Swift and Kotlin, or Unity for true 3D. Use the tool the platform is made for.
Offline-first field or driver app Yes, and we build this often. A real local database, a queue of changes and clash rules for each kind of data. Also fine in Flutter. What matters is that offline is part of the design, not a sprint-nine feature. The framework comes second.
Single platform, iOS only, premium feel Hard to defend. The saving from one codebase is the point, and you have just given it up. Native Swift and SwiftUI. Fewer layers, a better fit for the platform, and no bridge to worry about.
Team is Dart-first, no React anywhere No reason to force it. The benefit of its ecosystem is lost if nobody on the team works in it. Flutter. We build in it too. We would rather you launch with tools your team can fix at 2am.
You need to fix production fast Strong. EAS Update pushes a JavaScript fix to installed devices in minutes, with no store review. Flutter can do OTA with similar tools, but they are less proven. Native cannot do it at all.
What we build

React Native work we take on.

Field and driver apps

Offline-first, barcode and QR scanning, ePOD capture with signature and photo, GPS trails, and a sync that works even in a basement warehouse.

Consumer fintech apps

eKYC flows, UPI intent and collect, biometric unlock, certificate pinning, and security that passes an audit.

Commerce apps

Catalogue, cart, checkout, order tracking and push that really get people to buy, with a product list that scrolls at 60fps on cheap phones.

Companion apps for a web product

For when the app is the mobile half of a product you already run. Shared types, shared checks, one API, one team.

Rescue and modernisation

An old bare-workflow app on a dead React Native version, moved to Expo and the New Architecture without a full rewrite.

Store submission and release ops

EAS Build in CI, signing, App Store and Play Console submission, replies to reviewers, step-by-step rollout and crash fixing.

Characteristics

Performance, release velocity and cost.

  • Hermes, precompiled

    Bytecode is built ahead of time, so there is no JavaScript reading cost at launch. This is most of the cold-start gain.

  • Animations on the UI thread

    Reanimated and Gesture Handler keep gestures and screen changes at 60fps even while the JavaScript thread is busy with real work.

  • OTA in about eleven minutes

    EAS Update from merge to installed phones. A wrong tax rate is fixed before lunch, not after a four-day review.

  • Offline as the architecture

    A local SQLite or WatermelonDB store, a queue of changes, and a clear clash rule for each kind of data. Not an optimistic UI and a prayer.

  • Crashes you can actually read

    Sentry with source maps and native symbolication, so a crash report shows a stack trace with a line number, not a hex address.

  • One team instead of two

    The real saving is not lines of code. It is that five engineers own both platforms, not two separate teams drifting apart.

The stack

What ships with a React Native build from us.

React Native
Expo SDK
TypeScript
Hermes
Expo Router

Tell us which device your users actually hold.

If the answer is a ₹12,000 Android phone on a 4G connection that drops, that is the phone we will build and test against. Send us the brief and a senior mobile engineer will reply within one business day.

FAQ

The questions you were going to ask on the call.

If your team already writes TypeScript, or you have a React web app whose types, validation schemas and business logic can be shared, React Native wins on the total cost for your whole company, not just the app. If you have no React work and the app is heavy on animation and highly custom, Flutter is an excellent choice and we build in it too. Anyone who tells you one is always better is selling you the one they know.

Not on the apps we ship, and we test that on a mid-range Android phone, not an iPhone 16 Pro. The New Architecture removed the old bridge, Hermes builds the bytecode ahead of time, and animations run through Reanimated on the UI thread. You can tell at the extremes: heavy 3D, AR, live video processing, or an interface that must copy a platform look pixel for pixel. For those we would use native, and we would say so.

No. The advice to eject as soon as you need something serious is several years old and no longer true. Config plugins and local native modules cover the native features real apps need while keeping the managed workflow. That means EAS builds your app files in CI, nobody has to own a Mac, and you do not look after two native build systems by hand. We have not had a project that really needed ejecting.

EAS Update sends a new JavaScript bundle to installed phones in minutes without app store review. Yes, both Apple and Google allow it. The rule is that you cannot change the main purpose of the app. So a broken check, a wrong tax figure or bad text is fixed the same afternoon. Anything that touches a native module or a new permission still needs a store release. We put one out every two weeks anyway, so the app file does not go stale.

Then offline is part of the design, not a feature you add in sprint nine. We use a real local database, WatermelonDB or SQLite, as the truth for the screens the user needs when there is no signal. A queue of changes syncs when the network returns, and each kind of data has a clear rule for clashing edits. This is exactly what we build for logistics driver apps, where a phone will spend an hour in a basement warehouse and the day still has to add up at the end.

A focused app with authentication, a handful of core flows and an existing API behind it is typically 10 to 14 weeks from around ₹9,50,000. A full product — offline sync, payments, push, deep linking, an admin back end and store submission for both platforms — is 18 to 26 weeks and starts around ₹19,00,000. Store submission, replies to reviewers and the first release are included. We do not hand you an app file and wish you luck.

Let's talk react native development

Bring us the hard version of the problem.

A senior engineer reads every enquiry. You'll get a real answer — scope, risk and a number — within one business day.