DEV Community: Mason Roy

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

How to Run Supabase Edge Functions Locally Without a Separate Runtime

Mason Roy — Mon, 21 Sep 2026 05:58:20 +0000

Running Supabase Edge Functions Locally with tinbase

Supabase Edge Functions are useful when you need server-side logic without building a separate backend service. But during local development, setting up the complete environment around a project can add friction.

What if you could keep your local backend, database, authentication, and Edge Functions in one lightweight development environment?

This is where tinbase can be useful. It is a Supabase-compatible backend that can run locally and provides support for Edge Functions alongside database, Auth, Storage, Realtime, and Row Level Security.

In this tutorial, we will create a simple Edge Function and invoke it from a JavaScript application.

What We Are Building

The example will have this flow:

Client
   ↓
supabase.functions.invoke()
   ↓
tinbase
   ↓
Edge Function
   ↓
JSON Response

The important part is that the client can continue using the familiar Supabase SDK.

1. Create a Function

A typical Supabase project keeps Edge Functions inside:

supabase/
└── functions/
    └── hello/
        └── index.ts

Create index.ts:

Deno.serve(async () => {
  return new Response(
    JSON.stringify({
      message: "Hello from the Edge Function!",
    }),
    {
      headers: {
        "Content-Type": "application/json",
      },
    },
  );
});

The function simply returns a JSON response.

2. Start tinbase

With tinbase running locally, the backend can load functions from the project's supabase/functions directory.

The goal is to keep the local development environment simple:

npx tinbase start

You now have a local Supabase-compatible backend that can handle the function alongside your other backend services.

3. Invoke the Function

Because tinbase is compatible with the Supabase client API, you can invoke the function using supabase-js.

const { data, error } = await supabase.functions.invoke("hello");

if (error) {
  console.error(error);
} else {
  console.log(data);
}

The application does not need a custom HTTP wrapper just to communicate with the function.

4. Passing Data to a Function

Edge Functions become more useful when they accept input.

For example:

Deno.serve(async (req) => {
  const { name } = await req.json();

  return new Response(
    JSON.stringify({
      message: `Hello, ${name}!`,
    }),
    {
      headers: {
        "Content-Type": "application/json",
      },
    },
  );
});

The client can send data:

const { data, er

Mobile App CI/CD with EAS Build and GitHub Actions

Mason Roy — Mon, 21 Sep 2026 05:11:30 +0000

The first time you ship a React Native app, the code is the easy part. The hard part is everything after git push: signing certificates that expire, provisioning profiles that don't match, a Fastlane script from a two-year-old blog post, a keystore.jks that lives on one laptop, and a build that succeeds locally on macOS but fails on Ubuntu because Xcode isn't there.

React Native CI/CD is the discipline of turning that mess into a repeatable pipeline: every push runs lint and tests, every merge to main reaches users quickly, and every release goes to TestFlight and Google Play with no one touching Xcode. In 2026, one of the cleanest ways to build that pipeline is a combination of two tools: Expo Application Services (EAS) for the native heavy lifting, and GitHub Actions for everything else.

This guide walks through a pipeline you can actually copy: what belongs on each side, how to wire them together, how to handle secrets and code signing without leaking them, and how to add over-the-air (OTA) updates so most releases skip the app stores entirely.

What "mobile app CI/CD" actually means

Mobile app CI/CD is the automated pipeline that takes a React Native or Expo commit and turns it into a signed, distributable build without a human running Xcode or Android Studio. It combines continuous integration (lint, tests, type checks on every push) with continuous delivery (signed builds and store submissions on every release), and adds an OTA update layer so JavaScript-only changes reach users in minutes instead of days.
That paragraph is the whole idea. The rest of the article is about how to implement it without spending your weekend debugging code-signing errors.

There are three moving parts in every serious pipeline:

CI checks: TypeScript, ESLint, unit tests, format checks. These are cheap, fast, and run fine on Linux.
Native builds: compiling .ipa and .aab binaries. These need macOS machines (for iOS), signing keys, and a lot of setup.
Distribution: uploading to TestFlight and Google Play internal testing, and pushing OTA updates.

The mistake most teams make is trying to do all three in the same place. GitHub Actions can compile an iOS build; it will also take 15–20 minutes per attempt on a small macOS runner, drain your included minutes at a 10x multiplier, and force you to manage certificates by hand. EAS was built to do that specific job well. The pragmatic split is: GitHub Actions owns the code, EAS owns the binary.

The split-brain problem, and why it's actually the right answer

Expo supports both approaches: you can drive EAS from any CI service, or use Expo's own EAS Workflows. Running two systems felt wrong to me at first, until I looked at what each is actually good at.

Concern GitHub Actions EAS Build / Workflows
Lint, TypeScript, unit tests Native fit, generous free tier Works, but uses paid CI minutes
iOS .ipa compilation Slow, hand-rolled signing Purpose-built
Android .aab compilation Workable but manual One command
Code signing (iOS certs, Android keystore) Stored in Actions secrets, managed by hand Managed credentials, stored encrypted and shared across the team
OTA updates (EAS Update) Triggered via CLI First-class
PR preview builds Complex eas build --profile preview
Skipping unnecessary native builds DIY Fingerprint + get-build jobs in EAS Workflows
Cost model Cheap for Linux jobs, macOS burns minutes 10x faster Plan fee plus usage-based build pricing

The rule I've settled on: if a step needs Xcode, Ruby, or a keychain, it belongs in EAS. Everything else (the fast feedback loop developers actually feel) belongs in GitHub Actions. That way a broken test blocks a PR in a couple of minutes, and a full native build only runs when it actually needs to.

Show Image Photo by Luca Bravo on Unsplash

Step 1: Set up eas.json with real build profiles

eas.json is the config file EAS reads to decide how to build your app. It lives at the root of your Expo project alongside app.json and package.json. Most tutorials show a single production profile. That's a trap. You need at least three, because dev, QA, and prod are different environments with different API URLs and distribution methods.

Here's a working starting point:

json
{
"cli": {
"version": ">= 16.0.0",
"appVersionSource": "remote"
},
"build": {
"development": {
"developmentClient": true,
"distribution": "internal",
"environment": "development",
"ios": { "simulator": true }
},
"preview": {
"distribution": "internal",
"channel": "preview",
"environment": "preview"
},
"production": {
"channel": "production",
"environment": "production",
"autoIncrement": true
}
},
"submit": {
"production": {
"ios": {
"ascAppId": "1234567890"
},
"android": {
"track": "internal"
}
}
}
}

A few non-obvious decisions in there:

appVersionSource: "remote" delegates the build number to EAS. This is the setting that finally kills the "who bumped the version last?" merge conflict. EAS tracks build numbers server-side, and autoIncrement bumps them on production builds.
channel binds the build to an EAS Update channel. A preview-channel build only receives OTA updates published to the preview channel, so a QA release can't be accidentally overwritten by a main push.
environment tells EAS which set of EAS environment variables (development, preview, or production) to load for the build. Put values like APP_ENV or EXPO_PUBLIC_API_URL there with eas env:create instead of hardcoding them in eas.json, so builds, updates, and local dev all read the same values.
ios.simulator: true on development produces a build that runs in the iOS simulator on any Mac. Great for design review, useless on a physical device or for App Store submission. Add a second development profile without it if your team tests on real phones.
The submit block has no credentials in it. No Apple ID, no path to a Google service account JSON. Those live in EAS (see Step 3), which is what lets submission run non-interactively from CI. A serviceAccountKeyPath pointing at a gitignored file is the most common reason --auto-submit works on a laptop and fails in CI.

Full reference: Configuring EAS Build with eas.json.

Step 2: The GitHub Actions workflow

This is the file that ties everything together. It lives at .github/workflows/ci.yml. The design goal:

Every PR runs lint + tests, then kicks off a preview EAS build.
Every merge to main publishes an OTA update (added in Step 4).
Every version tag (v1.4.0) runs a production EAS build and submits it to the stores.

Store builds are deliberately tied to tags, not to every merge. A native build plus submission on every merge burns build credits, floods TestFlight with near-identical binaries, and is unnecessary when most merges are JavaScript-only.

yaml
name: CI/CD

on:
pull_request:
branches: [main]
push:
branches: [main]
tags: ["v*"]

permissions:
contents: read

concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: ${{ github.event_name == 'pull_request' }}

jobs:
quality:
name: Lint, type-check, test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint
- run: npm run type-check
- run: npm test -- --ci --coverage

preview-build:
name: EAS preview build
needs: quality
# Secrets are not available to PRs from forks, so skip those.
if: >-
github.event_name == 'pull_request' &&
github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: 22
cache: npm
- uses: expo/expo-github-action@v8
with:
eas-version: latest
token: ${{ secrets.EXPO_TOKEN }}
- run: npm ci
- run: eas build --profile preview --platform all --non-interactive --no-wait

production-release:
name: EAS production build + submit
needs: quality
if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v')
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: 22
cache: npm
- uses: expo/expo-github-action@v8
with:
eas-version: latest
token: ${{ secrets.EXPO_TOKEN }}
- run: npm ci
- run: eas build --profile production --platform all --auto-submit --non-interactive --no-wait

Read that carefully. The shape matters more than the details.

quality runs on Ubuntu, not macOS. JS-only jobs have no business on a macOS runner. Standard Linux runners bill at about $0.006/minute versus about $0.062/minute for macOS, and macOS drains your included minutes 10x faster.
--no-wait on both build jobs. The Actions job kicks off the EAS build and returns immediately. EAS runs the build on its own infrastructure, and Actions doesn't sit there burning minutes waiting on a native compile. With --auto-submit, the submission is queued on EAS and runs when the build finishes, so you don't need to wait for it either. The trade-off: the Actions job goes green when the build is queued, not when it succeeds. Watch build status in the EAS dashboard, or drop --no-wait if you want the job to fail when the build fails.
--auto-submit on production. EAS builds the binary, then hands it directly to EAS Submit. It lands in TestFlight and the Google Play internal track on its own. Promoting it from there to public release is still a manual (and deliberate) step in App Store Connect and Play Console.
EXPO_TOKEN authenticates the runner to your Expo account. For a team, create it from a robot user with the minimum role needed rather than using a personal access token. A personal token carries everything your account can do, and it disappears when you leave the team.
npm run type-check assumes you have that script in package.json (typically tsc --noEmit).
--platform all on every PR adds up. The EAS Free plan includes 15 Android and 15 iOS builds per month. See Step 5 for how to avoid building when native code hasn't changed.

Expo's guide on triggering builds from CI goes deeper into edge cases like monorepos and other CI providers.

Step 3: Handling secrets and code signing without losing your mind

Code signing is where mobile CI/CD historically goes to die. iOS wants a distribution certificate, a provisioning profile, and a private key. Android wants a keystore, a key alias, and two passwords.

How bad is losing them? It depends on the platform. iOS certificates and profiles can always be revoked and regenerated from your Apple Developer account. Android is the scary one: if you are not enrolled in Play App Signing and you lose your keystore, you cannot update your existing app. With Play App Signing (the default for new apps), Google holds the app signing key and you can request an upload key reset, which is painful but survivable.

iOS. EAS handles this almost entirely with managed credentials. On your first interactive eas build, it offers to generate and store the certificate and provisioning profile for you. Say yes. They are stored encrypted on EAS servers and are the same for every developer and every CI run. If you have existing credentials (say, from a legacy Fastlane pipeline), you can upload them once with eas credentials.

Two things to know so CI doesn't surprise you:

Distribution certificates expire after a year. EAS does not silently replace them; regenerating requires authenticating with Apple. An expired certificate does not affect apps already on the store, only your ability to make new builds.
Non-interactive runs can't prompt for an Apple ID and 2FA code. Run eas credentials --platform ios once on your machine, create an App Store Connect API key, and choose the option to use it for EAS Submit. That key is what lets --auto-submit work from CI.

Android. EAS can generate a keystore or you can upload your existing one. For submission, EAS needs a Google Service Account key. Upload it to your project's credentials once, either in the EAS dashboard (Credentials → Android → your application identifier → Service Credentials) or with:

bash
eas credentials --platform android

Google Service Account → Upload a Google Service Account Key

Don't commit the JSON, and don't reference it with serviceAccountKeyPath in eas.json if you want CI to work. Also note that Google requires the very first upload of a new app to be done manually in Play Console before API submissions work.

Other secrets. For build-time values like SENTRY_AUTH_TOKEN or NPM_TOKEN, use EAS environment variables. The older eas secret:* commands are deprecated in favor of eas env:*:

bash
eas env:create --name SENTRY_AUTH_TOKEN --value "xxxx" \
--environment production --visibility secret

Variables have three visibility levels: plain text, sensitive, and secret. Secret values are never readable outside EAS servers, not even in the dashboard or CLI.

On the GitHub Actions side, the only secret you need is EXPO_TOKEN. All the app-signing material stays inside EAS, which means:

Signing keys never touch the GitHub runner's disk or environment, so a leaked workflow log can't expose them.
A new developer joining the team gets access via Expo organization membership, not by copying files around.
There is one source of truth for credentials instead of a base64 blob per repo.

One honest caveat: EXPO_TOKEN is still a powerful secret. Anyone who has it can trigger builds and, depending on the role behind it, manage credentials. That's another reason to use a scoped robot user, and to never expose it to workflows triggered by fork PRs.

This is the single biggest reason to keep native builds off GitHub Actions. Managing an Apple distribution certificate inside ${{ secrets.IOS_P12 }} works, until it doesn't, and then you find out on a Friday afternoon.

Show Image Photo by FLY:D on Unsplash

Step 4: Add OTA updates so most releases skip the stores

The best CI/CD pipeline is the one you don't have to run. In a mature React Native app, the large majority of changes are JavaScript-only: a copy tweak, a style fix, a new screen using components that are already in the binary. These don't need a new native build. They just need to reach existing users' phones.

That's what EAS Update is for. Add one job to the workflow:

yaml
ota-update:
name: EAS OTA update
needs: quality
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: 22
cache: npm
- uses: expo/expo-github-action@v8
with:
eas-version: latest
token: ${{ secrets.EXPO_TOKEN }}
- run: npm ci
- name: Publish update
env:
COMMIT_MESSAGE: ${{ github.event.head_commit.message }}
run: >-
eas update --channel production --environment production
--message "$COMMIT_MESSAGE" --non-interactive

Two details in that last step are easy to get wrong:

Pass the commit message through env, never inline. Writing --message "${{ github.event.head_commit.message }}" directly in run: pastes untrusted text into a shell script. A commit message containing a quote or $(...) will break the step at best and execute arbitrary commands with access to your EXPO_TOKEN at worst.
--environment is required on SDK 55 and later. It tells eas update which EAS environment variables to bundle with. On SDK 54 and earlier, omitting it falls back to local .env files.

Now every merge to main publishes an OTA bundle within a few minutes. By default, the app downloads the update in the background on launch and applies it on the following launch, so expect users to see a change one cold start later unless you add your own reload logic with expo-updates.

If pushing every merge straight to production users makes you nervous (it should, a little), point this job at a staging channel instead and promote to production with eas update:republish, or use the rollout percentage options to release gradually.

Two caveats:

Native changes are not OTA-updatable. If you add expo-camera this morning, it needs a new binary. The runtime version protects you here: an update is only delivered to binaries with a matching runtime version. Set "runtimeVersion": { "policy": "fingerprint" } in app.json and the runtime version changes automatically whenever anything affecting the native layer changes, so a JS bundle that expects a missing native module never reaches an old binary. When that happens, cut a new tag to ship a fresh binary.
Fingerprints must be computed consistently. With the fingerprint policy, the hash calculated when you run eas update in GitHub Actions needs to match the one calculated during the EAS build. Lockfile drift or files that exist in one environment but not the other will produce a mismatch, and your update will target a runtime no binary has. If updates aren't arriving, compare fingerprints first (npx @expo/fingerprint fingerprint:generate).

Also remember the store rules: OTA updates are for fixes and incremental improvements, not for changing what your app fundamentally does after review.

Step 5: Cutting build time with fingerprints

The same fingerprint that guards your OTA updates can also save you from running native builds you don't need. The fingerprint hashes the parts of your project that affect the native binary: dependencies, app.json, native folders, config plugins. If the hash matches an existing build, the native side hasn't changed, and a new compile is wasted money.

This is not something plain eas build does for you automatically. It's a pattern you assemble in EAS Workflows from three pre-packaged job types:

fingerprint computes the hash for each platform
get-build looks for an existing build with that hash
build runs only if nothing was found (and optionally repack injects the new JS bundle into the existing binary, so testers still get an installable artifact)
yaml

.eas/workflows/pr-preview.yml

name: PR preview
on:
pull_request:
branches: [main]

jobs:
fingerprint:
type: fingerprint

get_ios_build:
needs: [fingerprint]
type: get-build
params:
fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
profile: preview

build_ios:
needs: [get_ios_build]
if: ${{ !needs.get_ios_build.outputs.build_id }}
type: build
params:
platform: ios
profile: preview

Expo reports cutting its own CI build times by up to 78% with the fingerprint + repack approach. For a JS-only PR, you go from a full native compile to roughly the time it takes to compute a hash and bundle JavaScript.

If you adopt this, move the preview-build job out of GitHub Actions and into an EAS Workflow like the one above, and leave lint and tests where they are. If you'd rather stay entirely in GitHub Actions, check the expo-github-action README for its fingerprint-related sub-actions, which can compare fingerprints on a PR and decide between building and publishing an update.

Where RapidNative fits into all of this

The problem with every tutorial like this one, including this one, is that it assumes you already have a working Expo project. The wiring above is straightforward when you already have eas.json, an EXPO_TOKEN, and a project with sensible module boundaries. It's much less straightforward if you're starting from a boilerplate someone copy-pasted three years ago.

RapidNative generates Expo apps from natural-language prompts, and the export ships with the pieces that make this pipeline possible on day one:

eas.json with development, preview, and production profiles already scaffolded, matching the structure in Step 1.
app.json with the runtime version set to the fingerprint policy, so OTA updates are automatically scoped to compatible binaries.
A monorepo layout (mobile/ for the React Native app, web/ if you generated a web version). In that case, set working-directory: mobile on the workflow steps above.
 A current Expo SDK and TypeScript setup, so you're not starting your pipeline with an SDK upgrade.

The reason this matters: we kept watching teams get a great AI-generated app, then lose two days rebuilding the project's scaffolding into something CI could actually consume. The whole reason RapidNative uses Expo over bare React Native is that Expo is the shortest path from "code exists" to "binary is signed and on TestFlight."

If you're not using RapidNative, none of this pipeline requires it. If you are, you can drop the workflow above into .github/workflows/ci.yml, add an EXPO_TOKEN, run one interactive eas build to set up credentials, and push. You can try RapidNative here.

Show Image Photo by Redd Francisco on Unsplash

FAQ
How much does EAS Build cost compared to GitHub Actions?

As of September 2026, EAS has a Free plan with 15 Android and 15 iOS builds per month, a Starter plan at $19/month that includes $45 of build credit, and a Production plan at $199/month that includes $225 of build credit and two build concurrencies. Beyond the included credit, builds are billed per build based on platform and machine size.

GitHub Actions is free for public repos and includes 2,000 minutes/month for private repos on the Free plan (3,000 on Pro and Team). macOS runners consume those minutes at a 10x multiplier, and overage on standard runners is about $0.006/minute for Linux versus $0.062/minute for macOS.

On raw compute alone, GitHub Actions is often the cheaper option: a 20-minute iOS build on a standard macOS runner is a little over a dollar. What you're paying EAS for is everything around the compile: managed credentials, submission, internal distribution links, OTA hosting, and not maintaining Fastlane and a CI keychain. Price out your own build volume, and count engineer hours honestly when you do.

Can I use GitHub Actions without EAS for React Native?

Yes. You'd need macOS runners with Xcode, a CI-managed keychain, Fastlane (or equivalent) for signing and upload, and a lot of YAML. It's a valid choice for teams with existing native mobile expertise who don't want a vendor dependency. There's also a middle path: eas build --local runs the EAS build process on your own runner. For most React Native teams, especially those already on Expo modules, the maintenance cost of a hand-rolled pipeline ends up exceeding the price of EAS fairly quickly.

Do I need EAS Workflows if I already use GitHub Actions?

EAS Workflows is Expo's own CI/CD product. If your repo is mostly mobile and you want one dashboard, plus pre-packaged jobs like fingerprint, get-build, repack, submit, and Maestro tests, use Workflows. If you have a broader repo (backend services, web app, mobile app) and GitHub Actions is already the source of truth, keep it and use EAS for build, submit, and update. A hybrid (tests in Actions, native jobs in Workflows) works fine too. Note that Workflows jobs consume EAS CI minutes on your plan.

What breaks first when a React Native CI pipeline goes wrong?

In rough order of frequency: expired or mismatched iOS provisioning profiles, Android keystore password confusion after a team member leaves, EXPO_TOKEN belonging to the wrong account or a user who left, submission failing in CI because Apple or Google credentials only existed on someone's laptop, and native module additions reaching users over OTA because the runtime version was pinned by hand instead of fingerprinted. Managed credentials in EAS take most of the pain out of the first two; the rest are process problems solved by a robot user, credentials stored in EAS, and the fingerprint policy.

The point of all this

A mobile CI/CD pipeline is a boring, un-fun piece of infrastructure that has an outsized effect on how fast you can ship. When it works, no one notices. When it doesn't, every release is a two-day fire drill and your team stops shipping between store submissions.

The pipeline in this article is deliberately not the most sophisticated one possible. There's no matrix build across Node versions, no Slack-notified rollout gates, no per-branch environment promotion. Those are worth adding later, but only after the core loop (push → tested → signed → shipped) runs on its own.

If you're building the pipeline from scratch, start with the eas.json in Step 1 and the workflow in Step 2. If you're building it into an existing project, budget a day for the first successful production build and submission (mostly iOS signing and store credentials) and another day for the OTA update wiring.

Either way, the goal is the same: a git push that ends with your users getting the new version, and nobody touching Xcode along the way.

DEV Community: Mason Roy

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

What the New Architecture actually is

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

Why the legacy bridge had to die

Fabric: what changes in rendering

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

Bridgeless: the mode that doesn't instantiate the bridge

What's locked in from 0.76 → 0.82 → beyond

What migrating actually feels like (the honest version)

What the New Architecture means for performance (realistically)

What this means for AI code generation

What developers should actually do in 2026

FAQ

Is the React Native New Architecture backwards-compatible?

Do I need to rewrite my app to use Fabric?

Is bridgeless mode the same as the New Architecture?

Will Hermes still work with the New Architecture?

Does Expo support the New Architecture?

Build on the New Architecture without thinking about it

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

What You Need to Build Video Calling in React Native

WebRTC vs Managed SDKs: The Choice That Shapes Everything

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

Setting Up React Native WebRTC

Capturing the Local Camera Stream

Building the Peer Connection

The Signaling Server

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

Rendering the Remote Stream

Call Controls: Mute, Switch Camera, Hang Up

What Breaks in Production (and How to Debug It)

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

Shipping the Rest of the App

Frequently Asked Questions

Does React Native WebRTC work with Expo Go?

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

What is the difference between STUN and TURN in WebRTC?

Build the Rest of Your App in Minutes

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

1. The 401 refresh storm

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

3. The ghost session after reinstall

4. The login-screen flash

The checklist I run before shipping auth

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

The problem isn't React Native

1. Custom buttons with no label or role

2. Tiny touch targets

3. Form errors that are only red text

4. Modals that don't trap focus

5. Text on gradients

Stop new violations at the PR

Retrofit vs. restart

The 20-minute test

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

1. The table you forgot to enable RLS on

2. update with using but no with check

3. Authorization from raw_user_meta_data

4. to public when you meant to authenticated

5. The view that bypasses everything

6. auth.uid() without the select

Putting it in CI

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

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

2. Shipping native changes over the air

3. Publishing to the wrong channel

4. Assuming the user has the update

5. Not knowing how to roll back

The config I start every project with

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

What a fitness wearable companion app actually is

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

Step 1: Design the screens before you write code

Step 2: Wire up HealthKit and Health Connect

Step 3: Talk to a wearable over BLE

Step 4: Persist, sync, and survive backgrounding

Step 5: Ship it

The shortcut: generate the scaffold, write the wearable code

Wrapping up

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

3. Authorization from `raw_user_meta_data`

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

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