DEV Community: Hugo Rus

Supabase Background Jobs, Tested Locally: Cron, Queues, HTTP from SQL, and Webhooks

Hugo Rus — Mon, 12 Oct 2026 09:58:40 +0000

Every Supabase app eventually grows a background layer. A nightly cleanup job. A digest email every morning. A queue that processes uploads one at a time. A webhook that fires when an order is paid.

In Supabase, that layer is mostly SQL: pg_cron schedules jobs, pgmq queues work, pg_net makes HTTP calls from the database (usually to an Edge Function), and database webhooks fire on inserts and updates.

It's also the part of the app most teams never run locally. It's easy to push a cron job straight to the hosted project and find out the next morning that the schedule was in the wrong timezone, or that the Edge Function it calls rejected the request.

This post walks through the four building blocks with working SQL, the patterns that hold up in production, and how to exercise all of it on your laptop before it ships.

The four building blocks

Tool	Job	Typical use
`pg_cron`	Run SQL on a schedule	Nightly cleanup, scheduled digests
`pg_net`	Make HTTP requests from SQL	Call an Edge Function from a cron job or trigger
`pgmq`	Durable message queue in Postgres	Process work one item at a time, with retries
Database webhooks	HTTP call on insert, update, or delete	React to a row changing

Most real setups combine them: a cron job uses pg_net to call an Edge Function, which reads work from a pgmq queue.

1. Scheduled jobs with `pg_cron`

select cron.schedule(
  'purge-old-sessions',          -- job name
  '0 3 * * *',                   -- every day at 03:00
  $$ delete from public.sessions where created_at < now() - interval '30 days' $$
);

Inspect jobs and their runs:

select jobid, jobname, schedule, active from cron.job;

select jobid, status, return_message, start_time
from cron.job_run_details
order by start_time desc
limit 20;

Remove a job by name:

select cron.unschedule('purge-old-sessions');

The timezone trap. Hosted Supabase runs cron schedules in UTC. 0 3 * * * is 3am UTC, which might be the middle of your users' afternoon. Write the timezone in the job name or a comment, and check it before you ship.

2. Calling an Edge Function from SQL with `pg_net`

Most cron jobs shouldn't do the work in SQL. They should kick off an Edge Function that can call APIs, send email, and use secrets.

select net.http_post(
  url := 'https://<project-ref>.supabase.co/functions/v1/send-digest',
  headers := jsonb_build_object(
    'Content-Type', 'application/json',
    'Authorization', 'Bearer ' || (
      select decrypted_secret from vault.decrypted_secrets where name = 'digest_function_key'
    )
  ),
  body := jsonb_build_object('kind', 'daily')
);

Combine it with cron:

select cron.schedule(
  'daily-digest',
  '0 8 * * *',   -- 08:00 UTC
  $$
    select net.http_post(
      url := 'https://<project-ref>.supabase.co/functions/v1/send-digest',
      headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'Authorization', 'Bearer ' || (select decrypted_secret from vault.decrypted_secrets where name = 'digest_function_key')
      ),
      body := '{"kind":"daily"}'::jsonb
    );
  $$
);

pg_net is asynchronous: net.http_post queues the request and returns a request ID immediately. Check what came back in the response table:

select id, status_code, content, created
from net._http_response
order by created desc
limit 10;

Two rules:

Keep keys in Vault, not in the job's SQL. Anything written inline into cron.schedule is stored in plain text in cron.job.
Check net._http_response for failures. A 401 or 500 from your function won't surface anywhere else.

3. Queues with `pgmq`

When work needs to happen reliably, one item at a time, with retries if something fails, use a queue instead of a bare cron job.

select pgmq.create('image_jobs');

-- Producer: enqueue work (from a trigger, an RPC, or app code)
select pgmq.send('image_jobs', '{"image_id": "abc123"}'::jsonb);

A worker (usually an Edge Function called on a schedule) reads a batch:

-- Read up to 10 messages, hiding them from other readers for 60 seconds
select msg_id, read_ct, message
from pgmq.read('image_jobs', 60, 10);

When a message is processed, delete or archive it:

select pgmq.delete('image_jobs', 42);     -- done, discard
select pgmq.archive('image_jobs', 43);    -- done, keep a record

If the worker crashes before deleting a message, the visibility timeout (60 seconds above) expires and the message becomes readable again. That's your retry. Use read_ct to spot messages that keep failing and move them aside after a few attempts, so one bad message doesn't block the queue forever.

4. Database webhooks

Webhooks call a URL when rows change. The payload has a fixed shape your Edge Function can rely on:

{
  "type": "INSERT",
  "table": "orders",
  "schema": "public",
  "record": { "id": "o1", "status": "paid", "user_id": "u1" },
  "old_record": null
}

For UPDATE, both record and old_record are set. For DELETE, record is null.

Make handlers idempotent. Deliveries can be retried, and an UPDATE can fire even when the column you care about didn't change. Compare record and old_record before sending a receipt, and record what you've already processed.

Testing all of it locally

The usual options for running this before deploying:

The Supabase CLI (supabase start) runs the full Docker stack, including these extensions. It's the highest-fidelity local option, at about a dozen containers and roughly 1.4 GB of RAM.
tinbase, an open-source, Supabase-compatible backend that runs as one process with no Docker. It emulates pg_cron, pgmq, pg_net, Vault, and database webhooks, so the SQL above runs as written.

A local test loop with tinbase:

npx tinbase start

Put your jobs in a migration so every environment gets the same schedule:

-- supabase/migrations/20261012000000_background_jobs.sql
select pgmq.create('image_jobs');

select cron.schedule('process-images', '* * * * *', $$
  select net.http_post(
    url := 'http://127.0.0.1:54321/functions/v1/process-images',
    headers := jsonb_build_object('Content-Type', 'application/json'),
    body := '{}'::jsonb
  );
$$);

Then, in the Studio-style dashboard's SQL editor or from a test:

Enqueue a few messages with pgmq.send.
Wait a minute for the cron job to fire.
Check cron.job_run_details for the run.
Check net._http_response for the function's status code.
Check that the queue is empty (or the bad message is still there with a higher read_ct).

Edge Functions written with Deno.serve run in-process from supabase/functions/, so the cron → pg_net → function → queue loop happens entirely on your laptop.

What to know about the emulation:

It implements the surface real projects call, not every function each extension offers. If you use something exotic, check tinbase's compatibility table.
It's alpha, and built for local development and CI, not production.
Edge Functions with npm: or jsr: imports need bundling first.
Run your jobs once against the real Supabase CLI or a staging project before deploying, especially anything time-sensitive.

Checklist before shipping background jobs

[ ] Jobs are defined in migrations, not typed into the dashboard
[ ] Every schedule's timezone is written down (hosted cron runs in UTC)
[ ] Function keys live in Vault, never inline in cron.schedule
[ ] Someone (or something) checks net._http_response for errors
[ ] Queue workers delete or archive every processed message
[ ] Messages that fail repeatedly are moved aside using read_ct
[ ] Webhook handlers are idempotent and compare record with old_record
[ ] The whole loop has run at least once before it reaches production

Background jobs fail quietly, at 3am, in UTC. Running them on your laptop first is the cheapest insurance you can buy.

What's the background job that bit you hardest? I'd like to collect the war stories.

Your Own Expo Boilerplate in 60 Minutes: The Day-One Setup I Wish I'd Done Every Time

Hugo Rus — Thu, 08 Oct 2026 14:45:25 +0000

Every Expo project I've regretted had the same origin story: npx create-expo-app, straight into building screens, and "I'll set up the boring stuff later." Later arrived as a broken production build, secrets in the bundle, a crash nobody could reproduce, and a weekend of retrofitting.

The boring stuff takes about an hour on day one. On day ninety it takes a week. This is the checklist I now run before writing a single feature, in order, with the commands. At the end you have your own boilerplate: a repo you can copy for every new app.

0. Start from the current template (2 minutes)

npx create-expo-app@latest my-app
cd my-app
npx expo-doctor

The default template already gives you TypeScript, Expo Router, and an @/* path alias. Run expo-doctor immediately and fix anything it flags while the project is still empty.

1. Make TypeScript strict (5 minutes)

In tsconfig.json:

{
  "extends": "expo/tsconfig.base",
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "paths": { "@/*": ["./*"] }
  }
}

Add a script so CI and you run the same check:

{
  "scripts": {
    "typecheck": "tsc --noEmit"
  }
}

Turning strict mode on later means fixing hundreds of errors at once. Turning it on now means fixing zero.

2. Linting and formatting (5 minutes)

npx expo lint          # sets up ESLint with Expo's config on first run
npm i -D prettier eslint-config-prettier

Add the rules that catch real bugs, not style debates:

react-hooks/exhaustive-deps as an error
@typescript-eslint/no-explicit-any as an error
no-restricted-imports for @react-navigation/*, so navigation always comes from expo-router

3. Decide the folder structure before it decides itself (5 minutes)

app/                  # routes only (Expo Router)
components/           # reusable UI
features/<name>/      # screens' logic, hooks, and components per feature
lib/                  # clients (supabase, api), utilities
queries/              # data-fetching hooks
theme/                # colors, spacing, typography tokens

The rule that matters most: app/ contains routes, not logic. A route file imports a screen from features/ and renders it. Routes stay thin, and features stay testable.

4. Theme tokens before the first screen (5 minutes)

// theme/tokens.ts
export const colors = {
  bg: '#0B0B0F',
  surface: '#16161D',
  text: '#F5F5F7',
  muted: '#9A9AA3',
  primary: '#3B82F6',
  danger: '#EF4444',
} as const;

export const space = { xs: 4, sm: 8, md: 16, lg: 24, xl: 32 } as const;
export const radius = { sm: 6, md: 12, lg: 20 } as const;

Whether you use NativeWind, StyleSheet, or a UI kit, the tokens live in one place. When the designer changes the primary color, it's one line, not a search across forty files.

5. Data fetching that handles loading and errors (5 minutes)

npm i @tanstack/react-query

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

const queryClient = new QueryClient();

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

Then make it a rule: no fetch or database calls inside useEffect in screens. Every request goes through a hook in queries/, which gives you caching, retries, and loading and error states for free.

6. Secure storage for anything sensitive (3 minutes)

npx expo install expo-secure-store

Session tokens and refresh tokens go in the Keychain (iOS) or Keystore (Android) via expo-secure-store, not in AsyncStorage. Set the pattern now and every auth library you add later plugs into it.

7. Environment variables, the safe way (5 minutes)

Two kinds of values, two places:

Public config (API URL, publishable keys): EXPO_PUBLIC_ variables, which are inlined into the JavaScript bundle.
Secrets (third-party API keys, service keys): never in the app. They live on your server or in a serverless function the app calls.

Store build-time values in EAS so every machine and CI run uses the same ones:

npm i -g eas-cli
eas init
eas env:create --environment production --name EXPO_PUBLIC_API_URL --value https://api.example.com
eas env:pull --environment development

Add a CI check that fails if anything like EXPO_PUBLIC_.*SECRET appears in the repo.

8. Build profiles and a development build (10 minutes)

npx expo install expo-dev-client
eas build:configure

Set up three profiles in eas.json, each linked to its environment:

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "development": { "developmentClient": true, "distribution": "internal", "environment": "development" },
    "preview": { "distribution": "internal", "environment": "preview", "channel": "preview" },
    "production": { "environment": "production", "channel": "production", "autoIncrement": true }
  }
}

Then make your first development build:

eas build:dev --platform ios

From here on, you develop in your own dev client instead of Expo Go. Push notifications, payments, and most native modules don't work in Expo Go, so finding out on day one beats finding out the week before launch.

9. Over-the-air updates, configured safely (5 minutes)

npx expo install expo-updates
eas update:configure

In app.json, use the fingerprint runtime policy so an update only reaches binaries that can run it:

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

Now a JavaScript-only bug fix is a five-minute publish instead of a store review.

10. Crash reporting before the first user (5 minutes)

npx @sentry/wizard@latest -i reactNative

The wizard adds the SDK, the config plugin, and source map uploads during EAS builds. A crash report with a readable stack trace is the difference between "fixed in an hour" and "can't reproduce."

11. CI that runs on every pull request (5 minutes)

# .github/workflows/ci.yml
name: CI
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm run typecheck
      - run: npx expo lint
      - run: npx expo install --check

Three checks: types, lint, and dependency versions that match your Expo SDK. That last one catches the "works locally, fails on EAS" class of bugs before they cost a build.

12. The two screens every app needs (optional, but cheap now)

Settings → Account → Delete account. Both app stores require in-app account deletion if users can sign up. Add the route now, even if the button is a stub.
Error and empty states. A shared <ErrorState /> and <EmptyState /> component means every screen handles failure the same way.

Save it as your boilerplate

Once all twelve are done, commit the repo, tag it, and mark it as a GitHub template repository. Every new app starts with:

gh repo create my-next-app --template you/expo-boilerplate --private --clone

Update the template whenever you upgrade the Expo SDK, and every future project starts current.

The checklist

[ ] Fresh template, expo-doctor clean
[ ] Strict TypeScript and a typecheck script
[ ] ESLint and Prettier with bug-catching rules
[ ] Folder structure: routes in app/, logic in features/
[ ] Theme tokens in one file
[ ] TanStack Query for all data fetching
[ ] expo-secure-store for tokens
[ ] Public vs secret env vars separated; values on EAS
[ ] Three build profiles and a development build
[ ] expo-updates with fingerprint runtime version
[ ] Sentry with source maps
[ ] CI: typecheck, lint, dependency check
[ ] Account deletion route and shared error/empty states

About an hour of work, and every app you build afterward starts from a foundation instead of a to-do list.

If you'd rather skip straight to screens, RapidNative generates Expo apps as real React Native code you own, so you can drop them into a setup like this one and keep going.

What's on your day-one list that isn't on mine?

React Native Accessibility: The 2026 WCAG 2.2 Compliance Guide

Hugo Rus — Mon, 05 Oct 2026 11:00:29 +0000

Most React Native apps fail accessibility audits for the same dozen reasons, and almost none of them are hard to fix. An unlabeled icon button. A tap target that's 28 points wide. A modal that VoiceOver can read straight through. Text that clips at 200% font size.

This guide maps WCAG 2.2 Level AA to the React Native APIs that satisfy it, with code for each. If you build to WCAG 2.2 AA, you also meet WCAG 2.1 AA, because 2.2 is backwards compatible and only adds criteria (plus removes one obsolete one, 4.1.1 Parsing).

Not legal advice. If you're building for a government agency, a public university, or a healthcare provider, confirm your specific obligations with counsel.

Why this matters in 2026

The U.S. Department of Justice's ADA Title II rule makes WCAG 2.1 Level AA the technical standard for web content and mobile apps provided by state and local governments, including public schools, universities, courts, transit authorities, and public hospitals. That includes apps built for them by contractors.

The deadlines moved. On April 20, 2026, four days before the original deadline, DOJ published an interim final rule extending them by a year:

Public entity	Original deadline	Current deadline
Population 50,000 or more	April 24, 2026	April 26, 2027
Population under 50,000, and special districts	April 26, 2027	April 26, 2028

Two things the extension didn't change. First, it only delays the WCAG compliance dates; Title II's underlying nondiscrimination obligations still apply today, and those have supported accessibility lawsuits for years. Second, the separate HHS Section 504 rule for recipients of HHS funding kept its May 11, 2026 first deadline.

And outside the U.S., the European Accessibility Act has applied to many consumer-facing apps (banking, e-commerce, transport, e-books) since June 28, 2025.

Even without a legal requirement, roughly one in six people worldwide lives with a significant disability. Accessibility is a big chunk of your addressable market.

1. Label everything a screen reader can focus

WCAG 1.1.1 Non-text Content (A), 4.1.2 Name, Role, Value (A)

The single most common failure: icon-only buttons with no label. VoiceOver reads "button." TalkBack reads "unlabeled."

// ❌ Screen reader says: "button"
<Pressable onPress={onDelete}>
  <TrashIcon />
</Pressable>

// ✅ Screen reader says: "Delete note, button. Removes this note permanently."
<Pressable
  onPress={onDelete}
  accessibilityRole="button"
  accessibilityLabel="Delete note"
  accessibilityHint="Removes this note permanently"
>
  <TrashIcon />
</Pressable>

Rules of thumb:

Labels describe what it is, not what it looks like. "Delete note," not "trash can icon."
Don't put the role in the label. "Delete button" becomes "Delete button, button."
Hints are optional and describe the result. Use them only when the label isn't enough.
Decorative images should be hidden: accessible={false} on the Image, or wrap them in a parent that sets importantForAccessibility="no" on Android.

Since React Native 0.71 you can also use the web-style aria-* props and role, which map to the same native properties:

<Pressable role="button" aria-label="Delete note" onPress={onDelete}>
  <TrashIcon />
</Pressable>

Pick one style per codebase and lint for it.

2. Expose state, not just labels

WCAG 4.1.2 Name, Role, Value (A)

A checkbox that looks checked but announces nothing about its state fails, even with a perfect label.

<Pressable
  accessibilityRole="checkbox"
  accessibilityState={{ checked: isDone }}
  accessibilityLabel="Buy groceries"
  onPress={toggle}
>
  <Checkbox value={isDone} />
  <Text>Buy groceries</Text>
</Pressable>

Other states worth wiring up: selected for tabs and segmented controls, expanded for accordions, disabled for inactive buttons, and busy while something loads.

For sliders and progress bars, use accessibilityValue:

<View
  accessibilityRole="adjustable"
  accessibilityLabel="Volume"
  accessibilityValue={{ min: 0, max: 100, now: volume }}
  accessibilityActions={[{ name: 'increment' }, { name: 'decrement' }]}
  onAccessibilityAction={(e) =>
    setVolume((v) => (e.nativeEvent.actionName === 'increment' ? v + 10 : v - 10))
  }
/>

Without accessibilityActions, screen reader users can't change the value at all; swipe up and down on an adjustable element does nothing.

3. Group related content

WCAG 1.3.1 Info and Relationships (A)

A product card with an image, title, price, and rating becomes five separate swipe stops by default. Group it so it reads as one sentence:

<Pressable
  accessible
  accessibilityRole="button"
  accessibilityLabel={`${name}, ${price}, rated ${rating} out of 5`}
  onPress={openProduct}
>
  <Image source={{ uri: photo }} />
  <Text>{name}</Text>
  <Text>{price}</Text>
  <StarRating value={rating} />
</Pressable>

Setting accessible on the parent makes it a single focusable element. The label you write replaces the children's text, so make sure it includes everything that matters.

4. Make tap targets big enough

WCAG 2.5.8 Target Size (Minimum), new in 2.2 (AA)

WCAG 2.2 requires targets of at least 24×24 CSS pixels, with spacing exceptions. That's the legal floor. Apple's Human Interface Guidelines recommend 44×44 points and Material Design recommends 48×48 dp; aim for those.

You don't have to make the icon bigger. Use hitSlop to expand the touchable area:

<Pressable
  onPress={onClose}
  accessibilityRole="button"
  accessibilityLabel="Close"
  hitSlop={{ top: 12, bottom: 12, left: 12, right: 12 }}   // 20pt icon → 44pt target
>
  <CloseIcon size={20} />
</Pressable>

Watch for adjacent targets: two 24-point icons touching each other technically pass the size rule but are still hard to hit. Leave space between them.

5. Provide alternatives to dragging

WCAG 2.5.7 Dragging Movements, new in 2.2 (AA)

If a feature only works by dragging (reordering a list, a swipe-to-delete row, a range slider), there must be a single-pointer alternative. Typical fixes:

Swipe-to-delete → also show a delete action in a long-press menu or an edit mode.
Drag-to-reorder → add "Move up" and "Move down" buttons, or expose them as accessibility actions:

<View
  accessible
  accessibilityLabel={item.title}
  accessibilityActions={[
    { name: 'moveUp', label: 'Move up' },
    { name: 'moveDown', label: 'Move down' },
  ]}
  onAccessibilityAction={(e) => move(item.id, e.nativeEvent.actionName)}
/>

Screen reader users reach these through the actions rotor on iOS and the actions menu on Android.

6. Keep focus visible and unobscured

WCAG 2.4.7 Focus Visible (AA), 2.4.11 Focus Not Obscured (Minimum), new in 2.2 (AA)

Mobile users navigate with keyboards, switch control, and external devices more than most developers assume. The rule in 2.2: when an element receives focus, it can't be completely hidden behind something else, like a sticky footer, a floating action button, or a cookie banner.

In practice:

Don't remove focus indicators on TextInput and custom buttons.
Pad scroll views so the last focusable item can scroll clear of a sticky bottom bar (contentContainerStyle={{ paddingBottom: footerHeight }}).
Test with a hardware keyboard on iPad and with Switch Access on Android.

7. Trap focus in modals

WCAG 2.4.3 Focus Order (A)

When a modal opens, screen reader focus should move into it and stay there. React Native's built-in Modal handles this on both platforms. Custom overlays (a bottom sheet built from an absolutely positioned View) usually don't.

For custom overlays, hide everything behind them:

<View
  importantForAccessibility={sheetOpen ? 'no-hide-descendants' : 'auto'}  // Android
  accessibilityElementsHidden={sheetOpen}                                  // iOS
>
  <MainContent />
</View>
{sheetOpen && (
  <View accessibilityViewIsModal>   {/* iOS: ignore siblings */}
    <BottomSheetContent />
  </View>
)}

Then move focus to the sheet's heading when it opens:

const headingRef = useRef(null);

useEffect(() => {
  if (sheetOpen && headingRef.current) {
    const tag = findNodeHandle(headingRef.current);
    if (tag) AccessibilityInfo.setAccessibilityFocus(tag);
  }
}, [sheetOpen]);

8. Announce changes nobody can see

WCAG 4.1.3 Status Messages (AA)

"Item added to cart," "Saved," "3 results found." Sighted users see a toast; screen reader users hear nothing unless you announce it.

import { AccessibilityInfo } from 'react-native';

const addToCart = async () => {
  await api.addToCart(id);
  AccessibilityInfo.announceForAccessibility('Added to cart');
};

On Android you can also mark a region as live so updates are read automatically:

<Text accessibilityLiveRegion="polite">{resultCount} results</Text>

9. Support text scaling to 200%

WCAG 1.4.4 Resize Text (AA), 1.4.10 Reflow (AA)

React Native scales Text with the system font size by default. The failures come from layouts that can't handle it: fixed heights, single-line rows, and text that clips.

Don't disable scaling with allowFontScaling={false}. If a specific element genuinely can't grow (a tab bar label), cap it with maxFontSizeMultiplier={1.5} instead.
Avoid fixed heights on containers that hold text. Use minHeight.
Let rows wrap. flexWrap: 'wrap' or a column layout at large sizes.
Test at the largest accessibility size, not just the largest standard size. On iOS that's Settings → Accessibility → Display & Text Size → Larger Text.

10. Meet contrast minimums

WCAG 1.4.3 Contrast Minimum (AA), 1.4.11 Non-text Contrast (AA)

4.5:1 for body text
3:1 for large text (18pt, or 14pt bold) and for UI components like input borders, icons, and focus indicators

The usual offenders are light grey placeholder text, disabled-looking secondary buttons that aren't actually disabled, and thin icon strokes on colored backgrounds. Check both light and dark mode; a palette that passes in one often fails in the other.

Also: don't use color alone to convey meaning (1.4.1). An error field needs an icon or text, not just a red border.

11. Respect reduced motion

WCAG 2.3.3 Animation from Interactions (AAA, but widely expected)

import { AccessibilityInfo } from 'react-native';

const [reduceMotion, setReduceMotion] = useState(false);

useEffect(() => {
  AccessibilityInfo.isReduceMotionEnabled().then(setReduceMotion);
  const sub = AccessibilityInfo.addEventListener('reduceMotionChanged', setReduceMotion);
  return () => sub.remove();
}, []);

If you use Reanimated, useReducedMotion() does the same in one line. When reduce motion is on, replace slides and parallax with fades or instant transitions.

12. Don't make people re-type or memorize

WCAG 3.3.7 Redundant Entry (A), 3.3.8 Accessible Authentication (Minimum) (AA), both new in 2.2

Redundant Entry: if a user already entered their address in step 1 of checkout, prefill it in step 3 or offer "same as shipping."
Accessible Authentication: don't block password managers or paste. Set the right content types so autofill works:

<TextInput
  textContentType="emailAddress"      // iOS
  autoComplete="email"                // Android
  keyboardType="email-address"
/>
<TextInput
  textContentType="password"
  autoComplete="password"
  secureTextEntry
/>
<TextInput
  textContentType="oneTimeCode"       // iOS SMS code autofill
  autoComplete="sms-otp"              // Android
/>

Avoid CAPTCHAs that require transcribing distorted text. Passkeys, magic links, and biometrics all satisfy this criterion.

13. Keep help in the same place

WCAG 3.2.6 Consistent Help, new in 2.2 (A)

If your app offers help (a chat button, a support link, a phone number), put it in the same relative place on every screen that has it. A help icon in the header on one screen and in a settings submenu on another fails.

Testing: what to actually do

Automated tools catch maybe a third of issues. The rest needs a human with a screen reader.

Lint in CI. eslint-plugin-react-native-a11y flags missing roles, labels, and invalid states:

npm i -D eslint-plugin-react-native-a11y

{
  "extends": ["plugin:react-native-a11y/all"]
}

Test by role in unit tests. React Native Testing Library queries by role and label, so a test that can't find the button is also a screen reader that can't:

const deleteBtn = screen.getByRole('button', { name: 'Delete note' });
fireEvent.press(deleteBtn);

Run the platform tools.

iOS: Accessibility Inspector in Xcode (audit any simulator screen)
Android: Accessibility Scanner app from Google Play

Test manually, once per release, on real devices:

[ ] Navigate every core flow with VoiceOver (iOS) and TalkBack (Android), eyes closed
[ ] Every interactive element has a sensible label and role
[ ] Modals and sheets trap focus; closing returns focus to the trigger
[ ] Status changes are announced
[ ] Largest text size: nothing clips, overlaps, or disappears
[ ] Contrast passes in both light and dark mode
[ ] Every drag interaction has a tap alternative
[ ] Reduce motion is respected
[ ] Password managers and SMS code autofill work

Start with the 20% that fixes 80%

If you only have a day, do these in order:

Label every icon-only button.
Add hitSlop to every small target.
Fix text clipping at the largest font size.
Add accessibilityState to every checkbox, switch, and tab.
Announce toasts with announceForAccessibility.

That clears the majority of failures in a typical audit.

Building it in from the start

Retrofitting accessibility is far more expensive than starting with it. If you're generating new screens, RapidNative produces React Native and Expo code you own, so you can add the patterns above, lint for them, and keep them consistent as the app grows.

What's the accessibility bug you see most often in React Native apps? Mine is still the unlabeled icon button, every single time.

The Code Review Checklist for AI-Generated React Native (10 Things Agents Get Wrong)

Hugo Rus — Wed, 30 Sep 2026 06:44:46 +0000

AI-generated React Native code has a specific failure profile. It compiles. It renders. The screenshot looks right. And then a reviewer who's shipped a few apps opens the PR and finds the same ten problems they found in the last one.

That predictability is useful. If agents make the same mistakes, you can review for them mechanically, and you can stop most of them before they're written. This is the checklist I use when reviewing Claude Code, Cursor, or Codex output in Expo projects, with the fix for each and, where possible, a lint rule that catches it automatically.

1. Data fetching inside `useEffect`

The most common pattern in generated code:

useEffect(() => {
  supabase.from('notes').select('*').then(({ data }) => setNotes(data ?? []));
}, []);

No loading state, no error state, no refetch, no cache, and a race condition if the component remounts. The fix is a query library:

const { data: notes, isLoading, error } = useQuery({
  queryKey: ['notes'],
  queryFn: async () => (await supabase.from('notes').select('*')).data ?? [],
});

Catch it: an ESLint no-restricted-syntax rule that flags supabase.from inside useEffect, or a CLAUDE.md line: "All data fetching goes through TanStack Query hooks in src/queries/."

2. Secrets in `EXPO_PUBLIC_` variables

Agents fix a failing API call by moving the key to where it "works":

EXPO_PUBLIC_OPENAI_KEY=sk-...   # shipped to every user's device

Anything prefixed EXPO_PUBLIC_ is inlined into the JS bundle. Third-party keys belong in an Edge Function; the app calls the function with the user's session.

Catch it: a CI grep for EXPO_PUBLIC_.*(KEY|SECRET|TOKEN) that fails on matches, plus a deny rule in .claude/settings.json for reading .env.

3. Tables created without RLS

Generated migrations create the table and stop:

create table public.notes (...);
-- no "alter table ... enable row level security"

On mobile, RLS is the only security boundary, because the client key ships inside the binary.

Catch it: a CI query that fails if any public table has rowsecurity = false, and a deny-case test per table.

4. `any` everywhere, or no types at all

const handleSubmit = (data: any) => { ... }

Generated code reaches for any the moment a type gets inconvenient, which hides exactly the bugs TypeScript exists to catch.

Catch it: @typescript-eslint/no-explicit-any as an error, and npx tsc --noEmit in the agent's definition of done.

5. Inline styles mixed with the styling system

Half the components use NativeWind classes, half use style={{ marginTop: 12 }}, and a few use StyleSheet.create. Each one was locally reasonable; together they're unmaintainable.

Catch it: react-native/no-inline-styles from eslint-plugin-react-native, and a single line in the agent instructions naming the one system you use.

6. Lists without stable keys and without `FlashList`

{items.map((item, i) => <Card key={i} ... />)}

Index keys break reordering and deletion. A .map inside a ScrollView renders every item at once. Long lists need FlatList at minimum, and FlashList for anything that scrolls fast.

Catch it: react/no-array-index-key, and a review rule: any list that can exceed ~20 items uses a virtualized list.

7. No empty, loading, or error states

Generated screens show the happy path. First launch with no data renders a blank screen; a failed request renders nothing.

Catch it: a review checklist item, not a lint rule. Every screen that fetches needs three extra states. Ask the agent for them explicitly: "include loading, empty, and error states."

8. Keyboard covers the input

Forms work in the simulator and fail on a real device: the keyboard hides the submit button, and nothing scrolls.

Fix: KeyboardAvoidingView with behavior="padding" on iOS, or react-native-keyboard-controller for anything more than a login form.

Catch it: test every form on a physical device with the keyboard open. No lint rule saves you here.

9. Navigation imported from the wrong package

In Expo Router projects (SDK 56+), agents still import useNavigation from @react-navigation/native, which now creates a second navigation context and breaks routing.

Catch it: no-restricted-imports for @react-navigation/*, and the instruction "navigation comes from expo-router only."

10. Hardcoded strings and magic numbers

'Something went wrong' in twelve places, #3B82F6 in thirty, 1000 as a timeout with no name.

Catch it: a theme.ts and a strings.ts (or i18n setup) that exist before the agent starts, so it has somewhere to put them. Agents copy the structure they see.

The pattern behind the pattern

Look at the fixes: most of them are structure that existed before the agent wrote a line. A queries folder. A theme file. RLS in the migration template. Lint rules that fail the build. An instruction file that names the one way to do each thing.

Agents don't write bad code because they're bad at code. They write the code the codebase implies. Give them a codebase that implies good code, and the checklist mostly stops firing.

That's the thesis behind AppLighter: Expo + Supabase templates where the structure above (queries, theme, RLS migrations, lint config, agent instructions) is already in place, so Claude Code or Cursor extends a good codebase instead of inventing a mediocre one.

The checklist, copy-pasteable

[ ] No data fetching in useEffect; queries live in hooks
[ ] No secrets in EXPO_PUBLIC_; third-party keys in Edge Functions
[ ] Every new table enables RLS in the same migration
[ ] No any; tsc --noEmit passes
[ ] One styling system, no inline styles
[ ] Stable keys; virtualized lists for anything long
[ ] Loading, empty, and error states on every fetching screen
[ ] Forms tested with the keyboard open on a device
[ ] Navigation from expo-router only
[ ] Strings and tokens in strings.ts / theme.ts

What's on your list that isn't on mine? I'd bet the eleventh item is different for every team.

React Native Maps in Production: 7 Gotchas Nobody Warns You About

Hugo Rus — Wed, 23 Sep 2026 05:37:36 +0000

Every tutorial makes react-native-maps look easy. npx expo install, drop a <MapView>, done. Then you ship, and you meet the real map. The one with API keys that fail only in TestFlight, permission prompts that Apple rejects, and marker lists that turn your framerate into a slideshow.

Here are the seven things that would have saved me a week of debugging on my first production map screen.

1. The blank map is almost always a height problem

// Won't render. Parent has no explicit height.
<View>
  <MapView style={{ flex: 1 }} />
</View>

// Works.
<View style={{ flex: 1 }}>
  <MapView style={StyleSheet.absoluteFill} />
</View>

MapView needs an ancestor with a resolved height. flex: 1 inside a zero-height parent silently fails. StyleSheet.absoluteFill is the safest pattern.

2. `initialRegion` vs `region`: pick one and don't switch

Use initialRegion for uncontrolled maps where the user pans freely. Use region only if you have a genuine reason to re-center on every render. Otherwise you're fighting user gestures and the map feels broken.

3. API keys must be restricted per platform

An unrestricted "any bundle ID" key works in dev and gets rotated by Google abuse detection within a week of launch. Restrict:

iOS: by bundle identifier
Android: by package name + SHA-1 fingerprint

Do this on day 1. Rotating a key that's already in the wild is painful.

4. Location permission ordering matters

const fg = await Location.requestForegroundPermissionsAsync();
if (fg.status !== 'granted') return;
const bg = await Location.requestBackgroundPermissionsAsync();

You cannot get background permission on iOS without foreground first. And do not request permission on app launch. Ask when the user taps a "show my location" button. Apple reviewers will reject an unexplained cold prompt.

5. `Accuracy.BestForNavigation` will kill your battery

Location.getCurrentPositionAsync({
  accuracy: Location.Accuracy.Balanced,  // 👈 default for 99% of apps
});

BestForNavigation is for driving and running apps that literally need meter-level precision. It's roughly 10x the battery drain of Balanced. Apple reviewers do notice.

6. `watchPositionAsync` leaks if you don't clean it up

useEffect(() => {
  let sub: Location.LocationSubscription | undefined;
  (async () => {
    sub = await Location.watchPositionAsync(
      { accuracy: Location.Accuracy.Balanced, distanceInterval: 5 },
      (loc) => setPosition(loc.coords),
    );
  })();
  return () => sub?.remove();   // 👈 THIS line
}, []);

Forget the sub?.remove() and every screen visit adds a permanent GPS listener. Users notice the battery drain within a day.

7. Every `<Marker>` is a native view

Above roughly 200 to 300 markers on Android, frames drop. Above 2,000, iOS runs out of memory. Two fixes:

Cluster with react-native-map-clustering (a drop-in MapView replacement built on supercluster).
Bitmap markers. Set image={require('./pin.png')} instead of rendering React children. Native views for markers are cheap; React trees inside markers are expensive.

If you must render custom React markers, wrap them in React.memo and hoist all callbacks. Otherwise every pan re-renders every marker.

Bonus: expo-maps vs react-native-maps in 2026

Short version:

react-native-maps: huge community, works in Expo Go, needs a config plugin. The default choice.
expo-maps: SwiftUI and Jetpack Compose under the hood, faster startup, iOS 17+ only, no Expo Go. Good for greenfield apps.

For most teams shipping today, react-native-maps is still the safer bet, because every LLM, every Stack Overflow answer, and every AI code assistant still assumes it.

Speaking of which: the entire scaffold above (maps, permissions, markers, backend) can also be generated end to end from a prompt on RapidNative, if you'd rather skip the 400 lines of boilerplate and go straight to the differentiated part of your app.

Boilerplate That Actually Ships: What to Include (and Cut) in a 2026 React Native Starter

Hugo Rus — Wed, 23 Sep 2026 05:33:08 +0000

Why most React Native boilerplates fail past week 2

Boilerplates optimize for the wrong number. The number that matters isn't screens included. It's time-to-first-paid-user. Every extra screen, every extra library, every unused abstraction is a tax you pay on the second refactor. The boilerplates that survive past week 2 keep the surface area small and the defaults opinionated.

The five must-includes

Auth with session restore on cold start. Sign in with Apple wired, refresh tokens handled, and a password reset that doesn't 404 in production. The scaffold that skips this rebuilds it under pressure in month one.
Payments end to end. Stripe or RevenueCat, with one test charge working in TestFlight. Not a screen with a Buy button. A working flow. Payments is the plumbing every indie dev underestimates.
EAS Build + Submit wired. eas.json filled with staging and production profiles. GitHub Actions or manual submit, either works, but the pipeline must exist. If your first submission takes longer than an hour, that's a leading indicator of shipping never.
A real error boundary. react-native-error-boundary or a custom top-level catch, plus a crash-log SDK like Sentry or Bugsnag. Silent JS crashes in prod are the number one reason indie apps ship a broken v1.
OTA update channels. expo-updates with channel-level control. Push a JS bundle to a beta channel, promote to production without touching the app-store binary. This is where "faster to build" becomes "faster to fix".

The five to cut by default

The navigation grab-bag. Pick one (expo-router with typed hrefs) and delete the others. Multiple navigators in one boilerplate is a smell.
Animation libraries "just in case". Don't ship reanimated + moti + lottie + a bespoke animation hook. Include one and document why.
In-house UI kits. Every custom Button component is a maintenance burden. Use platform primitives or a maintained design-system library (Tamagui, Restyle), not a hand-rolled kit that will diverge.
Redux for a v1 app. Zustand or Jotai handles it. Redux plus Redux Toolkit plus RTK Query is 300 lines of setup before your first fetch.
The "example" screens. Delete the calendar demo, the chat demo, the map demo. They confuse new devs and drift into stale APIs.

The rename-screen test

Here's a one-minute audit for any starter you're evaluating. Rename screens/Home.tsx to screens/Dashboard.tsx. Everything that survives without manual patching (router, deep links, typegen) is a real boilerplate. Anything that needs a find-and-replace is a demo dressed up as one.

A pragmatic 2026 stack

Framework: Expo SDK 53+, expo-router with typed hrefs
State: Zustand for client, TanStack Query for server
Auth + DB: Supabase (or tinbase for local-first and self-host)
Payments: Stripe SDK + Payment Sheet
Style: Restyle or unistyles, design tokens on day one
CI: GitHub Actions + EAS Build with staging and prod profiles

The folder-deletion principle

The best RN scaffold is one you can delete a folder from. Every project ships a subset, and your job as a maintainer is to make the deletion trivial. We built RapidNative to generate React Native + Expo apps that start from these defaults. Grab it, or clone your own. The principles matter more than the repo.

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

Hugo Rus — Wed, 16 Sep 2026 04:58:11 +0000

Prompt-on-install caps push acceptance at ~45%; a third-session gate lifts it to ~78%
Session count is a proxy: tie the prompt to a habit moment when you have one
Skip the iOS pre-permission modal (net -6pp in practice)
Already shipped? Linking.openSettings() is your only recovery path

Most React Native tutorials on push notifications skip the single decision that matters most: when to ask.

The default in every boilerplate is to prompt on install day, usually in the onboarding flow. That decision quietly caps your addressable notification audience at whatever fraction of users don't tap "Don't Allow" during the least trusting three seconds of their relationship with your app. Across the RapidNative-built apps we can see, that fraction is about 45%.

Move the prompt to after the third session — or better, tie it to a habit-forming moment — and acceptance climbs to about 78%. The change is a 3-line delta in your app entry file. This post walks through the pattern.

What "the third session" actually means

You don't need a fancy engagement model. Track sessions in AsyncStorage:

import * as Notifications from 'expo-notifications';
import AsyncStorage from '@react-native-async-storage/async-storage';

const SESSION_KEY = 'session_count';
const PROMPTED_KEY = 'push_prompted';

export async function maybeAskForPushPermission() {
  const already = await AsyncStorage.getItem(PROMPTED_KEY);
  if (already) return;

  const rawCount = await AsyncStorage.getItem(SESSION_KEY);
  const count = parseInt(rawCount ?? '0', 10) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));

  if (count < 3) return;

  const { status } = await Notifications.requestPermissionsAsync();
  await AsyncStorage.setItem(PROMPTED_KEY, 'true');
  return status;
}

Call maybeAskForPushPermission() from your root layout's useEffect, not from onboarding. The user sees the prompt on their third open, in a moment where they've already decided your app is worth returning to.

Why the habit-moment version is better

Session count is a proxy. The signal you actually want is "user just completed a meaningful action." Tie the prompt to the completion event instead:

async function onFirstJournalEntrySaved() {
  await AsyncStorage.setItem('has_first_entry', 'true');
  await maybeAskForPushPermission();
}

Now the permission prompt lands in the exact second the user is thinking "I could see myself using this again." Different question in the user's head. Different answer.

The iOS-specific trap: pre-permission modal

The pattern iOS teams reach for — showing your own custom "Would you like push?" modal before triggering the real prompt — has a subtle failure mode. If the user taps "Yes" on your modal and "Don't Allow" on the real one, you cannot re-prompt. iOS is one-and-done.

Skip the pre-modal unless you have data that your specific audience needs it. In our tests it dropped acceptance by 6 percentage points net, because "yes to modal + no to real prompt" was a bigger cohort than "no to modal at all."

What to do if you already shipped with prompt-on-install

You cannot re-prompt users who already denied. But you can:

Add the delayed prompt for new installs.
Build a settings page that deep-links to the iOS Settings > Notifications page for your app, so denied users can re-enable manually. Linking.openSettings() handles this.
Show the deep-link once, in-app, at a habit moment. Don't nag.

The whole thing in ~20 lines

import * as Notifications from 'expo-notifications';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { Linking } from 'react-native';

const SESSION_KEY = 'session_count';
const PROMPTED_KEY = 'push_prompted';

export async function maybeAskForPushPermission(force = false) {
  if (await AsyncStorage.getItem(PROMPTED_KEY)) return;

  const count = parseInt((await AsyncStorage.getItem(SESSION_KEY)) ?? '0', 10) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));
  if (count < 3 && !force) return;

  const { status } = await Notifications.requestPermissionsAsync();
  await AsyncStorage.setItem(PROMPTED_KEY, 'true');
  return status;
}

// Recovery flow for users who already denied
export async function openNotificationSettings() {
  const { status } = await Notifications.getPermissionsAsync();
  if (status === 'denied') await Linking.openSettings();
}

That is the pattern. Session-count gate, tie to a habit moment if you can (pass force = true from the completion event), use Linking.openSettings() for the recovery flow.

Something like RapidNative ships this gate in its generated Expo projects by default, so if you're scaffolding a new app the prompt is already off line 3 before you've written anything.

Don't ship the 45% cap

The point of writing this up is not that it's complex. It's that this is the highest-leverage thing you can do to your push notification stack this quarter, and most React Native tutorials still show you requestPermissionsAsync() on line 3 of the app.

If you've measured acceptance before and after moving the prompt, drop a comment with your numbers. Curious whether the third-session threshold holds across categories or whether it's a journaling/fitness thing.

How to Build an AI-Powered Personal Finance App with React Native and Expo

Hugo Rus — Fri, 04 Sep 2026 13:07:27 +0000

Four Postgres tables + RLS cover 90% of a personal finance MVP
Rules-based categorization first, LLM fallback second (the LLM's job is bootstrapping the rules)
Skip Plaid at v1: manual entry, done well, is a real product
Prompt-scaffold the v1, spend your time on categorization heuristics and first-run UX

Personal finance is one of those categories where the market keeps growing but the incumbents keep frustrating users. Mint shut down, YNAB raised prices, and Rocket Money spent its way to a huge user base. If you're a React Native dev thinking about building in this space, 2026 is a great time. AI-native tooling collapses the scaffolding phase enough that a solo dev can ship a real v1 in a week.

Here's how I'd approach it end to end.

The core data model (Postgres via Supabase)

Four tables cover 90% of what a personal finance app does:

create table accounts (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  name text not null,
  type text check (type in ('checking','credit','cash','savings')),
  currency text default 'USD',
  balance numeric(14,2) default 0,
  created_at timestamptz default now()
);

create table categories (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  name text not null,
  icon text,
  color text,
  monthly_budget numeric(14,2)
);

create table transactions (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  account_id uuid references accounts not null,
  category_id uuid references categories,
  amount numeric(14,2) not null,
  merchant text,
  notes text,
  occurred_at timestamptz not null,
  created_at timestamptz default now()
);

create index on transactions (user_id, occurred_at desc);

Enable RLS on every table with user_id = auth.uid() policies. This is not optional in a finance app. It's the difference between "shipped an MVP" and "leaked a stranger's bank data."

The screen tree

Expo Router, tabs at the root:

(tabs)/index.tsx: home with month spend, budget remaining, category donut, recent transactions
(tabs)/transactions.tsx: list, grouped by day, with search + filter
(tabs)/budgets.tsx: card per category
(tabs)/insights.tsx: charts (I use victory-native for these)
(tabs)/settings.tsx: biometric toggle, currency, CSV export, dark mode
add-transaction.tsx: big number pad, merchant autocomplete, category picker

Add-transaction is the one screen users touch daily. Optimize the hell out of it.

The AI categorization loop

Two layers:

Rules table. Regex on merchant string -> category_id. Covers 70–80% of what you see in practice ("STARBUCKS.*" -> Coffee).
LLM fallback. For unmatched merchants, prompt a model with the merchant + the user's category list, ask for { category_id, confidence }. Store the answer so it becomes a rule. Cache aggressively: the same 100 merchants generate 80% of a user's transactions.

Do the rules first, add the LLM later. It's the correct order because the LLM's whole job is to bootstrap the rules table.

Bank connections: later, not now

Every finance-app tutorial jumps straight to Plaid. Don't. Plaid charges per connected user per month once you're out of the free tier, and it comes with a real support burden ("why does my bank keep disconnecting?"). Ship a well-designed manual tracker first. Add Plaid in v2 as a Pro feature once you have signal that users actually want the automation.

If and when you do connect, use their Link SDK. Never accept bank credentials in your own UI, ever.

The AI-native way to scaffold all of this

I've built React Native apps by hand and by prompting, and there's no serious argument for hand-scaffolding a v1 anymore. Prompt the whole thing:

A personal finance app with tabs: home, transactions, budgets, insights, settings. Home shows monthly spend, remaining budget, category donut chart. Add-transaction has a big number pad, merchant autocomplete, category picker, account selector. Use Supabase for auth + data. Enable RLS. Dark palette, subtle green for income, subtle red for expenses.

Something like RapidNative will spit out a real Expo project: real navigation, real Supabase client, generated types matched to the schema. You spend your time on the actually-hard parts (categorization heuristics, chart clarity, first-run UX) instead of typing useNavigation for the eightieth time in your life.

Whatever tool you pick, verify it exports plain code. You want to own the project, not rent it.

Security checklist before you ship

Biometric unlock (Expo LocalAuthentication), required on cold start after N minutes.
No sensitive fields in Sentry / analytics payloads.
RLS on every table.
HTTPS only (default in Expo, but audit anyway).
Data export + delete-my-account (GDPR/CCPA, also good UX).

What I'd skip on day one

Investment tracking (whole different data shape).
Bill negotiation / subscription cancellation (Rocket Money moat; expensive to build).
Real bank connections (Plaid).
Household / joint budgeting (v2 feature).

Ship view-only + manual + smart categorization. That's a real product.

Try the prompt path first

Even if you're a seasoned dev, prompt the first version before you write a line. Worst case you throw it out. Best case you shave weeks off your MVP. The free tier is enough to see whether the output is close to what you'd build.

Ship soon. The category is wide open. If you're building in fintech-adjacent RN right now, drop a comment with what you're working on. Curious what the categorization edge cases look like in other people's data.

Your app/ folder is your information architecture

Hugo Rus — Wed, 02 Sep 2026 10:37:48 +0000

Information architecture is the deliverable everyone nods along to and nobody enforces. You draw the sitemap in Figma. A developer builds the navigator tree in code. Six weeks later the two have quietly drifted, and onboarding someone new takes a thirty-minute explanation of why Settings lives inside the Account stack when the design has it as a top-level tab.

Expo Router's file-based routing removes that gap. Not by adding process, but by making the folder structure the thing both sides read.

The folder is the sitemap

Here is the shape of a real app:

app/
├── _layout.tsx
├── (tabs)/
│   ├── _layout.tsx
│   ├── index.tsx           # Home
│   ├── explore.tsx         # Explore
│   └── profile/
│       ├── _layout.tsx
│       ├── index.tsx
│       ├── edit.tsx
│       └── settings.tsx
├── (auth)/
│   ├── _layout.tsx
│   ├── login.tsx
│   └── signup.tsx
└── modal.tsx

Open that in any file explorer and the app's shape is visible without reading a line of TypeScript. Three tabs. A nested profile section. An auth flow in its own gated group. A modal at the top level, because it can be presented from anywhere.

Now compare it to RootNavigator.tsx → TabNavigator.tsx → ProfileStack.tsx. The same information exists, spread across three files, and none of them show the shape at a glance. A designer can't open those files and learn anything. They can open the folder tree.

Moving a screen is moving a file

Say you want to promote Settings out of Profile and up to a top-level tab.

mv app/\(tabs\)/profile/settings.tsx app/\(tabs\)/settings.tsx

That's the change. No navigator config to update, no linking config to rewrite, no screenOptions to migrate. The route is now /settings instead of /profile/settings, and with typed routes turned on, every router.push that pointed at the old path either autocompletes to the new one or gets flagged by TypeScript before it ships.

The design intent — this should be top-level — becomes one commit. That matters more than it sounds. When a structural change costs an afternoon of navigator surgery, it doesn't get made. It gets deferred, and the sitemap becomes aspirational.

Layouts are where design lives

Each _layout.tsx defines the header, the tab bar, the presentation style, and the safe-area handling for everything beneath it. That makes it the single file that answers the questions design review actually asks: what does someone see when they enter this section? What's the back affordance? What's the visual container?

In a navigator-based app, those answers are scattered across screenOptions, tab bar props, and headerLeft overrides on individual screens. Reviewing them as a designer means asking a developer to narrate the code. With _layout.tsx, it's one file per section, and you can read it.

A five-minute IA review

We run this weekly. Design and engineering open the app/ folder together and ask three questions:

Does the folder shape still match the sitemap?
Are there orphaned routes — files with no entry point in the UI?
Has any _layout.tsx drifted from its section-header spec?

It used to take the better part of an hour on a navigator-based project, mostly spent reconstructing the tree from three files before anyone could evaluate it. Now the reconstruction step is free.

What we catch is unglamorous and worth catching: the profile stack that grew a fifth screen nobody remembers adding, the modal that got promoted to a full screen but kept its presentation: 'modal' prop, the route that survived a feature cut.

The part that isn't automatic

File-based routing makes drift visible. It doesn't stop it. Groups like (tabs) and (auth) don't appear in the URL, so the folder tree and the navigation model can still diverge if you nest groups aggressively. And a folder structure that mirrors your sitemap perfectly can still describe a bad sitemap.

What changes is the cost of noticing. When the IA is a file tree, anyone on the team can audit it in a minute — and the thing that stops IA reviews from happening is almost never disagreement. It's that nobody can see the current state clearly enough to have the argument.

If you're leading design on a React Native app and you've never opened the app/ folder, open it. It's the most honest artifact you have.

Suraj from the RapidNative Team. We build RapidNative, which generates real React Native and Expo projects from a prompt — file-based routing included.

Real-Time Location Tracking in React Native, Including Live Sharing

Hugo Rus — Fri, 28 Aug 2026 11:17:07 +0000

The moving dot on a delivery app looks trivial. Underneath it: a permission sequence that fails silently if you get the order wrong, a background task the OS actively wants to kill, a battery budget you have to defend, and a connection that has to survive a phone going into a pocket.

Most tutorials stop at watchPositionAsync on a demo screen. This goes through to live sharing between two devices.

Request foreground permission first, background second, and never on launch
Define the background task at module top level, not inside a component
Android needs a foreground service or the OS kills the task within minutes
Use broadcast for live position, not database inserts
Coarsest accuracy and longest interval that still feels responsive

The stack

npx expo install expo-location react-native-maps expo-task-manager
npm install @supabase/supabase-js

expo-location handles foreground and background GPS plus permissions. react-native-maps renders Apple Maps on iOS and Google Maps on Android. expo-task-manager is required for background location. Supabase provides the realtime channel for the sharing half.

Step 1: Permissions

This is where most of the bugs live.

{
  "expo": {
    "plugins": [
      [
        "expo-location",
        {
          "locationAlwaysAndWhenInUsePermission": "Allow $(PRODUCT_NAME) to share your live location.",
          "isIosBackgroundLocationEnabled": true,
          "isAndroidBackgroundLocationEnabled": true
        }
      ]
    ],
    "ios": { "infoPlist": { "UIBackgroundModes": ["location", "fetch"] } }
  }
}

Request foreground first, background second. Always that order.

import * as Location from 'expo-location';

async function requestLocationPermissions() {
  const { status: fg } = await Location.requestForegroundPermissionsAsync();
  if (fg !== 'granted') throw new Error('Location required');

  const { status: bg } = await Location.requestBackgroundPermissionsAsync();
  if (bg !== 'granted') console.warn('Background disabled');
}

And do not request background on app launch. Wait until the user taps something that needs it, like "start sharing". Asking for always-on location from a stranger is how you get a permanent denial on the first screen.

Step 2: Foreground tracking

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

export function useLiveLocation() {
  const [location, setLocation] = useState<Location.LocationObject | null>(null);

  useEffect(() => {
    let sub: Location.LocationSubscription | null = null;
    (async () => {
      sub = await Location.watchPositionAsync(
        {
          accuracy: Location.Accuracy.BestForNavigation,
          timeInterval: 2000,
          distanceInterval: 5,
        },
        setLocation,
      );
    })();
    return () => sub?.remove();
  }, []);

  return location;
}

Three knobs:

accuracy. Balanced for delivery ETAs, BestForNavigation for anything where a few metres matters.
timeInterval. Minimum milliseconds between fixes.
distanceInterval. Minimum metres moved before firing. Set this to 5 or 10, otherwise a stationary user on a poor fix floods your UI with jitter.

That last one is the difference between a dot that sits still and a dot that vibrates.

Step 3: The map

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

export function TrackingScreen() {
  const location = useLiveLocation();
  if (!location) return null;

  const region = {
    latitude: location.coords.latitude,
    longitude: location.coords.longitude,
    latitudeDelta: 0.005,
    longitudeDelta: 0.005,
  };

  return (
    <MapView style={{ flex: 1 }} region={region} showsUserLocation>
      <Marker coordinate={region} title="You are here" />
    </MapView>
  );
}

Use region, not initialRegion, if you want the map to follow. For a marker that slides between fixes rather than teleporting, animate the coordinate rather than setting it directly.

Step 4: Background tracking

Define the task at module top level. Not inside a component, not inside a hook. The OS invokes it before your React tree exists.

import * as TaskManager from 'expo-task-manager';
import * as Location from 'expo-location';

const LOCATION_TASK = 'background-location-task';

TaskManager.defineTask(LOCATION_TASK, ({ data, error }) => {
  if (error || !data) return;
  const { locations } = data as { locations: Location.LocationObject[] };
  void sendLocationsToServer(locations);
});

export async function startBackgroundTracking() {
  await Location.startLocationUpdatesAsync(LOCATION_TASK, {
    accuracy: Location.Accuracy.Balanced,
    timeInterval: 10_000,
    distanceInterval: 25,
    foregroundService: {
      notificationTitle: 'Sharing your location',
      notificationBody: 'Tap to open the app.',
    },
    pausesUpdatesAutomatically: true,
    activityType: Location.ActivityType.Fitness,
  });
}

Two non-negotiables. On Android, foregroundService or the OS kills the task within minutes. On iOS, UIBackgroundModes: ["location"] or you get rejected at review.

Step 5: Live sharing

The part most tutorials skip.

A Supabase Realtime channel must be subscribed before it will send anything. Creating a channel and immediately calling send transmits nothing, and it fails quietly, which makes it a genuinely unpleasant afternoon.

import { createClient } from '@supabase/supabase-js';
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

// create and subscribe once, then reuse
export function createSession(sessionId: string) {
  const channel = supabase.channel(`session:${sessionId}`);
  channel.subscribe();
  return channel;
}

export function shareLocation(channel, loc: Location.LocationObject) {
  return channel.send({
    type: 'broadcast',
    event: 'position',
    payload: {
      lat: loc.coords.latitude,
      lng: loc.coords.longitude,
      heading: loc.coords.heading,
      at: Date.now(),
    },
  });
}

On the observing device:

useEffect(() => {
  const channel = supabase
    .channel(`session:${sessionId}`)
    .on('broadcast', { event: 'position' }, ({ payload }) => {
      setPeerLocation({ latitude: payload.lat, longitude: payload.lng });
    })
    .subscribe();

  return () => { void channel.unsubscribe(); };
}, [sessionId]);

Broadcast, not database inserts. Inserting every fix burns through row quota and forces observers to poll. If you also need history for a breadcrumb trail or route replay, write to a table on a much slower cadence in addition to the broadcast. Two different jobs, two different mechanisms.

Battery

Continuous high-accuracy GPS is one of the most expensive things an app can do, and the cost scales with accuracy and frequency in roughly the way you'd expect.

The ordering that matters:

Config	Relative cost
`BestForNavigation`, 1 to 2s, foreground	Highest
`Balanced`, 10s, background	Moderate
`Lowest`, 30s, background	Lowest

Absolute numbers depend heavily on device, OS version, and whether the screen is on, so measure on your own target hardware rather than trusting anyone's table, including this one.

The rule that generalises: use the coarsest accuracy and longest interval that still feels responsive, and set pausesUpdatesAutomatically: true, which lets iOS suspend tracking when the user has stopped moving. That last flag is close to free and it does more than most tuning.

Pitfalls

Blank map on Android. Missing android.config.googleMaps.apiKey in app config.
watchPositionAsync never fires in the simulator. The iOS simulator has no GPS. Set a custom location from the simulator's location menu.
Permission dialog on every launch. You're calling request* where you should call get* first and only request when the answer is undetermined.
Background works locally, dies in production. Missing UIBackgroundModes on iOS or foregroundService on Android. Both work fine in development, which is what makes this one expensive.

Skipping the plumbing

If you want the scaffold without the permission archaeology, RapidNative generates the Expo and Supabase project from a description, and the output is real React Native you can export and finish wherever you normally work.

The parts above still need understanding. Generated or not, the OS is going to kill your background task if the foreground service isn't configured, and no scaffold argues with that.

What's your background tracking horror story? Mine was a task that worked for three weeks and then stopped, because the notification the foreground service depends on had been silently disabled by the user.

Reanimated vs Moti vs Skia: Which React Native Animation Library Should You Actually Use?

Hugo Rus — Mon, 24 Aug 2026 11:52:58 +0000

Every React Native team eventually asks the same question: Reanimated, Moti, or Skia?

The framing is wrong. These three don't compete, they compose. Here's the mental model that will save you a bad refactor.

Reanimated is the runtime. The other two depend on it.
Moti is a declarative wrapper over Reanimated. Less code, less control.
Skia is a rendering engine, not an animation library. It accepts Reanimated shared values directly.
Install Reanimated and Moti on day one. Add Skia when the design demands it.
Pick per interaction, not per app.

The one-sentence version of each

Reanimated. The animation runtime. Runs worklets on the UI thread through JSI. Everything else you install depends on it directly or indirectly.

Moti. A Framer Motion-style declarative wrapper over Reanimated. Less code for common transitions.

Skia. Google's 2D graphics engine, the one behind Chrome and Flutter, exposed as React Native components. Not an animation library. A rendering engine that happens to animate beautifully when you feed it shared values.

Reanimated in about ten lines

import Animated, { useSharedValue, useAnimatedStyle, withSpring } from 'react-native-reanimated';

const x = useSharedValue(0);
const style = useAnimatedStyle(() => ({
  transform: [{ translateX: x.value }],
}));

// somewhere in a handler:
x.value = withSpring(200);

return <Animated.View style={[styles.box, style]} />;

x is a shared value, and it lives on the UI thread. useAnimatedStyle is a worklet that reruns when x changes. A blocked JS thread doesn't stutter the animation, which is the entire point.

The same thing in Moti

<MotiView
  from={{ translateX: 0 }}
  animate={{ translateX: 200 }}
  transition={{ type: 'spring' }}
/>

Same worklets underneath. Half the code.

That's the trade: you lose direct access to the shared value, which matters the moment you want to drive it from a gesture. For a mount transition you'll never miss it. For a drag you'll rewrite it.

Where each one wins

You need	Use
A fade-in on mount	Moti
A pan gesture moving a card	Reanimated
A skeleton loader	Moti
Pinch-to-zoom on an image	Reanimated
An animated chart with 60+ points	Skia + Reanimated
A shader-driven splash screen	Skia
A stagger animation on a list	Moti
A blur that follows a bottom sheet	Skia + Reanimated

The composition detail people miss

Skia components accept Reanimated shared values as props directly. No createAnimatedComponent, no useAnimatedProps wrapper.

const progress = useSharedValue(0);

// progress updates, Skia canvas repaints, all on the UI thread
<Canvas style={{ flex: 1 }}>
  <Circle cx={progress} cy={100} r={40} color="hotpink" />
</Canvas>

That single fact is what made Victory Native XL and every other modern chart library possible. Before it, animating a canvas meant round-tripping through JS every frame.

The performance gotcha

You will not hit a performance ceiling because you picked the "wrong" library. All three drive animations on the UI thread.

You will hit one if you animate a property that forces a layout pass every frame. Reanimated can push a shared value at 120fps, but if consuming it triggers layout, you're queued behind that layout and you drop frames regardless of which library issued the update.

Animate transform and opacity. Animating width, height, top, or left is the version of this mistake people actually ship, and all three libraries will let you do it.

The rule I use

Pick per interaction, not per app.

A screen with a draggable card and a hero image wants Reanimated for the drag and Moti for the hero. Separate primitives, separate concerns.

The moment you try to standardise on one library, you make one of those two interactions worse. Usually the drag, because that's the one where the abstraction costs you the handle you needed.

Bottom line

Install Reanimated and Moti on day one. Add Skia when the design demands it. Compose freely.

The interesting part of this generalises past animation: the "pick per interaction" rule is roughly how RapidNative decides which primitive to emit for a given screen, since a prompt describing a drag and a prompt describing a fade want different code.

What's your default? I'm curious how many people reach for Reanimated directly on things Moti would handle in three lines, because I did that for about a year.

We Made Checkout 600ms Faster. Not One User Noticed.

Hugo Rus — Wed, 19 Aug 2026 06:41:56 +0000

We spent a sprint on checkout performance. Prefetched tokens, warmed the payment sheet, bundle-split the checkout screen. End-to-end timing improved by roughly 600ms, which is a real number and visible in the traces.

Then we retested with users. Not one person mentioned speed. Not in the sessions where it was faster, and not in the earlier ones where it wasn't.

Everything they did mention fell into one category, and it wasn't performance.

Measurable speed improvements produced zero user comments in moderated retests
Every drop-off users could articulate was a trust problem, not a latency problem
Biometric confirmation changed how users described an otherwise identical flow
Stripe's default decline message reliably reads as "your card is fraud-flagged"
We now review payment flows against four trust questions before touching perf

This is a follow-up. The earlier findings from this testing (the double-tap problem and the total-mismatch problem) are in the first writeup; this post covers what surfaced afterwards.

Users drop off at trust moments, not slow moments

That's the headline and it took us a sprint of wasted effort to learn.

When someone abandons a checkout, they can usually tell you why, and the reason is almost always about confidence rather than time. Nobody says "that took 900 milliseconds and I was unwilling to wait." They say some version of "I wasn't sure what was happening" or "that didn't feel right."

Latency matters when it creates a trust problem. A tap that produces no visible response for half a second reads as a broken button, and the user taps again. That's a trust failure caused by latency, and fixing the latency fixes it. But shaving 600ms off a flow that already felt responsive changed nothing anyone could perceive.

If you have a fixed budget for a payment flow rebuild, spend it on the four things below before you open a profiler.

Biometrics change how the same flow feels

This one surprised us most.

Users describing the flow with a Face ID confirmation on the final tap used the word "safe." The same users describing the flow without it reached for "kind of sketchy," "is this the real app," and "I don't know if it went through."

Same gateway. Same UI. Same latency. The only delta was a native biometric prompt before presenting the sheet.

import * as LocalAuthentication from 'expo-local-authentication';

async function confirmAndPay() {
  const hasHardware = await LocalAuthentication.hasHardwareAsync();
  const isEnrolled = await LocalAuthentication.isEnrolledAsync();

  if (hasHardware && isEnrolled) {
    const result = await LocalAuthentication.authenticateAsync({
      promptMessage: 'Confirm your purchase',
      fallbackLabel: 'Use passcode',
    });
    if (!result.success) return;
  }

  await presentPaymentSheet();
}

Note the graceful degradation. Devices without enrolled biometrics fall through to the sheet rather than blocking the purchase, which matters more than it sounds — gating checkout behind hardware some users don't have is a worse problem than the one you're solving.

The interesting part is that nobody asked for this. No user in any session said "I wish this had Face ID." They just described the version without it as untrustworthy, in language they'd never have produced in response to a survey.

Stripe's default decline copy is actively harmful

"Your card was declined."

Technically accurate. In sessions, users read it as your card has been flagged, assumed something was wrong with their account rather than with this transaction, and several closed the app entirely rather than trying another card.

The fix is mapping decline codes to plain language plus a recovery action:

const DECLINE_COPY: Record<string, { message: string; action: string }> = {
  insufficient_funds: {
    message: 'Your bank says there are insufficient funds on this card.',
    action: 'Try a different card',
  },
  incorrect_cvc: {
    message: "The security code didn't match.",
    action: 'Re-enter card details',
  },
  expired_card: {
    message: 'This card has expired.',
    action: 'Use a different card',
  },
  generic_decline: {
    message: 'Your bank declined this charge. This is usually temporary.',
    action: 'Try a different card',
  },
};

Two details that matter more than the copy itself. Attribute the decline to the bank, not to your app, because users who think your app rejected them do not retry. And make the recovery action reopen the sheet with the cart intact, rather than dumping them back at the top of checkout, which is a second abandonment opportunity you built yourself.

Show the real total before the sheet opens

Related to but distinct from the total-mismatch problem in the first writeup: it isn't only that the numbers must match, it's when the user learns the final number.

Fees and taxes computed server-side and revealed inside the payment sheet are technically visible, but by then the user has anchored on the cart price. A higher number appearing at the moment of payment reads as a bait-and-switch even when the delta is trivial. Forty cents is enough.

Compute the full total, including tax and fees, on the cart screen, with a breakdown available on tap. The number the user commits to should be the number they pay.

The four questions we ask now

Before any payment flow work, in this order:

Is the complete total, including all fees, visible before the sheet opens?
Is there a biometric confirmation on the final tap, with a sensible fallback?
Does the tap produce a visible response immediately, ideally by prewarming the sheet?
Are error states mapped to plain-English copy with a working recovery path?

Visual polish, sheet customisation, and perf tuning all come after these. Not because they don't matter, but because in our testing they didn't move the thing we were trying to move.

If you're scaffolding a new project rather than repairing one, starting from checkout screens that already have the biometric gate, prewarmed sheet, and mapped error states wired in removes most of this before it exists. It's part of what RapidNative generates for Expo projects.

What I'd tell past me

Run the sessions before the sprint, not after.

We built the perf work because it was legible, measurable, and felt like the responsible engineering choice. It was also unfalsifiable in the only way that mattered: we could prove it worked in a trace and never prove it worked on a person.

Twelve moderated sessions cost less than the sprint did.

What's the last checkout change you shipped that moved a real number? I'm collecting the ones that worked, and my suspicion is that almost none of them are performance.