DEV Community: Famitha M A

The 10 Most Common Expo Errors and How to Fix Them

Famitha M A — Tue, 27 Oct 2026 15:00:35 +0000

Most Expo errors fall into one of four layers: Metro couldn't bundle your code, JavaScript crashed at runtime, a native module is missing from the binary you're running, or the native build (Xcode or Gradle) failed. Naming the layer first is half the fix.

Here are the ten errors that come up most, what they mean and how to fix them. If yours isn't here, paste it into the free React Native & Expo Error Fixer and it will explain the cause and the fix.

Before anything else, two commands fix a surprising number of problems:

npx expo start --clear     # restart Metro with an empty cache
npx expo-doctor            # check your project for known issues

1. Unable to resolve module

Unable to resolve module ./components/Header from App.tsx:
./components/Header could not be found within the project

Layer: Metro.

Why: the import path doesn't match a real file, the package isn't installed, or Metro is serving a stale cache after you moved or renamed something. A common one: the file is header.tsx but you import ./Header. macOS ignores case, but Linux CI and EAS Build don't.

Fix:

Check the path and the exact capitalisation.
For a package, install it with npx expo install <package> so you get the version that matches your SDK.
Restart with npx expo start --clear.
If you use path aliases like @/components, make sure they're set in tsconfig.json (Expo reads paths from it).

Paste your resolve error into the Error Fixer →

2. "main" has not been registered

Invariant Violation: "main" has not been registered.

Layer: JavaScript, at startup.

Why: the app's entry file never ran registerRootComponent, usually because something crashed while the first modules were loading, or Metro is running from the wrong folder (common in monorepos).

Fix:

Scroll up: the real error is usually printed just above this one. Fix that first.
Run npx expo start from the app's own folder.
If you changed the entry point, check the main field in package.json (expo-router/entry for Expo Router, or a file that calls registerRootComponent(App)).

3. Text strings must be rendered within a `<Text>` component

Error: Text strings must be rendered within a <Text> component.

Layer: JavaScript, at render.

Why: a raw string or number is sitting directly inside a View. The sneaky version is a conditional: {count && <Badge />} renders the number 0 when count is 0.

Fix:

Wrap text in <Text>.
Make conditionals return a boolean: {count > 0 && <Badge />} or {!!count && <Badge />}.
Look for stray characters, like a space or ; left between JSX tags.

4. VirtualizedLists should never be nested inside plain ScrollViews

VirtualizedLists should never be nested inside plain ScrollViews
with the same orientation because it can break windowing and other functionality

Layer: JavaScript (a warning, but a real performance problem).

Why: a FlatList inside a vertical ScrollView renders every row at once, so you lose the virtualization that makes lists fast.

Fix: remove the outer ScrollView and move the content above and below the list into ListHeaderComponent and ListFooterComponent. If you need several lists on one screen, use a SectionList.

5. Native module not found in Expo Go

Error: Cannot find native module 'ExpoSomething'
Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'RNSomething' could not be found.

Layer: native module.

Why: Expo Go only contains the native code for the libraries bundled into it. A library with its own native code that isn't one of them will install fine and then crash at runtime.

Fix: create a development build, which is your own version of Expo Go with your libraries compiled in:

npx expo install expo-dev-client
eas build --profile development --platform ios   # or android

If you're already on a development build and see this, you added the library after building. Rebuild.

6. Element type is invalid

Element type is invalid: expected a string (for built-in components)
or a class/function (for composite components) but got: undefined.

Layer: JavaScript.

Why: an import resolved to undefined. Almost always a default/named import mix-up: import Header from './Header' when the file does export function Header, or the other way around. Circular imports can cause it too.

Fix: match the import to the export (import { Header } from './Header' for a named export). The error's component stack tells you which component was undefined.

7. Too many re-renders

Error: Too many re-renders. React limits the number of renders to prevent an infinite loop.

Layer: JavaScript.

Why: state is set during render. The classic: onPress={setOpen(true)} calls the function immediately instead of passing it.

Fix:

Pass a function: onPress={() => setOpen(true)}.
Move state updates that depend on props into an event handler or a useEffect with the right dependencies.
The related "Maximum update depth exceeded" usually means a useEffect updates a value that's in its own dependency list.

8. Network request failed

TypeError: Network request failed

Layer: JavaScript, but the cause is usually the network setup.

Why: on a phone, localhost is the phone, not your computer. Other causes: plain http:// URLs, which Android blocks by default (and iOS App Transport Security restricts), or a server that isn't reachable from the device's network.

Fix:

Use your computer's LAN IP (for example http://192.168.1.20:3000) or a tunnel, and keep the phone on the same Wi-Fi.
Use https for anything outside local development.
Read the URL from an environment variable (EXPO_PUBLIC_API_URL) so dev and production can differ.

9. Package versions don't match your Expo SDK

The following packages should be updated for best compatibility with the installed expo version:
  react-native-reanimated@3.x.x - expected version: ~3.y.y

Layer: everywhere. Mismatched versions cause crashes at runtime and failures at build time.

Why: a library was installed with npm install instead of npx expo install, or the SDK was upgraded without updating its packages.

Fix:

npx expo install --fix
npx expo-doctor

When upgrading the SDK, follow the release notes and run npx expo install expo@^<version> --fix.

10. EAS Build failed

Gradle build failed with unknown error. See logs for the "Run gradlew" phase for more information.

or on iOS, a failed "Install pods" or "Run fastlane" phase.

Layer: native build.

Why: the last line rarely says much. The real cause is further up in the phase that failed: often a version mismatch (see #9), a config plugin that needs a setting you haven't added, or credentials and signing.

Fix:

Open the failed phase in the EAS build page and search for the first error: line.
Run npx expo-doctor and fix what it reports.
Reproduce locally with npx expo prebuild --clean and then npx expo run:android or npx expo run:ios, which is much faster to iterate on than cloud builds.

Paste the failed build log into the Error Fixer →

A debugging routine that works for most of these

Read the first error, not the last line. Red screens and build logs often end with something generic.
Name the layer: Metro, JavaScript, native module or native build.
Check how you run the app. Expo Go, a development build and a bare project behave differently.
Clear caches with npx expo start --clear before deeper changes.
Align versions with npx expo install --fix.

If you're stuck on an error that isn't in this list, the free React Native & Expo Error Fixer explains it in plain English: paste the error, choose where it happens and how you run the app, and it gives you the likely causes and the fix. It's made by RapidNative, where I work.

What's the Expo error that has cost you the most time? Drop it in the comments.

Passwordless Sign-In in Expo: Email OTP Codes with Supabase (No Deep Links)

Famitha M A — Mon, 26 Oct 2026 11:05:10 +0000

TL;DR

Magic links on mobile need deep links and redirect URLs. A 6-digit code needs neither.
In Supabase it's the same feature: put {{ .Token }} in the Magic Link email template and users get a code.
signInWithOtp({ email }) sends it, verifyOtp({ email, token, type: 'email' }) signs in.
The built-in email service only sends to your project's team. Set up custom SMTP before real users.
Codes are 6 digits, expire after 1 hour by default, and can be requested once per 60 seconds.

1. Template

Dashboard → Authentication → Email Templates → Magic Link:

<p>Your sign-in code: <strong>{{ .Token }}</strong></p>

2. Send

await supabase.auth.signInWithOtp({
  email: email.trim().toLowerCase(),
  options: { shouldCreateUser: true }, // false = existing users only
});

3. Verify

const { data, error } = await supabase.auth.verifyOtp({
  email: email.trim().toLowerCase(),
  token: code,
  type: 'email',
});

Normalize the email the same way in both calls, or the code will "never work".

4. The input that makes it feel native

<TextInput
  value={code}
  onChangeText={(t) => setCode(t.replace(/\D/g, '').slice(0, 6))}
  keyboardType="number-pad"
  autoComplete="one-time-code"
  textContentType="oneTimeCode"
  maxLength={6}
/>

oneTimeCode lets iOS suggest the code above the keyboard. Stripping non-digits makes pasting "123 456" work.

If you're building the screens around this from scratch, RapidNative generates an Expo Router + TypeScript project from a prompt that you can export and wire up like this. (I work on it.)

5. Resend cooldown

Supabase allows one request per 60 seconds, so show a countdown instead of an error:

const [cooldown, setCooldown] = useState(0);
useEffect(() => {
  if (!cooldown) return;
  const t = setTimeout(() => setCooldown((c) => c - 1), 1000);
  return () => clearTimeout(t);
}, [cooldown]);

Debug table

Symptom	Cause
Email has a link, not a code	No `{{ .Token }}` in the template
"Email address not authorized"	Built-in email service + non-team address. Use custom SMTP.
Code always rejected	Email casing/whitespace differs between calls
"You can only request this after..."	60s resend limit

Codes or magic links in your app? What made you pick one?

Expo + RevenueCat: Subscriptions in 5 Steps (and How to Test Them)

Famitha M A — Fri, 23 Oct 2026 12:57:12 +0000

TL;DR

Real purchases don't work in Expo Go. RevenueCat only runs a mock Preview API Mode there. Use a development build.
Configure the SDK once at startup with a per-platform public key.
Gate features on an entitlement (pro), never on product IDs.
purchasePackage throws when the user cancels. Check e.userCancelled and move on.
restorePurchases only from a button tap, never on launch.
Test with RevenueCat's Test Store first, then Apple/Google sandboxes before review.

1. Install and rebuild

npx expo install react-native-purchases react-native-purchases-ui expo-dev-client
eas build --profile development --platform all

Skip the rebuild and you'll get `new NativeEventEmitter()` requires a non-null argument, which RevenueCat's docs call out directly.

2. Configure once

// app/_layout.tsx
useEffect(() => {
  if (__DEV__) Purchases.setLogLevel(LOG_LEVEL.VERBOSE);
  Purchases.configure({
    apiKey: Platform.OS === 'ios'
      ? process.env.EXPO_PUBLIC_RC_APPLE_KEY!
      : process.env.EXPO_PUBLIC_RC_GOOGLE_KEY!,
  });
}, []);

Public SDK keys are fine in EXPO_PUBLIC_ vars. Secret keys never go in the app. If you have your own auth, call Purchases.logIn(userId) after sign-in.

3. Paywall

Lazy option, RevenueCat's prebuilt paywall, only shown if the user isn't already pro:

import RevenueCatUI, { PAYWALL_RESULT } from 'react-native-purchases-ui';

const result = await RevenueCatUI.presentPaywallIfNeeded({
  requiredEntitlementIdentifier: 'pro',
});

const hasPro = [
  PAYWALL_RESULT.PURCHASED,
  PAYWALL_RESULT.RESTORED,
  PAYWALL_RESULT.NOT_PRESENTED, // already subscribed
].includes(result);

Custom UI option:

const offerings = await Purchases.getOfferings();
const packages = offerings.current?.availablePackages ?? [];

async function buy(pkg: PurchasesPackage) {
  try {
    const { customerInfo } = await Purchases.purchasePackage(pkg);
    if (customerInfo.entitlements.active['pro']) unlock();
  } catch (e: any) {
    if (!e.userCancelled) showError(e);
  }
}

Render pkg.product.priceString, not a hard-coded "$4.99". Prices are per country.

4. One hook for access

export function useIsPro() {
  const [isPro, setIsPro] = useState(false);
  useEffect(() => {
    const update = (info: CustomerInfo) =>
      setIsPro(typeof info.entitlements.active['pro'] !== 'undefined');
    Purchases.getCustomerInfo().then(update).catch(() => {});
    Purchases.addCustomerInfoUpdateListener(update);
    return () => { Purchases.removeCustomerInfoUpdateListener(update); };
  }, []);
  return isPro;
}

The listener means renewals, expiries and restores update the UI live. Still check on your backend for anything valuable server-side.

If you're still building the screens that sit behind the paywall, RapidNative generates a plain Expo Router + TypeScript project from a prompt that you can export and drop this code into. (I work on it.)

5. Restore button

const info = await Purchases.restorePurchases();

RevenueCat's docs say to call this only from a user action, because it can pop an OS sign-in prompt. Put the button on the paywall and in settings.

Testing

Stage	Use
Building	RevenueCat Test Store key. No store accounts needed.
Pre-review	Platform keys + Apple sandbox / Google Play testing
Production	Platform keys. Never the Test Store key.

Android gotcha: products won't load unless a signed build is on a closed testing track, your account is a license tester, and you've opened the opt-in link. Sandbox renewals are fast (monthly every 5 min, yearly every 30 min, max six renewals), which is great for testing expiry.

Debug cheatsheet

Symptom	Cause
Empty offerings	Products not attached to the offering, or not active in the store
Nothing happens in Expo Go	Preview API Mode. Use a dev build.
Android products missing	Not on a testing track / not a license tester
Subscriber sees paywall	Checking product IDs, or missing `logIn`

What's been your biggest subscriptions headache in React Native: store setup, sandbox testing, or syncing access with your backend?

Expo Push Notifications: First Push in 5 Steps (and Why It Didn't Arrive)

Famitha M A — Thu, 22 Oct 2026 04:20:44 +0000

TL;DR

Remote push doesn't work in Expo Go on Android since SDK 53. Use a development build.
Android needs FCM V1 credentials on EAS; iOS needs a paid Apple account and an APNs key.
Create the Android notification channel before asking permission, or the prompt never shows on Android 13+.
Pass projectId to getExpoPushTokenAsync explicitly.
A ticket saying ok isn't delivery. Check receipts.

1. Install

npx expo install expo-notifications expo-constants

2. Credentials + dev build

Platform	Needs
Android	FCM V1 credentials uploaded to EAS
iOS	Paid Apple Developer account + APNs key (EAS CLI offers to create it)

eas build --profile development --platform android
eas build --profile development --platform ios

3. Permission + token

import * as Notifications from 'expo-notifications';
import Constants from 'expo-constants';
import { Platform } from 'react-native';

export async function registerForPushNotifications() {
  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'default',
      importance: Notifications.AndroidImportance.MAX,
    });
  }

  const { status: existing } = await Notifications.getPermissionsAsync();
  let status = existing;
  if (existing !== 'granted') {
    ({ status } = await Notifications.requestPermissionsAsync());
  }
  if (status !== 'granted') return null;

  const projectId =
    Constants?.expoConfig?.extra?.eas?.projectId ??
    Constants?.easConfig?.projectId;
  if (!projectId) throw new Error('Missing EAS projectId');

  return (await Notifications.getExpoPushTokenAsync({ projectId })).data;
}

Save the token on your backend against the user. And add a handler, or foreground notifications stay hidden:

Notifications.setNotificationHandler({
  handleNotification: async () => ({
    shouldShowBanner: true,
    shouldShowList: true,
    shouldPlaySound: false,
    shouldSetBadge: false,
  }),
});

4. Send one

Fastest: paste the token into expo.dev/notifications. From a server:

curl -X POST https://exp.host/--/api/v2/push/send \
  -H "Content-Type: application/json" \
  -d '{"to":"ExponentPushToken[xxx]","title":"Order shipped","body":"Tap to track","data":{"url":"myapp://orders/42"}}'

You get a ticket back. Fetch the receipt later for real delivery errors like DeviceNotRegistered.

5. Handle taps

useEffect(() => {
  const sub = Notifications.addNotificationResponseReceivedListener((res) => {
    const url = res.notification.request.content.data?.url;
    if (typeof url === 'string') Linking.openURL(url);
  });
  return () => sub.remove();
}, []);

With Expo Router, myapp://orders/42 lands on app/orders/[id].tsx.

Didn't arrive? Check this

Symptom	Cause
Nothing in Expo Go (Android)	No remote push there since SDK 53
No permission prompt (Android)	Channel not created first
Token call throws	Missing `projectId` or credentials
Ticket `ok`, nothing shows	Check receipt + device notification settings
Only fails in foreground	No `setNotificationHandler`
`DeviceNotRegistered`	Stale token. Delete it.
Android fails, iOS fine	FCM V1 creds missing / wrong project

Skipping the boilerplate

If you'd rather not hand-build the screens your notifications open, I work on RapidNative, which generates a standard Expo project (Expo Router, TypeScript, NativeWind) from a prompt. Export it and drop the code above in.

What broke your first Expo push: credentials, tokens, or the foreground handler?

How to Write a Spec an AI App Builder Can Actually Build From

Famitha M A — Fri, 16 Oct 2026 12:48:01 +0000

TL;DR

AI app builders fill every gap in your prompt with a guess. A spec is just a way of making fewer gaps.
The seven things that matter most: users, core jobs, screen list, data model, navigation, states, constraints.
Write the data model before the screens. Most "the AI built the wrong thing" moments are really "I never said what a record looks like."
Don't ask for the whole app and then fix it. Generate the skeleton, then iterate one screen at a time with small, testable asks.
There's a full example spec below you can copy and adapt.

If you've tried any AI app generator, you've probably had this experience. You type "build me a habit tracker app," hit enter, and get something that looks impressive for about ninety seconds. Then you notice it has a social feed you didn't want, no way to edit a habit, and a settings screen that doesn't do anything.

The model didn't fail. It did exactly what you asked, which was almost nothing. Every detail you left out, it had to invent. And its inventions are the average of every habit tracker it has ever seen, not the one in your head.

This post is about closing that gap with the same thinking you'd put into a brief for a human developer, written down more explicitly.

Why vague prompts produce generic apps

A short prompt isn't a simple request. It's a request with a huge number of unstated decisions. "Habit tracker" leaves open:

Who is this for? A student? Someone in recovery? A team?
Is a habit daily, weekly, or custom?
Can you miss a day without losing your streak?
Is there an account, or is everything local?
What happens on first launch when there's no data?

A human developer would come back with twenty questions. Most AI tools just pick defaults. Your job is to answer those questions up front.

The seven parts of a buildable spec

Here's the structure I use. You don't need every section to be long. You need every section to exist.

1. Users

One or two sentences per user type. Who they are and what context they're in when they open the app.

Primary user: someone trying to build 1 to 3 new habits, opening the app once or twice a day, usually for under 30 seconds.

That last bit ("under 30 seconds") is doing a lot of work. It tells the generator that check-ins need to be one tap, not a form.

2. Core jobs

What the user is trying to get done. Keep it to three to five. If you have twelve, you have a different problem.

Write them as verbs ("log today's check-in," "add a new habit"), not features ("calendar view"). Jobs tell the model why a screen exists.

3. Screen list

Name every screen and give it one line of purpose. This is the single highest-leverage section. If a screen isn't on the list, it probably shouldn't exist.

4. Data model

The entities, their fields, and how they relate. Plain English is fine, but be specific about types and required fields. Screens, forms, and the backend all depend on this, so mistakes here cause the most rework.

5. Navigation

How screens connect. Tabs or a stack? What's the first screen after login? Where does "back" go from a detail screen? Mobile navigation has a lot of conventions, and stating which one you want saves a round of corrections.

6. States

For every screen that shows data: what does it look like when it's empty, loading, errored, or full? Empty states especially. Every new user sees them first, and generators often skip them unless asked.

7. Constraints

The stuff that's easy to forget: platforms, auth method, offline needs, accessibility, things you explicitly don't want. "No social features" is a perfectly good constraint.

A worked example: a small habit app

Here's a complete spec for a deliberately small app. It's about 400 words, which is roughly the size I'd aim for on a first generation.

# App: Streakly (working name)

## Users
- Primary: an adult building 1 to 3 habits. Opens the app 1 to 2 times a day,
  usually for under 30 seconds. Wants a quick check-in, not a dashboard.

## Core jobs
1. Check in on today's habits in one tap each
2. Add, edit, or archive a habit
3. See progress for the current week and the current streak

## Screens
1. Sign in: email + magic link only
2. Today (home tab): list of active habits with a check-in button each
3. Habit detail: name, schedule, current streak, last 4 weeks as a grid
4. Add / edit habit: form (name, schedule, reminder time)
5. Progress (tab): this week across all habits, one row per habit
6. Settings (tab): reminder toggle, sign out, delete account

## Data model
- User: id, email, created_at
- Habit: id, user_id, name (required, max 40 chars),
  schedule ("daily" or list of weekdays), reminder_time (optional),
  archived (bool, default false), created_at
- CheckIn: id, habit_id, date (one per habit per day), created_at
- Streak is computed from CheckIns, not stored.

## Navigation
- Bottom tabs: Today, Progress, Settings
- Today -> Habit detail (push)
- Habit detail -> Edit habit (modal)
- "+" button on Today -> Add habit (modal)
- After sign in, land on Today

## States
- Today, no habits: friendly message + "Add your first habit" button
- Today, all done: show a short "All done for today" banner
- Habit detail, no check-ins yet: show empty grid, streak = 0
- Any network error: inline retry message, keep last loaded data visible

## Constraints
- iOS and Android, portrait only
- Must work with large text sizes (Dynamic Type / font scaling)
- No social features, no sharing, no gamification badges
- Check-in must be a single tap with immediate visual feedback
- Archived habits are hidden from Today but kept in the database

A few things worth pointing out:

"Streak is computed, not stored." Without this, a lot of generators will add a streak column and then forget to update it.
"One per habit per day." That's a uniqueness rule. It prevents double check-ins, and it's the kind of thing you only remember after you see the bug.
The "no" list. Telling the model what to leave out is as useful as telling it what to include.

Before and after

Here's the same idea expressed two ways.

Before:

Build a habit tracking app with streaks, reminders, and nice charts.
Make it modern and clean.

After (the condensed version for a chat-style prompt):

Build a mobile habit tracker for adults building 1 to 3 habits who open
the app for under 30 seconds at a time.

Screens: Sign in (email magic link), Today (home tab, list of habits with
one-tap check-in), Habit detail (streak + last 4 weeks grid), Add/Edit
habit (modal form: name, schedule, reminder time), Progress tab (this week,
one row per habit), Settings tab (reminders toggle, sign out).

Data: Habit (name max 40 chars, schedule daily or weekdays, optional
reminder time, archived flag). CheckIn (one per habit per day). Compute
streaks from check-ins, don't store them.

Empty state on Today: message plus "Add your first habit" button.
No social features. Portrait only. Support large text sizes.

"Nice charts" and "modern and clean" mean nothing specific. The "after" prompt is longer but leaves little room to wander, and it swaps "charts" for a 4-week grid, which is more concrete.

Iterate screen by screen, not app by app

Even a great spec won't produce a perfect app in one pass. The trick is how you handle the second pass.

The tempting move is to write a giant follow-up: "fix the Today screen, also the colors are off, also add dark mode, also the detail screen should show a chart." That usually breaks something that was working.

What works better:

Generate the skeleton first. All screens, navigation, and data model. Don't polish anything yet.
Check the data model before anything else. If the entities are wrong, every screen built on top of them will be wrong too.
Pick one screen and make one or two changes. Be concrete: "On Today, make the check-in button a 44pt circle on the right side of each row, and fill it when checked."
Test that screen on a device before moving on.
Repeat for the next screen.

Small asks are easier to apply and to verify. If something breaks, you know which change did it.

This is the workflow I use most days, because I work on RapidNative, which turns a plain-English description into a React Native + Expo project with screens, navigation, styling, and a Supabase backend. You can select a single screen and describe a change to just that screen, which pairs well with the loop above. The output is a standard Expo project (Expo SDK 54, React Native 0.81, Expo Router 6, NativeWind 4, TypeScript) that you can export whenever you want. But nothing in this post depends on a specific tool. The same spec and the same loop apply whatever builder you're using, or if you're handing the spec to a human developer.

Common mistakes that cost you a regeneration

A few patterns I see in prompts that reliably lead to rework:

Describing the look before the function. "Glassmorphism, purple gradient" before saying what the screen does. Get structure right first, style later.
Implicit auth. If you don't say how sign-in works, you'll get whatever the default is. Say "email magic link" or "no account, local only."
No empty states. Your first test user will see an empty app. Design for it.
Changing the data model mid-iteration without saying so. If you add a field, mention which screens should show it.

Wrapping up

What an AI app builder gives you is capped by what you give it. Users, jobs, screens, data, navigation, states, constraints. Write them down (twenty minutes, usually), generate a skeleton, then iterate one screen at a time.

What's the one section of a spec you always forget until the generated app makes it painfully obvious? For me it's empty states. I'd love to hear yours in the comments.

How long did your first mobile app take, from idea to install?

Famitha M A — Thu, 15 Oct 2026 08:58:24 +0000

TL;DR

The screens are rarely the slow part of shipping a first mobile app
Auth, backend, push notifications, builds/signing and store review eat the time
I'd love to hear how long yours took and what you'd do differently

Something I keep noticing in mobile dev threads: nobody complains that the screens took forever.

It's everything around them. Setting up auth. Wiring a backend. Getting push notifications working on both iOS and Android. Figuring out EAS builds, certificates and signing. Then waiting on the first App Store review, and finding out that fixing a typo means another one (unless you've set up OTA updates).

Where RapidNative fits

Full disclosure: I work on RapidNative, so this stretch is literally what we work on. You describe the app in plain English and it generates a real React Native + Expo project: screens, Expo Router navigation, NativeWind styling and a Supabase backend. You can export the code any time and keep building it like any other Expo app.

It handles the "blank project to working screens" part. It doesn't make App Store review any faster, and you still own your builds and signing. That's partly why I'm asking: I want to know which of the remaining steps hurt the most for other devs.

A few questions

How long did your first mobile app take, from npx create-expo-app (or whatever you started with) to something real users could install?
What ate the most time that you didn't expect?
Did you start from a boilerplate, a no-code tool, an AI builder, or from scratch? Would you pick the same again?

Drop your honest timeline in the comments, especially the ones that took way longer than planned. 👇

Building a 1-to-1 video call in React Native with WebRTC (and the parts tutorials skip)

Famitha M A — Fri, 09 Oct 2026 13:02:11 +0000

TL;DR

A video call is really five systems in a row: camera capture, codec negotiation (SDP), NAT traversal (ICE/STUN/TURN), a signaling channel, and connection repair.
You need react-native-webrtc, a signaling server that just relays JSON, STUN + TURN, and camera/mic permissions on both platforms.
It does not run in Expo Go. Use a dev build (EAS) with @config-plugins/react-native-webrtc, or bare RN.
Calls stuck at ICE checking are a TURN problem nine times out of ten. Budget ~1.35 GB of TURN per fully relayed hour at 720p.
Mesh is fine for 1-to-1 and maybe 3-4 people. Past that, reach for an SFU like LiveKit or mediasoup.

Pick your lane first: raw WebRTC or a managed SDK

WebRTC is a protocol, not a product. You either own the stack or buy pieces of it.

Option	You build	You pay for	Good for
Raw WebRTC + self-hosted signaling	Signaling, STUN/TURN, call state	Infra, debugging, TURN bandwidth	Learning, custom protocols, low volume
WebRTC + managed TURN (Twilio, Xirsys)	Signaling, call logic	TURN bandwidth per GB	Production 1-to-1 at modest scale
Managed SDK (Agora, Daily, Twilio Video, Dyte)	UI integration	Per-minute fees	Shipping this week

What I see most: people start raw to learn, then switch to a managed SDK the moment they need group calls, recording or noise suppression. That's fine. For a 1-to-1 app, raw WebRTC is the right call. For a Zoom clone, buy the stack. This post goes the raw route because once you get it, every other option makes sense.

The signaling dance in 6 steps

Media goes phone-to-phone. Your server never touches audio or video. It only helps the two peers find each other and agree on codecs:

Caller creates an RTCPeerConnection and attaches the local camera/mic stream.
Caller creates an SDP offer (codecs, resolutions, capabilities) and sends it through signaling.
Callee creates its own RTCPeerConnection, sets the offer as remote description, and sends back an SDP answer.
Both sides gather ICE candidates (possible network paths) and trickle them through signaling.
Candidates are tried in priority order: host, srflx (via STUN), relay (via TURN).
One works, the peer connection is up, signaling goes quiet, video flows.

If any step fails silently, both users see "ringing" and then nothing. Debugging WebRTC is basically logging every phase of this.

Setup

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

# Expo (dev build / EAS only, not Expo Go)
npx expo install react-native-webrtc @config-plugins/react-native-webrtc

Expo config plugin in app.json:

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

Then npx expo prebuild and eas build --profile development. If it crashes in Expo Go, that's expected: Expo Go can't load custom native modules.

Bare RN, iOS ios/<YourApp>/Info.plist:

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

Android android/app/src/main/AndroidManifest.xml:

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

On Android you also need runtime permission requests before touching the camera (PermissionsAndroid).

Grab the local camera stream

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

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

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

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

  if (!localStream) return null;

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

RTCView takes a streamURL, not the stream object. Stop the tracks on unmount, or the camera light stays on and users notice fast.

The peer connection (caller side)

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

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

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

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

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

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

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

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

  return pc;
}

The callee is the mirror: take the offer, setRemoteDescription(offer), createAnswer(), setLocalDescription(answer), send it back. Both sides keep swapping ICE candidates as they show up.

A signaling server in ~20 lines

Anything that relays JSON works: WebSocket, Socket.io, Firebase, Supabase Realtime. Socket.io is the clearest:

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

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

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

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

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

It's a dumb relay on purpose. Cheap to scale, and media is already encrypted end to end by WebRTC's SRTP.

For production, add JWT auth on the handshake, room access control, and persisted signals for callees who are offline when the call rings. Real call ringing means PushKit + CallKit on iOS and high-priority FCM + ConnectionService on Android, which is its own rabbit hole.

STUN, TURN, and the hotel Wi-Fi problem

STUN lets a peer discover its public IP. Google's stun:stun.l.google.com:19302 is free and fine for dev. But roughly 15% of users sit behind symmetric NATs (hotel Wi-Fi, corporate networks, carrier CGNAT) where STUN alone can't make a path. They need TURN, which relays the media itself.

TURN costs bandwidth. Your options:

Self-host coturn: cheapest at scale, needs DevOps time.
Managed TURN (Twilio Network Traversal, Xirsys, Metered): a few dollars per GB, live in minutes.
Hybrid: self-hosted for most traffic, managed as fallback.

Napkin math: 720p/30fps is ~1.5 Mbps each way, so one fully relayed hour is about 1.35 GB.

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

Rotate TURN credentials and never ship long-lived ones in the app. Most providers use the HMAC scheme from RFC 7635.

Render the remote stream + controls

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

Without zOrder={1} on Android, your picture-in-picture hides behind the remote view. iOS uses tree order, so it just works.

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

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

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

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

enabled = false doesn't renegotiate SDP, so it's cheaper than removing the track. _switchCamera() is a react-native-webrtc extra; on the web you'd call getUserMedia again.

What breaks in production

Simulator has no camera. Test video on real devices.
Vague permission strings get rejected. "App needs camera" fails App Store review. "Needed for video calling with contacts" passes.
ICE stuck at checking. Candidates were swapped but none worked. Almost always TURN. Log it:

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

Audio dies in the background. iOS: add audio to UIBackgroundModes. Android: run a foreground service during calls.
One side sees video, the other doesn't. SDP direction mismatch, usually offerToReceiveVideo: false or addTrack called after createOffer. Check for a=sendrecv on each media line.

The boring screens around the call

The call is the hard part. Login, contacts, call history, settings and notifications are standard mobile UI, and they still eat weeks. I'd rather spend that time on TURN configs. RapidNative generates those screens as real React Native + Expo code from a prompt, with a live preview on your phone, and you export the project and drop the WebRTC code from this post into it.

Going past 1-to-1

Mesh scales badly: every extra person adds another upload per device. A 4-person call uploads your video three times, and by 5 most mobile uplinks are done.

Mesh (what we built): fine up to 3-4 people on good networks.
SFU: each client uploads once and the server forwards. Scales to ~50. Open source: mediasoup, LiveKit, Janus. Managed: Daily, Dyte, 100ms.
MCU: the server mixes everything into one stream. Light on clients, heavy on servers, rare these days.

Need group calls? Start with LiveKit or mediasoup. Writing your own SFU is a six-month detour.

More reading: react-native-webrtc community docs and the W3C WebRTC spec.

What's your setup for TURN in production: coturn, a managed provider, or a mix? And has anyone found a clean way to handle CallKit ringing with react-native-webrtc? Drop it in the comments 👇

AI built your React Native app. Now check the auth: 6 things to verify before you ship

Famitha M A — Thu, 08 Oct 2026 12:05:25 +0000

TL;DR

AI app builders now produce real React Native + Expo projects, but auth is the part most likely to look done and still break in production.
Six checks catch most of it: session storage, route-level gating, hydration, token refresh, deep-link callbacks, and Row Level Security.
Use Stack.Protected in Expo Router instead of useEffect redirects. It removes the "flash of private screen" bug.
If you're choosing a tool to build native iOS and Android apps with AI, the first question is whether it outputs a native project (React Native, Swift, Kotlin) or a web app. That one answer rules out half the list.
Comparison table and "who each tool is for" are near the end.

Why auth is where AI-built apps break

Ask any AI app builder for "a habit tracker with login" and you'll get a sign-in screen in a minute. It renders, it calls the backend, it navigates to Home. Demo done.

Then a real user kills the app, opens it two days later, and lands on the login screen again. Or they tap a password-reset email and the link opens a browser tab that goes nowhere. Or someone discovers they can read every other user's rows with the key that's sitting in your JS bundle.

None of that shows up in a preview. All of it shows up in reviews. So here's the checklist, with the code you want to see in the generated project.

The examples use Expo Router and Supabase because that's the most common stack AI builders output for mobile today. The ideas carry over to Clerk, Firebase or your own API.

1. Where does the session live?

Open the file that creates the auth client. If there's no storage option, the session lives in memory and disappears on every cold start.

// lib/supabase.ts
import { AppState, Platform } from 'react-native';
import 'react-native-url-polyfill/auto';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { createClient } from '@supabase/supabase-js';

export const supabase = createClient(
  process.env.EXPO_PUBLIC_SUPABASE_URL!,
  process.env.EXPO_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
  {
    auth: {
      ...(Platform.OS !== 'web' ? { storage: AsyncStorage } : {}),
      autoRefreshToken: true,
      persistSession: true,
      detectSessionInUrl: false, // no URL bar on native
    },
  }
);

What to look for:

persistSession: true and a real storage adapter.
detectSessionInUrl: false on native. Generated code copied from a web example often leaves this true.
Only EXPO_PUBLIC_ variables in the client. If you see a service-role key in an EXPO_PUBLIC_ var, stop and rotate it. Anything with that prefix is shipped inside the app.

Want tokens in the Keychain/Keystore instead of AsyncStorage? expo-secure-store works, but it has a value size limit, so large sessions need an encrypted-AsyncStorage wrapper. Check what your generator did before assuming "secure".

2. Is auth gated at the router, or per screen?

This is the most common pattern in generated code:

// app/(app)/home.tsx  ❌ per-screen redirect
export default function Home() {
  const { session } = useSession();
  useEffect(() => {
    if (!session) router.replace('/login');
  }, [session]);
  return <Dashboard />;
}

It works, kind of. The private screen renders for a frame before the redirect, every new screen needs the same effect, and deep links can land a logged-out user on a private route.

Expo Router has a declarative answer: Stack.Protected. Screens inside it only exist while guard is true.

// app/_layout.tsx  ✅ route-level gating
import { Stack } from 'expo-router';
import { SessionProvider, useSession } from '@/lib/session';

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

function RootNavigator() {
  const { session } = useSession();

  return (
    <Stack screenOptions={{ headerShown: false }}>
      <Stack.Protected guard={!!session}>
        <Stack.Screen name="(app)" />
      </Stack.Protected>

      <Stack.Protected guard={!session}>
        <Stack.Screen name="login" />
        <Stack.Screen name="signup" />
      </Stack.Protected>
    </Stack>
  );
}

File structure that goes with it:

app/
  _layout.tsx        # the guard lives here, once
  login.tsx
  signup.tsx
  (app)/
    _layout.tsx      # tabs for signed-in users
    home.tsx
    settings.tsx

When session flips, Expo Router moves the user to the first available screen. No redirects sprinkled across the app. Docs: Protected routes.

3. What renders while the session is loading?

Reading a session from storage is async. If the guard runs before that finishes, session is null and a signed-in user sees the login screen for a moment, or gets bounced there.

Keep the splash screen up until you know:

// lib/session.tsx
import * as SplashScreen from 'expo-splash-screen';
import { createContext, useContext, useEffect, useState } from 'react';
import type { Session } from '@supabase/supabase-js';
import { supabase } from './supabase';

SplashScreen.preventAutoHideAsync();

const SessionContext = createContext<{ session: Session | null }>({ session: null });

export function SessionProvider({ children }: { children: React.ReactNode }) {
  const [session, setSession] = useState<Session | null>(null);
  const [ready, setReady] = useState(false);

  useEffect(() => {
    supabase.auth.getSession().then(({ data }) => {
      setSession(data.session);
      setReady(true);
      SplashScreen.hideAsync();
    });

    const { data: sub } = supabase.auth.onAuthStateChange((_event, s) => setSession(s));
    return () => sub.subscription.unsubscribe();
  }, []);

  if (!ready) return null; // splash stays visible

  return <SessionContext.Provider value={{ session }}>{children}</SessionContext.Provider>;
}

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

Check two things: an onAuthStateChange subscription exists (so sign-out anywhere updates the guard), and it's cleaned up.

4. Does the token refresh when the app comes back?

JavaScript timers pause when a mobile app is backgrounded. Without this, a user who returns after an hour makes requests with an expired access token:

// lib/supabase.ts (continued)
if (Platform.OS !== 'web') {
  AppState.addEventListener('change', (state) => {
    if (state === 'active') supabase.auth.startAutoRefresh();
    else supabase.auth.stopAutoRefresh();
  });
}

It's four lines and it's missing from a surprising amount of generated code, because web examples don't need it.

5. Do email links come back into the app?

Magic links, sign-up confirmation and password reset all send the user out to their mail app. Something has to bring them back.

A scheme in app.json / app.config.ts, e.g. "scheme": "habits".
The redirect URL passed to auth calls is built from that scheme, not hard-coded to localhost:

import * as Linking from 'expo-linking';

const redirectTo = Linking.createURL('/reset-password');

await supabase.auth.resetPasswordForEmail(email, { redirectTo });

That URL is added to the allowed redirect URLs in your auth provider's dashboard.
A reset-password route exists and reads the token from the incoming URL.

Test it on a real device with a real inbox. The simulator hides most of the ways this fails.

6. Is the database actually locked down?

The publishable key is in your bundle. Anyone can extract it. That's fine only if every table has Row Level Security on and sensible policies.

alter table public.habits enable row level security;

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

create policy "own habits: write"
  on public.habits for insert
  with check (auth.uid() = user_id);

Quick test: sign in as user A, copy a row id that belongs to user B, and try to fetch it from the app. You should get nothing back. If the generator created tables without RLS, that's a ship blocker, not a nice-to-have.

The checklist, in one block

[ ] Session persisted with a storage adapter; detectSessionInUrl false on native
[ ] No secret keys in EXPO_PUBLIC_ vars
[ ] Auth gated once, in the root layout, with Stack.Protected
[ ] Splash held until session is read; onAuthStateChange subscribed
[ ] AppState listener starts/stops token refresh
[ ] App scheme + redirect URLs set; reset-password route exists
[ ] RLS enabled on every table, tested with two accounts

Paste that into your PR template or your prompt. AI builders get noticeably better when you ask for these by name.

What is the best AI app builder for native iOS and Android apps?

Short answer: the one that outputs a native project you can open, export and ship, not a web app inside a wrapper. After that, it comes down to how much of the backend (auth, database, storage) is included and how you want to publish.

Here's a fair comparison using criteria that matter for the checklist above. It's based on each vendor's own site as of October 2026. Things a site doesn't state are marked as such rather than guessed.

Tool	What it outputs	iOS + Android	Auth / backend included	Code export	Preview on device
RapidNative	React Native + Expo (Expo Router)	Yes, one codebase (plus web)	Postgres, auth, storage, realtime per project; or bring your own Supabase	Yes (paid plans)	QR code on iPhone and Android
Rork	Native mobile apps from chat; Rork Max targets Swift for Apple devices	Yes	Rork Backend: data, auth, storage	Not stated on homepage	Not stated on homepage
Lovable	Web apps	Not as native projects	Yes, via Supabase	Yes	Browser
AI coding agent + template (Claude Code, Cursor)	Whatever you scaffold	Yes, if you start from Expo	Whatever you wire up	You own the repo	Expo Go / dev build

How to read it:

Lovable is excellent at what it's built for, which is web apps. If you need a store-listed iOS and Android app, you'll be converting or wrapping later.
Rork alternatives usually come up when people want a specific stack or ownership of the code. If you want a React Native/Expo codebase you can open in your editor, check that before you commit.
Coding agents give the most control and the least scaffolding. You'll be doing all six checks above by hand, which is fine if you're a developer and slow if you're not.

Where RapidNative fits

RapidNative is an AI app builder that turns a prompt, sketch, screenshot or product spec into a React Native and Expo app for iOS, Android and web, with auth and a Postgres database included in every project.

For this article's checklist, the relevant parts are that its projects use Expo Router for navigation, ship with sign-up, sign-in and password reset out of the box, and let you open the code in your own IDE or export it. That means you can run the six checks above on the actual project, rather than trusting a preview. If you want to try that loop, RapidNative has a free tier that doesn't need a card.

Who each option is for

Non-technical founders who want a mobile app: pick a builder that includes the backend and lets you test on your own phone by QR. Then hand this checklist to whichever developer reviews it before launch.
Developers prototyping for clients: a builder that exports a clean Expo project saves the boring first week, and you keep full control after.
Teams with an existing web app on Lovable: decide early whether you need a real native app. Rebuilding later costs more than choosing right now.
Developers who want total control: a coding agent plus a good Expo template, and this checklist taped to your monitor.

FAQ

Can AI build native iOS and Android apps?
Yes. Several tools now generate React Native/Expo or Swift/Kotlin projects rather than web apps. The output is real native code, but you should still review auth, permissions and store compliance before submitting.

Is React Native "native"?
React Native renders real platform UI components, not a web view. It's the same approach used by many large production apps, and Expo adds build, update and store tooling on top.

What's the most common auth bug in AI-generated mobile apps?
Missing session persistence or missing token refresh on app foreground. Both pass every demo and fail on the second day of real use.

That's the list I'd want run on any AI-built mobile app before it hits the store. What did your AI builder get wrong on auth? Drop the weirdest bug you've found in the comments, and which tool generated it.

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.

DEV Community: Famitha M A

The 10 Most Common Expo Errors and How to Fix Them

1. Unable to resolve module

2. "main" has not been registered

3. Text strings must be rendered within a <Text> component

4. VirtualizedLists should never be nested inside plain ScrollViews

5. Native module not found in Expo Go

6. Element type is invalid

7. Too many re-renders

8. Network request failed

9. Package versions don't match your Expo SDK

10. EAS Build failed

A debugging routine that works for most of these

Passwordless Sign-In in Expo: Email OTP Codes with Supabase (No Deep Links)

1. Template

2. Send

3. Verify

4. The input that makes it feel native

5. Resend cooldown

Debug table

Expo + RevenueCat: Subscriptions in 5 Steps (and How to Test Them)

1. Install and rebuild

2. Configure once

3. Paywall

4. One hook for access

5. Restore button

Testing

Debug cheatsheet

Expo Push Notifications: First Push in 5 Steps (and Why It Didn't Arrive)

1. Install

2. Credentials + dev build

3. Permission + token

4. Send one

5. Handle taps

Didn't arrive? Check this

Skipping the boilerplate

How to Write a Spec an AI App Builder Can Actually Build From

Why vague prompts produce generic apps

The seven parts of a buildable spec

1. Users

2. Core jobs

3. Screen list

4. Data model

5. Navigation

6. States

7. Constraints

A worked example: a small habit app

Before and after

Iterate screen by screen, not app by app

Common mistakes that cost you a regeneration

Wrapping up

How long did your first mobile app take, from idea to install?

Where RapidNative fits

A few questions

Building a 1-to-1 video call in React Native with WebRTC (and the parts tutorials skip)

Pick your lane first: raw WebRTC or a managed SDK

The signaling dance in 6 steps

Setup

Grab the local camera stream

The peer connection (caller side)

A signaling server in ~20 lines

STUN, TURN, and the hotel Wi-Fi problem

Render the remote stream + controls

What breaks in production

The boring screens around the call

Going past 1-to-1

AI built your React Native app. Now check the auth: 6 things to verify before you ship

Why auth is where AI-built apps break

1. Where does the session live?

2. Is auth gated at the router, or per screen?

3. What renders while the session is loading?

4. Does the token refresh when the app comes back?

5. Do email links come back into the app?

6. Is the database actually locked down?

The checklist, in one block

What is the best AI app builder for native iOS and Android apps?

Where RapidNative fits

Who each option is for

FAQ

Design Your Expo Router Tree Before You Write a Single Screen

3. Text strings must be rendered within a `<Text>` component

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

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