Skip to content
PRSINDIA

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, tuned for the mid-range Android device your users actually own.

  • Cold start under 1.8s
  • OTA fixes in minutes, not days
  • ~85% code shared iOS/Android
  • Offline-first by default
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 elegant. It is that a single team of five can own both apps, share types and validation with the web product, and push a fix to every installed device in minutes instead of waiting four days for app review. We build on Expo with EAS, on the New Architecture, and we tune against a mid-range Android handset rather than the newest iPhone — because that is the device your users in Indore and Coimbatore are actually holding. Cold start under 1.8 seconds on that device is the bar, and it is the bar we hold in CI.

Talk to a mobile engineer
0s
Cold start

On a mid-range Android device with Hermes bytecode precompiled. Not on a flagship, and not on wifi.

0%
Code shared

Between iOS and Android. The remaining 15% is platform idiom, and it should be — that is what makes it feel native.

0min
OTA fix to devices

EAS Update, from merge to installed handsets. Against roughly four days for a store review cycle.

0fps
Held under load

Reanimated and Gesture Handler run animations on the UI thread, so they hold frame rate 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 out of date. 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 ship, we write a config plugin or a local native module and keep the managed workflow — we do not eject to bare and inherit two native build systems to maintain by hand. In three years of building this way, the number of projects that genuinely required ejecting is zero.

Expo Router gives us file-based navigation with typed routes and deep links that work without a week of Android intent-filter archaeology. EAS Build produces signed binaries in CI without anyone owning a Mac, which matters more than it sounds when your only Mac is a laptop belonging to someone on leave.

OTA updates change the shape of the release

EAS Update lets us ship a JavaScript-only fix to every installed device in minutes, bypassing app store review entirely. A bad copy change, a broken form validation, a wrong tax rate — fixed the same afternoon, not in four days after Apple looks at it. We use it aggressively for fixes, and we still ship a real store release on a fortnightly cadence, because OTA is not a licence to let the native binary rot. Anything touching a native module or a permission is a store release, no exceptions.

The New Architecture, in plain terms

Fabric and TurboModules removed the asynchronous JSON bridge that used to sit between JavaScript and native code. What that buys you in practice is synchronous native calls, lazy module loading and a startup that is meaningfully faster — we hold a cold start under 1.8 seconds on a mid-range Android device, which is the device your Indian users actually have. Hermes is the engine, with bytecode precompiled at build time so there is no parse 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 reconciliation strategy, not an optimistic UI and a prayer, because Indian mobile connectivity is not a nice curve. Sentry with source maps and native crash symbolication, so a crash report is a stack trace rather than a hex address. Detox or Maestro end-to-end tests on the critical flows, running in CI on every pull request. And a release checklist that includes an actual mid-range Android device, 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 good deal of business logic are shared. This is the strongest single argument for it. Nothing beats it on this axis. Flutter would mean maintaining 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 advantage you came for. Native Swift and Kotlin, or Unity for genuine 3D. Use the tool the platform intends for it.
Offline-first field or driver app Yes, and we build this often. A real local database, a queued mutation log and per-entity conflict rules. Also fine in Flutter. What matters is that offline is the architecture, not a sprint-nine feature — the framework is secondary.
Single platform, iOS only, premium feel Hard to justify. The cross-platform saving is the point, and you have just given it up. Native Swift and SwiftUI. Fewer layers, better platform idiom, and no bridge to reason about.
Team is Dart-first, no React anywhere No reason to force it. The ecosystem advantage evaporates if nobody on the team lives in it. Flutter. We build in it too, and we would rather you shipped in a stack your team can debug 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 via similar tooling, but the story is less mature. 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 breadcrumbs, and a sync that survives a basement warehouse.

Consumer fintech apps

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

Commerce apps

Catalogue, cart, checkout, order tracking and push that actually converts — with a product list that scrolls at 60fps on cheap hardware.

Companion apps for a web product

Where the app is the mobile half of a product you already run. Shared types, shared validation, one API, one team.

Rescue and modernisation

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

Store submission and release ops

EAS Build in CI, signing, App Store and Play Console submission, review responses, staged rollout and crash triage.

Characteristics

Performance, release velocity and cost.

  • Hermes, precompiled

    Bytecode is compiled at build time, so there is no JavaScript parse cost at launch. This is most of the cold-start improvement.

  • Animations on the UI thread

    Reanimated and Gesture Handler keep gestures and transitions at 60fps even while the JavaScript thread is doing real work.

  • OTA in about eleven minutes

    EAS Update from merge to installed devices. A wrong tax rate is fixed before lunch instead of after a four-day review.

  • Offline as the architecture

    A local SQLite or WatermelonDB store, a queued mutation log, and an explicit conflict policy per entity. Not an optimistic UI and a prayer.

  • Crashes you can actually read

    Sentry with source maps and native symbolication, so a crash report is 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 rather than two separate squads 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 device we will build and benchmark 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 of the organisation, not just the app. If you have no React investment and the app is animation-heavy and highly custom, Flutter is an excellent choice and we build in it too. Anyone who tells you one is universally better is selling you the one they know.

Not on the apps we ship, and we hold ourselves to that on a mid-range Android phone rather than an iPhone 16 Pro. The New Architecture removed the old bridge, Hermes precompiles the bytecode, and animations run through Reanimated on the UI thread. Where you can tell is at the extremes: heavy 3D, AR, real-time video processing, or an interface that is deliberately imitating a platform idiom 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 out of date. Config plugins and local native modules cover the native functionality real apps need while keeping the managed workflow, which means EAS builds your binaries in CI, nobody has to own a Mac, and you are not maintaining two native build systems by hand. We have not had a project that genuinely required ejecting.

EAS Update ships a new JavaScript bundle to installed devices in minutes without app store review, and yes, both Apple and Google permit it — the rule is that you cannot change the fundamental purpose of the app. So a broken validation rule, a wrong tax figure or bad copy is fixed the same afternoon. Anything touching a native module or a new permission still needs a store release, and we ship one on a fortnightly cadence anyway so the binary does not rot.

Then offline is the architecture, not a feature you add in sprint nine. We use a real local database — WatermelonDB or SQLite — as the source of truth for the screens the user needs when there is no signal, with a queued mutation log that syncs when connectivity returns and an explicit conflict resolution policy per entity. 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 reconcile 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, review responses and the first release are included; we do not hand you a binary and wish you luck.

Proof

Shipped, measured, still running.

All case studies

NM Company

A portfolio and enquiry site for events firm NM Company

A visual portfolio and enquiry website for an event management and supplies firm — presenting a full...

Read it

Swasthya Sarathi

A healthcare-companion platform for Swasthya Sarathi

A multi-service healthcare platform that helps people find hospitals, doctors, labs, medical stores,...

Read it

MV Tech Education

A course and admissions platform for MV Tech Education

A course-catalogue and admissions website for a Bihar vocational institute — leading with industrial...

Read it

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.