DEV Community: Mason Roy

The Complete Guide to Offline Storage in React Native

Mason Roy — Fri, 16 Oct 2026 08:19:26 +0000

Offline storage in React Native is the practice of persisting data on the device so your app keeps working when the network does not. The main options are AsyncStorage, MMKV, Expo SecureStore, SQLite, WatermelonDB, and Realm. Each solves a different problem: tiny preferences, hot key-value reads, secrets, structured relational data, or sync-ready local databases. Choosing well is less about picking the "fastest" library and more about matching the storage engine to your access pattern — then wrapping it in an offline-first architecture that survives flaky networks.

If you have ever watched a user curse at a loading spinner on the subway, you already understand why this matters. In 2026 users expect mobile apps to launch instantly, show real data, and accept writes whether or not the radio is connected. This guide walks through every serious offline storage option in React Native, the decision framework for picking one, and the architecture that turns a storage choice into a true offline-first experience.

Photo by Christopher Gower on Unsplash

Why Offline Storage Is Non-Negotiable in 2026

Three forces have pushed offline support from a nice-to-have to a baseline expectation.

Networks are still flaky. Subway tunnels, airplane cabins, elevators, rural areas, dense stadiums — users spend measurable chunks of time on degraded or absent connectivity. If your app stalls there, they churn.

Cold start is the new conversion funnel. Apps that hydrate from local storage show real content in under 300ms. Apps that fetch from the network first show skeletons for 1-3 seconds and lose attention. Instagram, Notion, and Linear all render from cache first, then reconcile.

App Store and Play Store reviewers notice. Both stores have rejected apps that show a blank screen when offline. A single <Text>No internet</Text> fallback is enough to pass, but if you are competing, the bar is higher.

Offline storage is the foundation that makes all three possible.

The Six Offline Storage Options in React Native

Before architecture, you need to know what each tool is actually good at. Here is the honest 2026 landscape.

1. AsyncStorage

The default. A simple asynchronous key-value store, backed by SQLite on iOS and SharedPreferences/SQLite on Android. Good for small, serializable values. The API is dead simple:

import AsyncStorage from '@react-native-async-storage/async-storage';

await AsyncStorage.setItem('user_prefs', JSON.stringify(prefs));
const raw = await AsyncStorage.getItem('user_prefs');

Use when: You have fewer than ~100 small values, each read on-demand (not in a tight render loop), and you do not need encryption. Fine for prototypes and small preference blobs.

Avoid when: You are serializing arrays of records, reading in render, or storing anything sensitive. The async overhead and JSON serialization costs add up fast.

2. MMKV (react-native-mmkv)

A key-value store built on Tencent's MMKV library, exposed through JSI (synchronous bridge). It is often 30-100x faster than AsyncStorage for small reads, with sub-millisecond operations because there is no serialization bridge hop. It also supports encryption out of the box.

import { MMKV } from 'react-native-mmkv';

const storage = new MMKV({ id: 'user', encryptionKey: 'hunter2' });

storage.set('onboarded', true);
const onboarded = storage.getBoolean('onboarded'); // synchronous

Use when: You need fast, frequent key-value reads — auth tokens, feature flags, user preferences, small JSON blobs. The synchronous API means you can read a token inside a selector without a Promise chain.

Avoid when: You need relational queries, large records, or complex schemas. MMKV is a hashmap, not a database.

3. Expo SecureStore

Thin wrapper over iOS Keychain and Android Keystore. Values are encrypted at the OS level and tied to device credentials. Capacity is limited (iOS allows ~2KB per item in practice), but security is strong.

Use when: You store secrets — OAuth refresh tokens, API keys, biometric-protected credentials. Anything that must survive an app reinstall on iOS (Keychain persists by default) or must be hardware-isolated.

Avoid when: You need to store more than a handful of small secrets. SecureStore is slow by design (it crosses the OS trust boundary) and not meant for bulk data.

4. SQLite (expo-sqlite / op-sqlite)

A full relational database on the device. expo-sqlite ships with Expo and now supports synchronous JSI access via openDatabaseSync. op-sqlite is a drop-in with even better performance and native encryption support (SQLCipher).

import * as SQLite from 'expo-sqlite';

const db = SQLite.openDatabaseSync('app.db');
db.execSync('CREATE TABLE IF NOT EXISTS notes (id TEXT PRIMARY KEY, body TEXT, updated_at INTEGER)');

const notes = db.getAllSync('SELECT * FROM notes WHERE updated_at > ?', [since]);

Use when: You have structured, queryable data — notes, messages, orders, products. Anything with relationships, filters, or indexes. SQLite scales to hundreds of thousands of rows on a modern phone.

Avoid when: You need reactive queries (your UI auto-updates when the DB changes) out of the box. Plain SQLite requires you to roll your own invalidation.

5. WatermelonDB

An opinionated, high-performance ORM on top of SQLite with reactive queries, lazy loading, and a batteries-included sync protocol. Designed for apps with tens of thousands of records.

Use when: You are building offline-first apps with large local datasets and bidirectional sync — think CRM, project management, or messaging. The reactive layer eliminates manual cache invalidation and the sync adapter handles pull/push cycles for you.

Avoid when: Your dataset is small, or you want full control over the SQL layer. WatermelonDB's abstractions have a learning curve.

6. Realm (Atlas Device SDK)

A mobile-first object database with its own storage engine (not SQLite-backed). Reactive queries, strong typing, and historically a slick sync product via MongoDB Atlas. MongoDB has deprioritized the hosted sync service, but the local Realm database is still a solid, stable choice.

Use when: You want reactive queries with an object-oriented API and are not depending on the hosted Atlas Device Sync going forward.

Avoid when: You want long-term vendor-managed sync — look at PowerSync or roll your own on top of SQLite.

Photo by Carlos Muza on Unsplash

Choosing the Right Storage: A Decision Framework

The honest answer is almost always "more than one." Real apps combine two or three storage engines because each solves a different job.

Need	Pick	Why
Auth tokens, secrets	Expo SecureStore	OS-level encryption, Keychain/Keystore
User preferences, feature flags	MMKV	Sub-ms sync reads, tiny footprint
Small, read-once JSON (migration flag)	AsyncStorage or MMKV	Either works; MMKV future-proofs
Structured records with queries	SQLite (expo-sqlite)	SQL, indexes, joins
Large offline-first dataset with sync	WatermelonDB	Reactive queries + sync adapter
Reactive object DB without sync	Realm	Clean API, zero-copy reads

A typical production stack looks like this: SecureStore for the refresh token, MMKV for session state and user preferences, and SQLite (or WatermelonDB on top of it) for domain data. That is three storage engines, and they do not fight — each owns a different concern.

Building a Real Offline-First Architecture

Picking a storage library gets you maybe 20% of the way. The other 80% is the architecture that makes writes survive airplane mode and reads survive cold starts. Four pieces matter.

1. Detect connectivity with NetInfo

@react-native-community/netinfo exposes real connectivity state (not just the radio status — it does a reachability check). Subscribe once and expose a isConnected flag through context or a store.

import NetInfo from '@react-native-community/netinfo';

NetInfo.addEventListener((state) => {
  store.dispatch(setConnected(state.isInternetReachable));
});

Do not trust state.isConnected alone — on Wi-Fi captive portals the radio is "connected" but the internet is not reachable. Use isInternetReachable.

2. Hydrate the UI from local storage first

On app start, read from local storage synchronously (MMKV) or with a tiny Promise (SQLite JSI) and render immediately. Then fire a background refresh. Your users should never see a blank screen because of a network request.

const cached = storage.getString('home_feed');
if (cached) hydrateFeed(JSON.parse(cached));
void refreshFeedInBackground();

3. Queue writes while offline

When a user creates, edits, or deletes something offline, store two things: the authoritative local row (so the UI reflects the change immediately) and a mutation entry in a sync queue. The queue is a plain SQLite table with columns like id, type, payload, created_at, attempts, last_error.

CREATE TABLE mutation_queue (
  id TEXT PRIMARY KEY,
  type TEXT NOT NULL,
  payload TEXT NOT NULL,
  created_at INTEGER NOT NULL,
  attempts INTEGER DEFAULT 0,
  last_error TEXT
);

When connectivity returns (via the NetInfo listener), drain the queue in order. Mark each mutation idempotent — include a client-generated UUID so the server can deduplicate retries. Without idempotency keys, a flaky connection creates duplicates every time a request succeeds server-side but the response never reaches the client.

4. Resolve conflicts explicitly

Two devices edit the same note offline. Both come back online. You now have a conflict. Three strategies, in order of complexity:

Last-write-wins (LWW): Compare timestamps, newer wins. Simple, lossy. Fine for user preferences and non-collaborative data.
Server-authoritative merge: Server applies both mutations in order and returns the canonical state. You replace local state on sync. Good for simple domains like a shopping cart.
CRDTs or operational transforms: Required for collaborative editing (think Notion, Linear). Libraries like Yjs or Automerge handle this; they are heavy but produce correct merges without a central authority.

Pick the simplest one that matches your product. 90% of apps are fine with LWW plus a visible "last synced at" timestamp.

A Minimal Offline-First Setup, in Code

Here is a realistic skeleton combining MMKV, expo-sqlite, and a NetInfo-driven sync queue. It is intentionally small so the pattern is visible.

// storage.ts
import { MMKV } from 'react-native-mmkv';
import * as SQLite from 'expo-sqlite';

export const kv = new MMKV({ id: 'app' });
export const db = SQLite.openDatabaseSync('app.db');

db.execSync(`
  CREATE TABLE IF NOT EXISTS notes (
    id TEXT PRIMARY KEY,
    body TEXT,
    updated_at INTEGER
  );
  CREATE TABLE IF NOT EXISTS mutation_queue (
    id TEXT PRIMARY KEY,
    type TEXT,
    payload TEXT,
    created_at INTEGER,
    attempts INTEGER DEFAULT 0
  );
`);

// notes.ts
import { db } from './storage';
import { randomUUID } from 'expo-crypto';

export function createNoteOffline(body: string) {
  const id = randomUUID();
  const now = Date.now();

  db.runSync('INSERT INTO notes (id, body, updated_at) VALUES (?, ?, ?)', [id, body, now]);
  db.runSync(
    'INSERT INTO mutation_queue (id, type, payload, created_at) VALUES (?, ?, ?, ?)',
    [randomUUID(), 'create_note', JSON.stringify({ id, body }), now]
  );

  return id;
}

// sync.ts
import NetInfo from '@react-native-community/netinfo';
import { db } from './storage';

NetInfo.addEventListener(async (state) => {
  if (!state.isInternetReachable) return;

  const pending = db.getAllSync('SELECT * FROM mutation_queue ORDER BY created_at ASC');
  for (const m of pending) {
    try {
      await fetch(`/api/${m.type}`, {
        method: 'POST',
        headers: { 'Idempotency-Key': m.id },
        body: m.payload,
      });
      db.runSync('DELETE FROM mutation_queue WHERE id = ?', [m.id]);
    } catch (err) {
      db.runSync('UPDATE mutation_queue SET attempts = attempts + 1 WHERE id = ?', [m.id]);
      break; // stop on first failure, retry on next connectivity change
    }
  }
});

That is the entire core. Everything else — exponential backoff, mutation chunking, optimistic UI — is a refinement on top.

Common Pitfalls (and How to Dodge Them)

Serializing giant arrays into AsyncStorage. The classic performance trap. One developer stored their entire chat history as a single JSON string in AsyncStorage; the app froze for 2 seconds on launch. Move to SQLite the moment you have more than a few hundred records.

Storing secrets in MMKV without encryption. MMKV supports encryption but does not enable it by default. If you store refresh tokens, pass an encryptionKey — and store that key in SecureStore, not MMKV itself.

Trusting isConnected instead of isInternetReachable. Mentioned above but it bites so often it is worth repeating. Captive portals, misconfigured VPNs, and corporate networks all report "connected" while being unreachable.

No idempotency keys on retried mutations. Without them, a user who creates a post on a flaky network can end up with three identical posts. Generate the UUID on the client, send it on every retry, deduplicate on the server.

Blocking the JS thread with sync SQLite. JSI SQLite is synchronous, which is a feature — but a getAllSync over 50,000 rows will still block for hundreds of milliseconds. Use indexes, paginate, or drop to an async worker for heavy queries.

Photo by Markus Spiske on Unsplash

Performance: What the Numbers Actually Look Like

Benchmarks on a mid-range Android (Pixel 6a) in 2026, for storing a 1KB JSON blob:

Operation	AsyncStorage	MMKV	expo-sqlite (JSI)
Single write	8-15 ms	<1 ms	1-2 ms
Single read	6-12 ms	<1 ms	1-2 ms
1000 sequential writes	4-6 s	60 ms	300 ms (in tx)
Read + parse large JSON (1 MB)	180-250 ms	90 ms	40 ms (indexed)

The pattern is consistent: MMKV wins on key-value speed, SQLite wins on structured bulk operations, AsyncStorage is the slowest at everything. If a user-visible interaction depends on a storage read, you want sub-millisecond latency — that rules out AsyncStorage for anything on a hot path.

How RapidNative Generates Offline-Ready React Native Code

When you describe an app to RapidNative in plain English, you get a working Expo project with real screens, real state, and — importantly — a sensible storage layer out of the box. The generator picks Expo SecureStore for tokens, MMKV for session preferences, and SQLite (via expo-sqlite) for the domain data your prompt described. You can see it in action by sketching an app or starting from a PRD.

What that means in practice: the generated project already has the storage engines wired, the schema modeled, and the hydration-on-mount pattern applied — the architecture described above, scaffolded automatically. You can export the code at any time and keep extending it (sync queues, encryption, custom conflict resolution) with any React Native patterns you prefer. For more on how the generated apps are structured, see our deep dives on state management in AI-generated React Native apps and database schema generation.

FAQ

Is AsyncStorage deprecated?

No. AsyncStorage is actively maintained by the React Native community and remains the default for simple preferences. It is just slow enough that most apps outgrow it. For new projects, start with MMKV and reach for AsyncStorage only when a dependency requires it.

Can I use multiple storage libraries in the same app?

Yes, and most production apps do. SecureStore for secrets, MMKV for preferences, and SQLite or WatermelonDB for domain data is the standard combination. They do not conflict — each owns a different concern.

How do I migrate from AsyncStorage to MMKV?

On first launch after the upgrade, read every AsyncStorage key, write it to MMKV, verify, then clear AsyncStorage. Gate the migration behind a flag stored in MMKV so it runs exactly once. Keep AsyncStorage as a dependency until you are confident the migration has reached your entire user base — usually one or two release cycles.

What is the best offline database for React Native in 2026?

For most apps, expo-sqlite with its JSI synchronous API is the best balance of performance, portability, and ecosystem support. If you need reactive queries and sync out of the box, WatermelonDB is excellent. Pick based on whether your data has strong relational structure and whether sync is a first-class concern.

Do I need an offline-first architecture if my app is always online?

Even "always online" apps face dropped requests, flaky Wi-Fi, and backgrounded sessions. At a minimum, cache the last response for every screen so cold start is instant. The full sync queue is overkill for a dashboard but mandatory for anything that accepts user writes.

Conclusion

Offline storage in React Native is a solved problem — you just have to pick the right tool for each job. MMKV for hot key-value reads, SQLite for structured data, SecureStore for secrets, and a sync queue to make writes resilient. Wrap it in a NetInfo-driven architecture that hydrates from cache first and reconciles with the server in the background, and your app will feel instant whether the network is there or not.

The hard part has never been the storage API. It is the discipline to design around flakiness from day one — because retrofitting offline support into an app that assumed always-online is one of the ugliest refactors in mobile development.

If you would rather skip the plumbing and get a Expo project with the storage layer already wired up, try RapidNative free — describe your app in plain words and get real, exportable React Native code in minutes.

6 Expo Router Gotchas I Hit Moving From React Navigation

Mason Roy — Thu, 15 Oct 2026 09:37:26 +0000

TL;DR

_layout.tsx wraps everything in its folder — put providers in the root one, not in screens.
(group) folders organize routes without changing the URL.
Dynamic params come in as strings, always. Parse them.
Do auth redirects in a layout, not inside every screen.
+not-found.tsx saves you from blank screens on bad deep links.
Turn on typed routes and let TypeScript catch broken links.

I moved a mid-sized app from React Navigation to Expo Router last month. File-based routing is genuinely nicer, but the mental model is different, and these six things cost me the most time.

1. Layouts are not screens

Every folder can have a _layout.tsx, and it wraps every route inside that folder.

app/
  _layout.tsx        ← root: providers, fonts, theme
  index.tsx
  settings/
    _layout.tsx      ← Stack for settings only
    index.tsx
    profile.tsx

// app/_layout.tsx
import { Stack } from 'expo-router';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';

const queryClient = new QueryClient();

export default function RootLayout() {
  return (
    <QueryClientProvider client={queryClient}>
      <Stack screenOptions={{ headerShown: false }} />
    </QueryClientProvider>
  );
}

My mistake: I put a provider inside a screen, and it remounted on every navigation. Providers go in layouts.

2. Groups don't show up in the URL

Need tabs for logged-in users and a separate auth flow? Use parentheses:

app/
  (auth)/
    _layout.tsx
    login.tsx        → /login
  (tabs)/
    _layout.tsx
    index.tsx        → /
    feed.tsx         → /feed

(auth) and (tabs) exist only for organization and layouts — they're invisible in routes. Watch out for two groups both defining index.tsx at the same level; that's an ambiguous route.

3. Params are always strings

// app/post/[id].tsx
import { useLocalSearchParams } from 'expo-router';

export default function Post() {
  const { id } = useLocalSearchParams<{ id: string }>();
  const postId = Number(id); // "42" → 42

  if (Number.isNaN(postId)) return <NotFound />;
  // ...
}

Even if you navigate with router.push({ pathname: '/post/[id]', params: { id: 42 } }), you get "42" back. I lost an hour to a === comparison against a number.

4. Guard routes in the layout

Don't sprinkle auth checks across screens. Redirect once, at the group level:

// app/(tabs)/_layout.tsx
import { Redirect, Tabs } from 'expo-router';
import { useSession } from '@/hooks/useSession';

export default function TabsLayout() {
  const { session, isLoading } = useSession();

  if (isLoading) return null; // or a splash
  if (!session) return <Redirect href="/login" />;

  return <Tabs />;
}

Every screen in (tabs) is now protected, including when someone deep-links straight to /feed.

5. Add a not-found route

Deep links from old emails or push notifications will point at routes that no longer exist.

// app/+not-found.tsx
import { Link, Stack } from 'expo-router';
import { Text, View } from 'react-native';

export default function NotFound() {
  return (
    <View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
      <Stack.Screen options={{ title: 'Oops' }} />
      <Text>This screen doesn't exist.</Text>
      <Link href="/">Go home</Link>
    </View>
  );
}

6. Turn on typed routes

{
  "expo": {
    "experiments": {
      "typedRoutes": true
    }
  }
}

Now <Link href="/sttings" /> is a TypeScript error instead of a runtime 404. This alone caught three broken links during my migration.

The folder structure I ended up with

app/
  _layout.tsx
  +not-found.tsx
  (auth)/
    _layout.tsx
    login.tsx
    signup.tsx
  (tabs)/
    _layout.tsx
    index.tsx
    feed.tsx
    settings.tsx
  post/
    [id].tsx

If you'd rather not wire this up by hand, RapidNative generates Expo apps with this layout, auth groups and typed routes already in place — it's how I prototype new screens now.

Wrap-up

Expo Router clicks once you treat folders as navigation structure and layouts as the place where logic lives. Most of my bugs came from thinking in React Navigation terms.

What tripped you up when you switched to file-based routing? Drop a comment — especially if you've found a cleaner auth pattern.

Your Expo OTA Update Shipped. Half Your Users Never Got It. Here's Why.

Mason Roy — Wed, 14 Oct 2026 10:50:04 +0000

TL;DR

An OTA update only reaches builds whose runtimeVersion exactly matches the update's.
Hardcoding runtimeVersion: "1.0.0" and forgetting to bump it after a native change will crash users. Use the fingerprint policy.
By default, updates download on launch but apply on the next cold start. Many "it didn't work" bugs are really "the app wasn't restarted."
Always ship to a preview channel first, then promote the same update to production.

I pushed a hotfix with eas update, watched the dashboard say "Published," and went to lunch. Two hours later the bug reports were still coming in. Not a crash, just the old behavior, as if the update never existed.

For a chunk of users it didn't. Here's what I learned.

How EAS Update decides who gets what

Every update is tagged with three things:

Channel: which builds listen (e.g. production)
Platform: ios / android
Runtime version: the native "shape" the JS bundle expects

A build fetches an update only if all three match. The runtime version is the one that bites, because JS that calls a native module the binary doesn't have causes a crash on launch.

Mistake #1: A hardcoded runtime version

This is in a lot of tutorials:

{
  "expo": {
    "runtimeVersion": "1.0.0"
  }
}

It works until you add a native library like expo-camera, ship a new binary, and forget to bump the string. Now your new JS (which imports the camera) gets served to old binaries (which don't have it). The result is a red screen.

The fix is to let Expo hash your native layer for you:

{
  "expo": {
    "runtimeVersion": {
      "policy": "fingerprint"
    }
  }
}

With fingerprint, any native change produces a new runtime version automatically. Old binaries keep receiving only compatible JS updates.

Check what a build will report before you publish:

npx expo-updates fingerprint:generate --platform ios

Mistake #2: Expecting the update to apply instantly

The default is checkAutomatically: "ON_LOAD". The app downloads the update in the background and runs it on the next launch. Users who background the app instead of killing it can sit on the old bundle for days.

For critical fixes, check and reload yourself:

import * as Updates from 'expo-updates';
import { useEffect } from 'react';

export function useCriticalUpdate() {
  useEffect(() => {
    if (__DEV__) return; // updates are disabled in dev

    (async () => {
      try {
        const result = await Updates.checkForUpdateAsync();
        if (result.isAvailable) {
          await Updates.fetchUpdateAsync();
          await Updates.reloadAsync(); // applies immediately
        }
      } catch (e) {
        // Network failures are normal; don't block the app
        console.warn('Update check failed', e);
      }
    })();
  }, []);
}

Don't reload without warning on every update; users lose whatever screen they were on. A good pattern: reload immediately only when update metadata flags it as critical, otherwise show a "Restart to update" banner.

You can also react to the built-in state hook:

const { isUpdatePending } = Updates.useUpdates();
// show a banner when isUpdatePending === true

Mistake #3: Publishing straight to production

eas update --branch production from your laptop is the mobile version of git push --force to main. Do this instead:

# 1. Ship to preview builds used by your team
eas update --branch preview --message "Fix checkout total rounding"

# 2. Test on a real preview build. Then promote the *same* update:
eas update:republish --branch preview --destination-branch production

Republishing promotes the exact bundle you tested instead of rebuilding it, so there are no "works on preview" surprises.

And if production still breaks:

eas update:rollback

Debugging checklist when users "don't get" an update

console.log({
  channel: Updates.channel,
  runtimeVersion: Updates.runtimeVersion,
  updateId: Updates.updateId, // null = running the embedded bundle
  isEmbeddedLaunch: Updates.isEmbeddedLaunch,
});

updateId is null → the app never fetched anything. Check the channel name.
Runtime version differs from the dashboard → the update is incompatible with this binary, which is working as intended. Ship a new build.
IDs match but behavior is old → you're probably looking at a cached screen or state, not a stale bundle.

Put this behind a hidden debug screen. You'll be glad you did when support tickets come in.

Don't hand-wire all of this every project

The update hook, the channel setup, and the fingerprint config are the same boilerplate in every Expo app I start. These days I generate the base app with RapidNative, which outputs a standard Expo + React Native codebase I can drop this config into. That leaves time for the parts that are actually specific to the app.

Your turn: what's the worst OTA update incident you've shipped? Drop it in the comments. I'll trade you my "pushed to production on a Friday" story.

React Native New Architecture in 2026: What Developers Need to Know

Mason Roy — Mon, 12 Oct 2026 10:11:38 +0000

For eight years, every React Native app in the world shipped the same compromise: a JavaScript bridge that serialized every call between your JS code and the native platform as JSON, then shipped it across an async boundary. It worked. It also quietly capped the performance ceiling of the entire framework.

In October 2025, Meta shipped React Native 0.82 and removed the ability to turn the bridge back on. The React Native New Architecture — in development since 2018 — is no longer a migration path. It's the only architecture. If you ship a React Native app in 2026, you're shipping on Fabric, TurboModules, JSI, and bridgeless mode, whether you planned to or not.

This guide explains what actually changed, what breaks in practice, and what the New Architecture means for anyone building mobile apps in 2026 — including the AI tools now generating most of the new React Native code in the wild.

Image suggestion: a modern React Native dev setup — editor + physical device running the app.

What the New Architecture actually is

The React Native New Architecture is the collective name for four related changes that replace the legacy bridge-based runtime:

JSI (JavaScript Interface) — a C++ API that lets JavaScript hold direct references to native objects and call them synchronously. No more JSON serialization.
Fabric — the new renderer. React's fiber tree is reconciled directly against native view hierarchies via JSI, with a shared C++ core instead of two parallel implementations.
TurboModules — the new native module system. Modules are lazy-loaded and expose typed, JSI-backed methods generated from a single TypeScript or Flow spec via Codegen.
Bridgeless mode — the runtime mode where the legacy async bridge is never instantiated at all. Startup is faster, memory is lower, and a whole class of lifecycle bugs disappears.

In short: the New Architecture deletes the slowest piece of React Native and replaces it with something that behaves much more like a native app that happens to be scripted in JavaScript.

The 40-60 word answer, for the Google snippet readers

The React Native New Architecture is a complete overhaul of how JavaScript talks to native code on iOS and Android. It replaces the asynchronous JSON bridge with JSI for direct, synchronous calls, Fabric for rendering, and TurboModules for native modules — enabled by default from React Native 0.76 and mandatory from 0.82.

Why the legacy bridge had to die

To understand why Meta spent seven years rewriting the core, you have to understand what the legacy architecture actually did on every single frame.

Imagine a FlatList scrolling at 60 fps. In the old world:

The scroll gesture fires on the native UI thread.
The event gets serialized to JSON.
The JSON crosses the bridge to the JavaScript thread, asynchronously.
JS runs, computes new state, and sends view updates back as JSON.
The native thread deserializes and applies them.

Every step was async. Every step allocated. Every step did string work. A list that was trivial in Swift or Kotlin became a performance puzzle in React Native — hence the entire cottage industry of libraries like FlashList, Reanimated, and Gesture Handler, each of which exists in part because the bridge made the obvious implementation too slow.

JSI killed the serialization. A JS function can now hold a C++ HostObject reference and call native methods synchronously, on the same thread, with the same cost as any other C++ call. That one change is the foundation under everything else in the New Architecture.

Fabric: what changes in rendering

Fabric is the New Architecture's renderer, and it's the piece most developers will feel directly, even if they never touch native code.

Four things that are new in Fabric:

Synchronous layout. onLayout and measure calls used to be async because they had to cross the bridge. Under Fabric, layout happens on the UI thread via JSI, and measurement is synchronous. A huge amount of brittle setTimeout-based layout code can simply go away.

Shared C++ core. The old renderer had two separate implementations — one for iOS (Objective-C++), one for Android (Java). Fabric moves the shadow tree, prop diffing, and view-update logic into a single C++ library consumed by both platforms. One source of truth, two platform-specific binding layers.

Concurrent rendering support. Fabric is the first React Native renderer that genuinely supports React 18 concurrent features — Suspense, transitions, useDeferredValue — because the renderer no longer assumes a single JS→native commit per frame.

Static view configs. View props are declared ahead of time via Codegen rather than discovered at runtime, which means the native side knows the full prop surface of every component before the first render. Faster startup, fewer runtime surprises.

The practical consequence: animations and gestures that were previously only feasible with native-threaded libraries like Reanimated are now feasible in plain React. Reanimated still wins for truly complex cases, but the baseline moved up.

Image suggestion: diagram showing legacy bridge (async JSON) vs. JSI (synchronous C++ calls).

TurboModules and Codegen: the end of the native module soap opera

If you've been in the React Native ecosystem long enough, you've written a native module. You've also probably written a Podfile fix, an android/settings.gradle tweak, and a jest.setup.js mock to make it work in all four environments.

TurboModules clean this up significantly. The flow in 2026 is:

Author a TypeScript spec (NativeMyModule.ts) with the module's interface.
Codegen reads the spec at build time and generates:
- Platform-specific interface headers (ObjC++ protocol, Java interface + Kotlin shims)
- A JSI binding layer
- A JavaScript wrapper with real types
The module is lazy-loaded on first access — it isn't initialized at app launch unless you touch it.

The three practical wins:

Lazy loading cuts cold start time, especially on apps with many native modules installed but used rarely (think: a payments SDK that's only touched on the checkout screen).
Type safety across the JS/native boundary stops a long-standing class of bugs where a native method signature drifted from its JS wrapper and nobody noticed until runtime.
No more manual linking. Expo-style autolinking is now the default assumption. Most libraries no longer ship linking instructions because there's nothing to link manually.

TurboModules sit next to another new concept, Fabric Native Components, which are the equivalent for native UI primitives (think UIView subclasses or custom Android ViewGroups). Together they cover the full "I need to call something written in Swift / Kotlin / C++" surface of React Native.

Bridgeless: the mode that doesn't instantiate the bridge

Here's where the semantics get fuzzy for people new to this. "New Architecture" and "bridgeless" are often used interchangeably, but they're not the same thing.

For a while, apps could run on the New Architecture while still booting the legacy bridge for backwards compatibility — Fabric for rendering, TurboModules for new modules, but the old RCTBridge was still created to host anything that hadn't been migrated.

Bridgeless mode removes even that. The entire bridge class never gets instantiated. The runtime boots directly into a JSI-only world. On Android, that means no CatalystInstance. On iOS, no RCTBridge. The surface area for lifecycle bugs collapses, and startup gets measurably faster.

Bridgeless shipped as default in React Native 0.74 (experimental), stabilized in 0.76, and from 0.82 is the only option. If you have legacy anything in your Podfile or AndroidManifest.xml in 2026, it's dead code.

What's locked in from 0.76 → 0.82 → beyond

The timeline matters because the ecosystem's assumptions keep shifting:

Version	Date	New Arch status
0.68	Mar 2022	New Architecture first available, opt-in
0.74	Apr 2024	Bridgeless shipped (experimental)
0.75	Aug 2024	Codegen improvements, library migration wave
0.76	Oct 2024	New Architecture enabled by default; `newArchEnabled` flag introduced for opt-out
0.78	Mar 2025	React 19 support
0.81	Aug 2025	Final version supporting legacy architecture
0.82	Oct 2025	Legacy architecture removed; `newArchEnabled=false` no longer honored
0.83+	2026	Deeper C++ core work, future-proofing for React Native in server-driven UI contexts

Expo tracked this closely: Expo SDK 52 enabled New Arch by default, SDK 53 made every expo-* package New Arch-compatible, and SDK 55 (which bundles React Native 0.83) removed the newArchEnabled field from app.json entirely.

The ecosystem story mirrors this. React Native Directory's compatibility list crossed 95% New Arch-ready in mid-2025. The long-tail holdouts in 2026 are mostly abandoned community modules — not actively maintained libraries.

What migrating actually feels like (the honest version)

Most of the "migration guides" published in 2024 vastly overstated how hard this is. In 2026, for a typical app, the migration is:

Bump to React Native 0.82 (or Expo SDK 55).
Run the Expo doctor / React Native upgrade helper.
Fix anywhere between 0 and 4 library incompatibilities.
Ship.

That's it. The hard migration work was done by Meta, by Expo, and by library maintainers — not by app teams.

Where it genuinely gets painful is a narrow set of cases:

Custom native modules written against the old API. If your team wrote RCT_EXPORT_METHOD-style modules in 2020 and never touched them, you'll need to port them to the TurboModule spec. The ported code is cleaner, but the port isn't automatic.

Direct references to UIManager. Legacy code that reached directly into the view manager (UIManager.measure, UIManager.dispatchViewManagerCommand) is one of the most common breakage points. Fabric exposes most of this via refs and imperative handles instead.

Libraries with native UI primitives that haven't been ported to Fabric Native Components. Common offenders: anything built on top of legacy UIViewController-container patterns, some charting libraries, and a handful of older map and video SDKs.

Third-party SDKs that ship their own React Native shims. Analytics SDKs, in particular, often shipped RN wrappers that assumed the bridge existed. Most have been updated; a few still haven't. See the official New Architecture status page for the up-to-date compatibility picture.

The rule of thumb from teams that migrated large apps in 2025: budget two weeks for a mature app and one afternoon for anything built in the last 18 months.

What the New Architecture means for performance (realistically)

A fair question for anyone evaluating React Native in 2026: does bridgeless mode actually make my app faster? Based on reports from teams that migrated and published numbers:

Startup time: 10–30% improvement on cold start is typical. Apps with many lazy-loadable TurboModules see more.
Scrolling and gestures: measurable improvements, especially on lower-end Android devices where the bridge was the bottleneck.
Memory: lower baseline, because the two parallel renderer implementations are gone.
Jank: fewer "frame drops under load" scenarios because layout no longer waits for the JS thread to respond across an async boundary.

What the New Architecture does not do: make a badly architected app fast. If your bottleneck is rendering 10,000 items in a ScrollView, Fabric helps but doesn't fix it. The usual advice — virtualized lists, memoization, native-driven animations — still applies.

Image suggestion: side-by-side iOS + Android devices running a React Native app — represents the shared C++ core now powering both.

What this means for AI code generation

Here's the angle most of the coverage of the New Architecture has missed in 2026: the dominant React Native code generator in 2026 isn't a human — it's an AI model.

Tools like RapidNative now generate full React Native + Expo apps from natural-language prompts, and the New Architecture quietly made that process significantly cleaner. Three reasons:

TypeScript specs for native modules are now the source of truth. An AI generating code against a TurboModule spec is generating against a typed interface, not reading tribal knowledge from a six-year-old native module README. The spec files are small, structured, and ideal context for a language model.

Synchronous layout removes an entire class of hallucinated code. AI models historically generated a lot of setTimeout(() => measure(ref), 0) patterns because that's what the training data looked like. Under Fabric, that code is both wrong and unnecessary — layout is just synchronous. Modern generation targeting RN 0.82+ emits cleaner idioms.

Fabric's static view configs are discoverable. Codegen produces machine-readable prop definitions for every component. An AI generator with access to those specs knows exactly which props a given component accepts, with their types, without guessing from docs.

If you're building apps with an AI mobile app builder in 2026, the New Architecture is one of the reasons the generated code is better than the equivalent generation would have been two years ago. The platform underneath is simpler, more typed, and more predictable — all qualities LLMs reward.

What developers should actually do in 2026

A short, honest checklist:

If you're starting a new app: don't think about this. Use the current Expo SDK or create-react-native-app. You're on the New Architecture by default.
If you're on 0.74 or 0.75 and shipping: upgrade when you can. There's no rush, but every month of drift makes the eventual bump larger.
If you're on 0.70 or older: this is now a real project. Budget time for library audits.
If you maintain a React Native library: if it isn't New Arch-ready yet in 2026, it's going to lose adoption fast. The ecosystem has moved on.
If you're deciding between React Native and native in 2026: the main historical performance argument against React Native is substantially weaker now. Evaluate on team skills and library ecosystem, not on "the bridge is slow" — because the bridge is gone.

The broader point: React Native in 2026 is a materially different framework than React Native in 2022. The runtime underneath has been rebuilt. The developer-facing surface looks the same, but the ceiling has moved up, and the cost of writing fast cross-platform mobile apps keeps dropping.

FAQ

Is the React Native New Architecture backwards-compatible?

Partially. Your JavaScript code is almost always compatible. Your native modules may need porting if they used the legacy RCT_EXPORT_METHOD or Android ReactMethod APIs directly. Starting from React Native 0.82, there is no backwards-compatible fallback — the legacy architecture is removed.

Do I need to rewrite my app to use Fabric?

No. For almost all apps, the migration is a version bump plus library updates. Your component code, state management, and business logic don't change. Only direct interactions with legacy native APIs (UIManager, custom bridge modules, old gesture handlers) need touching.

Is bridgeless mode the same as the New Architecture?

They overlap but aren't identical. The New Architecture is the full set of changes — JSI, Fabric, TurboModules, Codegen. Bridgeless mode specifically refers to the runtime mode in which the legacy RCTBridge / CatalystInstance is never instantiated. From 0.82 onward, both are the only option.

Will Hermes still work with the New Architecture?

Yes. Hermes is the recommended JavaScript engine and is deeply integrated with JSI. If anything, Hermes benefits most from the New Architecture because its startup-time advantages compound with TurboModule lazy loading.

Does Expo support the New Architecture?

Yes. Expo SDK 52 enabled it by default, SDK 53 made every expo-* package compatible, and SDK 55 (bundling RN 0.83) removed the opt-out field entirely. See the Expo guide to the New Architecture for details.

Build on the New Architecture without thinking about it

The best thing about the React Native New Architecture in 2026 is that for most app teams, it's invisible. The platform got faster, cleaner, and more typed, and you didn't have to do anything to get those benefits.

If you want to see what shipping on this modern stack looks like without wiring any of it up yourself, try describing your app idea in plain English. RapidNative generates React Native + Expo apps that already target the New Architecture, Fabric, and bridgeless mode by default — because that's the only React Native there is now.

How to Build a Video Calling App with React Native and WebRTC

Mason Roy — Fri, 09 Oct 2026 08:43:06 +0000

A FaceTime-quality call looks like one feature. Underneath, it is five systems that have to work in perfect sequence — camera capture, codec negotiation, NAT traversal, a signaling channel, and connection repair. This guide walks through building a React Native WebRTC video calling app end to end: real code, honest architectural tradeoffs, and the parts most tutorials skip. By the end you will have a working 1-to-1 call, a signaling server, and a clear path to scale beyond two participants. For the surrounding screens — login, contacts, call history — RapidNative generates production-grade React Native code from a prompt, so you can focus the hard engineering budget on the call itself.

React Native and WebRTC together ship real-time video to iOS and Android from a single codebase — Photo by Christopher Gower on Unsplash

What You Need to Build Video Calling in React Native

A React Native WebRTC video calling app needs four pieces: the react-native-webrtc library to expose native video APIs, a signaling server to exchange SDP offers and ICE candidates, STUN/TURN servers for NAT traversal, and camera and microphone permissions configured for both iOS and Android. Expo users must use the bare workflow or EAS Build with the Expo config plugin — WebRTC does not run in Expo Go.

That is the 60-second answer. The rest of this guide is why each piece exists, how they talk to each other, and how to debug the specific failure modes that will show up when you plug it all together.

WebRTC vs Managed SDKs: The Choice That Shapes Everything

Before you write a line of code, choose a lane. WebRTC is a protocol, not a product. You can either own the whole stack or buy pieces of it.

Option	What You Build	What You Pay For	Best For
Raw WebRTC + self-hosted signaling	Your signaling server, STUN/TURN infrastructure, call state logic	Infra, debugging, TURN bandwidth	Learning, custom protocols, low volume
WebRTC + managed TURN (Twilio, Xirsys)	Signaling, call logic	TURN bandwidth per GB	Production 1-to-1 at modest scale
Managed SDK (Agora, Daily, Twilio Video, Dyte)	UI integration	Per-minute call fees	Teams who want to ship this week

The pattern I see most often: people start with raw WebRTC to learn, then move to a managed SDK the moment they need group calls, recording, or background noise suppression. There is no shame in that — building an SFU (Selective Forwarding Unit) that scales to 50 participants is a product in itself. For a 1-to-1 call app, raw WebRTC is the right call. For a Zoom clone, buy the stack.

This tutorial covers the raw-WebRTC path because understanding it makes every other option legible.

The Signaling Dance: SDP, ICE, and Why Two Phones Can't Just Talk

WebRTC uses peer-to-peer video, meaning your two phones exchange media directly without routing it through your server. But before they can, they need to find each other across the public internet, agree on video codecs, and punch holes through their NATs. The signaling server mediates that negotiation. It does not touch any video or audio.

Here is the choreography for a 1-to-1 call:

Caller creates a RTCPeerConnection and attaches their local camera and microphone stream.
Caller generates an SDP offer — a text blob describing codecs, resolutions, and media capabilities — and sends it to the callee through the signaling server.
Callee creates its own RTCPeerConnection, sets the offer as the remote description, and generates an SDP answer.
Both peers gather ICE candidates — network paths the other side might use to reach them — and swap them through the signaling server (this is "trickle ICE").
The browsers try candidates in priority order (host, srflx via STUN, relay via TURN) until one works.
A direct peer connection is established. Signaling is no longer needed. Video flows.

If any of those steps silently fails, the call appears to connect, both users see "ringing," and then nothing happens. Debugging WebRTC is 80% logging each phase of this dance.

WebRTC peer connection flow — the signaling server negotiates, but media flows directly between devices — Photo by Taylor Vick on Unsplash

Setting Up React Native WebRTC

Install the library and native dependencies first.

# Bare React Native project
npm install react-native-webrtc
cd ios && pod install && cd ..

# Expo projects (bare workflow or EAS Build only)
npx expo install react-native-webrtc @config-plugins/react-native-webrtc

For Expo projects, add the config plugin to app.json:

{
  "expo": {
    "plugins": [
      [
        "@config-plugins/react-native-webrtc",
        {
          "cameraPermission": "Allow $(PRODUCT_NAME) to access your camera for video calls",
          "microphonePermission": "Allow $(PRODUCT_NAME) to access your microphone for calls"
        }
      ]
    ]
  }
}

Then run npx expo prebuild and eas build --profile development. WebRTC will crash in Expo Go — that is not a bug, Expo Go cannot load custom native modules.

For bare React Native, add permissions to ios/<YourApp>/Info.plist:

<key>NSCameraUsageDescription</key>
<string>We need the camera for video calls</string>
<key>NSMicrophoneUsageDescription</key>
<string>We need the microphone for calls</string>

And in android/app/src/main/AndroidManifest.xml:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />

On Android, you also need to request runtime permissions before accessing the camera. React Native's PermissionsAndroid handles this.

Capturing the Local Camera Stream

With permissions in place, grab the local media stream using mediaDevices.getUserMedia:

import { mediaDevices, MediaStream, RTCView } from 'react-native-webrtc';
import { useEffect, useState } from 'react';

export function CallScreen() {
  const [localStream, setLocalStream] = useState<MediaStream | null>(null);

  useEffect(() => {
    async function startLocalStream() {
      const stream = await mediaDevices.getUserMedia({
        audio: true,
        video: {
          width: 640,
          height: 480,
          frameRate: 30,
          facingMode: 'user', // front camera
        },
      });
      setLocalStream(stream);
    }
    startLocalStream();

    return () => {
      localStream?.getTracks().forEach((t) => t.stop());
    };
  }, []);

  if (!localStream) return null;

  return (
    <RTCView
      streamURL={localStream.toURL()}
      style={{ flex: 1 }}
      objectFit="cover"
      mirror
    />
  );
}

RTCView is the native component that renders a MediaStream. It accepts a streamURL (not the stream object directly), objectFit for aspect handling, and mirror for front-camera previews. Clean up tracks in the unmount return — forgetting this leaves the camera light on, which users notice fast.

Building the Peer Connection

Once you have a local stream, create the RTCPeerConnection and attach it. Here is the caller side:

import {
  RTCPeerConnection,
  RTCSessionDescription,
  RTCIceCandidate,
} from 'react-native-webrtc';

const configuration = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:your-turn-server.com:3478',
      username: 'user',
      credential: 'pass',
    },
  ],
};

export async function startCall(localStream: MediaStream, signaling: SignalingClient) {
  const pc = new RTCPeerConnection(configuration);

  // Attach local tracks
  localStream.getTracks().forEach((track) => {
    pc.addTrack(track, localStream);
  });

  // Remote stream handler
  pc.addEventListener('track', (event) => {
    const [remoteStream] = event.streams;
    // Pass remoteStream up to render in another <RTCView />
  });

  // Trickle ICE candidates to the signaling channel
  pc.addEventListener('icecandidate', (event) => {
    if (event.candidate) {
      signaling.send({ type: 'ice-candidate', candidate: event.candidate });
    }
  });

  // Create and send the SDP offer
  const offer = await pc.createOffer({ offerToReceiveVideo: true, offerToReceiveAudio: true });
  await pc.setLocalDescription(offer);
  signaling.send({ type: 'offer', sdp: offer });

  // Handle incoming answer and ICE from callee
  signaling.on('answer', async (msg) => {
    await pc.setRemoteDescription(new RTCSessionDescription(msg.sdp));
  });
  signaling.on('ice-candidate', async (msg) => {
    await pc.addIceCandidate(new RTCIceCandidate(msg.candidate));
  });

  return pc;
}

The callee is a mirror image: receive the offer, create its own RTCPeerConnection, setRemoteDescription(offer), create an answer, setLocalDescription(answer), send the answer back. Both sides exchange ICE candidates as they appear.

The Signaling Server

Any transport that can relay JSON between two clients works — WebSocket, Socket.io, Firebase Realtime Database, Supabase Realtime, or your own channel. For this guide, a minimal Socket.io server is clearest:

// server/signaling.js
const { createServer } = require('http');
const { Server } = require('socket.io');

const io = new Server(createServer().listen(3001), { cors: { origin: '*' } });

const rooms = new Map(); // roomId -> Set of socket IDs

io.on('connection', (socket) => {
  socket.on('join', (roomId) => {
    socket.join(roomId);
    const peers = Array.from(io.sockets.adapter.rooms.get(roomId) ?? []);
    socket.emit('peers', peers.filter((id) => id !== socket.id));
  });

  socket.on('signal', ({ to, payload }) => {
    io.to(to).emit('signal', { from: socket.id, payload });
  });

  socket.on('disconnect', () => {
    socket.rooms.forEach((roomId) => socket.to(roomId).emit('peer-left', socket.id));
  });
});

The server never sees SDP or ICE content — it is a dumb relay. That is deliberate: it keeps signaling cheap to scale and makes end-to-end encryption straightforward (WebRTC's SRTP handles media encryption automatically).

In production you will want authentication (JWT on the socket handshake), room access control, and persistence of pending signals for callees who are offline when the ringer fires. For push-based call ringing on iOS, you need PushKit and CallKit; on Android, FCM with high-priority messages and ConnectionService. That is a separate rabbit hole worth its own guide.

STUN, TURN, and Why Your Call Fails on Hotel Wi-Fi

STUN servers help a peer discover its public IP so another peer can reach it directly. Google's public STUN (stun:stun.l.google.com:19302) is free and fine for development. In production, roughly 15% of users sit behind symmetric NATs where STUN alone cannot establish a path — hotel Wi-Fi, corporate networks, mobile carrier CGNAT. For those, you need a TURN server that relays media through itself.

TURN is bandwidth-hungry and therefore expensive. Options:

Self-host coturn — the open-source TURN server. Cheapest at scale, requires DevOps capacity. coturn on GitHub.
Managed TURN (Twilio Network Traversal, Xirsys, Metered) — a few dollars per GB. Rolls into production in minutes.
Hybrid — self-hosted for most traffic, Twilio as fallback.

Rule of thumb: a 1-to-1 call at 720p/30fps uses ~1.5 Mbps per direction. One hour of fully-relayed call ≈ 1.35 GB of TURN bandwidth. Price your plan accordingly.

Set up your iceServers with both:

const configuration = {
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: ['turn:turn.example.com:3478', 'turns:turn.example.com:5349'],
      username: timeLimitedUsername,
      credential: timeLimitedCredential,
    },
  ],
  iceCandidatePoolSize: 10,
};

Rotate TURN credentials — never hard-code long-lived ones in your mobile app. The HMAC-based scheme in RFC 7635 is the pattern most managed providers use.

A production video call combines WebRTC's protocol, platform-native rendering, and robust signaling — Photo by Yura Fresh on Unsplash

Rendering the Remote Stream

When the track event fires, you have a remote stream. Pass it up and render it in a second RTCView:

<View style={styles.container}>
  <RTCView
    streamURL={remoteStream.toURL()}
    style={styles.remoteVideo}
    objectFit="cover"
  />
  <RTCView
    streamURL={localStream.toURL()}
    style={styles.pictureInPicture}
    objectFit="cover"
    mirror
    zOrder={1} // Android: render above remote view
  />
</View>

zOrder={1} is Android-specific — without it, the local picture-in-picture renders behind the full-screen remote view. iOS orders by component tree order, so it just works there.

Call Controls: Mute, Switch Camera, Hang Up

These are small methods on the stream and track objects:

// Mute mic
localStream.getAudioTracks()[0].enabled = false;

// Toggle video
localStream.getVideoTracks()[0].enabled = false;

// Switch between front and back camera
localStream.getVideoTracks()[0]._switchCamera();

// End the call
pc.close();
localStream.getTracks().forEach((t) => t.stop());
signaling.send({ type: 'bye' });

enabled = false on an audio track is cheaper than removing it entirely and does not renegotiate SDP. _switchCamera() is a react-native-webrtc extension — on web WebRTC you would renegotiate with a new getUserMedia call.

What Breaks in Production (and How to Debug It)

Three failure modes account for most "it works on my simulator" moments:

Simulator has no camera. iOS Simulator cannot access a real camera, and Android emulators have limited support. Test video on physical devices. Audio can be simulated on both.

App Store review requires permission strings in English. Your NSCameraUsageDescription must clearly explain why you need the camera. "App needs camera" gets rejected. "Needed for video calling with contacts" passes.

ICE connection stalls at checking. The ICE state goes new → checking → connected → completed. Stuck at checking means candidates were exchanged but none worked. Nine times out of ten this is a missing or misconfigured TURN server. Attach a listener:

pc.addEventListener('iceconnectionstatechange', () => {
  console.log('ICE state:', pc.iceConnectionState);
});

Background audio stops. On iOS, add audio to UIBackgroundModes in Info.plist. On Android, run a foreground service during active calls — otherwise the OS will suspend your process.

One side sees the other but not vice versa. Almost always an SDP direction mismatch — one peer created an offer with offerToReceiveVideo: false or forgot to addTrack before createOffer. Log the SDP on both sides; look for a=sendrecv on each media line.

Scaling Beyond 1-to-1: SFU, MCU, or Mesh?

Peer-to-peer scales badly. Each additional participant adds N-1 upstreams per device — a 4-person call uploads your video three times. By 5 participants you have saturated most mobile uplinks.

Three paths forward:

Mesh (what we built) — works up to 3-4 participants on good networks. No server-side media infra.
SFU (Selective Forwarding Unit) — each client sends one upload; the server forwards streams to everyone else. Scales to ~50 participants. Open-source options: mediasoup, LiveKit, Janus. Managed: Daily, Dyte, 100ms.
MCU (Multipoint Control Unit) — server mixes streams into one composite video. Lowest client CPU, highest server cost. Rare in modern stacks.

If your product needs group calls, start with LiveKit or mediasoup. Writing an SFU from scratch is a six-month detour.

Shipping the Rest of the App

The hard part of a calling app is the call. The rest — authentication, contacts, call history, settings, notifications — is standard mobile UI. That is where RapidNative saves weeks. Describe the screens in plain English and get working React Native + Expo code with real state, Supabase-backed data, and a live preview you can test on your phone via QR code. Point and edit any element, iterate in minutes, and export the full project when you are ready to drop in your WebRTC code. Teams typically ship 85% faster than hand-coding the surrounding surfaces.

For deeper reading, see the official react-native-webrtc documentation and the WebRTC specification at the W3C. For related mobile patterns, our guides on push notifications in React Native and how we built real-time collaboration cover adjacent real-time infrastructure.

Frequently Asked Questions

Does React Native WebRTC work with Expo Go?

No. react-native-webrtc is a native module and cannot run in Expo Go. You need the bare workflow or Expo's EAS Build with the @config-plugins/react-native-webrtc plugin. After adding the plugin, run expo prebuild and build a development client — it will then work exactly like a bare React Native project.

Do I really need a TURN server for a video calling app?

Yes, if you want calls to work for everyone. Roughly 15% of users sit behind symmetric NATs or firewalls where direct peer-to-peer connections fail. A TURN server relays their traffic. In development, Google's public STUN is enough; in production, pair STUN with a managed TURN provider (Twilio, Xirsys, Metered) or self-hosted coturn.

What is the difference between STUN and TURN in WebRTC?

STUN helps a peer discover its public IP so another peer can connect directly. TURN relays media through a server when direct connections fail. STUN is lightweight and nearly free; TURN consumes significant bandwidth and costs money. Every production WebRTC app configures both — STUN as the preferred path, TURN as fallback.

Build the Rest of Your App in Minutes

WebRTC is deep, specific engineering. The screens around it should not be. Describe your calling app in plain words with RapidNative, export clean React Native code, and plug in the WebRTC flow from this guide. Start free with 20 credits — no card required.

Your React Native Login Works. Your Session Doesn't.

Mason Roy — Wed, 07 Oct 2026 08:41:03 +0000

TL;DR

Login is the easy 10%. The bugs live in session handling: refresh, offline, reinstall, cold start.
Five requests hitting a 401 at once = five refresh calls = rotated tokens invalidating each other = random logouts. Fix: a single-flight refresh promise.
A failed fetch (no signal) is not a failed refresh. Never log the user out on a network error.
iOS Keychain survives app uninstall. Your "fresh install" can boot into someone's old session. Wipe SecureStore on first launch.
Gate routes with Stack.Protected and keep the splash screen up until the session is resolved — no login-screen flash.

Every auth tutorial ends at the same place: user taps "Sign in", you get a token, you navigate to the home screen. Ship it.

Then the bug reports start. "App logged me out on the train." "I reinstalled and it showed my old account." "It flashes the login screen for a second every time I open it." None of these are login bugs. They're session bugs, and they only show up once real people use the app on real phones with real network conditions.

Here are the four I've hit most, with the code I now drop into every Expo project.

1. The 401 refresh storm

Your home screen mounts and fires five requests in parallel. The access token expired an hour ago. All five come back 401. Your interceptor — written the obvious way — calls /auth/refresh five times.

If your backend rotates refresh tokens (it should), call #1 succeeds and invalidates the old refresh token. Calls #2–#5 send the now-dead token, fail, and your error handler logs the user out. The user did nothing wrong. They opened the app.

The fix is boring: only ever have one refresh in flight, and make everyone else wait on it.

// lib/auth/refresh.ts
import * as SecureStore from 'expo-secure-store';

const REFRESH_KEY = 'auth.refresh';
const API = process.env.EXPO_PUBLIC_API_URL;

let accessToken: string | null = null;   // memory only — see below
let inflight: Promise<string> | null = null;

export class SessionExpiredError extends Error {}

export function getAccessToken() {
  return accessToken;
}

export function refreshAccessToken(): Promise<string> {
  if (!inflight) {
    inflight = doRefresh().finally(() => {
      inflight = null;
    });
  }
  return inflight;
}

async function doRefresh(): Promise<string> {
  const refresh = await SecureStore.getItemAsync(REFRESH_KEY);
  if (!refresh) throw new SessionExpiredError();

  const res = await fetch(`${API}/auth/refresh`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ refreshToken: refresh }),
  });

  // The server *answered* and said no → the session is genuinely dead.
  if (res.status === 401 || res.status === 403) {
    await clearSession();
    throw new SessionExpiredError();
  }
  if (!res.ok) throw new Error(`Refresh failed: ${res.status}`);

  const body = await res.json();
  accessToken = body.accessToken;
  if (body.refreshToken) {
    // rotation: persist the new one before anyone else needs it
    await SecureStore.setItemAsync(REFRESH_KEY, body.refreshToken);
  }
  return body.accessToken;
}

export async function clearSession() {
  accessToken = null;
  await SecureStore.deleteItemAsync(REFRESH_KEY);
}

Then a fetch wrapper that retries once:

// lib/auth/authFetch.ts
import { getAccessToken, refreshAccessToken } from './refresh';

export async function authFetch(input: string, init: RequestInit = {}) {
  const send = (token: string | null) =>
    fetch(input, {
      ...init,
      headers: {
        ...init.headers,
        ...(token ? { Authorization: `Bearer ${token}` } : {}),
      },
    });

  let res = await send(getAccessToken());
  if (res.status !== 401) return res;

  const fresh = await refreshAccessToken(); // all 5 callers share this
  res = await send(fresh);
  return res; // a second 401 is a real authorization error — don't loop
}

Five parallel 401s now produce exactly one refresh call. The other four await the same promise and retry with the new token.

Opinion: keep the access token in memory only. It's short-lived, and re-deriving it from the refresh token on cold start costs one request. That leaves exactly one secret on disk.

2. Logging people out because the train went into a tunnel

Look at doRefresh again. There are three outcomes, and most code treats two of them the same:

What happened	What it means	What to do
`fetch` throws	No network. You know nothing.	Keep the session. Retry later.
Server returns 401/403	Refresh token revoked or expired	Clear session, go to sign-in
Server returns 5xx	Your backend is having a day	Keep the session. Surface an error.

The common bug is a try/catch around the refresh that logs out on any exception. That turns "I had one bar of signal" into "I have to find my password." Only an actual answer from the auth server should end a session — which is why the code above only calls clearSession() on 401/403 and lets everything else bubble up as a normal error.

Pair it with a foreground check so a stale token gets refreshed when the user comes back, not on their first tap:

// lib/auth/useForegroundRefresh.ts
import { useEffect } from 'react';
import { AppState } from 'react-native';
import { refreshAccessToken } from './refresh';

export function useForegroundRefresh(enabled: boolean) {
  useEffect(() => {
    if (!enabled) return;
    const sub = AppState.addEventListener('change', (state) => {
      if (state === 'active') {
        refreshAccessToken().catch(() => {
          // network errors are fine here; authFetch will retry on demand
        });
      }
    });
    return () => sub.remove();
  }, [enabled]);
}

3. The ghost session after reinstall

This one surprises people. On iOS, expo-secure-store is backed by the Keychain, and Keychain items are not removed when the app is uninstalled. Delete the app, reinstall it, and your bootstrap code happily finds the old refresh token and logs straight into the previous account.

On a personal phone that's mostly confusing. On a shared or resold device, it's someone else's account.

The fix: AsyncStorage is wiped on uninstall, so use it as a "have I launched before?" marker.

// lib/auth/firstLaunch.ts
import AsyncStorage from '@react-native-async-storage/async-storage';
import { clearSession } from './refresh';

const INSTALL_FLAG = 'app.installed';

export async function wipeKeychainOnFreshInstall() {
  const seen = await AsyncStorage.getItem(INSTALL_FLAG);
  if (!seen) {
    await clearSession();                 // kill any leftover Keychain token
    await AsyncStorage.setItem(INSTALL_FLAG, '1');
  }
}

Run it before you read anything from SecureStore. While you're in there, two more SecureStore notes:

It isn't available on web. If you ship a web build, you need a separate storage path.
Values over ~2KB may be rejected. Store tokens, not user profiles.

4. The login-screen flash

Cold start, signed-in user, and for 300ms they see the sign-in screen before the app "realizes" they're logged in. Two causes: rendering routes before the session is resolved, and resolving the session with a network call.

Resolve it locally: if a refresh token exists, treat the user as signed in and let authFetch refresh lazily. Don't block the first frame on the network — remember section 2, the user might be offline.

// lib/auth/SessionProvider.tsx
import { createContext, useContext, useEffect, useState } from 'react';
import * as SecureStore from 'expo-secure-store';
import { wipeKeychainOnFreshInstall } from './firstLaunch';

type Status = 'loading' | 'signedIn' | 'signedOut';
const SessionContext = createContext<{
  status: Status;
  setStatus: (s: Status) => void;
}>({ status: 'loading', setStatus: () => {} });

export function SessionProvider({ children }: { children: React.ReactNode }) {
  const [status, setStatus] = useState<Status>('loading');

  useEffect(() => {
    (async () => {
      await wipeKeychainOnFreshInstall();
      const refresh = await SecureStore.getItemAsync('auth.refresh');
      setStatus(refresh ? 'signedIn' : 'signedOut');
    })();
  }, []);

  return (
    <SessionContext.Provider value={{ status, setStatus }}>
      {children}
    </SessionContext.Provider>
  );
}

export const useSession = () => useContext(SessionContext);

Then gate routes with Expo Router's protected screens and hold the splash until status is known:

// app/_layout.tsx
import { Stack } from 'expo-router';
import * as SplashScreen from 'expo-splash-screen';
import { useEffect } from 'react';
import { SessionProvider, useSession } from '@/lib/auth/SessionProvider';
import { useForegroundRefresh } from '@/lib/auth/useForegroundRefresh';

SplashScreen.preventAutoHideAsync();

function RootNavigator() {
  const { status } = useSession();
  useForegroundRefresh(status === 'signedIn');

  useEffect(() => {
    if (status !== 'loading') SplashScreen.hideAsync();
  }, [status]);

  if (status === 'loading') return null; // splash is still showing

  return (
    <Stack screenOptions={{ headerShown: false }}>
      <Stack.Protected guard={status === 'signedIn'}>
        <Stack.Screen name="(app)" />
      </Stack.Protected>
      <Stack.Protected guard={status === 'signedOut'}>
        <Stack.Screen name="sign-in" />
      </Stack.Protected>
    </Stack>
  );
}

export default function RootLayout() {
  return (
    <SessionProvider>
      <RootNavigator />
    </SessionProvider>
  );
}

Stack.Protected needs a recent Expo Router (SDK 53+). On older versions, the same idea works with a <Redirect /> in each group's _layout.tsx.

One last wire: when authFetch throws SessionExpiredError, call setStatus('signedOut'). The protected guard flips and Expo Router moves the user to sign-in on its own — no manual router.replace scattered around the codebase.

If you're spinning up a new app and would rather start from a project where the (app) / sign-in route groups and _layout.tsx are already in place, RapidNative generates React Native + Expo projects from a prompt, so you can spend your time on the session logic above instead of the scaffolding.

The checklist I run before shipping auth

[ ] Parallel 401s trigger exactly one refresh call (test it: expire the token, open the busiest screen)
[ ] Airplane mode on cold start → user stays signed in
[ ] Refresh endpoint returning 500 → user stays signed in
[ ] Refresh endpoint returning 401 → user lands on sign-in, no crash
[ ] Uninstall + reinstall on iOS → user is signed out
[ ] Cold start as a signed-in user → no sign-in screen flash
[ ] Access token never written to disk

Most of these take five minutes to test and are invisible until a user files the bug for you.

What's the weirdest auth bug you've shipped to production? Drop it in the comments — I'm collecting these.

I Audited 12 React Native Apps for WCAG 2.2. Here's What 11 of Them Got Wrong.

Mason Roy — Mon, 05 Oct 2026 08:56:46 +0000

TL;DR

I audited 12 production React Native apps against WCAG 2.2 AA. 11 would fail. The median app failed 23 of 55 criteria.
The DOJ's ADA Title II deadline for state and local government apps is now April 2027 (pushed back a year in April 2026). The EU Accessibility Act is already in force for private-sector apps.
RN maps almost 1:1 to native accessibility APIs. The problem is nothing forces you to use them.
Retrofitting a 40-screen app takes 2–4 engineer-weeks. Building with the props from day one costs ~zero.
Fastest wins: test with VoiceOver/TalkBack, add eslint-plugin-react-native-a11y as a merge blocker, fix the five patterns below.

The problem isn't React Native

Every accessibilityLabel becomes a UIAccessibilityLabel on iOS. Every accessibilityRole ends up in AccessibilityNodeInfo on Android. The plumbing is good.

But you can ship an entire app of styled Views with onPress handlers and never set a single accessibility prop. It runs, it looks fine, and VoiceOver users can't see any of it.

All 12 apps I audited had the same five patterns. Here they are, with fixes.

1. Custom buttons with no label or role

The classic:

// ❌ VoiceOver reads nothing useful
<Pressable onPress={onClose}>
  <CloseIcon />
</Pressable>

// ✅ Announced as "Close, button"
<Pressable
  onPress={onClose}
  accessibilityRole="button"
  accessibilityLabel="Close"
  accessibilityHint="Closes the settings panel"
>
  <CloseIcon />
</Pressable>

Icon-only buttons are the worst offenders. If there's no visible text, there must be a label.

2. Tiny touch targets

WCAG 2.2 added Target Size (Minimum) at AA: at least 24×24 CSS px. Apple and Google both recommend going bigger (44pt / 48dp). A 16pt icon fails all of them.

You don't have to change the visual size, just the hit area:

<Pressable
  onPress={onLike}
  accessibilityRole="button"
  accessibilityLabel="Like"
  hitSlop={{ top: 14, bottom: 14, left: 14, right: 14 }}
>
  <HeartIcon size={16} />
</Pressable>

3. Form errors that are only red text

A sighted user sees the error. A screen reader user hears nothing and wonders why submit didn't work.

import { useEffect } from 'react';
import { AccessibilityInfo, Text, TextInput } from 'react-native';

function EmailField({ value, onChange, error }) {
  useEffect(() => {
    if (error) AccessibilityInfo.announceForAccessibility(error);
  }, [error]);

  return (
    <>
      <TextInput
        value={value}
        onChangeText={onChange}
        accessibilityLabel="Email address"
        accessibilityHint={error ?? undefined}
      />
      {error && (
        <Text accessibilityLiveRegion="polite" style={{ color: '#B00020' }}>
          {error}
        </Text>
      )}
    </>
  );
}

accessibilityLiveRegion covers Android; announceForAccessibility covers iOS.

4. Modals that don't trap focus

Users swipe right past your dialog into the screen behind it. Mark the modal content as modal on iOS and hide the background on Android:

<View accessibilityViewIsModal>
  {/* dialog content */}
</View>

<View importantForAccessibility={modalOpen ? 'no-hide-descendants' : 'auto'}>
  {/* screen behind the modal */}
</View>

React Native's built-in <Modal> handles most of this for you. Custom bottom sheets and overlays usually don't.

5. Text on gradients

Text that passes 4.5:1 contrast at the top of a gradient often fails at the bottom. Check the lightest point the text sits on, not the average. The quick fix is a solid or semi-opaque scrim behind the text.

Stop new violations at the PR

None of the fixes above matter if new screens keep shipping without props. Add the lint plugin and make it a required check:

npm install --save-dev eslint-plugin-react-native-a11y

// .eslintrc.js
module.exports = {
  plugins: ['react-native-a11y'],
  extends: ['plugin:react-native-a11y/all'],
};

It won't catch contrast or focus order, but in my audits it would have caught roughly 90% of failures: the missing labels and roles.

Retrofit vs. restart

The retrofit math: a 40-screen app built without accessibility takes 2–4 weeks of one engineer doing nothing else. With 200 screens, every fix needs review, QA and regression testing.

If your app is under six months old and under thirty screens, restarting on a stack that generates accessible components by default can be cheaper than retrofitting. That's part of why we built RapidNative: every generated screen ships with accessibility props filled in, because the templates treat them as required.

The 20-minute test

Before any of this: turn on VoiceOver (iOS) or TalkBack (Android), close your eyes, and try your app's main user flow. Not a demo — the real thing. If you can't finish it, neither can your users.

That one exercise will tell you more about your priorities than any audit report.

What's the worst accessibility bug you've found in your own RN app? Drop it in the comments. I'm collecting them for a follow-up post.

6 Supabase RLS Policies That Pass Code Review and Still Leak Data

Mason Roy — Wed, 30 Sep 2026 07:17:16 +0000

TL;DR

enable row level security with zero policies is safe. Forgetting to enable it is a public table. Check every table, not just the ones you remember creating.
using is for reading rows. with check is for writing them. An update policy with only using lets users move rows to someone else.
Never put authorization data in raw_user_meta_data. The user can edit it. Use app_metadata or a separate table.
to public includes anon. Say to authenticated when you mean logged-in users.
Views and security definer functions bypass RLS silently. Audit them.
Wrap auth.uid() in (select auth.uid()) or your policies will be slow at scale.
Every one of these is testable. If your RLS isn't tested, it's a hope.

Row Level Security is the reason Supabase works from a mobile client at all. Your anon key is in the app bundle, anyone can extract it, and the only thing between them and your orders table is a policy you wrote in SQL at 11pm.

I've reviewed a lot of RLS. The scary ones aren't the obviously wrong policies — those get caught. The scary ones are the ones that read correctly, pass review, and leak in a way that only shows up when someone tries. Here are the six I see most, with the fix and the test.

1. The table you forgot to enable RLS on

Not a bad policy. No policy — because RLS was never turned on.

create table profiles (
  id uuid primary key references auth.users,
  display_name text,
  email text
);
-- ...and nothing else

This table is readable and writable by anyone with the anon key. Supabase's dashboard warns you, but the dashboard isn't in your CI. Migrations written by hand (or by an AI) skip this constantly.

The fix is to make it structurally impossible to forget:

-- Put this in your first migration and never remove it
create or replace function public.tables_without_rls()
returns table(table_name text) language sql stable as $$
  select c.relname::text
  from pg_class c
  join pg_namespace n on n.oid = c.relnamespace
  where n.nspname = 'public'
    and c.relkind = 'r'
    and not c.relrowsecurity;
$$;

The test:

test('every public table has RLS enabled', async () => {
  const { data } = await admin.rpc('tables_without_rls');
  expect(data).toEqual([]); // prints the offending table name when it fails
});

Run it on every migration. This one test has caught more real leaks for me than the other five combined.

2. `update` with `using` but no `with check`

This is the one that reads correctly.

create policy "users update own profile" on profiles
  for update
  using (auth.uid() = id);

using decides which existing rows the user can touch. with check decides what the row is allowed to look like after the write. With only using, a user can select their own row — and then update its id to someone else's, or on a table with a user_id column, reassign ownership entirely:

// Alice, logged in, doing something she shouldn't be able to
await supabase
  .from('posts')
  .update({ user_id: BOB_ID })   // now Bob owns Alice's spam post
  .eq('id', alicesPostId);        // passes `using`, no `with check` to stop it

The fix:

create policy "users update own posts" on posts
  for update
  using (auth.uid() = user_id)
  with check (auth.uid() = user_id);

The test:

test('cannot reassign a row to another user', async () => {
  const alice = await signInAs('alice');
  const { error } = await alice
    .from('posts')
    .update({ user_id: BOB_ID })
    .eq('id', alicesPostId);
  expect(error?.code).toBe('42501'); // insufficient_privilege
});

Same applies to insert — with check is the only clause that matters there, and a missing one means users can insert rows with any user_id they like.

3. Authorization from `raw_user_meta_data`

Someone wants an admin flag. The fastest place to put it is user metadata, because it's right there in the JWT:

create policy "admins see everything" on orders
  for select
  using ((auth.jwt() -> 'user_metadata' ->> 'role') = 'admin');

The user can update their own user_metadata through the client:

await supabase.auth.updateUser({ data: { role: 'admin' } });
// refresh session, now they're an admin

That's it. That's the whole exploit.

The fix: app_metadata is only writable with the service role, so it's safe to trust. Better still, keep roles in a table and join:

create table user_roles (
  user_id uuid primary key references auth.users,
  role text not null check (role in ('user', 'admin'))
);
alter table user_roles enable row level security;
-- deliberately no policies: nobody can read or write this from the client

create policy "admins see all orders" on orders
  for select
  using (
    exists (
      select 1 from user_roles
      where user_id = (select auth.uid()) and role = 'admin'
    )
  );

The test:

test('user cannot self-promote via metadata', async () => {
  const mallory = await signInAs('mallory');
  await mallory.auth.updateUser({ data: { role: 'admin' } });
  await mallory.auth.refreshSession();
  const { data } = await mallory.from('orders').select('id');
  expect(data).toHaveLength(0); // still sees nothing
});

4. `to public` when you meant `to authenticated`

create policy "read published posts" on posts
  for select
  using (published = true);

No to clause means to public, which includes the anon role. Sometimes that's intended — published posts probably should be public. But copy that pattern to a table where it isn't:

create policy "read own notifications" on notifications
  for select
  using (auth.uid() = user_id);

Here anon gets auth.uid() as null, null = user_id is null, and the policy fails closed. Fine — by accident. Change the policy to use coalesce or a not exists, or add a or public = true branch, and suddenly the accident stops working.

The fix is to be explicit every time:

create policy "read own notifications" on notifications
  for select
  to authenticated
  using ((select auth.uid()) = user_id);

The test:

test('anon cannot read notifications at all', async () => {
  const anon = createClient(URL, ANON_KEY);
  const { data, error } = await anon.from('notifications').select('id');
  expect(data ?? []).toHaveLength(0);
});

5. The view that bypasses everything

Views in Postgres run with the permissions of their owner by default, not the caller. The owner is usually postgres, which bypasses RLS.

create view order_summaries as
  select o.id, o.total, u.email
  from orders o join auth.users u on u.id = o.user_id;

Every authenticated user can now select * from order_summaries and get every order and every email in the system. The orders policies are fine. The view doesn't use them.

The fix (Postgres 15+):

create view order_summaries
  with (security_invoker = true)
as
  select o.id, o.total, u.email
  from orders o join auth.users u on u.id = o.user_id;

security_invoker makes the view run as the caller, so the underlying RLS applies. Same story for functions — security definer functions bypass RLS, which is sometimes exactly what you want (the tables_without_rls helper above needs it), and sometimes a hole. Audit every one:

select p.proname
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public' and p.prosecdef;

The test:

test('order_summaries respects caller RLS', async () => {
  const alice = await signInAs('alice');
  const { data } = await alice.from('order_summaries').select('id');
  expect(data?.every(r => aliceOrderIds.includes(r.id))).toBe(true);
});

6. `auth.uid()` without the `select`

This one doesn't leak. It's here because it's the one that makes people remove RLS when the table gets big.

using (auth.uid() = user_id)

Postgres calls auth.uid() once per row. On a 5-million-row table with a user_id index, that's 5 million function calls before the index is even considered.

using ((select auth.uid()) = user_id)

Wrapped in a subselect, Postgres evaluates it once and treats it as a constant, so the index is used. On a table I looked at last month this was the difference between 3.2 seconds and 4 milliseconds. Nobody had leaked anything; they'd just been about to turn RLS off "temporarily" for performance.

Same rule for auth.jwt() and anything else that's stable within a query.

Putting it in CI

All six tests together are about 80 lines. They need a real Postgres with your migrations applied and a way to sign in as different test users — which is a one-line supabase start in CI, or a lighter single-process alternative if you don't want Docker there.

The pattern I use:

// test/rls.setup.ts
export async function signInAs(name: string) {
  const client = createClient(URL, ANON_KEY);
  await client.auth.signInWithPassword({
    email: `${name}@test.local`,
    password: 'test-password',
  });
  return client;
}

Seed the users in seed.sql, write one test per policy, run on every PR. The tests are boring. That's the point — the day one of them goes red is the day you didn't ship a leak.

If you're starting from a template rather than a blank project, check whether it ships with these. The AppLighter Expo + Supabase foundation is the one I've seen that has the RLS test harness in it out of the box — the tables_without_rls check and per-policy tests wired into CI — which matters more than any single policy, because it's the thing that catches the seventh mistake I haven't found yet.

Which of these have you hit? And more usefully — which one am I missing? Drop it in the comments and I'll add it with a test.

Expo OTA Updates Are a Loaded Gun. Here's the Safety.

Mason Roy — Wed, 30 Sep 2026 06:32:17 +0000

TL;DR

runtimeVersion is the only thing standing between an OTA update and a crash loop. Use the fingerprint policy, not appVersion.
An OTA update can't change native code. If you touched ios/, android/, a config plugin, or a package with native code, ship a store build. No exceptions.
Default checkOnLaunch + fallbackToCacheTimeout: 0 means users get the update next launch, not this one. Decide if that's what you want.
Test updates on a preview build with a dedicated channel. expo-updates is disabled in dev clients.
Rollback isn't a button. It's republishing a known-good update. Know the command before you need it.

OTA updates are the best thing about Expo and the fastest way I've shipped a broken app to 100% of users in under a minute.

That's not a contradiction. eas update is a loaded gun. It's incredibly useful. It also has no safety on by default. Here's the one I've built up over a couple of years of using it in production, one incident at a time.

1. The runtime version mismatch (aka the crash loop)

This is the big one. Every OTA update is tagged with a runtimeVersion. Every native build has one too. Expo only delivers an update to a build with a matching runtime version. If you get this wrong in the permissive direction — an update that matches a build it shouldn't — you ship JS that calls a native module the build doesn't have, and the app crashes on launch. Forever. There's no "next update fixes it," because the app never runs long enough to fetch it.

The default in a lot of older projects:

{
  "expo": {
    "runtimeVersion": {
      "policy": "appVersion"
    }
  }
}

appVersion ties the runtime to the version string in app.json. Sounds fine. It means: as long as you don't bump version, every build is considered compatible. Add a native dependency, forget to bump, publish an update — crash loop for anyone on the old build.

The fix is to let Expo compute it from what's actually native in the project:

{
  "expo": {
    "runtimeVersion": {
      "policy": "fingerprint"
    }
  }
}

fingerprint hashes the native project — dependencies with native code, config plugins, ios/ and android/ if you have them. Change any of it and the fingerprint changes, so the next eas update simply won't be delivered to old builds. You can check what you're about to ship against:

npx expo-updates fingerprint:generate
# or compare against a specific build
eas fingerprint:compare

If the fingerprint changed and you didn't expect it to, that's your signal that a store build is required, not an update.

2. Shipping native changes over the air

Related, but a different mistake: knowing the rule and getting it wrong anyway because the change didn't look native.

Things that are native and require a new build, that people routinely try to OTA:

✗ Adding any package with an ios/ or android/ directory
✗ Changing a config plugin's options (permissions text, deep link schemes, etc.)
✗ Bumping Expo SDK version
✗ Changing app icon, splash screen, or bundle identifier
✗ Enabling/disabling the new architecture
✗ Updating expo-updates itself

Things that are JS and are fine to OTA:

✓ Any .ts / .tsx / .js change
✓ Assets imported from JS (images via require(), fonts loaded via expo-font)
✓ Changes to app.json fields that are read at runtime (extra, updates config)

The fingerprint policy catches all of the first list. But you should know the list anyway, because you'll want to plan a store release before you're blocked by one.

3. Publishing to the wrong channel

Channels are how you point a build at a stream of updates. Branches are where updates live. A build says "I listen to channel production." A channel is mapped to a branch. eas update publishes to a branch.

// eas.json
{
  "build": {
    "preview": {
      "channel": "preview",
      "distribution": "internal"
    },
    "production": {
      "channel": "production"
    }
  }
}

The mistake is treating the branch name as a free-form string:

# This creates a branch called "fix-login" that no build listens to.
# Nothing happens. You think the update is out. It isn't.
eas update --branch fix-login --message "fix login"

What I do now, without exception:

# Preview first — this hits the internal build the team has installed
eas update --channel preview --message "fix: login race on cold start"

# Once someone on the team confirms it on-device:
eas update --channel production --message "fix: login race on cold start"

Using --channel instead of --branch means the update goes wherever that channel is currently pointed, which is what you actually mean. Check the mapping if in doubt:

eas channel:view production

4. Assuming the user has the update

The default update behaviour:

{
  "expo": {
    "updates": {
      "enabled": true,
      "checkAutomatically": "ON_LOAD",
      "fallbackToCacheTimeout": 0
    }
  }
}

fallbackToCacheTimeout: 0 means: on launch, immediately load the cached bundle, check for an update in the background, download it if there is one, and apply it next time the app launches. Users are always one launch behind.

That's the right default for a consumer app. It's the wrong default when you're fixing something urgent and the user opened the app to hit the bug. Two ways to close the gap.

Option A — prompt and reload:

import * as Updates from 'expo-updates';
import { useEffect } from 'react';
import { Alert } from 'react-native';

export function useUpdatePrompt() {
  useEffect(() => {
    if (__DEV__) return; // expo-updates is a no-op in dev

    (async () => {
      const { isAvailable } = await Updates.checkForUpdateAsync();
      if (!isAvailable) return;

      await Updates.fetchUpdateAsync();
      Alert.alert('Update ready', 'Restart to apply the latest version?', [
        { text: 'Later', style: 'cancel' },
        { text: 'Restart', onPress: () => Updates.reloadAsync() },
      ]);
    })().catch(() => {}); // never let an update check crash the app
  }, []);
}

Option B — apply on foreground:

import * as Updates from 'expo-updates';
import { useEffect } from 'react';
import { AppState } from 'react-native';

export function useApplyUpdateOnForeground() {
  useEffect(() => {
    if (__DEV__) return;

    const sub = AppState.addEventListener('change', async (state) => {
      if (state !== 'active') return;
      const { isAvailable } = await Updates.checkForUpdateAsync().catch(() => ({ isAvailable: false }));
      if (isAvailable) {
        await Updates.fetchUpdateAsync();
        await Updates.reloadAsync(); // hard reload — only do this if the user isn't mid-form
      }
    });
    return () => sub.remove();
  }, []);
}

Option B is aggressive. Reloading while someone's halfway through a checkout is worse than the bug you're fixing. I use A by default and B only behind a "critical" flag in the update's metadata.

Also: __DEV__ early-return matters. expo-updates is disabled in development builds, and checkForUpdateAsync throws. Wrap it or skip it.

5. Not knowing how to roll back

There's no undo. Rollback means publishing a new update whose contents are the old update.

# Find the last known-good update
eas update:list --branch production

# Republish it. This creates a new update with the old bundle.
eas update:republish --branch production --group <update-group-id>

That's it, but the key detail is that you should run update:list before the incident, so you know what a healthy list looks like and can spot the bad group in seconds instead of minutes. I keep the last three good group IDs in a pinned message in the team chat. Low-tech, works.

If the bad update caused a crash loop (mistake #1), rollback won't save the users already affected — their app can't fetch anything. That's why #1 is first.

The config I start every project with

Pulling it together:

// app.json
{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" },
    "updates": {
      "enabled": true,
      "checkAutomatically": "ON_LOAD",
      "fallbackToCacheTimeout": 0,
      "url": "https://u.expo.dev/<project-id>"
    }
  }
}

// eas.json
{
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "channel": "preview", "distribution": "internal" },
    "production": { "channel": "production" }
  }
}

Plus the useUpdatePrompt hook at the root, and a scripts/ota-release.sh that runs the fingerprint compare, refuses to publish if it changed, publishes to preview, and prints the production command for a human to run. That last step being manual is on purpose.

If you'd rather not assemble that from scratch, the RapidNative boilerplate ships with the fingerprint policy, channel config, and update hook already wired — it's the setup above, minus the incidents that taught me each line.

What's your OTA horror story? Drop it in the comments — I'm collecting them, and I'm sure there's a #6 I haven't been burned by yet.

How to Build a Fitness Wearable App with React Native (HealthKit, Health Connect, and BLE)

Mason Roy — Mon, 28 Sep 2026 06:14:14 +0000

TL;DR

A wearable companion app is a phone app that pairs with a device, streams data from it, persists it, and writes it back to Apple Health / Health Connect. It is not a "log your workouts" app.
Stack: Expo SDK 52+, expo-router, react-native-health, react-native-health-connect, react-native-ble-plx, Zustand, expo-sqlite. Don't use bare RN, don't use react-native-google-fit.
Design the six screens first, then wire HealthKit/Health Connect, then BLE, then background persistence.
Standard GATT heart rate is ~40 lines. Reconnect logic and battery are where you'll actually spend your time.
Store on-device first, sync to the cloud opportunistically.

Most "build a fitness app in React Native" tutorials stop at the easy part: a nice UI, a workout list, a chart. The interesting engineering starts once your phone has to talk to a device that isn't the phone — a Whoop, a Garmin, a Polar strap, an Apple Watch. This is the end-to-end version.

What a fitness wearable companion app actually is

It's a phone app whose job is to pair with a physical wearable (watch, chest strap, ring, bike sensor), read health data from it in real time, persist that data, and present it back to the user. Roughly 60–70% of the code is React Native on the phone; the rest is native permissions, Bluetooth adapters, and background delivery bridges to Apple HealthKit and Android Health Connect.

If you've wired a Polar H10 into a running app, or streamed cycling power from an Assioma pedal into a dashboard, that's the shape of app this is about. It's structurally different from a workout logger, and confusing the two is the #1 reason people underestimate the timeline.

The tech stack (and why each piece is non-negotiable)

Layer	Library	Why
Runtime	Expo (SDK 52+), config-plugin workflow	Managed native config, EAS Build
Router	expo-router v4	File-based routing
Health (iOS)	react-native-health	HealthKit read/write, background delivery
Health (Android)	react-native-health-connect	Health Connect (replaced Google Fit in 2025)
BLE	react-native-ble-plx	GATT client for any BLE peripheral
State	Zustand or Redux Toolkit	One store
Charts	victory-native	Skia-backed, doesn't drop frames
Backend (optional)	Supabase	Postgres + Auth + realtime
Auth	expo-auth-session + Sign in with Apple	App Store requirement if you offer any other login

Two things worth stressing. Use Expo, not bare React Native — every library above ships an Expo config plugin now, and the friction that used to justify bare has mostly gone. And Health Connect replaced Google Fit's developer API in 2025. If a tutorial tells you to install react-native-google-fit, close the tab.

Step 1: Design the screens before you write code

The mistake is starting with BLE. BLE is the interesting part, so it will eat every hour you give it, and you'll end up with heart-rate data and no app to put it in.

A minimum-viable companion app has six screens:

Onboarding — permissions (Bluetooth, Location, HealthKit / Health Connect, Notifications)
Device pairing — scan, pair, remember
Live session — real-time HR, elapsed time, distance, power
Session summary — charts, splits, HR zones, calories
History — past sessions with quick stats
Profile & settings — units, connected devices, data export

Scaffold those first. They're boring, and that's the point.

Step 2: Wire up HealthKit and Health Connect

Users expect workouts to show up in Apple Health and Health Connect. Not writing there is a bug report you'll get in week one.

npx expo install react-native-health react-native-health-connect

{
  "expo": {
    "plugins": [
      [
        "react-native-health",
        {
          "isClinicalDataEnabled": false,
          "healthSharePermission": "Allow $(PRODUCT_NAME) to read your workout and heart rate data",
          "healthUpdatePermission": "Allow $(PRODUCT_NAME) to save your workouts"
        }
      ],
      "react-native-health-connect"
    ]
  }
}

Read today's step count on both platforms with one function:

import AppleHealthKit, { HealthValue } from 'react-native-health';
import { readRecords } from 'react-native-health-connect';
import { Platform } from 'react-native';

export async function getTodaySteps(): Promise<number> {
  const start = new Date(new Date().setHours(0, 0, 0, 0));
  const end = new Date();

  if (Platform.OS === 'ios') {
    return new Promise((resolve) => {
      AppleHealthKit.getStepCount(
        { date: end.toISOString() },
        (err, r: HealthValue) => resolve(err ? 0 : r.value),
      );
    });
  }

  const { records } = await readRecords('Steps', {
    timeRangeFilter: { operator: 'between', startTime: start.toISOString(), endTime: end.toISOString() },
  });
  return records.reduce((sum, r) => sum + r.count, 0);
}

What this hides: background delivery on iOS lets HealthKit wake your app when a new sample lands — set it up once at boot and treat it like a push. Android gives you nothing equivalent from Health Connect; you poll on app resume, which is fine for workouts and wrong for continuous monitoring.

Step 3: Talk to a wearable over BLE

This is the real work. Most consumer wearables expose data over BLE using either a standard GATT service (heart rate 0x180D, cycling power 0x1818, running speed and cadence 0x1814) or a vendor protocol you'll reverse-engineer from their SDK docs.

npx expo install react-native-ble-plx

Plugin config (iOS 13+ needs both usage strings; Android 12+ needs BLUETOOTH_SCAN and BLUETOOTH_CONNECT runtime permissions):

[
  "react-native-ble-plx",
  {
    "isBackgroundEnabled": true,
    "modes": ["peripheral", "central"],
    "bluetoothAlwaysPermission": "Allow $(PRODUCT_NAME) to connect to your heart rate monitor"
  }
]

Subscribe to a standard heart-rate monitor — works with any GATT-compliant strap on the market:

import { BleManager, Characteristic } from 'react-native-ble-plx';
import { Buffer } from 'buffer';

const manager = new BleManager();
const HR_SERVICE = '0000180d-0000-1000-8000-00805f9b34fb';
const HR_MEASUREMENT = '00002a37-0000-1000-8000-00805f9b34fb';

export function subscribeToHeartRate(
  deviceId: string,
  onBpm: (bpm: number) => void,
): () => void {
  const sub = manager.monitorCharacteristicForDevice(
    deviceId,
    HR_SERVICE,
    HR_MEASUREMENT,
    (error, characteristic: Characteristic | null) => {
      if (error || !characteristic?.value) return;
      const bytes = Buffer.from(characteristic.value, 'base64');
      const flags = bytes[0];
      const is16Bit = (flags & 0x01) !== 0;
      const bpm = is16Bit ? bytes.readUInt16LE(1) : bytes[1];
      onBpm(bpm);
    },
  );
  return () => sub.remove();
}

Two lessons from shipping BLE apps:

Never scan continuously. Scanning wakes the radio and kills battery on iOS. Scan for pairing only; once you have the device ID, connectToDevice(id) directly next time.
Reconnect is a state machine, not a callback. A worn strap drops every time the user walks out of range or sweats too much. You need an explicit disconnected → reconnecting → connected state that survives foreground/background transitions.

Skip either and your five-star reviews become "app drains my battery" one-stars within a week.

Step 4: Persist, sync, and survive backgrounding

You have a hook streaming BPM. Where does it go? The pattern that works in production is a three-tier store:

In-memory ring buffer — last 60 seconds of raw samples for the live chart. Never persisted.
On-device SQLite (expo-sqlite or WatermelonDB) — the durable copy of every session. Batch writes every second, not per sample.
Cloud (optional) — Supabase or your own Postgres, synced when the network is there.

The on-device layer is non-negotiable. Users run out of cell coverage, and losing a workout to "cloud sync failed" is unforgivable. Store first, sync opportunistically.

For long workouts, enable background modes:

{
  "ios": {
    "infoPlist": {
      "UIBackgroundModes": ["bluetooth-central", "location", "fetch"]
    }
  },
  "android": {
    "permissions": ["FOREGROUND_SERVICE", "FOREGROUND_SERVICE_HEALTH"]
  }
}

On Android 14+, a health-tracking foreground service is required to keep BLE alive with the screen off. Getting this wrong is a Play Store rejection.

Step 5: Ship it

eas build --profile production --platform all
eas submit --platform ios
eas submit --platform android

Two App Store gotchas for health apps:

HealthKit apps need a privacy policy URL in App Store Connect and usage descriptions in Info.plist for every read/write category.
Sign in with Apple is mandatory if you offer any other login. Adding the button takes 30 seconds; a rejection and resubmit takes 3–7 days.

The shortcut: generate the scaffold, write the wearable code

After building a few of these, here's the honest split. The parts that make the app yours — the device protocol, the training-load math, the coaching UX — are maybe 25% of the code. The other 75% is scaffold everyone builds identically: onboarding, permission flows, tab bar, session list, chart cards, settings, auth, a Postgres schema for sessions and samples.

That 75% is what an AI app builder like RapidNative generates from a prompt: describe the six screens and the Supabase data layer once, get an Expo project with expo-router routes, a wired-up store, and RLS policies, then drop the BLE and HealthKit code from this post into it. You still write the interesting code. You just don't rewrite the tab bar again.

Wrapping up

Building a fitness wearable app in React Native isn't hard because tools are missing — it's hard because there are 30 small integrations (permissions, background modes, BLE reconnect, health-store round-trips) and every one has an edge case. Nail the stack, design screens before touching a peripheral, and treat disconnection as a first-class state, and you'll ship in weeks rather than quarters.

What wearable are you building against? Drop a comment — especially if you've fought a vendor BLE protocol that doesn't follow the GATT spec. I'd like to hear which ones are the worst.

I Read Every React Native Support Ticket We Got Last Year. Here’s What I Learned.

Mason Roy — Fri, 25 Sep 2026 10:39:45 +0000

There’s a moment, if you work with developer tooling, when you realize your support inbox is one of the most honest sources of developer feedback.

People don't usually file a support ticket because everything is working perfectly. They file one because a build has been failing for hours, a production release is blocked, or something that worked yesterday suddenly doesn't work after an upgrade.

We looked at a year of React Native support tickets and found recurring problems around builds, dependencies, Expo configuration, Supabase, and production setup.

The interesting part isn't just what breaks. It's where developers lose the most time.

Build and dependency problems

React Native projects sit on top of several layers: JavaScript, React Native, Expo, native iOS and Android projects, and third-party packages.

When those layers get out of sync, errors can become difficult to diagnose.

A package might expect a different React Native version. An Expo SDK upgrade might expose an incompatible native dependency. A clean build can suddenly fail even though the application code hasn't changed.

This is why checking dependency compatibility before adding more packages matters.

Expo build errors

Expo simplifies a lot of React Native development, but build configuration can still become a source of problems.

When a project depends on native modules, configuration has to remain compatible with the Expo SDK and the native projects being generated.

A useful sanity check is to test the project from a clean clone rather than relying only on an existing local environment.

If a fresh environment cannot reproduce the expected build, there may be configuration or dependency problems hiding in the developer's machine.

Supabase and authentication issues

Backend configuration creates another category of problems.

A common example is authentication or database queries returning unexpected results even though the application code appears correct.

With Supabase, Row Level Security policies can affect whether queries return data. Developers may see an empty result and initially assume the query itself is broken when the actual issue is authorization.

Debugging these issues requires checking both the application code and the backend policies.

React Native template problems

A starter project can save significant setup time, but only if it remains maintainable after the initial setup.

A template with outdated dependencies or unnecessary configuration can create more work later.

Before adopting a React Native starter, it's worth checking:

React Native and Expo versions
Native dependency compatibility
Build configuration
Authentication setup
Environment variable handling
Whether the project works from a fresh clone

The number of features in a template isn't necessarily the most important factor.

The real question is whether the project gives you a reliable starting point.

Production problems are different

Something working in development doesn't guarantee that it will work in production.

Production builds introduce additional variables: release configuration, native build settings, environment variables, API configuration, and platform-specific behavior.

That's why reproducing production-like conditions as early as possible can reduce surprises later.

What support tickets reveal

The biggest lesson from support requests is that many React Native problems aren't caused by one complicated piece of code.

They're often caused by interactions between tools and dependencies.

A project can have perfectly reasonable application code and still fail because:

A dependency expects another SDK version
Native configuration is outdated
A backend policy blocks a request
Environment variables aren't available in the build
A starter template contains legacy configuration

Understanding those layers makes debugging much easier.

Final takeaway

React Native development isn't just about writing components.

A large part of the developer experience comes from the tooling around those components: dependency management, native builds, backend configuration, and production environments.

If you're starting a new React Native project, spending a little time validating the foundation can save much more time once development gets serious.

Shipping React Native Updates Without App Store Releases: A Practical Guide to OTA Updates

Mason Roy — Wed, 23 Sep 2026 05:53:16 +0000

Building a React Native app is only half the job.

Once an app is in production, one of the biggest challenges is shipping fixes and improvements quickly without asking users to download a new version from the App Store or Google Play for every small change.

This is where Over-The-Air (OTA) updates become useful.

With OTA updates, JavaScript and other supported application assets can be delivered to users after the app has already been installed. This makes it possible to fix UI issues, update business logic, or release content changes without going through a complete store release process.

This article explains how OTA updates work in Expo/React Native, when to use them, and the important limitations developers should understand before relying on them in production.

What Are OTA Updates?
Why OTA Updates Matter
How OTA Updates Work
OTA Updates With Expo
Basic Setup
Publishing an Update
Checking for Updates
When Updates Are Applied
What OTA Updates Can and Cannot Change
A Practical Production Strategy
Common Mistakes
OTA Updates and RapidNative
Conclusion

What Are OTA Updates?

OTA stands for Over-The-Air.

In a React Native application, a significant part of the application is written in JavaScript or TypeScript. That code is bundled and delivered with the application.

Normally, when you change that code, you create a new application build and submit it to the App Store or Google Play.

With OTA updates, supported JavaScript and asset changes can be distributed separately from the native application binary.

The general flow looks like this:

Developer
   |
   | Build & publish update
   v
Update Server
   |
   | Download
   v
User's React Native App
   |
   | Apply update
   v
New JavaScript Bundle

This can significantly reduce the time between fixing an issue and getting that fix to users.

Why OTA Updates Matter

Imagine you discover a small production bug:

User opens Profile
        ↓
Profile screen crashes
        ↓
Bug is in JavaScript code

Without OTA:

Fix bug
   ↓
Build application
   ↓
Submit to App Store / Play Store
   ↓
Review / rollout
   ↓
User downloads new version

With OTA:

Fix bug
   ↓
Publish OTA update
   ↓
App downloads update
   ↓
User receives the fix

The second workflow can be much faster.

OTA updates are particularly useful for:

JavaScript bug fixes
UI improvements
Business logic changes
Copy/content changes
Configuration changes supported by the application
Small feature improvements

However, OTA updates are not a replacement for native application releases.

How OTA Updates Work

An OTA system generally involves four important components:

┌────────────────────┐
│ Developer           │
│ Changes JS / Assets │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ Update Service      │
│ Stores update       │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ React Native App    │
│ Checks for update   │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ Download + Apply    │
└────────────────────┘

When the installed application starts, it can check whether an update compatible with the current native runtime is available.

If one exists, the application can download it and apply it according to the update strategy you've configured.

The important concept here is compatibility.

An OTA update still has to work with the native code already installed on the user's device.

OTA Updates With Expo

For Expo-based React Native applications, EAS Update provides a managed way to distribute updates.

The basic workflow is:

npx expo install expo-updates

Then configure the project for EAS Update.

You can initialize EAS configuration with:

eas update:configure

You will typically have an eas.json configuration describing your build profiles.

For example:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  }
}

The exact configuration depends on your project's build and release strategy.

Basic Setup

After configuring EAS Update, you can create an update using:

eas update

You can also specify a branch:

eas update --branch production

And provide a message describing the change:

eas update \
  --branch production \
  --message "Fix profile screen rendering issue"

The update is then published to the configured update service.

Publishing an Update

A typical production workflow might look like this:

# Make your changes
git checkout -b fix/profile-rendering

# Test locally
npm start

# Commit your changes
git add .
git commit -m "fix: profile rendering"

# Publish OTA update
eas update --branch production --message "Fix profile rendering"

The important distinction is that eas update publishes an update to the OTA service; it does not create a new App Store or Google Play binary.

Checking for Updates

You can also control update behavior inside your application using expo-updates.

For example:

import * as Updates from 'expo-updates';

async function checkForUpdates() {
  try {
    const update = await Updates.checkForUpdateAsync();

    if (update.isAvailable) {
      await Updates.fetchU