DEV Community: Famitha M A

Design Your Expo Router Tree Before You Write a Single Screen

Famitha M A — Thu, 01 Oct 2026 05:46:06 +0000

Most Expo Router tutorials start with npx create-expo-app and a single index.tsx. That's fine for screen one. By screen thirty, the same project usually has three index.tsx files nobody can tell apart, a modal that remounts the whole tab bar, and a components/ folder that accidentally became a set of routes.

None of that is a code problem. It's a planning problem.

With file-based routing, the folder tree is the navigation design. Every folder you create is a decision about URLs, layouts, and what gets remounted when a user moves around. This post is a planning-first workflow: sketch the route tree as a sitemap, review it like a design artifact, and only then create files.

In Expo Router, mkdir is a product decision. Make it on paper first.

Why the tree deserves a design pass

Property	What it means for planning
Every file in the routes directory is a route	Helper files placed there become screens (or break the build)
`_layout.tsx` files wrap everything below them	Folder depth decides which navigator, header, and providers a screen inherits
Route groups `(name)` organize without adding URL segments	You can restructure layouts without changing deep links, if you plan for it

Moving a screen between folders can change its URL, its parent navigator, and its remount behavior in one move. That's a change you want to make on a whiteboard, not in a refactor PR.

Newer Expo templates place routes under src/app/ instead of app/. The rules are identical. Examples use app/ for brevity.

Step 1: Write the sitemap as URLs, not screens

List every destination as a URL a deep link could point at. Running example: a habit-tracking app.

/                     -> home feed (today's habits)
/habits               -> all habits
/habits/:id           -> habit detail
/habits/:id/edit      -> edit habit (modal)
/habits/new           -> create habit (modal)
/stats                -> weekly stats
/settings             -> settings
/settings/account     -> account details
/sign-in              -> sign in
/onboarding           -> first-run flow

Three questions to answer now:

Which must be deep-linkable? A push notification or email link will point at /habits/:id, so that URL must stay stable.
Which are modals? new and edit present over the current context, not inside the tab navigator's stack.
Which are gated? sign-in and onboarding are only reachable in certain states.

If a screen can't be expressed as a URL, it's probably a component, a sheet, or a step inside another screen.

Step 2: Group by navigator, not by feature

The common mistake: grouping top-level folders by feature (habits/, stats/, settings/) and bolting a tab bar on top. Group by which navigator owns the screen.

app/
├── _layout.tsx              # Root Stack: owns modals + gating
├── +not-found.tsx
├── sign-in.tsx
├── onboarding.tsx
├── (tabs)/
│   ├── _layout.tsx          # Tabs navigator
│   ├── index.tsx            # /
│   ├── stats.tsx            # /stats
│   ├── habits/
│   │   ├── _layout.tsx      # Stack inside the Habits tab
│   │   ├── index.tsx        # /habits
│   │   └── [id].tsx         # /habits/:id
│   └── settings/
│       ├── _layout.tsx
│       ├── index.tsx        # /settings
│       └── account.tsx      # /settings/account
└── habits/
    ├── new.tsx              # /habits/new  (modal, root stack)
    └── [id]/
        └── edit.tsx         # /habits/:id/edit (modal, root stack)

The (tabs) group adds no URL segment, so /stats stays /stats. The modals live outside the tabs group as root-stack siblings, so they present over the tab bar.

/habits and /habits/new share a URL prefix but live in different folders. URLs describe destinations; folders describe navigator ownership. Keep those separate and most "why does this screen look wrong" bugs disappear.

Step 3: Decide what each layout owns

One line per _layout.tsx before you write any. If you need two lines, you need two layouts.

Layout	Owns
`app/_layout.tsx`	Providers, fonts, auth gating, modal presentation
`app/(tabs)/_layout.tsx`	Tab bar, tab icons, badge counts
`app/(tabs)/habits/_layout.tsx`	Header styling for the habits stack
`app/(tabs)/settings/_layout.tsx`	Header styling for settings

The matching root layout, with modals and protected routes:

// app/_layout.tsx
import { Stack } from 'expo-router';
import { useSession } from '@/lib/session';export default function RootLayout() {
  const { isSignedIn, hasOnboarded } = useSession();

  return (
    <Stack screenOptions={{ headerShown: false }}>
      <Stack.Protected guard={!isSignedIn}>
        <Stack.Screen name="sign-in" />
      </Stack.Protected>

      <Stack.Protected guard={isSignedIn && !hasOnboarded}>
        <Stack.Screen name="onboarding" />
      </Stack.Protected>

      <Stack.Protected guard={isSignedIn && hasOnboarded}>
        <Stack.Screen name="(tabs)" />
        <Stack.Screen name="habits/new" options={{ presentation: 'modal' }} />
        <Stack.Screen name="habits/[id]/edit" options={{ presentation: 'modal' }} />
      </Stack.Protected>
    </Stack>
  );
}

Gating lives in one place. No redirect logic sprinkled across screens.
A screen belongs to one active group at a time. If you want the same screen in two guarded blocks, the sitemap needs another URL, not a clever workaround.

Step 4: Plan dynamic segments and their params

Params arrive as strings (or string arrays). Decide their shape up front and validate at the boundary.

// app/(tabs)/habits/[id].tsx
import { useLocalSearchParams, Redirect } from 'expo-router';
import { HabitDetail } from '@/features/habits/HabitDetail';export default function HabitScreen() {
  const { id } = useLocalSearchParams<{ id: string }>();

  // Deep links can carry anything. Validate before you fetch.
  if (!id || !/^[a-z0-9-]+$/i.test(id)) {
    return <Redirect href="/habits" />;
  }

  return <HabitDetail habitId={id} />;
}

The route file is thin: read the param, validate, hand off to a feature component. That keeps the routes directory a map and nothing more.

When you're planning the screens themselves, this is a good time to prototype. RapidNative turns a prompt, sketch, or PRD into React Native and Expo screens, so you can paste your Step 1 sitemap in as context and get UI scaffolded around the structure you already decided on.

Step 5: Keep non-routes out of the routes directory

The routes directory holds screens, layouts, and special files like +not-found.tsx. Nothing else.

app/                # routes only
features/
  habits/
    HabitDetail.tsx
    HabitCard.tsx
    useHabit.ts
  stats/
components/         # shared UI primitives
lib/                # session, api client, storage

No accidental routes. A HabitCard.tsx in app/(tabs)/habits/ becomes a navigable screen.
Cheap restructures. Moving habits out of tabs means moving a few thin route files; feature code stays put.
Readable reviews. A diff in app/ is a navigation change. A diff in features/ is UI or logic.

Step 6: Review the tree before you commit

Check	Question to ask
Index ambiguity	Multiple `index.tsx` files? Is each obviously tied to its folder?
Modal placement	Are all modals root-stack siblings, not nested in a tab?
Remount risk	If this screen moves groups later, does its layout ancestry change and remount state?
Deep link stability	Are the URLs a notification or email points at unlikely to change?
Gating	Is every protected screen covered by exactly one guard in one layout?
Not found	Is there a `+not-found.tsx` so broken links land somewhere useful?

Then turn on typed routes so the compiler enforces the tree. A typo in an href becomes a type error instead of a blank screen in production. Check the Expo docs for your SDK version to see whether it's on by default or needs a config flag.

import { Link } from 'expo-router';

// Typed: autocompletes valid paths, flags invalid ones.
<Link href={{ pathname: '/habits/[id]', params: { id: habit.id } }}>
  {habit.name}
</Link>

Step 7: Test deep links against the sitemap

Your Step 1 list doubles as a test plan. Open every URL on a device or simulator and confirm the right screen and navigator appear:

# iOS simulator
npx uri-scheme open "myapp://habits/abc-123" --ios

# Android emulator
npx uri-scheme open "myapp://habits/abc-123/edit" --android

Watch for two things: modals presenting as modals when opened cold from a link, and gated URLs redirecting cleanly when signed out.

Once the tree is stable, the last hurdle is store review. If you'd rather not wrangle signing, listings, and submission yourself, RapidNative Deploy handles the App Store and Play Store submission side.

A planning template you can copy

Paste into your PRD or README before creating the routes directory:

## Route plan

### Sitemap (URLs)
- / :
- /... :

### Navigators
- Root stack owns: (modals, gating, providers)
- Tabs: (list tabs)
- Nested stacks: (which tabs have their own stack)

### Modals (root stack siblings)
-

### Gated groups
- Signed out:
- Signed in, not onboarded:
- Signed in:

### Deep links that must stay stable
-

If your team works from a PRD, hand this section to an AI builder too. In RapidNative, including the route plan next to the feature description gives generated screens a structure to fit into.

Wrapping up

Write the sitemap as URLs.
Group folders by navigator, not by feature.
Give every layout one job.
Keep route files thin and validate params at the boundary.
Keep non-route code out of the routes directory.
Review the tree like a design artifact, then lock it in with typed routes.
Test every URL in the sitemap as a deep link.

What does your route tree look like at screen thirty? Share the structure in the comments.

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

Famitha M A — Mon, 28 Sep 2026 14:33:32 +0000

TL;DR

Use Expo with a dev build. Every lib you need ships a config plugin.
iOS health data: react-native-health. Android: react-native-health-connect (Google Fit's APIs are deprecated).
BLE: react-native-ble-plx. Standard heart-rate straps speak GATT service 0x180D.
Never scan continuously, and model reconnect as a state machine.
Store sessions on-device first (SQLite), sync to the cloud later.
Android 14+ needs a health foreground service to keep BLE alive with the screen off.

Most "fitness app in React Native" tutorials stop at a workout list and a chart. The fun (and painful) part starts when your phone has to talk to a device that isn't the phone. Here's how I'd build a real wearable companion app, in order.

The stack

Layer	Library
Runtime	Expo (recent SDK) + config plugins
Router	expo-router
Health (iOS)	react-native-health
Health (Android)	react-native-health-connect
BLE	react-native-ble-plx
State	Zustand or Redux Toolkit
Charts	victory-native (Skia)
Backend	Supabase (optional)
Auth	expo-auth-session + Sign in with Apple

Hot take: bare React Native isn't worth it here anymore. Heads up though, HealthKit and BLE won't run in Expo Go, so you need a development build:

npx expo install expo-dev-client
eas build --profile development --platform all

If a tutorial tells you to install react-native-google-fit, close the tab.

Step 1: Build the screens before the Bluetooth

Don't start with BLE. It's the interesting part, so it eats every hour you give it, and you end up with heart-rate data and no app to put it in.

Six screens get you to an MVP:

app/
├── (onboarding)/permissions.tsx   # Bluetooth, Location, Health, Notifications
├── (tabs)/
│   ├── index.tsx                  # History
│   ├── pair.tsx                   # Scan, pair, remember device
│   └── settings.tsx               # Units, devices, export
├── session/live.tsx               # Live HR, time, distance, power
└── session/[id].tsx               # Summary: charts, splits, HR zones

You can hand-roll all of that, or generate the scaffold with RapidNative (screens, expo-router tree, Zustand store, Supabase data layer) and spend your time on the wearable protocol instead of another tab bar.

A minimal store to hang everything off:

import { create } from 'zustand';

type ConnState = 'disconnected' | 'reconnecting' | 'connected';

type SessionStore = {
  deviceId: string | null;
  conn: ConnState;
  bpm: number | null;
  setDevice: (id: string) => void;
  setConn: (s: ConnState) => void;
  setBpm: (bpm: number) => void;
};

export const useSession = create<SessionStore>((set) => ({
  deviceId: null,
  conn: 'disconnected',
  bpm: null,
  setDevice: (deviceId) => set({ deviceId }),
  setConn: (conn) => set({ conn }),
  setBpm: (bpm) => set({ bpm }),
}));

Step 2: HealthKit + Health Connect

Users expect workouts to land in Apple Health and Health Connect. Skip it and you'll get the bug report fast.

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"
    ]
  }
}

One hook, both platforms:

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

// Assumes initHealthKit() / initialize() + requestPermission() ran at boot.
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);
}

Gotcha: iOS has background delivery (HealthKit wakes your app on new samples). Health Connect doesn't, so on Android you poll on resume. Fine for workouts, wrong for continuous monitoring.

Step 3: Talk BLE to the wearable

Standard GATT services cover a lot: heart rate 0x180D, cycling power 0x1818, running speed and cadence 0x1814. Anything else means the vendor's SDK docs.

npx expo install react-native-ble-plx

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

Android 12+ also needs BLUETOOTH_SCAN and BLUETOOTH_CONNECT at runtime.

Heart-rate subscription that works with any GATT-compliant strap:

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

export 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 is16Bit = (bytes[0] & 0x01) !== 0;
      onBpm(is16Bit ? bytes.readUInt16LE(1) : bytes[1]);
    },
  );
  return () => sub.remove();
}

Two rules that save your ratings:

Never scan continuously. Scan to pair, save the ID, then connect directly next time.
Reconnect is a state machine. Straps drop when users walk away, sweat, or move the phone.

Here's a simple reconnect loop wired to the store:

import { manager, subscribeToHeartRate } from './ble';
import { useSession } from './store';

export async function connectWithRetry(id: string, attempt = 0): Promise<void> {
  const { setConn, setBpm } = useSession.getState();
  setConn(attempt === 0 ? 'disconnected' : 'reconnecting');
  try {
    const device = await manager.connectToDevice(id, { autoConnect: true });
    await device.discoverAllServicesAndCharacteristics();
    setConn('connected');
    const unsub = subscribeToHeartRate(id, setBpm);
    device.onDisconnected(() => {
      unsub();
      connectWithRetry(id, 1);
    });
  } catch {
    const delay = Math.min(30_000, 1_000 * 2 ** attempt);
    setTimeout(() => connectWithRetry(id, attempt + 1), delay);
  }
}

Step 4: Persist first, sync later

Three tiers:

In-memory ring buffer: last 60s of samples for the live chart.
SQLite (expo-sqlite or WatermelonDB): durable session data, batched writes every second.
Cloud (optional): Supabase, synced when online.

A tiny batching writer:

import * as SQLite from 'expo-sqlite';

const db = SQLite.openDatabaseSync('fitness.db');
db.execSync(`CREATE TABLE IF NOT EXISTS samples (
  session_id TEXT, ts INTEGER, bpm INTEGER
);`);

let queue: { sessionId: string; ts: number; bpm: number }[] = [];

export function pushSample(sessionId: string, bpm: number) {
  queue.push({ sessionId, ts: Date.now(), bpm });
}

setInterval(() => {
  if (!queue.length) return;
  const batch = queue;
  queue = [];
  db.withTransactionSync(() => {
    for (const s of batch) {
      db.runSync('INSERT INTO samples VALUES (?, ?, ?)', s.sessionId, s.ts, s.bpm);
    }
  });
}, 1000);

Background modes for long workouts:

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

On Android 14+, no health foreground service means BLE dies when the screen turns off, and you risk a Play Store rejection.

Step 5: Ship

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

App Store traps for health apps:

HealthKit apps need a privacy policy URL and a usage string for every read/write category.
Sign in with Apple is required if you offer third-party logins like Google.

Wrapping up

The UI isn't the hard part. The hard part is the pile of small integrations (permissions, background modes, BLE reconnect, health-store sync), each with its own edge case. Lock the stack, build screens first, treat disconnects as a real state, and store locally before you sync.

What wearable are you building for? Drop a comment with your device and stack, especially if you've fought a vendor-specific BLE protocol. 👇

React Native Maps: Build Location Features That Actually Work in Production

Famitha M A — Wed, 23 Sep 2026 08:49:14 +0000

TL;DR

Pick react-native-maps over expo-maps for most apps in 2026. The ecosystem (docs, answers, LLM snippets) is the real advantage.
A blank map is almost always an unsized parent view or an API key missing from the release build.
Request location permission on user action, never on launch. Apple rejects the splash-screen prompt.
Always call remove() on watchPositionAsync subscriptions, or you leak GPS listeners and drain battery.
Above a few hundred markers, cluster. Custom <Marker> children are the #1 cause of slow maps.

Adding a map to a React Native app looks easy until you ship it. Then you meet API keys that only fail in release builds, permission prompts that fail review, and marker lists that turn your framerate into a slideshow. Here's how react-native-maps actually behaves in production.

What react-native-maps actually is

It's a cross-platform library that renders native map views: Google Maps on Android, and Apple Maps or Google Maps on iOS. You get a declarative MapView plus Marker, Polyline, Polygon, and Circle. Gestures, tiles, and rendering all run natively, not in JS.

Why it's the default: it works in Expo Go, it was originally built at Airbnb, and it has years of production mileage behind it.

react-native-maps vs expo-maps

Expo shipped expo-maps, built on SwiftUI and Jetpack Compose. The honest comparison:

Concern	react-native-maps	expo-maps
Providers	Google + Apple (both on iOS)	Apple on iOS, Google on Android
Expo Go	Yes	No (dev client / EAS build)
Setup	Config plugin + API keys	Config plugin, cleaner defaults
Community	Huge, years of answers	Small, growing
iOS target	Older versions supported	Newer iOS versions
Native feel	Good	Excellent
Many markers	Needs clustering	Similar limits

My take: start with react-native-maps unless you need the newest platform look. When you hit a weird bug at 11pm before release, the ecosystem matters more than anything else in this table.

Setup with Expo

npx expo install react-native-maps expo-location

Keys come from the Google Maps Platform and go in app.json:

{
  "expo": {
    "ios": {
      "config": { "googleMapsApiKey": "YOUR_IOS_KEY" },
      "infoPlist": {
        "NSLocationWhenInUseUsageDescription": "We show nearby places on a map.",
        "NSLocationAlwaysAndWhenInUseUsageDescription": "We sync your route in the background so you can see the full trip."
      }
    },
    "android": {
      "config": { "googleMaps": { "apiKey": "YOUR_ANDROID_KEY" } },
      "permissions": ["ACCESS_FINE_LOCATION", "ACCESS_COARSE_LOCATION"]
    }
  }
}

Gotchas, in the order they'll bite you:

Restrict keys per platform. iOS by bundle ID, Android by SHA-1. Unrestricted keys are an abuse risk once you're live.
Blank map in TestFlight but fine in dev? The key isn't wired into the release build. Rebuild after any app.json change.
Every NSLocation* string must explain why in user language. "We need your location" gets rejected.

Rendering a map and markers

import MapView, { Marker, PROVIDER_GOOGLE } from 'react-native-maps';
import { StyleSheet, View } from 'react-native';

export default function LocationScreen() {
  return (
    <View style={{ flex: 1 }}>
      <MapView
        provider={PROVIDER_GOOGLE}
        style={StyleSheet.absoluteFill}
        initialRegion={{
          latitude: 37.78825,
          longitude: -122.4324,
          latitudeDelta: 0.0922,
          longitudeDelta: 0.0421,
        }}
      >
        <Marker
          coordinate={{ latitude: 37.78825, longitude: -122.4324 }}
          title="Union Square"
          description="Downtown San Francisco"
        />
      </MapView>
    </View>
  );
}

Things that trip up first builds:

initialRegion vs region. Use initialRegion for maps users pan freely. region re-centers on every render and fights gestures.
Deltas set zoom, not radius. Roughly 0.01 = city block, 0.1 = neighborhood, 1.0 = metro. There's no zoom prop.
PROVIDER_GOOGLE forces Google tiles on iOS. Omit it to fall back to Apple Maps.
Unsized parent = zero-height map. This is the #1 "my map is blank" bug.

Location permissions without getting rejected

import * as Location from 'expo-location';

async function getCurrentPosition() {
  const { status } = await Location.requestForegroundPermissionsAsync();
  if (status !== 'granted') {
    return null; // Show a soft explainer, not a hard error.
  }

  const location = await Location.getCurrentPositionAsync({
    accuracy: Location.Accuracy.Balanced,
  });

  return location.coords;
}

Three rules:

Never request on launch. Trigger it from a "Show my location" button or a screen that visibly needs it.
Foreground before background. iOS enforces the order.
Accuracy.Balanced is the right default. BestForNavigation is for driving/running apps and eats battery.

Live tracking, with the cleanup everyone forgets:

import { useEffect, useState } from 'react';
import * as Location from 'expo-location';

export function useLivePosition() {
  const [position, setPosition] = useState<Location.LocationObjectCoords | null>(null);

  useEffect(() => {
    let subscription: Location.LocationSubscription | undefined;
    (async () => {
      subscription = await Location.watchPositionAsync(
        { accuracy: Location.Accuracy.Balanced, timeInterval: 3000, distanceInterval: 5 },
        (location) => setPosition(location.coords),
      );
    })();
    return () => subscription?.remove(); // skip this and you leak GPS listeners
  }, []);

  return position;
}

Routes, polylines, and geofences

import { Polyline, Circle } from 'react-native-maps';

<Polyline
  coordinates={route} // array of { latitude, longitude }
  strokeColor="#2563eb"
  strokeWidth={4}
/>

<Circle
  center={{ latitude, longitude }}
  radius={500} // meters
  fillColor="rgba(37, 99, 235, 0.15)"
  strokeColor="#2563eb"
/>

react-native-maps doesn't compute routes. Call the Google Directions API or Apple MapKit Directions and feed the coordinates into a Polyline. react-native-maps-directions wraps the Google call, but check Google's billing before you scale.

Geofencing lives in expo-location's startGeofencingAsync. It uses OS-level geofence APIs and keeps working when the app is backgrounded.

Marker clustering: the performance cliff

Every Marker is a native view. A hundred is fine. A few hundred gets choppy on mid-range Android. Thousands can crash with out-of-memory errors.

Options, most pragmatic first:

react-native-map-clustering: drop-in MapView replacement using supercluster.
Server-side clustering: for very large datasets, cluster on the backend and send only the visible viewport.
Bitmap markers: an image prop pointing to a PNG is much cheaper than a custom React child.

If you do need custom children, memoize them:

import React, { memo } from 'react';
import { View, Text } from 'react-native';
import { Marker } from 'react-native-maps';

const PriceMarker = memo(function PriceMarker({
  coordinate,
  price,
}: {
  coordinate: { latitude: number; longitude: number };
  price: string;
}) {
  return (
    <Marker coordinate={coordinate} tracksViewChanges={false}>
      <View style={{ backgroundColor: '#2563eb', padding: 4, borderRadius: 6 }}>
        <Text style={{ color: 'white', fontWeight: '600' }}>{price}</Text>
      </View>
    </Marker>
  );
});

A slow map is almost always a re-rendering-markers problem, not a tile problem. And test on a mid-range Android device, not your flagship iPhone.

Skipping the boilerplate

Wiring MapView, markers, permissions, routes, and the "location denied" state is a few hundred lines and half a day of "why is my map blank." It barely changes between a delivery app, a fitness app, and a real-estate app.

That's the kind of scaffold AI builders handle well. If you describe "a food delivery app where couriers see nearby orders on a map" to RapidNative, it generates an Expo project with react-native-maps, expo-location permission strings, and a marker list bound to a data model. It's real React Native code you can export and edit by hand, so you spend your time on the parts that differentiate your app.

FAQ

Why is my map blank? Check in order: parent view has no height, API key not in the release build, key restricted to the wrong bundle ID, config plugin missing in app.json.

Is react-native-maps free? The library is MIT licensed. Google Maps usage is billed through the Google Maps Platform beyond its free usage allowance. Apple Maps on iOS has no usage fee.

Does it work in Expo Go? Yes. expo-maps needs a custom dev client.

Background tracking? NSLocationAlwaysAndWhenInUseUsageDescription + UIBackgroundModes: location on iOS, ACCESS_BACKGROUND_LOCATION on Android, then startLocationUpdatesAsync with a registered task. Foreground permission first, and be ready to justify it in review.

Your turn

What's the worst map bug you've shipped? Blank TestFlight map, marker slideshow, or something weirder? Drop it in the comments, along with what you're building.

6 Expo Router file-structure mistakes I keep finding in code reviews

Famitha M A — Wed, 23 Sep 2026 07:59:15 +0000

TL;DR

In Expo Router, the app/ folder is your navigation config. Every file you drop in there is a decision.
Most routing bugs I see aren't logic bugs. They're files in the wrong place.
Six mistakes below, each with a before/after tree or snippet.
Run your own project against the checklist at the end before you ship.

Why file structure is where routing breaks

With React Navigation you wrote a navigator config in code. With Expo Router you write it with folders. That's great until someone (you, a teammate, or an AI tool) drops a helper file into app/, or adds a second index.tsx inside a group, and the tree quietly says something different from what you meant.

Here's what I look for first.

1. Non-route files living inside `app/`

Every file in app/ is treated as a route. Put your Button.tsx or useCart.ts in there and Expo Router will try to render it as a screen and warn about a missing default export.

# Before
app/
  _layout.tsx
  index.tsx
  Button.tsx        <- becomes a route
  useCart.ts        <- becomes a route

# After
app/
  _layout.tsx
  index.tsx
components/
  Button.tsx
hooks/
  useCart.ts

Rule of thumb: app/ holds screens and layouts. Nothing else.

2. Two files resolving to the same URL

Route groups (folders in parentheses) don't appear in the URL. So these two files both claim /:

app/
  index.tsx          -> /
  (tabs)/
    index.tsx        -> also /

You get a conflict, and whichever screen wins, it's probably not the one you wanted as your entry point. Pick one owner for /:

app/
  _layout.tsx
  (tabs)/
    _layout.tsx
    index.tsx        -> /
    settings.tsx     -> /settings

If you need a splash or redirect at the root, do it in the root _layout.tsx, not with a competing index.tsx.

3. Deep links that land with no back button

A user taps a link to /product/42. The product screen opens, but there's nothing under it in the stack, so the back button does nothing. That's because the stack was never told what its first screen is.

// app/(shop)/_layout.tsx
import { Stack } from 'expo-router';

export const unstable_settings = {
  // Recent templates call this `anchor`. Check the docs for your SDK version.
  initialRouteName: 'index',
};

export default function ShopLayout() {
  return <Stack />;
}

Now a deep link into /product/42 renders the shop index underneath, and back behaves like users expect.

4. Treating dynamic params as always-a-string

[id].tsx gives you a param, but untyped params can be string | string[]. The classic bug is passing it straight to a fetch and getting 42,43 in your URL from a catch-all or a repeated query key.

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

export default function ProductScreen() {
  const { id } = useLocalSearchParams<{ id: string }>();

  if (!id || Array.isArray(id)) {
    return null; // or render a not-found state
  }

  return <ProductDetail id={id} />;
}

Two habits that save time here:

Prefer useLocalSearchParams inside stacks. useGlobalSearchParams re-renders on every route change in the app, which you rarely want.
Navigate with the object form so params are explicit:

import { router } from 'expo-router';

router.push({ pathname: '/product/[id]', params: { id: product.id } });

5. Modals declared deep in the tree

A modal defined inside a tab's stack only presents over that tab. Want it available from anywhere? Declare it once, at the root.

// app/_layout.tsx
import { Stack } from 'expo-router';

export default function RootLayout() {
  return (
    <Stack>
      <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
      <Stack.Screen name="compose" options={{ presentation: 'modal' }} />
    </Stack>
  );
}

app/
  _layout.tsx
  compose.tsx        <- modal, reachable from any tab
  (tabs)/
    _layout.tsx
    index.tsx

Also: declare each screen once. Listing the same screen in two places in a layout is not allowed, so if its availability depends on state, wrap it conditionally instead of duplicating it.

6. No `+not-found.tsx` and no typed routes

Two small files that catch a whole class of bugs.

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

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

Then turn on typed routes so a typo in href fails at compile time instead of in production:

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

After the next npx expo start, <Link href="/prodcut/42" /> becomes a TypeScript error.

Generated trees need the same review

These mistakes show up the same way whether the tree was hand-written or scaffolded. If you're generating Expo screens from a prompt or a screenshot with something like RapidNative, the output is real code you own, so run it through the same checklist before you build on top of it. It takes five minutes and saves a week of "why does back do nothing".

The checklist

[ ] app/ contains only screens, layouts, and special files (+not-found, +html)
[ ] Exactly one file resolves to each URL (check groups!)
[ ] Every nested stack sets an initial route for deep links
[ ] Dynamic params are typed and guarded against arrays
[ ] Global modals live in the root layout; each screen declared once
[ ] +not-found.tsx exists and typedRoutes is on

What's the weirdest Expo Router bug you've traced back to a file in the wrong folder? Drop it in the comments, I'm collecting them.

Mobile App CI/CD with EAS Build and GitHub Actions (the split that actually works)

Famitha M A — Mon, 21 Sep 2026 07:30:56 +0000

TL;DR

Run lint/tests/type checks on GitHub Actions (Ubuntu, cheap, fast)
Run native builds and code signing on EAS (purpose-built, managed credentials)
The rule: if a step needs Xcode, Ruby, or a keychain, it belongs in EAS
Add EAS Update so JS-only changes ship OTA in ~90 seconds, no store review
Fingerprint runtime policy auto-detects when a native rebuild is actually needed

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.

Here's the pipeline that fixed it for me: every push runs checks, every merge to main produces a signed build, every release lands on TestFlight and Google Play without anyone opening Xcode.

Why two CI systems (yes, really)

The Expo team openly recommends using both GitHub Actions and EAS. Felt wrong at first. Then I looked at what each is good at:

Concern	GitHub Actions	EAS
Lint, TS, unit tests	Native fit, generous free tier	Overkill
iOS `.ipa` compile	Slow, expensive, hand-rolled signing	Purpose-built, fingerprint caching
Android `.aab` compile	Workable but manual	One command
Code signing	Secrets you rotate manually	Managed, auto-rotated
OTA updates	Trigger via CLI	First-class
Cost	Free-ish for JS, painful for macOS	Paid tiers, honest about it

GitHub Actions can technically compile an iOS build. It'll also take 15–20 minutes per attempt and bill macOS minutes at 10x the Linux rate. So: GitHub Actions owns the code, EAS owns the binary.

Step 1: `eas.json` with real profiles

One production profile is a trap. You need three:

{
  "cli": {
    "version": ">= 12.0.0",
    "appVersionSource": "remote"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "env": { "APP_ENV": "development" },
      "ios": { "simulator": true }
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview",
      "env": { "APP_ENV": "preview" },
      "ios": { "simulator": false }
    },
    "production": {
      "channel": "production",
      "env": { "APP_ENV": "production" },
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "you@example.com",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCD123456"
      },
      "android": {
        "serviceAccountKeyPath": "./google-service-account.json",
        "track": "internal"
      }
    }
  }
}

Non-obvious bits:

appVersionSource: "remote" kills the "who bumped version last?" merge conflict forever. EAS tracks build numbers server-side.
channel binds each build to an EAS Update channel, so a QA release can't get clobbered by a main push.
ios.simulator: true on dev gives you simulator builds for design review on any Mac.

Step 2: the workflow

.github/workflows/ci.yml. Every PR: checks + preview build. Every merge to main: production build + submit.

name: CI/CD

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  quality:
    name: Lint, type-check, test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          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
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, 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' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, 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

The shape matters more than the details:

quality runs on Ubuntu, not macOS. JS jobs have no business on a macOS runner.
--no-wait on previews: Actions kicks off the EAS build and returns instead of burning minutes waiting on a 15-minute compile.
--auto-submit on production: binary succeeds → straight to TestFlight and Play internal testing. No human in App Store Connect.
EXPO_TOKEN (from your Expo dashboard) is the only secret GitHub needs.

Step 3: secrets and signing without losing your mind

Code signing is where mobile CI/CD historically goes to die. iOS: distribution cert + provisioning profile + private key. Android: keystore + alias + two passwords. Lose any of them and you can't update your existing app.

EAS managed credentials fix this. First eas build, it offers to generate and store everything. Say yes. Encrypted, auto-rotated, shared across the team.

Android submit key stays out of your repo:

eas secret:create --scope project --name GOOGLE_SERVICE_ACCOUNT_KEY --type file --value ./google-service-account.json

Because signing material never touches GitHub:

A compromised Actions run can't leak your keys. They aren't there.
New teammates get access via Expo membership, not file-copying.
Cert renewal is a background task, not a Friday fire drill.

Stuffing an Apple cert into ${{ secrets.IOS_P12 }} works until it doesn't.

Step 4: OTA updates so most releases skip the stores

Most changes to a mature RN app are JS-only: copy tweaks, style fixes, new screens from existing components. They don't need a binary. They need to reach phones.

  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@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: npm ci
      - run: eas update --channel production --message "${{ github.event.head_commit.message }}"

Every merge → OTA bundle live in ~90 seconds. Users get it on next app open. The native build still runs in parallel so binary and channel stay in sync.

The caveat Expo's docs don't shout: native module changes are not OTA-updatable. Added expo-camera this morning? New binary. Protect yourself with:

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

in app.json. EAS refuses to serve an update to a binary whose runtime doesn't match, and fingerprinting auto-detects when a rebuild is required.

Step 5: fingerprint caching

EAS hashes everything that affects the native binary (package.json, app.json, native folders, plugin configs) and reuses a previously built binary when nothing changed. JS-only PR: iOS build drops from ~15 minutes to a couple. Preview builds on every PR go from painful to routine.

The shortcut nobody mentions

All of this assumes you already have a sane Expo project. If you're generating apps with RapidNative, the export already ships the scaffolding this article builds on: eas.json with dev/preview/production profiles, fingerprint runtime policy in app.json, and a monorepo layout that doesn't fight expo/expo-github-action. Drop the workflow above into .github/workflows/ci.yml, add an EXPO_TOKEN, push. Done.

Not using it? Nothing here requires it. The pipeline is the pipeline.

Wrap-up

Deliberately not the fanciest pipeline possible. No matrix builds, no Slack-gated rollouts. Get the core loop (push → tested → signed → shipped) running on its own first; budget a day for the first production build (iOS signing, mostly) and another for OTA wiring.

What broke first in your React Native pipeline? Expired provisioning profile? Keystore password nobody wrote down? Drop it in the comments. Misery loves company, and the fixes are usually reusable.

How We Built the Real-Time Sync Layer for Team App Building

Famitha M A — Fri, 18 Sep 2026 11:01:19 +0000

TL;DR

We run a dedicated Socket.IO service next to our Next.js app instead of using Supabase Realtime, because presence and "a teammate's generation just finished" aren't database rows.
Auth is a two-stage handshake: the socket server asks the Next.js API who the user is, so identity has one source of truth.
Every payload carries a tabId. Clients drop their own echoes with one line: if (tabId === this.getTabId()) return.
The sync channel carries pointers, not truth. When an event can't describe what changed, the client refetches from the database.
Presence is deduped by userId, not by socket, so a power user with five tabs is one avatar.
No live cursors, no CRDT. Both are deliberate omissions, explained at the bottom.

The problem

Two teammates open the same project. One prompts the AI to add a screen. Files stream into the virtual file system. The preview iframe hot-reloads. Chat messages flip from streaming to complete. If the second teammate's editor doesn't reflect any of that within a few hundred milliseconds, the product feels broken. Worse, they silently drift out of sync until one overwrites the other.

Here's the part most "how to build collab" posts miss. A Google Docs-style architecture assumes both users are typing keystrokes. In our editor most edits don't come from a human, they come from an AI generation that writes a dozen files over 90 seconds while multiple teammates watch. The AI's side of the conversation is a first-class multi-user event.

That reframing changes every downstream decision.

Why not Supabase Realtime

Our data plane is Supabase. Projects, files, messages, teams, and share permissions live in Postgres with row-level security, and Realtime can stream postgres_changes from any table. It was the obvious first thing to try.

We didn't use it, for one reason above all the others: presence isn't a row. Neither is "another user's generation just entered a terminal status, please refetch your thread." Encoding those as Postgres rows just so a Realtime channel could carry them would have been architectural laundering. The events would arrive, but every consumer would have to reconstruct semantics that were only lossily written in the first place.

So we run rapidnative-sync-server: a small stateful Node service that talks Socket.IO to the browser and REST to the Next.js app.

The two-stage auth handshake

Every WebSocket system has to answer one question the moment a socket connects: who is this. We answer it by making the sync server ask the app.

Browser  --join-room-->  Sync Server  --/api/sync/validate-->  Next.js API
         <--presence:update--          <--{userId,email,name,isAdmin}--

Server side:

socket.on('join-room', async ({ projectId, tabId, authToken }) => {
  const res = await fetch(`${APP_URL}/api/sync/validate`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ projectId, authToken }),
  });

  if (!res.ok) {
    socket.emit('join-error', { projectId });
    return;
  }

  const { userId, email, name, isAdmin } = await res.json();

  socket.data = { userId, email, name, isAdmin, tabId, projectId };
  socket.join(projectId);

  io.to(projectId).emit('presence:update', { users: usersInRoom(projectId) });
});

Why route auth this way instead of terminating it in the sync server? Because identity in our system is a Next.js concern. It involves NextAuth sessions, our users table, and platform-admin checks driven by ADMIN_EMAILS. Duplicating any of that into the sync server creates two sources of truth for who counts as an admin, which is the kind of divergence that surfaces months later in exactly the wrong customer's account.

ProjectAuthService.validateProjectAccess is the single decision-point. It reads team membership, project_share rows, and the is_public flag, all under RLS, and returns a shape the sync server trusts without re-checking.

The event schema

Small and domain-shaped:

type SyncEvent =
  | 'files:created'   | 'files:updated'   | 'files:deleted'
  | 'messages:created'| 'messages:updated'| 'messages:deleted'
  | 'presence:update'
  | 'join-room'       | 'leave-room'
  | 'project:emit';   // generic passthrough, not yet formalized

The interesting engineering isn't the events. It's the envelope.

The tabId trick

Every event carries a tabId, generated once per browser tab and stored in sessionStorage:

private getTabId(): string {
  let id = sessionStorage.getItem('rn_tab_id');
  if (!id) {
    id = crypto.randomUUID();
    sessionStorage.setItem('rn_tab_id', id);
  }
  return id;
}

Every handler opens with the same guard:

private handleFileUpdated(payload: FileEvent) {
  if (payload.tabId === this.getTabId()) {
    return; // our own echo
  }
  this.dispatch(applyRemoteFileUpdate(payload.file));
}

That single line prevents an entire class of bugs. When you save a file your own client emits files:updated. The server broadcasts it to everyone in the room, including you. Without the check your tab re-applies the update to its own Redux store, which sometimes clobbers unsaved local state, sometimes fires a redundant thunk, and always makes the state graph harder to reason about.

Broadcasting to the sender and letting the sender filter is deliberate. The alternative looks simpler:

// The version that quietly breaks
socket.broadcast.to(room).emit('files:updated', payload);

Until one user has two tabs open. The tab you didn't type in still needs the update, and socket.broadcast skips the whole socket, not the whole tab. Per-tab dedup survives the "one power user with five tabs" case.

The same envelope caught a real bug. Two code paths emit messages:updated: feedback ratings send { messageId, feedback }, and generation status transitions send { id, status }. The original handler only destructured messageId, so every status update from another collaborator's generation was silently dropped:

// before
const { messageId, tabId } = payload;

// after
const targetId = payload.messageId ?? payload.id;

Every payload shape has a comment above it now.

AI generation as a multi-user event

Generation isn't a keystroke. It's a stream that produces many messages and many files over tens of seconds, terminating asynchronously with a status transition rather than a "done" character. Two patterns make it bearable.

Silent refetch on terminal status. When messages:updated carries a status that isn't streaming, some other collaborator's generation just finished:

private handleMessageUpdated(payload: MessageEvent) {
  if (payload.tabId === this.getTabId()) return;

  const isTerminal = payload.status && payload.status !== 'streaming';
  if (!isTerminal) return;

  // our own stream owns this message's state, don't race it
  if (this.getState().editor.isAiRequestInProgress) return;

  this.dispatch(fetchMessages({ silent: true }));
}

silent is doing real work. It refreshes the thread from the API without flipping the editor into the full-screen loading state. React reconciles by message id and the mounted thread updates in place. Blanking the surface would make every completed generation feel like a page reload for every viewer.

Compact-message full refresh. Long threads get compacted server-side into a summary message to keep context windows manageable. When that arrives, don't splice:

const hasCompact = newMessages.some((m) => m.type === 'compact');
if (hasCompact) {
  this.dispatch(fetchMessages({ silent: true }));
  return;
}

A compact message means the earlier messages are semantically replaced. Any client-side patch would produce something that looks like a valid thread while hiding the fact that the thread was rewritten.

Both patterns follow one rule: the sync channel carries pointers, not truth. The database is truth. When the pointer says "something changed I can't fully describe," the client goes back to Postgres. Slower per event, but the real-time layer never has to encode every server-side transformation into its wire format.

Presence, deduped by userId

The avatars in the editor header are the most visible part of the layer, and the one place the multi-tab problem can't hide.

private handlePresence(users: PresenceUser[]) {
  const seen = new Set<string>();
  const deduped = [];

  for (const user of users) {
    if (seen.has(user.userId)) continue;
    seen.add(user.userId);
    deduped.push({
      userId: user.userId,
      email: user.email,
      name: user.name,
      isAdmin: user.isAdmin,
    });
  }

  this.dispatch(setActiveUsers(deduped));
}

Without dedup a teammate with three tabs shows up as three avatars, and closing one tab makes one of "them" vanish. That's exactly the thing that erodes trust in a UI whose whole job is signalling presence.

The admin flag is filtered client-side, so regular users don't see platform admins in the avatar group. Support engineers open customer projects daily and those visits shouldn't materialize as ghost avatars on a customer's screen. Admins still see other admins, so support pairing works.

The team layer underneath

Everything rides on a team model the sync server doesn't need to know about, because Postgres enforces it. team_users maps users to teams with a role of owner, admin, or member. Owners can't be demoted, admins can't change each other's roles. project_share and project_share_team_user grant view or edit to specific teammates. is_public opens read-only access to anonymous visitors.

The sync server never queries the database directly. It asks the Next.js API, which runs every read through the requesting user's Supabase client. If a user shouldn't open a project, validateProjectAccess says no, the server refuses the room join, and no files:* event ever reaches their browser. The security boundary is at Postgres, not at Socket.IO, which is where you want it.

This is the architecture behind team projects in RapidNative, if you want to poke at the running version: open one project in two tabs and watch the avatars settle.

What we deliberately didn't build

No live cursors. A cursor is 30 to 60 events per second per user and needs a conflict-free rendering model to be worth anything. It would triple the sync server's load without solving a problem customers actually report. Comments carry spatial metadata (layerPath, coordinates) instead, which covers most of what teams want: leave a note on this specific button.

No CRDT. Yjs and Automerge are excellent and neither is in this stack. Our editing model is serial per file: one AI generation at a time, one human edit at a time, with the tabId envelope preventing cross-tab conflicts for the same user. Two teammates typing into the same file will fight, and we tell them so. A CRDT stops the fight at the cost of a new failure surface: merge outcomes users can't predict. For an app builder where the AI is the primary author, that trade doesn't pay off yet.

Wrapping up

Nothing here is exotic. Socket.IO in a Node process, an authenticated handshake through the Next.js API, domain-shaped events with a tabId envelope, a Redux slice that treats events as pointers back to the database, and RLS holding it together.

The pattern that carried the most weight is the smallest one: tabId in every payload, if (tabId === this.getTabId()) return in every handler. Three lines that killed an entire class of state bugs and made the rest of the system safe to broadcast into.

If you've built real-time collab: did you go server-side skip or client-side filter, and what broke? Drop a comment.

Delayed Push Permissions in React Native: Why the Third-Session Prompt Wins

Famitha M A — Wed, 16 Sep 2026 08:19:52 +0000

TL;DR

Asking for push permission on first launch is the single most common way apps burn their one clean shot at the iOS prompt
Waiting until the third session roughly doubles your odds, because the user has now chosen to come back twice
Session counting is a five-line AsyncStorage pattern
Better still: trigger on a habit moment (first save, first completed workout, first message) instead of a raw session count
Skip the custom "pre-permission" explainer modal unless you have data proving it helps. It often does not
If you already shipped the install-time prompt, there is a recovery path via Linking.openSettings()

The default cap

On iOS you get one native permission prompt. Decline it and the OS will never show it again for your app. The user has to dig through Settings to reverse it, which almost nobody does.

So the question is not "how do I ask." It is "when does the user have a reason to say yes."

At install, they don't. They opened your app forty seconds ago. They have no idea what your notifications contain, whether they are useful, or how often they will fire. Blind install-time prompts get rejected constantly, and every rejection is permanent. You are spending an unrecoverable resource at the moment of lowest trust.

What "the third session" actually means

Not "day three." Not "72 hours after install." Session three: the third distinct time the user opens the app. By then they have voluntarily returned twice. They have context. The ask is no longer coming from a stranger.

The mechanic is a counter that increments once per cold start:

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

const SESSION_KEY = 'session_count';

export async function bumpSession() {
  const raw = await AsyncStorage.getItem(SESSION_KEY);
  const count = (parseInt(raw, 10) || 0) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));
  return count;
}

Call it once from your root component:

useEffect(() => {
  bumpSession().then(setSessionCount);
}, []);

Then gate the prompt:

import * as Notifications from 'expo-notifications';

async function maybeAskForPush(sessionCount) {
  if (sessionCount < 3) return;

  const { status } = await Notifications.getPermissionsAsync();
  if (status !== 'undetermined') return; // already asked, never re-burn

  await Notifications.requestPermissionsAsync();
}

The undetermined check matters. It makes the function safe to call on every launch without ever re-triggering anything.

Habit moments beat session counts

Session three is the floor, not the ceiling. A raw counter still fires the prompt at an arbitrary moment. The stronger pattern is tying the ask to the first action that notifications will actually serve:

A task app asks right after the user sets their first due date
A fitness app asks after the first completed workout
A chat app asks when the user sends their first message

At that moment the value proposition is self-evident. "Want a reminder when this is due?" needs no explanation. If your app has a moment like that, use it as the trigger and keep the session count as a fallback for users who never hit it:

async function askAtHabitMoment() {
  const { status } = await Notifications.getPermissionsAsync();
  if (status === 'undetermined') {
    await Notifications.requestPermissionsAsync();
  }
}

Same guard, different call site. That is the whole change.

If you are prototyping this flow, this gating logic is exactly the kind of glue code worth generating rather than hand-writing. RapidNative scaffolds React Native and Expo screens from a prompt, and wiring a permission flow like this into a generated onboarding is a five-minute job.

The pre-permission modal trap

The popular advice says: show a custom in-app modal first ("We'd like to send you helpful reminders!"), and only fire the native prompt if the user taps yes.

The theory is sound. In practice it is easy to get wrong, and plenty of teams have watched it hurt more than help. You are now showing two interruptions instead of one, and the custom modal gives users a free, zero-cost place to say no. Some users who would have shrugged and accepted the native prompt bounce off the softer one first.

If you ask at a habit moment, the context does the explaining and the extra modal is redundant. My take: ship without it, and only add it if your own funnel data says otherwise. Do not cargo-cult it in.

Recovery for already-shipped apps

Already burned the prompt on install? You cannot re-trigger it, but you can route users to Settings at a habit moment instead:

import { Linking } from 'react-native';

async function recoverPush() {
  const { status, canAskAgain } = await Notifications.getPermissionsAsync();

  if (status === 'undetermined' || canAskAgain) {
    await Notifications.requestPermissionsAsync();
  } else if (status === 'denied') {
    // one-tap jump to your app's own settings page
    Linking.openSettings();
  }
}

Pair Linking.openSettings() with a single line of UI ("Turn on reminders in Settings") and fire it only at a moment where the user just tried to do something that needs notifications. Cold recovery rates are low, but warm ones, triggered by intent, are worth shipping.

The whole thing

Counter, guard, trigger, recovery. About 20 lines total, no library beyond AsyncStorage and expo-notifications, and it protects the one prompt you cannot get back.

What trigger moment are you using in your app: session count, habit moment, or something weirder? Drop it in the comments.

How to Add Payment Processing to Your React Native App (2026 Guide)

Famitha M A — Fri, 11 Sep 2026 13:24:35 +0000

TL;DR

Decide first: digital goods (subscriptions, unlocks) or physical goods/services. That decision, not the SDK, determines what you're allowed to use.
Physical goods or services: Stripe + Apple Pay + Google Pay via @stripe/stripe-react-native.
Digital goods: native IAP through RevenueCat (react-native-purchases). US external web checkout and EU alternative processors are now legal, but IAP is still the safe global default.
The client integration is ~30% of the work. Webhooks, idempotency, and receipt validation are the other 70%.
Never test on a live card. Stripe test mode, Apple sandbox testers, and Play license testers cover every failure path.

Every founder building a React Native app hits the same wall: the demo works, users love it, and then someone asks, "So how do people actually pay?" What sounds like a one-afternoon integration turns into a week of reading Apple's guidelines, comparing Stripe versus RevenueCat, and arguing about whether your feature counts as "digital goods." The stack is not the hard part. The rules around the stack are.

The decision that comes before the code

Before you touch an SDK, answer one question: is what your app sells a digital good or a physical good? This is not a UX distinction. It's the rule Apple and Google use to decide whether you're allowed to use Stripe at all.

Digital goods: subscriptions, premium unlocks, in-game currency, credits, cloud storage, ad-removal. Apple and Google have historically required these to go through their native in-app purchase (IAP) system and taken a 15–30% commission (30% for large developers on standard transactions and year-one subscriptions, 15% after year two or under the Small Business Program).
Physical goods and real-world services: t-shirts, meal kits, ride-sharing, bookings. These have always been allowed to use third-party processors like Stripe or PayPal at standard card fees (~2.9% + $0.30).

For a long time, that was the whole story. Then Epic v. Apple in the US and the DMA in the EU cracked it open. As of late 2025, US developers can link out to an external web checkout for digital goods too (Apple still shows a warning sheet), and EU users on iOS can use fully alternative payment providers inside the app. Your practical options in 2026:

Physical/services app: use Stripe (or PayPal, Adyen, Braintree) natively in-app.
Digital goods, US-only: IAP is still simplest, but external web checkout via Stripe is now legal.
Digital goods, EU: alternative in-app payment providers are allowed.
Digital goods, global: use IAP for the safest cross-border coverage, or add a web-checkout fallback.

Pick the answer before you pick an SDK. Everything downstream depends on it.

Payment options compared

Option	Best for	Fees	RN SDK	App Store safe
Stripe	Physical goods, services, B2B	2.9% + $0.30	`@stripe/stripe-react-native`	Yes for physical, conditionally for digital
RevenueCat (wraps IAP)	Subscriptions, digital goods	Free < $2.5k MRR, then 1%	`react-native-purchases`	Yes (uses Apple/Google IAP)
Apple Pay / Google Pay	Fast checkout on top of a processor	Same as processor	Built into Stripe SDK	Yes for physical goods
PayPal / Braintree	Markets where PayPal is preferred	2.9% + fixed	community SDKs	Same rules as Stripe
Native IAP directly	Digital goods, no abstraction	15–30% Apple/Google	`expo-in-app-purchases` / `react-native-iap`	Yes (required by default)

For 90% of React Native apps in 2026, the answer is one of two combos: Stripe + Apple/Google Pay for physical goods or services, or RevenueCat on top of native IAP for subscriptions and digital unlocks. Let's build both.

Setting up Stripe

Stripe's official SDK handles PCI compliance for you (card details never touch your server), supports Apple Pay and Google Pay out of the box, and has first-class Expo support via a config plugin.

Step 1: install.

# Expo (recommended)
npx expo install @stripe/stripe-react-native

# Bare React Native
npm install @stripe/stripe-react-native
cd ios && pod install

With Expo, add the plugin to app.json:

{
  "expo": {
    "plugins": [
      ["@stripe/stripe-react-native", {
        "merchantIdentifier": "merchant.com.yourapp",
        "enableGooglePay": true
      }]
    ]
  }
}

Step 2: wrap your app in StripeProvider.

import { StripeProvider } from '@stripe/stripe-react-native';

export default function App() {
  return (
    <StripeProvider
      publishableKey={process.env.EXPO_PUBLIC_STRIPE_PUBLISHABLE_KEY!}
      merchantIdentifier="merchant.com.yourapp"
      urlScheme="yourapp"
    >
      <RootNavigator />
    </StripeProvider>
  );
}

The publishable key is safe to ship in the bundle. The secret key never leaves your backend.

Step 3: create a Payment Intent on your server. This is the piece a lot of tutorials skip. Stripe requires a server-side call so the amount is not manipulable from the client.

// Backend: /api/create-payment-intent
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const { amount, currency = 'usd' } = await req.json();

  const paymentIntent = await stripe.paymentIntents.create({
    amount,
    currency,
    automatic_payment_methods: { enabled: true },
  });

  return Response.json({ clientSecret: paymentIntent.client_secret });
}

Step 4: present the Payment Sheet. Stripe's pre-built, PCI-compliant UI supports cards, Apple Pay, Google Pay, and 40+ local payment methods depending on your country.

import { useStripe } from '@stripe/stripe-react-native';

function CheckoutScreen({ amount }: { amount: number }) {
  const { initPaymentSheet, presentPaymentSheet } = useStripe();

  async function pay() {
    const res = await fetch('/api/create-payment-intent', {
      method: 'POST',
      body: JSON.stringify({ amount }),
    });
    const { clientSecret } = await res.json();

    await initPaymentSheet({
      merchantDisplayName: 'Your App',
      paymentIntentClientSecret: clientSecret,
      applePay: { merchantCountryCode: 'US' },
      googlePay: { merchantCountryCode: 'US', testEnv: __DEV__ },
    });

    const { error } = await presentPaymentSheet();
    if (error) console.log(error.message);
    else Alert.alert('Payment complete');
  }

  return <Button title="Pay" onPress={pay} />;
}

That's a functioning payment flow. Cards, Apple Pay, and Google Pay all light up in the same sheet with no extra integration work. If you'd rather not hand-wire this, RapidNative generates this exact stack (checkout screen, provider, payment intent endpoint, webhook handler) from a plain-English prompt, and the code exports to your own repo.

Handling in-app purchases for digital goods

Selling subscriptions, credits, or premium unlocks? You'll almost certainly go through StoreKit and Google Play Billing. Wiring these APIs directly is painful: different receipt formats, different renewal semantics, different edge cases for pauses, grace periods, refunds, and family sharing. Nearly every serious React Native app in 2026 uses RevenueCat to abstract this away.

Step 1: install.

npx expo install react-native-purchases

Step 2: configure at app start.

import Purchases from 'react-native-purchases';

Purchases.configure({
  apiKey: Platform.OS === 'ios'
    ? process.env.EXPO_PUBLIC_RC_IOS_KEY!
    : process.env.EXPO_PUBLIC_RC_ANDROID_KEY!,
});

Step 3: fetch offerings and present a paywall.

const offerings = await Purchases.getOfferings();
const monthly = offerings.current?.availablePackages.find(
  (p) => p.packageType === 'MONTHLY'
);

if (monthly) {
  const { customerInfo } = await Purchases.purchasePackage(monthly);
  const isPro = customerInfo.entitlements.active['pro'] !== undefined;
}

RevenueCat handles receipt validation, cross-platform sync, subscription state, and analytics. You configure products in App Store Connect and Google Play Console, mirror them in RevenueCat, and let the SDK reconcile everything. The commission is still Apple's or Google's. RevenueCat itself is free below $2,500/month in tracked revenue, then 1%.

One warning: do not route digital-goods subscriptions through Stripe just to dodge the 30% cut globally. Apple will reject the app. The narrow exception (US external web-checkout linking) requires the StoreKit External Purchase Link entitlement plus an explicit user warning sheet. Worth doing at scale, not worth the review risk for a first launch.

Adding Apple Pay and Google Pay

Good news: if you integrated the Payment Sheet above, Apple Pay and Google Pay are already working. The sheet auto-detects device capability and shows the right button.

Two extra steps to get store-approved:

Apple Pay: enable the Apple Pay capability in your Apple Developer account, create a merchant ID (merchant.com.yourapp), and add it to the Expo config plugin. Test on a real device: the simulator doesn't run Apple Pay.
Google Pay: enable Google Pay in the Google Pay Business Console, register your app, and turn on the googlePay flag. Test on a real Android device with a saved card.

Both are free on top of Stripe, and they dramatically improve conversion. Stripe's own data shows one-tap payments increase mobile checkout completion by 60–70%. Treat them as table stakes, not features.

The backend half nobody talks about

Client-side integration is maybe 30% of a real payment system. The other 70% lives on your server:

Webhooks. Stripe (and RevenueCat) push events for every state change: payment_intent.succeeded, invoice.payment_failed, customer.subscription.updated. You need an endpoint that verifies signatures, reads the event, and updates your database. Skipping this is the number-one cause of "user paid but the app says they didn't" bugs.
Idempotency. Payment operations must be safe to retry. Use idempotency keys on Stripe requests and dedupe webhook events by ID. Networks fail; users retry; you cannot charge twice.
Receipt validation. For IAP, Apple and Google receipts must be validated server-side. RevenueCat does this for you. Rolling your own? The App Store Server API docs are your source of truth.
Subscription lifecycle. Grace periods, billing retries, pauses, refunds, and family sharing mean "active" is not a single boolean. Model it as state, not a flag.
Compliance. Even with Stripe absorbing PCI scope, you still need Strong Customer Authentication (SCA) in the EU/UK. The Payment Sheet handles the 3DS challenge automatically, but your backend must handle the requires_action state.

This is where most hand-rolled payment integrations quietly leak revenue.

Testing payments safely

Never run a first payment against a live card. Both Stripe and RevenueCat have first-class sandbox modes:

Stripe test mode: use test API keys and Stripe's published test cards. 4242 4242 4242 4242 for success, 4000 0000 0000 9995 for insufficient funds, 4000 0025 0000 3155 to trigger 3D Secure. Run every failure branch before switching to live keys.
Apple sandbox: create a Sandbox Tester in App Store Connect, sign into it on your test device under Settings → App Store → Sandbox Account, then run TestFlight or a dev build. Sandbox subscriptions renew every 5 minutes instead of monthly, which is how you test renewals in a reasonable amount of time.
Google Play: add license testers in the Play Console, upload to an internal test track, and purchase without being charged.
Real devices: Apple Pay and Google Pay don't work in simulators. Test the payment sheet the way an end user actually sees it.

Write end-to-end tests for the happy path, the SCA path, the network-failure path, the webhook-late path, and the cancellation path. If those five work, you have a payment system. If any of them fails silently, you have a support ticket queue.

Ship payments, not payment bugs

Adding payment processing to a React Native app in 2026 is a solved problem, but only if you make the digital-vs-physical decision first, treat webhooks as first-class code, and test the failure paths as hard as the happy path. Stripe + Apple Pay + Google Pay covers most physical-goods and services apps. RevenueCat covers most subscription apps. The rest is discipline: idempotency, sandbox testing, and a webhook handler you actually trust.

What are you wiring payments into right now? Drop a comment with your stack (and any App Store review horror stories).

React Native OTA Updates: A Production Playbook (Rollback Discipline, Canaries, and Session-Safe Applies)

Famitha M A — Wed, 09 Sep 2026 09:50:47 +0000

OTA updates are the closest thing React Native has to a cheat code. You can ship a fix to every user in minutes without waiting on App Store review. And that is exactly why most teams get burned by them: the same speed that ships fixes fast also ships bugs fast, to everyone, at once.

This is the playbook we settled on after enough OTA incidents to stop treating eas update like a deploy button.

TL;DR

Treat OTA pushes in three tiers: hotfix, canary, staged. Each has different rules.
Write the rollback runbook before you push, not during the incident.
Never apply an update mid-session. Download in the background, apply on next cold start or an explicit safe point.
EAS Update channels are a rollout dimension, not just an environment label. Use them like one.
OTA is for JS-only changes. Anything touching native code goes through the store, no exceptions.

Why OTA is a superpower most teams misuse

The failure pattern is almost always the same: a team discovers OTA, loves it, and starts using it as their default release path. No staged rollout, no rollback plan, updates applying whenever the client feels like it. It works fine for weeks. Then one bad bundle lands on 100% of users simultaneously, and there is no "roll back the servers" because the broken code is already on the devices.

The fix is not to avoid OTA. It is to give it the same discipline you give backend deploys.

The three update tiers

Not every OTA push is the same kind of event. We label every update as one of three tiers before it goes out.

Tier 1: Hotfix. A crash or a broken critical path. Goes to 100% as fast as possible. This is the only tier allowed to skip a canary, and it requires two people to sign off.

Tier 2: Canary. Behavior changes, refactors, anything with real surface area. Ships to a small channel first, soaks, then promotes.

Tier 3: Staged. Larger feature work that happens to be JS-only. Rolls out gradually with explicit checkpoints.

Naming the tier forces the conversation: "is this really a hotfix, or are you just impatient?"

Rollback discipline: write the runbook before you push

The rule that has saved us the most: no update ships without a rollback line already written. Concretely, the PR description for an OTA push includes:

Rollback plan:
- Known-good update group: <id of the current production update>
- Command: eas update:republish --group <id> --channel production
- Owner if this goes wrong after hours: <name>

Republishing a known-good group is the core move. You are not reverting git and rebuilding under pressure. You are re-pointing the channel at a bundle that was already live and healthy:

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

# re-point production at it
eas update:republish --group <update-group-id>

Two habits make this actually work:

Record the current production group id in the release checklist before every push. During an incident you do not want to be scrolling update:list output trying to remember which one was fine.
Rehearse it once per quarter on a staging channel. A runbook nobody has executed is a rumor.

One caveat to internalize: rollback is not instant for users. Devices pick up the republished bundle on their next check, so your real recovery time is rollback plus the client's update-check cadence. That number should be written down somewhere your team can see it.

Session-safe apply: don't swap the bundle mid-scroll

The default temptation is to call Updates.reloadAsync() the moment a download finishes. From the user's side, that is the app blinking and eating their half-written message.

The pattern we use: fetch eagerly, apply lazily, at safe points only.

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

export function useSafeOtaApply() {
  const pendingUpdate = useRef(false);

  useEffect(() => {
    async function check() {
      try {
        const update = await Updates.checkForUpdateAsync();
        if (update.isAvailable) {
          await Updates.fetchUpdateAsync();
          pendingUpdate.current = true; // downloaded, NOT applied
        }
      } catch {
        // never let update plumbing crash the app
      }
    }
    check();

    // apply only when the app goes to background: user is gone anyway
    const sub = AppState.addEventListener('change', (state) => {
      if (state === 'background' && pendingUpdate.current) {
        Updates.reloadAsync();
      }
    });
    return () => sub.remove();
  }, []);
}

Safe points, in order of preference:

Next cold start (the default: set the update policy to apply on launch and do nothing clever).
App backgrounded for more than a few seconds.
An explicit "restart to update" prompt, reserved for Tier 1 hotfixes where you cannot wait.

The one thing you never do is reload while a form, checkout, or upload is in flight. If your app has flows like that, gate the reload behind a "is anything critical in progress" check.

EAS channels as a first-class rollout dimension

Most teams use channels as environment labels: development, preview, production. That works, but it leaves the interesting part on the table. Channels are also how you slice your user base for rollout.

Our channel layout:

production        <- everyone on the store build
production-canary <- internal team + opted-in users
staging           <- QA builds

The canary build is the same runtime as production (same native code, same runtime version), just pointed at a different channel. A Tier 2 update flows like this:

# 1. ship to canary
eas update --channel production-canary --message "fix: cart total rounding"

# 2. soak. watch crash rate and the specific flow you touched.

# 3. promote the same update to production
eas channel:edit production --branch <canary-branch>

Promoting the branch rather than publishing twice means production gets the exact bytes the canary soaked on. No "it worked on canary because we rebuilt it" mysteries.

Since runtimeVersion fences which builds can receive which updates, keep canary and production builds on the same runtime version policy or your canary stops being representative.

When OTA vs. a store release

The boundary is mechanical, not judgment-based:

OTA: JS, assets, config that lives in JS. Copy changes, logic fixes, style fixes, feature flags.
Store release: any native dependency change, permissions changes, SDK upgrades, anything touching the native project. Also anything Apple would consider a significant change in app behavior; OTA is for fixes and iterations, not for shipping a different app than the one that was reviewed.

We also run a soft rule: if an OTA diff is big enough that you would want a changelog, it probably deserves the store pipeline and its slower, safer cadence anyway.

This calculus changes a bit depending on how the app was built. A lot of the apps we see coming out of RapidNative are Expo projects where the entire product surface is JS, which makes almost everything OTA-eligible. That makes the discipline above more important, not less: when every change can go OTA, the tiering and rollback rules are the only thing standing between you and pushing straight to 100%.

The shortest reliable loop we've settled on

For a Tier 2 change, end to end:

1. PR merged with rollback plan in the description
2. Note current production update group id
3. eas update --channel production-canary
4. Soak on canary (crash rate + touched flow)
5. Promote canary branch to production channel
6. Watch dashboards through one full update-check cycle
7. Log the new known-good group id

Seven steps, and five of them are copy-paste. The whole loop is still dramatically faster than a store release, which is the point: the discipline does not slow you down enough to notice, but it converts "OTA incident" from an outage into a non-event.

What does your OTA setup look like: are you applying on cold start, on background, or (be honest) reloading the second the download finishes? Drop your setup in the comments, especially if you have a rollback story.

From Figma to Expo Router — turning wireframes into RN scaffolding in an afternoon

Famitha M A — Wed, 02 Sep 2026 10:27:17 +0000

Designer-dev handoff on RN apps has a specific waste: I finish wireframes, hand them to dev, and then wait a day or two while someone types out Stack.Screen name="Foo" component={FooScreen} for every one of my screens. It's mechanical work, but it blocks me from clicking through my own design in a real device.

Expo Router's file-based routing changed that for me. As a designer, I can now scaffold the entire route structure of a new prototype in an afternoon — no dev required until I want interactivity beyond navigation.

Reading a wireframe as a folder tree

Every well-organized Figma file already has an implicit tree: pages → frames → sub-flows. Turning that into an Expo Router app/ folder is a mechanical mapping:

Top-level pages in Figma → top-level files in app/
Sub-flows within a page → nested folders
Modal flows → files at the top level marked with presentation: 'modal' in the parent _layout.tsx
Auth-gated flows → wrap in (auth)/ group

Example: a 12-screen social-app prototype with home feed, explore, profile, and auth flow becomes:

app/
├── _layout.tsx
├── (tabs)/
│   ├── _layout.tsx
│   ├── index.tsx        # Feed
│   ├── explore.tsx
│   └── profile.tsx
├── (auth)/
│   ├── _layout.tsx
│   ├── login.tsx
│   ├── signup.tsx
│   └── forgot.tsx
├── post/[id].tsx        # Post detail
├── user/[id].tsx        # User profile detail
├── new-post.tsx         # Modal
└── settings/
    ├── _layout.tsx
    ├── index.tsx
    ├── notifications.tsx
    └── account.tsx

Each file gets a placeholder component with the screen name, a text You are on: Feed, and a couple of <Link> components pointing at the next screens per the wireframe.

The scaffolding script

I wrote a tiny script — you copy a JSON that mirrors your Figma page tree, and it generates the folder + file structure with placeholder components. Nothing fancy:

// scaffold.mjs
import fs from 'fs';
import path from 'path';

const tree = JSON.parse(fs.readFileSync('./ia.json'));

function render(name) {
  return `import { View, Text } from 'react-native';
export default function ${name}() {
  return <View><Text>You are on: ${name}</Text></View>;
}
`;
}

function scaffold(node, dir) {
  fs.mkdirSync(dir, { recursive: true });
  for (const [key, val] of Object.entries(node)) {
    if (typeof val === 'string') {
      fs.writeFileSync(path.join(dir, `${key}.tsx`), render(val));
    } else {
      scaffold(val, path.join(dir, key));
    }
  }
}

scaffold(tree, './app');

With ia.json derived from your Figma page tree (I copy-paste layer names), you get a runnable Expo Router app in seconds. npx expo start, click through your own design, feel the flow before writing a line of real UI code.

What still needs a dev

The _layout.tsx files: tab bar styling, header options, auth gating, transitions.
Any real data fetching or state.
Custom transitions (modal presentation, shared element).
Anything that touches native modules.

But structure? That's mine now. And structure is what determines whether the design feels right in-hand.

Case study

Last month we prototyped a 12-screen fitness-tracker concept. Old workflow: hand Figma to dev, wait 2 days for a clickable prototype. New workflow: I scaffolded the routes in an afternoon, walked through it on my own phone the same evening, caught two flow issues before dev started real work, and by the time engineering opened the ticket the IA was already validated.

Designer-authored scaffolding won't replace engineering. It moves the design-validation gate 2–3 days earlier — which for us has been the single biggest reduction in "we shipped the wrong flow" incidents.

If you're a design lead on an RN team and you're still handing wireframes to dev to translate into a nav tree, try scaffolding once. You'll never go back.

If you want to go beyond scaffolding and generate a complete mobile app from your designs and requirements, you can also try RapidNative: RapidNative

The Design System of a Trustworthy React Native Checkout Screen

Famitha M A — Thu, 20 Aug 2026 09:59:52 +0000

TL;DR

Checkout is the most emotionally loaded screen in your app. Design it like it.
Five zones: header, amount, line items, payment method, sticky Pay button.
Two type sizes. Not three. Not five.
No custom fonts on this screen. They delay the render of the total.
Never green on the Pay button. Never red outside errors.
The three states everyone skips: loading, error, success. Specs below.

Most React Native checkout screens I audit are functional and forgettable. A stack of <View> and <Text> in the app's default theme. The user taps through and either succeeds or bounces.

But this is where the user hands you money. Every pixel choice either builds trust or leaks it.

Here's the whole system, with code.

The five zones

┌─────────────────────────────┐
│  ← Back        Order summary │  Zone 1: Header (32pt height)
├─────────────────────────────┤
│                             │
│  Total                      │
│  $42.87 USD                 │  Zone 2: Amount (dominant type)
│                             │
├─────────────────────────────┤
│  Item 1              $30    │
│  Item 2              $10    │  Zone 3: Line items (collapsed)
│  Tax                 $2.87  │
├─────────────────────────────┤
│                             │
│  [ Apple Pay ]              │  Zone 4: Payment method
│  [ Card ending 4242 ]       │
│  [ + Add payment method ]   │
│                             │
├─────────────────────────────┤
│  [    Pay $42.87 USD    ]   │  Zone 5: Pay button (sticky)
└─────────────────────────────┘

Zone 5 stays sticky above the keyboard. Zone 2 collapses when the keyboard opens so the Pay button never leaves the viewport.

<KeyboardAvoidingView
  behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
  style={{ flex: 1 }}
>
  <ScrollView contentContainerStyle={{ flexGrow: 1 }}>
    <AmountBlock total={total} currency={currency} compact={keyboardVisible} />
    <LineItems items={items} />
    <PaymentMethods methods={methods} onSelect={setMethod} />
  </ScrollView>
  <PayButton total={total} currency={currency} onPress={handlePay} />
</KeyboardAvoidingView>

Typography: two sizes, that's it

export const type = {
  amount: {
    fontSize: 32,
    fontWeight: '600' as const,
    letterSpacing: -0.5,
  },
  body: {
    fontSize: 15,
    fontWeight: '400' as const,
  },
};

Platform system font only. SF Pro Display on iOS, Roboto on Android. Skip expo-font entirely on this screen. Custom font loading is real work on a cold boot, and anything that delays the render of the total is worth cutting. If you want a number for your own app, profile it instead of trusting a blog post.

Color tokens

import { PlatformColor, Platform } from 'react-native';

export const color = {
  background: Platform.select({
    ios: PlatformColor('systemBackground'),
    android: '#FFFFFF',
  }),
  text: Platform.select({
    ios: PlatformColor('label'),
    android: '#111111',
  }),
  // Brand primary only if it clears 4.5:1 on white. Otherwise black.
  payButton: contrastRatio(brandPrimary, '#FFFFFF') >= 4.5 ? brandPrimary : '#000000',
  errorBg: '#FFF4F4',
  errorText: '#B00020',
};

Never use red for anything except errors. Never use green on the Pay button. Users associate green with "Buy" but not with "you're about to spend money," which is a subtle difference that still shows up in testing.

The three states everyone forgets

Loading. Swap the label, disable the button, and escalate the copy on a timer. An indeterminate spinner alone reads as a frozen app.

function usePayingLabel(processing: boolean) {
  const [elapsed, setElapsed] = useState(0);

  useEffect(() => {
    if (!processing) return setElapsed(0);
    const id = setInterval(() => setElapsed((e) => e + 1), 1000);
    return () => clearInterval(id);
  }, [processing]);

  if (!processing) return null;
  if (elapsed >= 8) return 'This is taking longer than usual, please wait.';
  if (elapsed >= 2) return 'Contacting your bank...';
  return null; // button label already says "Processing..."
}

Error. Full-width bar above the Pay button. One human sentence, one recovery action. Never the raw API code.

{error && (
  <View style={{ backgroundColor: color.errorBg, padding: 12 }}>
    <Text style={{ color: color.errorText, fontSize: 15 }}>
      Your card was declined by your bank.
    </Text>
    <Pressable onPress={resetToPaymentMethod}>
      <Text style={{ color: color.errorText, fontWeight: '600' }}>Try again</Text>
    </Pressable>
  </View>
)}

Success. Full-screen replacement: large checkmark, order ID, amount, timestamp, email receipt button. Hold 3 seconds minimum before any auto-dismiss so the user feels the transaction land.

The two components that carry the screen

// Pay button
<Pressable
  style={{
    height: 52,
    borderRadius: 12,
    backgroundColor: color.payButton,
    justifyContent: 'center',
    alignItems: 'center',
    marginHorizontal: 16,
  }}
  onPress={handlePay}
  disabled={!ready || processing}
>
  <Text style={{ color: 'white', fontSize: 17, fontWeight: '600' }}>
    {processing ? 'Processing...' : `Pay ${formatCurrency(total, currency)}`}
  </Text>
</Pressable>

// Amount block
<View style={{ paddingHorizontal: 16, paddingVertical: 24 }}>
  <Text style={{ fontSize: 13, color: subtle, marginBottom: 4 }}>Total</Text>
  <Text style={type.amount}>
    {formatCurrency(total, currency)}{' '}
    <Text style={{ fontSize: 13, color: subtle }}>{currency}</Text>
  </Text>
</View>

Note the 24pt of vertical padding above the total and the 16pt horizontal margin on the button. Those are the two anchor values on the 8pt grid. Density signals cheapness. Whitespace signals trust.

If you're scaffolding a fresh app rather than retrofitting one, RapidNative generates the screen structure and theme tokens up front, so you're wiring Stripe on day one instead of rebuilding the amount block by hand again.

Ship it in a sprint

Day 1: Audit the current checkout against the five zones. Find what's missing.
Day 2: Rebuild the amount zone and the Pay button. Do these first, they carry most of the perceived trust.
Day 3: Build the three states.
Day 4: Test with five people. Watch where they pause.
Day 5: Ship.

The rest is plumbing to Stripe or Razorpay.

What does your checkout look like right now? Drop a comment with the ugliest part of yours and I'll tell you which zone it belongs to.

How AI Is Making Mobile Accessibility Easier Than Ever

Famitha M A — Mon, 17 Aug 2026 08:27:47 +0000

TL;DR

95.9% of the top million sites have detectable a11y failures. Mobile apps are not better, they're just harder to audit.
Four things changed: on-device assistive AI, ML-assisted testing, generated alt text and captions, and AI-assisted code generation.
On-device AI raises the floor, not the ceiling. VoiceOver guessing "Button, likely a heart" is not a label.
Rule-based tools catch 30 to 40% of WCAG failures. AI pushes that up, nowhere near 100%.
The real fix is at generation time: if the model writes the JSX, it can write accessibilityLabel in the same pass, for free.

The gap between apps shipping and apps shipping accessibly has been widening for a decade. What changed recently is that AI shows up on both sides of the shipping fence: in the runtime layer (the phone), in the tooling layer (audits), and at the code-generation layer, where the app is actually being written.

Why mobile a11y is harder than the web

Native apps don't share a common semantic model. On the web you have HTML, and HTML has a built-in accessibility contract. On mobile you have UIAccessibility on iOS, AccessibilityNodeInfo on Android, two screen readers with different gesture conventions, and a framework translation layer (React Native, Flutter, SwiftUI) sitting on top of both.

That means a label that works on one platform can be silently dropped on the other. Here's the version everyone writes first:

// Ships. Announces as "Button". Useless.
<Pressable onPress={toggleFavorite}>
  <Icon name={isFavorite ? "heart-filled" : "heart"} />
</Pressable>

And the version that actually works with VoiceOver and TalkBack:

<Pressable
  onPress={toggleFavorite}
  accessibilityRole="button"
  accessibilityLabel="Add to favorites"
  accessibilityHint="Saves this item to your favorites list"
  accessibilityState={{ selected: isFavorite }}
  hitSlop={12}
>
  <Icon name={isFavorite ? "heart-filled" : "heart"} />
</Pressable>

Four extra props. Nobody argues they're hard. They just never get written, because they're invisible in the simulator and they're the last-day task that gets cut.

Regulation is closing in anyway: the European Accessibility Act took effect for consumer digital products in June 2025, and ADA Title II requires state and local government apps to hit WCAG 2.1 AA by April 2026. Regulation without automation is a punishment. AI is what makes the automation possible.

Shift 1: the OS started covering for you

iOS runs an on-device model that generates image descriptions for photos and unlabeled UI elements. Ship a button with no label and VoiceOver will guess: "Button, likely a play triangle." Android's TalkBack does the same with Gemini Nano, including for images inside third-party apps that never set contentDescription. Both platforms now generate Live Captions for any audio playing on the device. Voice Control on iOS understands intent, so "tap the little heart" resolves even when your label is favoriteButton.

The floor is rising. The ceiling is not. A guessed description loses to a real one every time, and the guess is silently wrong often enough to matter.

Shift 2: audits got cheap

Three categories worth knowing:

Rule engines plus ML (axe DevTools Mobile, Google's Accessibility Scanner). These now catch labels that exist but are meaningless, like contentDescription="image1.jpg".
Visual regression plus ML (Applause, BrowserStack, testRigor). Diffs screens against known-good corpora and flags contrast ratios, small tap targets, low-legibility fonts.
LLM audits. Feed in screenshots plus an accessibility tree dump, get back findings in plain English: "The 'Sign in with Apple' button has no accessibility label; VoiceOver will announce it as 'Button'."

You can wire the cheap version of the third one into CI yourself:

// jest + @testing-library/react-native
// Fails the build when an interactive element ships unlabeled.
import { render } from "@testing-library/react-native";

test("all buttons are labeled", () => {
  const { UNSAFE_root } = render(<ProductScreen />);
  const buttons = UNSAFE_root.findAll(
    (n) => n.props.accessibilityRole === "button"
  );

  expect(buttons.length).toBeGreaterThan(0);
  buttons.forEach((b) => {
    expect(b.props.accessibilityLabel).toBeTruthy();
  });
});

WebAIM's own numbers say automated tooling catches 30 to 40% of WCAG failures. AI raises it, not to 100%. Keep a human in the loop, ideally one who uses the tech.

Shift 3: the missing content is now generated

Alt text from vision models is table stakes. Whisper-class models made captions good enough for accessibility use in most languages. LLMs are producing plain-language versions of dense content on the fly, which is a genuine breakthrough for cognitive accessibility. Live cross-language captioning is built into the call stack on both platforms.

The catch: generated descriptions are only usually right, and a screen reader confidently reading a subtly wrong description is worse than one that says nothing.

Shift 4: fix it at generation time

This is the one that matters. When an LLM writes the screen, the accessibility props are not extra work, they're the same tokens. That flips the default from "no labels, ship it" to "labels came with the generation."

This is the bet RapidNative is built on: prompt in, real React Native and Expo code out, with accessibilityLabel, accessibilityRole, accessibilityHint, and accessibilityState attached at generation rather than bolted on later. An image comes out as accessibilityLabel="Sunset over the ocean" instead of a nameless <Image /> someone will theoretically label next sprint.

None of this is exclusive to one tool. A well-prompted Copilot, Cursor, or Claude does the same thing in a hand-written codebase. Put it in the repo rules and it applies to every generation:

<!-- .cursorrules / CLAUDE.md / copilot-instructions.md -->
Every interactive element must have accessibilityRole and accessibilityLabel.
Every Image must have accessibilityLabel or accessible={false}.
Touch targets must be >= 44x44 (use hitSlop when the visual is smaller).
Never use placeholder text as the only label for a TextInput.

What AI still can't do

It tells you labels exist, not that the flow is usable. Reading order that jumps around passes every automated check.
Generated alt text is generic. "A person" is compliant. "The founder of the org you're about to donate to" is what a sighted user sees.
Cognitive accessibility is barely automatable. The fix is design work, not a tag.
Live captioning fails contextually: wrong medication name, wrong price, wrong date. Plausible-but-wrong is the worst failure mode for exactly the users you were helping.
Motor accessibility is under-covered because it doesn't map cleanly onto structured tests.

Treat AI as the intern who catches the obvious stuff at 10x speed. It makes a specialist's time higher-leverage. It doesn't replace them.

The checklist I'd run on any AI-generated app

Every interactive element has accessibilityLabel, plus accessibilityRole and accessibilityHint where useful.
Images are labeled or explicitly marked decorative with accessible={false}.
Contrast passes WCAG 2.2 AA (4.5:1 body, 3:1 large). Re-check after any palette tweak.
Font scaling works. Test at 200%.
Touch targets are 44x44 minimum. Generators over-index on clean small icons, so this is the most-violated rule in generated code.
Forms have labels, not just placeholders.
Video has captions.
You personally turned on VoiceOver and TalkBack and completed the primary flow.

Point 4 is worth a snippet, since it's the one people get wrong quietly:

import { useWindowDimensions, PixelRatio, Text } from "react-native";

// Bad: fixed height locks text out of scaling
<View style={{ height: 44 }}><Text>Continue</Text></View>

// Better: let the row grow with the user's font scale
const scale = PixelRatio.getFontScale();
<View style={{ minHeight: 44 * scale, justifyContent: "center" }}>
  <Text maxFontSizeMultiplier={2}>Continue</Text>
</View>

Where this goes next

WCAG 3.0 moves toward outcome-based scoring instead of binary pass/fail, which is far better suited to LLM evaluation. EAA enforcement in Europe starts producing fines and case law in 2026, which changes the internal politics of a11y work fast. And expect compliance tooling that lives inside the AI development pipeline: reviewing PRs, gating deploys, producing an audit trail.

The direction of travel is that accessibility becomes a property of how the app was built, not a coat of paint applied afterward.

What's the a11y bug that has burned you hardest in a shipped app? Drop it in the comments. I'm especially interested in the ones no automated audit caught.

DEV Community: Famitha M A

Design Your Expo Router Tree Before You Write a Single Screen

Why the tree deserves a design pass

Step 1: Write the sitemap as URLs, not screens

Step 2: Group by navigator, not by feature

Step 3: Decide what each layout owns

Step 4: Plan dynamic segments and their params

Step 5: Keep non-routes out of the routes directory

Step 6: Review the tree before you commit

Step 7: Test deep links against the sitemap

A planning template you can copy

Wrapping up

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

The stack

Step 1: Build the screens before the Bluetooth

Step 2: HealthKit + Health Connect

Step 3: Talk BLE to the wearable

Step 4: Persist first, sync later

Step 5: Ship

Wrapping up

React Native Maps: Build Location Features That Actually Work in Production

What react-native-maps actually is

react-native-maps vs expo-maps

Setup with Expo

Rendering a map and markers

Location permissions without getting rejected

Routes, polylines, and geofences

Marker clustering: the performance cliff

Skipping the boilerplate

FAQ

Your turn

6 Expo Router file-structure mistakes I keep finding in code reviews

Why file structure is where routing breaks

1. Non-route files living inside app/

2. Two files resolving to the same URL

3. Deep links that land with no back button

4. Treating dynamic params as always-a-string

5. Modals declared deep in the tree

6. No +not-found.tsx and no typed routes

Generated trees need the same review

The checklist

Mobile App CI/CD with EAS Build and GitHub Actions (the split that actually works)

Why two CI systems (yes, really)

Step 1: eas.json with real profiles

Step 2: the workflow

Step 3: secrets and signing without losing your mind

Step 4: OTA updates so most releases skip the stores

Step 5: fingerprint caching

The shortcut nobody mentions

Wrap-up

How We Built the Real-Time Sync Layer for Team App Building

TL;DR

The problem

Why not Supabase Realtime

The two-stage auth handshake

The event schema

The tabId trick

AI generation as a multi-user event

Presence, deduped by userId

The team layer underneath

What we deliberately didn't build

Wrapping up

Delayed Push Permissions in React Native: Why the Third-Session Prompt Wins

The default cap

What "the third session" actually means

Habit moments beat session counts

The pre-permission modal trap

Recovery for already-shipped apps

The whole thing

How to Add Payment Processing to Your React Native App (2026 Guide)

The decision that comes before the code

Payment options compared

Setting up Stripe

Handling in-app purchases for digital goods

Adding Apple Pay and Google Pay

The backend half nobody talks about

Testing payments safely

Ship payments, not payment bugs

React Native OTA Updates: A Production Playbook (Rollback Discipline, Canaries, and Session-Safe Applies)

TL;DR

1. Non-route files living inside `app/`

6. No `+not-found.tsx` and no typed routes

Step 1: `eas.json` with real profiles