DEV Community: Jules Sarah

App Store and Google Play Screenshots for Expo Apps: Sizes, Clean Captures, and Automation

Jules Sarah — Fri, 16 Oct 2026 12:34:38 +0000

Screenshots are the last thing most developers think about before submitting an app, and they're the first thing users see in the store. They also cause avoidable trouble: wrong sizes block the upload, a messy status bar looks unfinished, and screenshots that don't match the app can get you rejected.

This guide covers the sizes each store needs, how to capture clean screenshots from an Expo app, how to automate them so you're not redoing them by hand every release, and what to put in them.

What sizes do the stores need?

Requirements change, so double-check the current App Store Connect and Play Console help pages before you export. As of this writing:

Apple App Store

Device	Required?	Size (portrait)
iPhone 6.9"	Yes	1320 × 2868 (1290 × 2796 also accepted)
iPad 13"	Only if your app supports iPad	2064 × 2752

Upload 1 to 10 screenshots per device size.
Apple scales your largest iPhone screenshots down for smaller devices, so one set usually covers every iPhone.
If your Expo app has "supportsTablet": true, you need iPad screenshots too. If you don't plan to design for iPad, set it to false in app.json.

Google Play

Asset	Required?	Size
Phone screenshots	Yes, at least 2 (up to 8)	16:9 or 9:16; each side 320–3840 px
Feature graphic	Yes	1024 × 500
App icon	Yes	512 × 512
Tablet screenshots	Recommended for tablet visibility	7" and 10"

A 1080 × 1920 or 1080 × 2400 phone screenshot works well for Play.

How do you capture clean screenshots?

iOS Simulator

Boot a simulator that matches the 6.9" size (an iPhone "Pro Max" model), run a release-like build, and clean up the status bar first:

xcrun simctl status_bar booted override \
  --time "9:41" \
  --batteryState charged --batteryLevel 100 \
  --cellularBars 4 --wifiBars 3

xcrun simctl io booted screenshot home.png

Clear the override when you're done:

xcrun simctl status_bar booted clear

Android emulator

Android has a "demo mode" that cleans the status bar:

adb shell settings put global sysui_demo_allowed 1
adb shell am broadcast -a com.android.systemui.demo -e command enter
adb shell am broadcast -a com.android.systemui.demo -e command clock -e hhmm 0941
adb shell am broadcast -a com.android.systemui.demo -e command battery -e level 100 -e plugged false
adb shell am broadcast -a com.android.systemui.demo -e command notifications -e visible false

adb exec-out screencap -p > home.png

adb shell am broadcast -a com.android.systemui.demo -e command exit

Before you capture, prepare the app

Use realistic sample data. Not "test test asdf." Seed a demo account with content that shows the app at its best.
Hide developer UI. No dev menus, debug banners, or warning overlays. Use a release or preview build.
Pick one theme. Light or dark, consistently across all screenshots.

How do you automate screenshots?

Retaking screenshots by hand every release gets old fast. Maestro can drive your app through a flow and capture each screen:

# .maestro/screenshots.yaml
appId: com.yourcompany.yourapp
---
- launchApp:
    clearState: true
- tapOn: "Sign in"
- inputText: "demo@example.com"
- tapOn: "Password"
- inputText: "demo-password"
- tapOn: "Continue"
- takeScreenshot: 01-home
- tapOn: "Insights"
- takeScreenshot: 02-insights
- tapOn: "Settings"
- takeScreenshot: 03-settings

maestro test .maestro/screenshots.yaml

Run the status bar commands first, then the flow, once on the iOS Simulator and once on the Android emulator. You get the same set of screens for both stores in a couple of minutes, and you can rerun it whenever the UI changes.

What should go in the screenshots?

Raw screenshots work, but most successful listings add a short caption and a background. A few principles:

The first three matter most. In search results, users often see only the first few screenshots. Make sure those three explain what the app does.

One idea per screenshot. A short caption, a few words, that states a benefit: "Track every workout in seconds," not "Workout logging screen."

Order them like a story. Start with the core value, then key features, then extras like settings or integrations.

Keep text readable on a phone. If you can't read the caption at thumbnail size, it's too small.

Show the real app. Apple's guidelines (2.3) require screenshots to show the app in use. Mockups of features that don't exist, or paid features presented as free, can get the app rejected. Label paid features clearly.

A simple workflow: export raw screenshots from the Maestro run, drop them into one design file with a template for each store size, add captions, and export. Next release, replace the raw screenshots and export again.

Checklist before upload

[ ] iPhone 6.9" set, 1 to 10 screenshots
[ ] iPad 13" set, or supportsTablet: false
[ ] Google Play: 2+ phone screenshots, 1024 × 500 feature graphic, 512 × 512 icon
[ ] Clean status bar (9:41, full battery, no notifications)
[ ] Realistic demo data, no debug UI
[ ] First three screenshots explain the app
[ ] Captions readable at thumbnail size
[ ] Paid features labeled; everything shown actually exists

Wrapping up

Screenshots aren't hard, but they're easy to leave until the night before submission. Get the sizes right, capture clean frames, automate the capture once with Maestro, and treat the first three screenshots as your pitch.

Want someone else to handle screenshots, store listings, and submission? LetsDeployIt takes your app from build to live on the App Store and Google Play.

What tool do you use for store screenshots? Share it in the comments.

Google Play's 12 Testers for 14 Days Rule: A Day-by-Day Plan That Gets You to Production

Jules Sarah — Thu, 15 Oct 2026 11:47:02 +0000

You've built the app. The iOS build is in review. Then Google Play Console tells you that before you can publish to production, you need to run a closed test with at least 12 testers, opted in for at least 14 days in a row.

For a solo developer, this is often the longest step of the whole launch. Not because it's technically hard, but because finding 12 real people and keeping them opted in for two weeks takes planning.

Here's a day-by-day plan that gets you through it without restarting the clock.

Who does this apply to?

The requirement applies to personal developer accounts created after November 13, 2023. Organization accounts (registered as a business, with a D-U-N-S number) don't have this requirement.

If you're starting a new account and can register as an organization, that's worth considering. Otherwise, plan for the test.

The rule, exactly

It has to be a closed test. Internal testing doesn't count.
At least 12 testers must be opted in.
They must have been opted in for the last 14 days, continuously.
After that, you apply for production access, which includes a short questionnaire about your test. Google then reviews the application.

The word that trips people up is continuously. If testers drop out and you fall below 12, you're no longer meeting the requirement for those days.

Day -7 to 0: Recruit before you need them

Start recruiting before your build is ready. This is the single biggest time saver.

Aim for 15 to 20 people, not 12. Someone always leaves, switches phones, or never opts in.
Everyone needs an Android phone and a Google account. iPhone friends can't help here.
Ask people who'd actually use the app. Google's questionnaire asks about feedback and changes you made, so real engagement makes the application easier.
Collect Gmail addresses, or set up a Google Group that testers join. A group is easier: add the group to the test once, and anyone who joins it becomes eligible.

Good places to find testers: friends and family with Android phones, your mailing list or waitlist, a community related to your app's topic, and other developers in the same situation (swap testing with them, and actually use each other's apps).

Day 0: Set up the closed test

1. Create the app and complete the setup tasks

In Play Console, create your app and work through the dashboard's setup tasks: privacy policy, app access (demo account), ads declaration, content rating, target audience, and Data Safety. Some of these must be done before testing tracks can be reviewed.

2. Upload a build to the closed testing track

With EAS, configure a submit profile that targets closed testing. In eas.json, the closed testing track is called alpha:

{
  "submit": {
    "closed": {
      "android": {
        "serviceAccountKeyPath": "./play-service-account.json",
        "track": "alpha"
      }
    }
  }
}

Then build and submit:

eas build --platform android --profile production
eas submit --platform android --profile closed

If the submission is rejected because the app has never had a build uploaded, upload the first .aab manually in Play Console, then use EAS Submit for everything after. Check the current EAS Submit docs, since first-upload support has been improving.

3. Add testers and share the opt-in link

In the closed testing track, add your email list or Google Group, then copy the opt-in link. Send it to every tester with clear instructions:

Open this link on your Android phone, signed in with the Google account you gave me.

Tap "Become a tester."

Install the app from the Play Store link on that page.

Please stay opted in for the next two weeks, and use the app a few times.

Step 4 matters. Say it explicitly.

4. Wait for the track to be reviewed

The first closed test release goes through review. The 14 days only start counting once testers can actually opt in.

Days 1 to 3: Confirm everyone is in

Check the tester count in Play Console. It shows how many testers have opted in.
Chase the stragglers personally. The most common problem is someone opting in with a different Google account than the one on their phone.
Don't stop at 12. Keep inviting until you have a buffer of three or more.

Days 4 to 13: Keep them engaged

Opted in is the requirement, but engagement makes the production application stronger and the app better.

Ship one or two updates to the closed track based on feedback. Each update is something concrete to mention in the questionnaire.
Ask a specific question every few days: "Did the sign-up flow make sense?" gets more answers than "Any feedback?"
Keep a simple log: who reported what, and what you changed. You'll use it on day 14.
Re-check the tester count a couple of times. Catch drop-offs before you fall under 12.

Day 14+: Apply for production access

Once 12 or more testers have been opted in for 14 continuous days, Play Console lets you apply for production access. The questionnaire asks things like:

How you recruited testers, and how easy it was
How testers engaged with the app, and what feedback they gave
What changes you made based on that feedback
Who the app is for, and what value it provides
Whether the app is ready for production

Answer from your log. Specific beats vague: "Five testers said the onboarding skipped explaining notifications, so we added a permission explainer screen in build 1.0.3" is much stronger than "We got good feedback and made improvements."

Then wait for the review. Use the time to finish your store listing, screenshots, and release notes.

What resets or delays the process?

Mistake	What happens	Fix
Using internal testing	Doesn't count toward the requirement	Use the closed testing track
Recruiting exactly 12	One dropout drops you below the minimum	Recruit 15 to 20
Testers using the wrong Google account	They're not counted as opted in	Send clear instructions; confirm the count
Waiting to recruit until the build is ready	Adds a week or more	Recruit while building
Vague questionnaire answers	Weaker application	Keep a feedback log from day 1
Paying for fake testers	Low engagement and risk to your account	Use real people who'll try the app

The whole timeline at a glance

When	What
Day -7	Start recruiting 15 to 20 Android users
Day 0	Finish setup tasks, submit to closed testing, share opt-in link
Days 1–3	Confirm 12+ opted in; chase stragglers
Days 4–13	Ship updates, collect feedback, keep a log
Day 14+	Apply for production access
After review	Release to production

Plan on roughly three weeks from first upload to production for a brand-new personal account, and start recruiting early to keep it there.

Don't want to manage testers, tracks, and the production access questions yourself? LetsDeployIt handles App Store and Google Play submission end to end, including the closed testing setup.

What's been the hardest part of the 14-day test for you? Share in the comments.

Plan, Build, Review, Verify: A Claude Code Workflow for Shipping Expo + Supabase Features

Jules Sarah — Thu, 08 Oct 2026 14:52:01 +0000

Most Claude Code setups for React Native stop at a CLAUDE.md file. That's the foundation: it tells the agent your conventions. But conventions alone don't stop the two failures I see most often in agent-built Expo features:

The agent starts writing before it understands the codebase, and you get a feature that works but ignores how the rest of the app is built.
The agent says "done" when it isn't: types don't check, a Supabase table has no RLS, and the screen has never rendered an error state.

This post is the workflow I use to fix both: four stages, each backed by a Claude Code feature, with the files to set it up. It assumes you already have a CLAUDE.md with your commands and conventions.

The four stages

Stage	Claude Code feature	What it prevents
Plan	Plan mode	Code written before the codebase is understood
Build	A project skill (`/new-feature`)	Inconsistent structure across features
Review	Read-only subagents	Security and convention mistakes the builder can't see
Verify	A verifier subagent + a Stop hook	"Done" that isn't done

Stage 1: Plan before any edit

Start every non-trivial feature in plan mode. Press Shift+Tab to cycle permission modes until plan mode is active, or type /plan. In plan mode Claude explores and proposes but can't edit files. When it needs to research the codebase, it delegates to a built-in read-only Plan subagent, so the exploration output stays out of your main conversation.

A good planning prompt for an Expo + Supabase feature:

Plan a "favorites" feature: users can heart a workout and see a Favorites tab.

Before planning, find:
- how existing features are structured under features/
- how data fetching is done (queries/ hooks)
- the most recent migration in supabase/migrations/ and its RLS pattern
- how tabs are defined in app/(tabs)/_layout.tsx

The plan must list: the migration (with RLS and policies), the query hooks,
the route files, the components, and the tests. Don't write code yet.

Then read the plan. This is the cheapest moment to catch a wrong assumption: a plan that puts supabase.from() calls inside a screen component costs ten seconds to correct now and an hour to refactor later. When the plan is right, approve it and let Claude build.

Stage 2: Build with a skill, not a paragraph

If you build features the same way every time, stop retyping the instructions. A skill is a folder with a SKILL.md that you invoke as a slash command. Put project skills in .claude/skills/ and commit them so the whole team gets the same workflow.

<!-- .claude/skills/new-feature/SKILL.md -->
---
name: new-feature
description: Scaffold a new feature in this Expo + Supabase app following project conventions.
disable-model-invocation: true
---

Build the feature described by the user, following this order:

1. **Migration** in `supabase/migrations/<timestamp>_<name>.sql`:
   - `create table` and `enable row level security` in the same file
   - policies scoped to `(select auth.uid())`; never `using (true)` on user data
   - an allow test and a deny test in `supabase/tests/`
2. **Query hooks** in `queries/<feature>.ts` using TanStack Query.
   No data fetching inside components.
3. **Feature folder** `features/<feature>/` for screens and components.
4. **Routes** in `app/` that only import and render the feature screen.
5. Every screen that fetches data has loading, empty, and error states.

Use theme tokens from `theme/tokens.ts`. Navigation comes from `expo-router` only.
When finished, run `npm run typecheck` and the tests, and report the results.

Now building a feature is:

/new-feature favorites: heart a workout, Favorites tab lists hearted workouts

disable-model-invocation: true means the skill only runs when you call it, which is what you want for a workflow that creates files.

Stage 3: Review with read-only subagents

The agent that wrote the code is the worst reviewer of it: it has the same blind spots it had while writing. A subagent runs in its own context window with its own system prompt and tool restrictions, which makes it a fresh pair of eyes that can't accidentally "fix" things during review.

Subagents are Markdown files with YAML frontmatter in .claude/agents/. Two are worth having in every Expo + Supabase repo.

An RLS reviewer

<!-- .claude/agents/rls-reviewer.md -->
---
name: rls-reviewer
description: Reviews Supabase migrations and policies for RLS mistakes. Use proactively after any change in supabase/.
tools: Read, Grep, Glob
model: sonnet
---

You review Supabase SQL for security problems. You never edit files.

Check every migration changed on this branch for:
- tables created without `enable row level security` in the same file
- `using (true)` or `with check (true)` on tables holding user data
- update policies that let users change privileged columns (role, plan, is_admin, credits)
- views without `security_invoker = true`
- `security definer` functions without an `auth.uid()` check
- storage policies that don't scope paths to the user's folder
- missing deny tests in supabase/tests/

Report findings as Critical / Warning / OK, with file and line for each.

Because tools lists only Read, Grep, Glob, this subagent can't edit or run anything. It reads and reports.

A mobile conventions reviewer

<!-- .claude/agents/rn-reviewer.md -->
---
name: rn-reviewer
description: Reviews React Native changes for project conventions and mobile pitfalls. Use proactively after UI changes.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You review React Native code. You never edit files.

Run `git diff main...HEAD` and check the changed files for:
- data fetching inside useEffect or components instead of queries/ hooks
- secrets or keys in EXPO_PUBLIC_ variables
- imports from @react-navigation/* instead of expo-router
- lists rendered with .map in ScrollView instead of FlatList/FlashList
- icon-only buttons without accessibilityLabel
- forms without keyboard handling
- hardcoded colors or spacing instead of theme tokens
- missing loading, empty, or error states

Report Critical / Warning / Suggestion with file and line.

After the build stage, ask for both reviews:

Use the rls-reviewer and rn-reviewer subagents to review this branch in parallel,
then fix every Critical finding.

The reviews run in their own contexts, only their summaries come back, and the main conversation does the fixing with full context of what it built.

Stage 4: Verify, and make "done" mean done

Two layers here: one the agent uses on purpose, one that runs whether it remembers or not.

A verifier subagent for noisy output

Test and typecheck output is long, and you rarely need all of it in your main context. A subagent that runs the checks and returns only failures keeps the main conversation clean:

<!-- .claude/agents/verifier.md -->
---
name: verifier
description: Runs typecheck, lint, and tests, and reports only failures. Use before reporting any task as complete.
tools: Bash, Read
model: haiku
---

Run, in order:
1. npm run typecheck
2. npx expo lint
3. npx vitest run
4. npx supabase test db   (if supabase/ changed)

Report only failures: the command, the file, the line, and the error.
If everything passes, say so in one line.

Routing a mechanical task like this to a smaller, cheaper model is one of the cost controls subagents are designed for.

A Stop hook as the backstop

Instructions can be forgotten; hooks can't. Add a Stop hook in .claude/settings.json that typechecks whenever Claude finishes a turn:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "npx tsc --noEmit" }
        ]
      }
    ]
  }
}

If types fail, you see it immediately, before you read "Done!" and move on.

What a full run looks like

Shift+Tab into plan mode. Describe the feature and what to research. Review and approve the plan.
/new-feature favorites: … to build it in your conventions.
"Use rls-reviewer and rn-reviewer in parallel, then fix every Critical."
"Use the verifier." Fix anything it reports.
Read the diff yourself before committing.

Step 5 isn't optional. The workflow makes agent output reliably reviewable, not reliably correct. You're still the last reviewer.

Three rules that keep this working

Keep subagent descriptions short and specific. Claude uses the description field to decide when to delegate, and all descriptions sit in context. "Reviews Supabase migrations for RLS mistakes. Use proactively after any change in supabase/." routes well. A paragraph doesn't.

Read-only reviewers should stay read-only. Don't give review subagents Edit or Write. A reviewer that fixes things isn't reviewing.

Commit .claude/. Skills, subagents, and settings in the repo mean every teammate (and every CI run) gets the same workflow. Personal tweaks go in your user-level ~/.claude/ folder.

The part no workflow fixes

All four stages work better when the codebase itself is consistent. An agent copies the patterns it finds: if three features fetch data in useEffect, the fourth will too, whatever your skill says. Reviewers catch some of that drift; a clean starting structure prevents it.

That's the idea behind AppLighter: Expo + Supabase templates where the conventions this workflow enforces (query hooks, RLS in every migration, theme tokens, thin routes) are already in place, so Claude Code extends a codebase that's consistent from day one.

What's in your .claude/agents/ folder? I'm always looking for the next reviewer worth adding.

Claude Code features change quickly. The file formats here follow the current Claude Code docs; check them if something doesn't load.

Postgres Local Dev in 2026: The Numbers, and Lighter Alternatives to Docker Supabase

Jules Sarah — Mon, 05 Oct 2026 11:44:50 +0000

Running Postgres locally has never been easier. Running a backend locally has quietly become one of the heaviest things on your laptop.

That distinction matters. If your app only talks to a database, brew install postgresql is as light as it was ten years ago. But if your app uses Supabase (or any backend-as-a-service), it expects auth, a REST API, realtime, storage, and edge functions too. Locally, that's a stack of containers, and it's where the RAM goes.

Here are the numbers, the reason they got this way, and the alternatives, with commands to measure everything on your own machine.

The baseline: Docker Supabase

supabase start
docker stats --no-stream

The official local stack runs about a dozen containers: Postgres, PostgREST, GoTrue (auth), Realtime, Storage, imgproxy, the edge runtime, Studio, the API gateway, the meta service, and supporting services. The tinbase project's README benchmarks the stack at about 1.4 GB of RAM at boot and about a minute to boot cold, before Docker Desktop's own VM overhead.

Your numbers will differ with your Docker Desktop version, CPU architecture, and how many projects you run. That's why the measurement commands are at the end of this post: run them and see what your machine actually pays.

The old baseline: just Postgres

brew install postgresql@17
brew services start postgresql@17
createdb myproject

A native Postgres server idles in tens of megabytes and starts in about a second. Nothing about Postgres got heavier. What changed is what we expect "the local database" to include.

Why the stack got heavy

Backend-as-a-service platforms made a reasonable packaging choice: ship the local environment as the same set of services that runs in production, one container per service. Supabase, Appwrite, and Nhost all lean on Docker Compose for local development.

For parity with production, that's correct. In the cloud those services run as separate deployments, and mirroring that locally catches configuration differences early.

For a laptop, it's expensive. Every auxiliary service carries its own runtime, its own memory floor, and its own startup time, even when it sits idle for the whole session. Locally, most of those services could share one process, but the packaging doesn't make that distinction.

(The notable exception is PocketBase, which has always been a single Go binary with SQLite. It proved developers love the single-binary model; it just isn't Postgres.)

Three lighter alternatives

1. Native Postgres, and stub the rest

brew install postgresql@17
brew services start postgresql@17

Footprint: tens of megabytes, about a second to start.

Trade-off: you lose auth, realtime, storage, and edge functions. Either stub them in your code or point those calls at a hosted project. That works if your app barely uses them; it breaks the first time your code calls supabase.auth.

2. PGlite (Postgres compiled to WASM)

npm install @electric-sql/pglite

import { PGlite } from '@electric-sql/pglite';
const db = new PGlite();
await db.exec('create table todos (id serial primary key, text text)');

Footprint: the package is small and an empty database starts fast, but memory is the catch. Under real workloads the WASM heap grows to hundreds of megabytes (the tinbase README measures roughly 575–650 MB) and doesn't shrink.

Trade-off: it's a library inside your process, not a server, and it runs Postgres in single-user mode. That makes it excellent for tests (a fresh database per test file), and awkward for day-to-day work: psql, GUI clients, and connection pools need extra plumbing or won't work.

3. A single-process, Supabase-compatible backend: tinbase

npx tinbase start

Footprint (from the README): 2 processes, about 59 MB of RAM at boot, about 2 seconds to boot, with embedded native Postgres 17 on macOS and Linux.

It runs REST, auth, storage, realtime, and edge functions in one process, on port 54321 like the Supabase CLI, and the official supabase-js works unchanged. It reads your existing supabase/migrations/ folder.

Trade-off: it's alpha. It covers roughly 80% of the supabase-js surface; MFA, SSO, phone auth, and pgvector aren't supported yet; realtime DELETE events aren't filtered per row; and writes go through a single connection. It's for laptops, CI, and prototypes, not production. Full disclosure: I'm on the team.

Side by side

Approach	RAM at boot	Cold boot	Auth / realtime / storage	Client
Docker Supabase	~1.4 GB + Docker VM	~1 min	Yes, full fidelity	supabase-js
Native Postgres	tens of MB	~1 s	No	pg, Drizzle, Prisma
PGlite	small at start; hundreds of MB under load	under 1 s	No	In-process
tinbase	~59 MB	~2 s	Yes, ~80% coverage	supabase-js

Docker Supabase and tinbase figures are from the tinbase README benchmarks. Treat all of these as ballparks and measure your own.

The decision tree

Need full Supabase fidelity, and Docker runs fine on your machine → Docker Supabase.
Only need Postgres; no auth, realtime, or storage → native Postgres.
Writing tests that need a fresh database each time → PGlite.
Want the Supabase stack without Docker's footprint → tinbase, with a Docker Supabase or hosted check before deploy.

Most teams end up with two: PGlite for tests, and one of the others for development.

Where this is heading

Hosted platforms have little reason to optimize for laptop RAM. Local development has every reason to. I expect more backend tools to ship two packagings: the production-shaped deployment, and a lightweight dev-time runtime. PGlite becoming the local engine for Prisma Postgres is an early sign. A lighter official local story from Supabase would be a big win for its community, and I'd welcome it.

Measure it yourself

# Docker Supabase: per-container memory
supabase start
docker stats --no-stream

# Native Postgres: resident memory (KB)
brew services start postgresql@17
ps -axo rss,command | grep '[p]ostgres'

# tinbase: resident memory (KB) of its processes
npx tinbase start
ps -axo rss,command | grep '[t]inbase'

Run each from a cold start and time it with time. If your numbers differ a lot from the table, leave a comment with your OS, chip, and Docker version. I'm collecting them.

Expo Push Notifications: The Backend Half Nobody Finishes

Jules Sarah — Wed, 30 Sep 2026 06:32:00 +0000

Every Expo push notification tutorial ends the same way: you get a token on the device, paste it into Expo's push tool, a notification appears, done.

That's the first half. The second half is what runs in production: storing tokens per user, sending from your backend, checking receipts, and deleting dead tokens before Apple and Google start throttling you. Most apps skip it, and it's why "push works in testing but not for real users" is such a common bug report.

This is the backend half, using Supabase for storage and an Edge Function for sending. Two quick ground rules first:

Expo Go can't receive remote push since SDK 53. You need a development build (eas build --profile development).
A token identifies a device, not a user. One user can have three devices; one device can be handed to a new user after sign-out. Model it that way.

Step 1: A token table that survives real life

create table public.push_tokens (
  token       text primary key,
  user_id     uuid not null references auth.users(id) on delete cascade,
  platform    text not null check (platform in ('ios', 'android')),
  updated_at  timestamptz not null default now()
);

alter table public.push_tokens enable row level security;

create policy "own tokens" on public.push_tokens
  for all to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

The token is the primary key on purpose. When a device changes hands, an upsert on the token reassigns it to the new user instead of leaving a stale row that pushes the previous user's notifications to a stranger.

Step 2: Register the token on the device

import * as Notifications from 'expo-notifications';
import * as Device from 'expo-device';
import Constants from 'expo-constants';
import { Platform } from 'react-native';
import { supabase } from '@/lib/supabase';

export async function registerPushToken() {
  if (!Device.isDevice) return;                    // simulators don't get tokens

  const { status } = await Notifications.requestPermissionsAsync();
  if (status !== 'granted') return;

  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'Default',
      importance: Notifications.AndroidImportance.DEFAULT,
    });
  }

  const projectId = Constants.expoConfig?.extra?.eas?.projectId;
  const { data: token } = await Notifications.getExpoPushTokenAsync({ projectId });

  await supabase.from('push_tokens').upsert({
    token,
    user_id: (await supabase.auth.getUser()).data.user!.id,
    platform: Platform.OS,
    updated_at: new Date().toISOString(),
  });
}

Call it after sign-in and on every app launch. On sign-out, delete the row for this device's token so the next user doesn't inherit it.

Step 3: Send from an Edge Function

Never send from the client: the Expo push endpoint doesn't need a secret, but your token table does, and you don't want app code deciding who gets notified.

// supabase/functions/send-push/index.ts
import { createClient } from 'npm:@supabase/supabase-js@2';
import { Expo } from 'npm:expo-server-sdk';

const expo = new Expo();

Deno.serve(async (req) => {
  const { userId, title, body, data } = await req.json();

  const admin = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!   // server-only; never in the app
  );

  const { data: rows } = await admin
    .from('push_tokens').select('token').eq('user_id', userId);

  const messages = (rows ?? [])
    .filter((r) => Expo.isExpoPushToken(r.token))
    .map((r) => ({ to: r.token, title, body, data, sound: 'default' }));

  const tickets = [];
  for (const chunk of expo.chunkPushNotifications(messages)) {
    tickets.push(...(await expo.sendPushNotificationsAsync(chunk)));
  }

  // Store ticket ids so a later job can fetch receipts
  await admin.from('push_tickets').insert(
    tickets
      .filter((t) => t.status === 'ok')
      .map((t, i) => ({ ticket_id: t.id, token: messages[i].to }))
  );

  return Response.json({ sent: tickets.length });
});

Call it from a database trigger, a webhook, or another function with the user's ID. The service-role key stays in the function's environment.

Step 4: Check receipts (the step everyone skips)

A "ticket" only means Expo accepted the message. Whether Apple or Google delivered it comes back later as a receipt. If you never read receipts, you never learn that a token is dead, and you keep sending to it. Apple and Google both throttle apps that do that.

Run this as a scheduled function 15–30 minutes after sends:

// supabase/functions/check-receipts/index.ts
const { data: pending } = await admin
  .from('push_tickets').select('ticket_id, token').eq('checked', false).limit(1000);

for (const chunk of expo.chunkPushNotificationReceiptIds(pending.map((p) => p.ticket_id))) {
  const receipts = await expo.getPushNotificationReceiptsAsync(chunk);

  for (const [id, receipt] of Object.entries(receipts)) {
    if (receipt.status === 'error' && receipt.details?.error === 'DeviceNotRegistered') {
      const row = pending.find((p) => p.ticket_id === id);
      await admin.from('push_tokens').delete().eq('token', row!.token);
    }
  }
  await admin.from('push_tickets').update({ checked: true }).in('ticket_id', chunk);
}

DeviceNotRegistered means the user uninstalled, revoked permission, or the token expired. Delete it. That single loop is the difference between a push system that works for six months and one that quietly degrades.

Step 5: Handle taps

A notification that opens the app to the wrong screen feels broken. Read data and route:

import { useRouter } from 'expo-router';
import * as Notifications from 'expo-notifications';

const router = useRouter();

useEffect(() => {
  const sub = Notifications.addNotificationResponseReceivedListener((res) => {
    const { screen, id } = res.notification.request.content.data as any;
    if (screen === 'order') router.push(`/orders/${id}`);
  });
  return () => sub.remove();
}, []);

Also check Notifications.getLastNotificationResponseAsync() on cold start, since the listener isn't mounted yet when a tap launches the app.

Checklist before you ship

[ ] Tokens stored per device with user reassignment on upsert
[ ] Token deleted on sign-out
[ ] Sends happen server-side with the service-role key in the function's env only
[ ] Tickets stored; receipts checked on a schedule; DeviceNotRegistered tokens deleted
[ ] Android notification channel created; Android 13+ runtime permission requested
[ ] APNs key uploaded and FCM v1 credentials configured in EAS
[ ] Tap handling covers both the running app and cold start
[ ] Tested on a physical device with a development build, not Expo Go

Where the scaffold comes from

The device-side code above, the token table, and the Supabase wiring are the same in every app. That's the part I let RapidNative generate: it produces the Expo app with expo-notifications, Supabase auth, and the data layer already connected, so the time goes into the sending logic and the receipt job, which are the parts that are actually yours.

What does your receipt-checking setup look like? I've seen everything from a cron job to "we didn't know receipts existed," and I'm curious where most teams land.

Why We Built a Single-Process Supabase Instead of a docker-compose Stack (and What We Learned)

Jules Sarah — Fri, 25 Sep 2026 09:20:19 +0000

The moment docker-compose became the problem

Local Supabase is about a dozen containers. On a laptop that's roughly 1.4 GB of RAM at idle and about a minute to boot cold. For a backend engineer with a 32 GB machine, that's fine. It stops being fine the moment anyone else on the team needs the app running locally: a designer iterating on screens, a PM checking a flow, a CI runner with a 7 GB memory cap.

We hit that wall building RapidNative, where thousands of generated apps each need a working backend for preview. A container stack per preview was never going to work. That constraint is where tinbase came from.

What "single process" actually means

We didn't want a slimmer container stack. We wanted the backend to be a library.

In tinbase, every Supabase service is a plain (Request) => Response fetch handler: REST (PostgREST grammar), Auth (GoTrue-shaped), Storage, Realtime (Phoenix protocol over WebSocket), Edge Functions, and a Studio-style dashboard at /_/. Underneath sits a swappable database engine. On a server, one HTTP + WebSocket server wraps those handlers. In a browser, supabase-js calls them directly through a custom fetch, and no server exists at all.

The official @supabase/supabase-js works unchanged. That was a hard requirement: the moment you ship your own client, every app has to be written twice.

The numbers, from the README

	Supabase local (Docker)	tinbase (native engine)
Processes	12 containers	2
RAM at boot	~1.4 GB	~59 MB
Cold boot	~1 min	~2 s
Install	GB of images	tens of MB

Same SDK, same APIs, same migration files.

What took longer than expected

Three database engines instead of one. We started with PGlite (Postgres compiled to WASM) because it runs in a browser. Then we learned its WASM heap sits at roughly 575–650 MB and doesn't shrink. So we added embedded native Postgres 17 as the default on macOS and Linux, and a pure-JS pgmem engine (about 3.6 MB, no WASM) for the lightest browser previews. Each engine has a different trade-off, and pretending one fits every case would have been dishonest.

Wire-protocol fidelity. Keeping the real SDK working meant implementing the actual PostgREST query grammar, GoTrue-shaped responses, and the Phoenix realtime protocol. More work than a "compatible" API, but it's why apps move to hosted Supabase without edits.

Single-connection realities. PGlite is single-user mode, so writes serialize through one connection. Fine for one developer or one preview. Not a production database, and we say so.

Gotchas nobody warns you about

pgmem doesn't enforce RLS. It runs with superuser rights, so policies are created but not applied per request. Use it for previews, never for testing security.
Realtime DELETE events aren't filtered per row. INSERT and UPDATE are; DELETE isn't yet. It's in the coverage table.
Edge Functions with npm:, jsr:, or URL imports still need bundling. Plain functions run in-process.
Safari and OPFS. PGlite's OPFS filesystem needs a Web Worker, and Safari's open-file-handle limit blocks it. IndexedDB is the safe browser default.

Would we do it again? Yes, but…

Yes: npx tinbase start boots real Postgres with RLS in about two seconds, a designer can run the whole stack without knowing what Docker is, and CI jobs run RLS tests with no service containers.

But: tinbase is alpha, built for local dev, CI, prototypes, and embedded use. It covers roughly 80% of the supabase-js surface, and the gaps (MFA, SSO, phone auth, pgvector, among others) are listed openly. The right setup for most teams is tinbase on every laptop and every PR, and hosted Supabase for staging and production, with the same migration files moving between them.

The source is MIT on GitHub. If you hit an API edge we haven't covered, open an issue. Those reports are what move the coverage table.

What's your experience with the docker-compose vs single-process trade-off? Drop your setup in the comments. I'm curious how teams at different sizes land on this.

Build vs Buy a React Native Template: What Founders Miss

Jules Sarah — Wed, 23 Sep 2026 05:44:50 +0000

Every week a founder pings me: "Should we build our React Native app from scratch, or buy a template?"

Wrong question.

The right question is: where is the differentiator in my product actually located? Answer that, and the build-vs-buy question answers itself.

Let me show you why.

The 80/20 nobody prices out

Every React Native app has two layers.

Layer 1, the 80% that's the same in every app:

- Email + OAuth + Apple Sign-In flows
- Password reset with deep-linked tokens
- Row-Level Security on every table
- Push notifications (iOS + Android + delivery receipts)
- Stripe or IAP + license grants
- Offline-safe state, cache invalidation
- Error boundaries, loading skeletons, empty states
- Accessibility labels + dynamic type
- EAS Build + code signing + TestFlight + Play Console
- OTA updates
- Legal screens (privacy, terms, refund)

Layer 2, the 20% that's actually your product:

- The AI pipeline
- The recipe database
- The marketplace matcher
- The workout planner
- The unique thing

When you "build from scratch," you're paying to build both layers. When you "buy a template," you're paying to skip Layer 1 so your whole team can chase Layer 2.

The math

Rough numbers at $80/hr for a mid-market React Native engineer, using realistic (not optimistic) hours:

Component	Hours	Cost
Auth (email + OAuth + Apple + reset)	90	$7,200
Supabase schema + RLS + migrations	70	$5,600
Push notifications (iOS + Android)	60	$4,800
Stripe + license grants	80	$6,400
Nav + deep links + tab bar	50	$4,000
EAS Build + submission	40	$3,200
Design system + dark mode + a11y	100	$8,000
Total for Layer 1	490	~$39,200

That's what you pay before writing one line of Layer 2.

Meanwhile, a template that ships Layer 1 as a working repo, with backend, auth, Stripe, and pipelines, costs $79 to $299 one time.

Why so many "buy" attempts fail

Founders who tried a template and hated it usually got burned by one of these:

UI-only "full-stack" templates. You paid for the mockups. Backend is your problem.
Ambiguous licensing. You can't legally ship in a paid app without a bigger tier.
Copy-paste soup. Three state-management libraries in one repo. Cursor and Claude Code refuse to extend it.
Dead vendor. Last commit 14 months ago. React Native version is two majors behind.
Vendor lock-in. Can't swap the AI provider without rewriting half the app.

The fix isn't "give up on templates." The fix is "don't buy those templates."

The decision framework

Ask one question:

Where is my differentiator actually located?

Three cases.

Case A: product-shaped differentiator (~90% of apps).
AI pipeline, marketplace mechanic, workflow, recipe DB, planner logic.
→ Buy a template. Spend every hour of engineering budget on Layer 2.

Case B: infrastructure-shaped differentiator (rare).
Custom native module, novel audio pipeline, on-device ML.
→ Build from scratch, or fork a template and rewrite what matters.

Case C: mixed.
Product-shaped mostly, but one or two infra pieces are genuinely custom.
→ Buy and fork. Keep the Layer 1 you get. Rewrite the parts that don't fit.

Case A is where most founders actually are, but Case B is where they think they are. Be honest.

What "a good buy" looks like

The template needs to check these boxes. If it can't, keep looking:

[x] Full source, TypeScript everywhere
[x] Real backend (Postgres + auth + storage + edge functions)
[x] RLS policies on every table
[x] Consistent state management (one library, not three)
[x] Consistent file structure across screens
[x] Modular AI/backend layer (swap providers without rewriting)
[x] Commercial license, one-time or clear upgrade path
[x] Refund window that isn't hostile
[x] Vendor still active (commits in last 90 days)

The last four boxes matter more than any screen-count number in the marketing copy.

Comparison table

	Build from scratch	Cheap UI template	Marketplace template	Applighter
Time to MVP	8–16 weeks	6–10 weeks	5–9 weeks	1–3 weeks
Backend included	❌ (you build)	❌	Sometimes	✅ Supabase
Auth flows	❌	Screens only	Screens only	✅ Real
AI wired up	❌	❌	❌	✅ Where relevant
Agent-friendly	Depends	Rarely	Rarely	✅
License	You own it	Ambiguous	Per-app fees	✅ Clear
Lifetime updates	You maintain	❌	❌	✅

Concrete example

Applighter's AI Voice Notes template, $79 one time, ships with:

16 React Native + Expo screens, TypeScript
Working Supabase backend with schema + RLS + migrations
Recording, transcription, summarization pipelines wired up
EAS Build pre-configured for TestFlight + Play Console
Single commercial license, upgradeable to multi-app
Lifetime updates, no subscription
7-day no-questions refund window

That template gets a founder to TestFlight in about 2 weeks. Building the equivalent Layer 1 from scratch takes about 490 hours. The delta is what ships your product.

More options and stack comparisons in the Applighter apps catalog and the honest boilerplate comparison post.

Reference docs worth reading

Build vs buy is a false binary. The right question is where your differentiator lives. If it's product-shaped, and it is for roughly 90% of apps, buy a template that gives you a real Layer 1: backend, auth, payments, EAS. Spend your engineering budget on Layer 2. If your first template was bad, that's a lesson about which template, not about templates in general.

If you're currently in week one of a Notion doc about this, close it and ship.

Claude Code Is Only as Good as the React Native Repo You Point It At

Jules Sarah — Wed, 23 Sep 2026 05:43:18 +0000

There's a pattern in every "AI coding is overrated" thread. Someone points Claude Code at their React Native project, asks for a feature, gets a mess, and concludes the tool is hype. Someone else points it at a different repo, asks for the same thing, and ships the feature before lunch.

The difference usually isn't the prompt. It's the repo.

Coding agents are imitation machines. They read the code around the task and extend the patterns they find. Give them a codebase with one clear way of doing things and they multiply it. Give them a codebase with three navigation setups, two fetch patterns, and a 900-line screen, and they'll faithfully produce a fourth navigation setup. The repo is the prompt.

Here's what actually moves the needle for React Native projects.

1. Write a CLAUDE.md before you write another prompt

Claude Code reads a CLAUDE.md at the repo root automatically. Most projects don't have one, which means the agent re-derives your stack from scratch every session. Mine looks roughly like this:

# Project
Expo SDK 53, expo-router (typed routes), TypeScript strict.

# Conventions
- State: Zustand for client state, TanStack Query for server state
- All data access goes through src/api/. Never call supabase directly from screens.
- Styling: unistyles tokens from src/theme. No inline hex colors.

# Commands
- npm run typecheck
- npm run lint
- npm test
- npx expo start

# Don't
- Don't add new dependencies without asking
- Don't edit files in src/generated/

Thirty lines. It removes the entire category of "technically correct code in the wrong style" and stops the agent from installing a second date library.

2. One way to do each thing

This is the highest-leverage change and it has nothing to do with AI, which is exactly why it works. Agents pick the nearest example and copy it. If your repo fetches data three ways, the agent picks whichever file it read last.

Audit for one pattern each: one navigation approach, one data-fetching layer, one form setup, one styling system. Delete the strays. Every duplicate pattern in your repo is a coin flip you're handing the agent.

3. Make the repo self-verifying

Claude Code is dramatically better when it can check its own work. That means fast, runnable feedback loops:

Strict TypeScript. Every hallucinated prop and misnamed hook becomes a compile error the agent sees and fixes itself, instead of a runtime crash you find on device.
Typed routes in expo-router. A wrong href fails typecheck. Without it, it fails in the user's hand.
Scripts that run headless. typecheck, lint, test as npm scripts the agent can execute after every change. If your test suite needs a simulator and three manual steps, the agent skips verification, and so does the code quality.

The loop you want: agent writes, agent runs typecheck, agent fixes, you review a diff that already compiles.

4. Keep files small enough to read

Agents work inside a context window, and a 900-line screen component eats it. Files under ~200 lines with clear names get read whole; God-components get read in fragments, and fragments produce fragment-quality edits. Colocate the query, the types, and the component for a feature so one directory tells the whole story.

5. Know what to delegate and what to keep

After months of running Claude Code on RN projects, the split is pretty consistent.

Delegate freely: wiring new screens from existing patterns, refactors across many files, writing tests for existing logic, dependency upgrades with their config changes, form plumbing, and the long tail of "make this screen match that screen".

Keep your hands on: native module and config-plugin work (the agent can't run the iOS build), anything visual (it can't see the screen), platform-specific quirks like keyboard behavior, and architecture decisions. The agent extends architecture well and invents it badly.

That last sentence is the whole article, honestly.

6. Never start it on a blank folder

A blank folder is the worst possible context: no conventions to imitate, so the agent invents an architecture token by token, and you inherit whatever it improvised. Starting from a well-structured starter flips the dynamic. The conventions exist, the CLAUDE.md exists, the verification loops exist, and every feature you ask for is an extension instead of an invention.

That's the real reason starter kits aged well in the agent era instead of dying. A reviewed template is context engineering you didn't have to do; it's what we curate for on AppLighter, where React Native templates are vetted for exactly the things above: one pattern per concern, strict types, and a structure an agent can extend without supervision.

Point Claude Code at a repo like that and the "AI coding is overrated" thread starts to look like a repo problem wearing a tooling costume.

Where AI-Generated Full-Stack Code Silently Rots (and How Templates Cap the Damage)

Jules Sarah — Wed, 16 Sep 2026 05:11:50 +0000

AI-generated code doesn't fail loudly. It fails in the three places nothing exercises: auth boundaries, RLS policies, and webhook event coverage
A template's value isn't the code it saves you writing. It's the code that already survived production
Prompt for features on top of a debugged foundation, never for the plumbing itself
Any diff touching policies/, webhooks/, or auth/ gets a human read. Everything else, trust the agent

I've shipped a handful of React Native + Supabase apps this year where an agent wrote most of the code. None of them broke on day one. Two of them broke on day forty, and both times the failure had been sitting in the repo since the first week, green in CI, invisible in the demo.

That's the thing about agent-written full-stack code. It doesn't rot where you're looking. It rots where the happy path never goes.

1. Auth boundary tests that only test the happy path

Ask an agent to "add tests for the profile endpoint" and you get something like this:

it('returns the profile for the current user', async () => {
  const res = await api.get('/profile', { headers: authHeader(userA) });
  expect(res.status).toBe(200);
  expect(res.body.id).toBe(userA.id);
});

Correct, and useless. The test that matters is the one the agent almost never writes unprompted:

it('does not return another user\'s profile', async () => {
  const res = await api.get(`/profile/${userB.id}`, { headers: authHeader(userA) });
  expect(res.status).toBe(403);
});

it('rejects an expired token', async () => {
  const res = await api.get('/profile', { headers: authHeader(userA, { expired: true }) });
  expect(res.status).toBe(401);
});

The model optimizes for "the feature works." Nobody in the prompt said "the feature refuses." So the boundary never gets a test, and three refactors later a where user_id = ? clause quietly becomes a where id = ? and nothing catches it.

2. RLS policies that look right and aren't

This is the one that bit me on day forty. The agent added a workout_logs table for a new feature. It wrote the migration, the types, the screen. It also wrote this:

alter table workout_logs enable row level security;

create policy "Users can read their own logs"
  on workout_logs for select
  using (auth.uid() = user_id);

Looks fine. Reads fine in review. Three things are wrong with it:

There's no insert policy, so the app "works" only because the agent also wrote the insert through a service-role edge function to get around the error it hit. That function had no auth check of its own.
There's no update or delete policy, which is safe by accident today and a landmine the day someone adds "edit log."
There's no with check clause anywhere, so the moment an insert policy does get added, a user can insert rows with someone else's user_id.

RLS is where AI-generated code is at its most dangerous, because the failure mode is silent, the code is syntactically perfect, and the agent will route around any error it hits rather than ask why the error exists.

3. Stripe webhooks that handle one event

Every agent-written Stripe integration I've reviewed handles checkout.session.completed. Almost none of them handle:

customer.subscription.updated (plan changes, trial ending)
customer.subscription.deleted (the user cancelled, and your app still thinks they're Pro)
invoice.payment_failed (card declined on renewal; you now have a paying user with no payment)
Duplicate deliveries. Stripe retries. Without idempotency on event.id, a retry double-grants credits or double-sends the welcome email

The checkout.session.completed path is the one the agent can verify in a test run. The other four only show up with real customers over real months, which is exactly when you've stopped looking.

Why templates cap the damage

The usual pitch for a starter template is "skip two weeks of setup." That undersells it. Two weeks of typing is not the expensive part. The expensive part is the six months of production that turned the first version of that auth boundary, that RLS policy set, and that webhook handler into the version that actually holds.

A template's value is debugged code, not written code. Specifically:

The boundary tests already exist, so an agent refactoring auth has something to break.
The RLS policies come as a complete set (select, insert, update, delete, with with check), so the agent's job is to add a table that matches the pattern, not invent the pattern.
The webhook handler already switches on the whole subscription lifecycle and dedupes on event.id, so the agent adds a case, not a file.

The agent is good at extending a pattern that's in front of it. It's bad at inventing the pattern from a one-line prompt. Templates put the pattern in front of it. Something like AppLighter ships exactly these three pieces already wired for Supabase, with the CLAUDE.md and slash commands so the agent reads the conventions before it writes anything. That's the whole reason the sister product, RapidNative, can generate full-stack apps at all: the generated code lands inside a foundation that already knows where the boundaries are.

The 4-step workflow

This is what I do now on every feature that touches auth, data access, or money.

1. Read the template's boundary tests before you prompt. Five minutes. You need to know what "refuses correctly" looks like in this codebase so you can tell when the agent has broken it.

2. Prompt for the feature, not the plumbing. "Add a workout log screen that saves to Supabase" is fine. "Set up RLS for workout logs" is not. The RLS pattern already exists; tell the agent to follow it. If the template has a /add-table command or equivalent, use that instead of describing the migration.

3. Ask for the negative test first. Before the happy path. "Write a test proving user A cannot read user B's workout logs, then make it pass." Agents are perfectly capable of writing boundary tests; they just don't volunteer them.

4. Human-read any diff that touches three directories. policies/, webhooks/, auth/ (or whatever your template calls them). Everything else, review at whatever depth you review agent output today. These three get a line-by-line read, every time, no matter how small the change. That's the entire discipline. It takes about ten minutes per PR.

It's a workflow problem

None of the three rot sites are hard to fix once you know they exist. That's what makes them frustrating: the fix isn't a better model or a better prompt, it's starting from a foundation where the boundaries are already tested and pointing the agent at the boundaries before it writes anything.

The workflow fix is trivially available. Most teams just haven't been burned yet.

If you've found a fourth place agent code rots quietly, drop it in the comments. I've got a suspicion about push token cleanup on logout but haven't caught it in the wild yet.

How we cut support tickets 70% with docs

Jules Sarah — Fri, 04 Sep 2026 13:15:43 +0000

We sell React Native + Expo app templates. Six months ago, ~25% of buyers opened a support ticket within their first week. Today it's ~7%. Same product, same buyers. Only the docs changed.

This is the tactical writeup: what we audited, what we changed, and the seven doc pages that eat most of our former support volume.

Audit 90 days of tickets. Tag each with root cause + which doc would have prevented it.
Two-thirds of our tickets were setup friction, not bugs.
Consolidate environment variable docs into ONE page with a complete table.
Ship a "first 15 minutes" quick start that skips every optional feature.
Put error strings verbatim in your docs so Google indexes them.
Make your support surface more prominent, but route through a dialog that suggests docs first.
Result: ~70% fewer tickets, better bug reports, more time for real work.

The audit

We store support requests in a Supabase table (support_requests) surfaced through a small admin dashboard. Pulled 90 days, ~312 tickets, tagged each:

category: env-misconfig | supabase-setup | eas-build | stripe | bug | customization
template: weather-app | fitness-app | ai-voice-notes | chat-with-pdf | ...
doc_that_would_have_helped: <path or "none">

Breakdown:

Category	% of tickets
`.env` misconfig	34%
Supabase project setup	22%
Expo / EAS build errors	15%
Genuine bugs	11%
Stripe / license activation	9%
"How do I customize X"	9%

66% of tickets were pre-first-run setup friction. Not novel bugs. Not missing features. The twenty-minute cliff between git clone and a working simulator build.

Change #1: Index error strings, not concepts

The single highest-ROI change. For every ticket that mentioned an error message, the literal string now appears verbatim in a doc page with the fix beneath it.

Bad:

### AsyncStorage resolution issues

If your bundler can't resolve async storage, ensure the dependency is installed.

Good:

### Error: `Unable to resolve module "@react-native-async-storage/async-storage"`

```bash
npx expo install @react-native-async-storage/async-storage
npx expo start --clear
```

This happens when the module was added transitively (usually via
`@supabase/supabase-js` session persistence) but not explicitly installed.

Devs paste error strings into Google. Google indexes the string. Google sends them to the fix. You never see the ticket.

Change #2: One `environment.mdx`, not seven scattered mentions

Old state: .env variables were mentioned in the Supabase page, the Stripe page, the push-notifications page, the OneSignal page, the EAS page. Each mention was correct in isolation. Collectively, nobody could find anything.

New state: one environment.mdx page. One table. Columns: variable name, source, client-or-server, what fails if missing.

| Variable                          | Source                | Scope   | If missing                                |
|-----------------------------------|-----------------------|---------|-------------------------------------------|
| EXPO_PUBLIC_SUPABASE_URL          | Supabase dashboard    | Client  | App loads, all queries return 401         |
| EXPO_PUBLIC_SUPABASE_ANON_KEY     | Supabase dashboard    | Client  | Auth silently fails                       |
| SUPABASE_SERVICE_ROLE_KEY         | Supabase dashboard    | Server  | Server routes return 500                  |
| STRIPE_SECRET_KEY                 | Stripe dashboard      | Server  | Purchase webhooks 500, no license grants  |
| ...                                                                                                     |

Boring. Effective. This one page killed a plurality of setup tickets alone.

Change #3: Six-command quick start

Old quick-start.mdx was maximalist: clone, install, env, Supabase, Stripe, EAS, push notifications, deep linking. New one:

git clone <your-license-url>
cd applighter-template
npm install
cp .env.example .env
# fill in EXPO_PUBLIC_SUPABASE_URL + ANON_KEY
npx expo start

Six commands. A running app on your simulator. Everything else is optional and lives on its own page.

Nobody wants to configure OneSignal in their first hour. Stop making them.

Change #4: Prominent support surface, routed through docs

Counter-intuitive result: making our support link more visible reduced tickets, not increased them.

The floating support button (a contact-author-fab component) opens a dialog. The dialog:

Asks for a one-line problem summary
Searches our docs for keyword matches
Surfaces top 3 doc results before offering the submit button
Only then lets you file a ticket

Roughly 40% of dialog opens never become tickets. People click a doc result, read it, close the dialog, and move on. Zero human interaction.

What didn't work

Videos. Three 8-minute setup walkthroughs. Two weeks of production. ~40 views/month combined. No measurable ticket delta. Devs skim; video prevents skimming.

Chatbot on our docs. Hallucinated flags, invented API surface, confidently misrepresented patterns we don't use. Customers pasted its answers back to us as bug reports. Killed after one week. The space is improving fast, but static docs that say the true thing still beat generative docs that say a plausible false thing.

The seven-page scaffold

If you're starting fresh (this is the structure every Applighter template's docs now follow):

quick-start.mdx: six commands, no optional features
installation.mdx: prerequisites, tool versions, common install errors verbatim
environment.mdx: one table, every variable, every failure mode
folder-structure.mdx: where things live, in one screen
supabase.mdx: project provisioning, RLS, storage buckets
expo-integration.mdx: EAS Build, provisioning, error strings verbatim
ui-components.mdx: customization points, how to not break updates

Everything beyond these seven pages is a nice-to-have.

Metrics worth tracking

Tickets per 100 active customers/week (target: <8)
% of tickets citing a doc page (target: >60%, which means people are reading first)
% of support-dialog opens that don't become tickets (target: >30%)
Median first-response resolution rate (target: >50%)

Metric to stop tracking: total weekly support hours. Goes to zero if you ignore your inbox. Useless.

References

Expo EAS docs: https://docs.expo.dev/build/introduction/
Supabase RLS docs: https://supabase.com/docs/guides/auth/row-level-security

Fewer tickets, better product, same 4,000 words of docs, just pointed at the right problems.

If you sell templates or dev tools: what's your top ticket category? Curious whether the two-thirds-setup-friction split holds outside our niche. Drop it in the comments.

The auth-screen UX playbook for Expo apps

Jules Sarah — Wed, 02 Sep 2026 10:58:13 +0000

Auth is the most scrutinised surface in a mobile app. People decide whether it looks legitimate almost immediately, and whether they're willing to sign up shortly after. Everything downstream is gated behind that.

Mobile OAuth in particular is where otherwise good apps leak users quietly, because the failure isn't an error. It's a browser tab the user has to close themselves.

The legitimacy scan

On first open, people scan for a small set of signals:

A logo that isn't pixelated
Provider buttons using the official brand assets, not lookalikes
Copy that doesn't read as machine-translated
No layout shift as the screen mounts

All four have to land. Any one being off loses users who will never tell you why.

Use the platform packages rather than rolling your own buttons. expo-apple-authentication renders Apple's official button, and @react-native-google-signin/google-signin gives you Google's. Both handle the brand requirements you'd otherwise have to read the guidelines for.

Keep the OAuth callback in-app

This is the difference between OAuth working and OAuth converting.

The naive flow opens a browser, the user signs in, the browser shows a success page, and then the user has to work out that they should return to the app themselves. Some don't.

const { data } = await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: {
    redirectTo: Linking.createURL('/'),
    skipBrowserRedirect: true,
  },
});

const result = await WebBrowser.openAuthSessionAsync(
  data.url,
  Linking.createURL('/'),
);

if (result.type === 'success') {
  // parse access_token and refresh_token from the returned URL fragment
  await supabase.auth.setSession({ access_token, refresh_token });
}

openAuthSessionAsync uses ASWebAuthenticationSession on iOS and Custom Tabs on Android. Both close themselves when they see the return scheme, so the user lands back in the app with a session already established and no visible handoff.

The token parsing is the fiddly part and the snippet leaves it as a comment deliberately: the tokens arrive in the URL fragment rather than the query string, so a naive URLSearchParams on the whole URL returns nothing and you'll spend twenty minutes wondering why.

Password reset is a funnel nobody revisits

It gets designed once and never looked at again, which means when it breaks, it breaks silently. Nobody files a bug about a password reset that didn't arrive. They just leave.

The flow that works:

Email input screen
resetPasswordForEmail(email, { redirectTo: 'myapp://reset' })
The emailed link deep-links into the app with a session already established
New password via updateUser({ password }), then a success screen with a sign-in action

The breakage to know about: the emailed link won't open the app unless the scheme is registered under Additional Redirect URLs in your Supabase auth settings. Add it once. This accounts for most "reset doesn't work" reports, and it produces no error anywhere in your code.

Error copy that doesn't alarm people

Never surface raw auth errors. AuthApiError: Invalid login credentials reads as something being broken. "Email or password doesn't match" reads as a typo.

Map every one:

const AUTH_ERRORS: Record<string, string> = {
  'Invalid login credentials': "Email or password doesn't match. Try again.",
  'User already registered': 'You already have an account. Try signing in.',
  'Password should be at least 6 characters': 'Password needs to be 6+ characters.',
};

Plus a network fallback, because "can't reach the server, check your connection" is a completely different message from "your details are wrong" and users act on them differently.

And put errors inline, under the field that failed. A red banner at the top of the screen is a web pattern that mobile inherited, and on a phone it means the user is looking at the wrong part of the screen to find out what went wrong.

The general shape

Every item here is the same class of problem: nothing throws, nothing appears in your error tracking, and the user simply doesn't complete. A browser tab left open. A reset email that goes nowhere. An error message that reads as a system failure rather than a typo.

Auth either works or it doesn't, technically. The gap between working and converting is entirely in these details.

The Applighter Expo templates ship auth wired this way, though everything above is a few hours of work in any project and worth doing before your first round of user testing.

What's the auth bug that took you longest to find? Mine was the redirect URL, and it took two days because nothing anywhere reported an error.

7 AI App Templates in 12 Months: What We Learned

Jules Sarah — Fri, 28 Aug 2026 11:30:28 +0000

Seven React Native templates in twelve months. Two AI-first, five conventional apps with AI stitched into the seams.

This is the concrete retrospective: the stack, the schema, the payment webhooks, the SDK bumps, the pricing. If you're building a template business or considering buying one, it's the post I wanted a year ago.

One AI job per template beats a chat tab bolted onto a generic app
The schema with correct RLS is the hard part; screens are replaceable
SDK upgrades are the largest recurring cost and we didn't price them in
Payments took four weeks, not four days
Cheap templates sold fewer copies, not more

The stack

After two false starts we locked it:

Runtime      : Expo SDK 54, new architecture
Language     : TypeScript, strict
UI           : NativeWind
Motion       : Reanimated + Gesture Handler
State        : Zustand + TanStack Query
Backend      : Supabase (Postgres, Auth, Storage, Edge Functions)
Payments     : Stripe, webhooks handled server-side
LLM          : Provider abstraction so the model is swappable
Tooling      : EAS build, update, submit

Each piece was picked for one property: it survives contact with a customer who doesn't know the library. NativeWind classes are searchable. Worklets don't stall when the JS thread does. Supabase migrations are versioned SQL you can read.

The registry pattern

Every template is a config file registered in one map:

// app/apps/config/index.ts
export const appConfigs: Record<string, ProductData> = {
  "weather-app":       weatherAppConfig,
  "fitness-app":       fitnessAppConfig,
  "e-learning-app":    eLearningAppConfig,
  "taxi-booking-app":  taxiBookingAppConfig,
  "ai-voice-notes":    aiVoiceNotesConfig,
  "chat-with-pdf":     chatWithPdfConfig,
};

Adding a template is one import and one map entry. A database-backed catalog was tempting for about a week and turned out to be unnecessary. Seven templates fit in a Record comfortably.

1. AI feature, not AI wrapper

Both of our best-selling AI templates do exactly one AI thing.

// AI Voice Notes: one job, audio to structured summary
async function summarize(audioUri: string) {
  const transcript = await transcribe(audioUri);
  return await extractStructure(transcript); // { summary, actions, decisions }
}

No chat bubble. No "ask this app anything" tab.

The templates where we bolted a chat tab onto a generic screen underperformed the ones where the AI was the feature. A chat tab is a way of not deciding what the AI is for, and buyers can tell.

2. RLS is the moat

Screens are easy to replace. A schema with correct row-level security takes weeks.

Every template ships migrations under supabase/migrations/, and every read and write is gated by a policy assuming auth.uid().

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

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

create policy "update own notes" on notes
  for update using (auth.uid() = user_id);

The bug we caught most in review was a missing sibling policy. Select correct, update absent. It fails silently, because the read works and the write just quietly does nothing to rows it shouldn't touch.

We test every template with two dummy accounts on a fresh Supabase project. Not optional. Reference: Supabase RLS docs.

3. SDK bumps eat weeks

Three SDK versions across the year. Each bump cost roughly a full engineering week per template:

New architecture opt-in
expo-audio replacing expo-av
Native modules re-verified on both platforms
Animation API drift

Seven templates, three bumps, a week each. That arithmetic is unpleasant and we didn't price it into the first three templates. We paid for it in December.

If you sell templates, maintenance is not overhead. It's the product.

4. Payments is a project

The webhook granting a customer access to what they bought is larger than any screen in any template.

type Grant = { userId: string; productId: string; source: "single" | "bundle" };

async function reconcile(event: Stripe.Event) {
  switch (event.type) {
    case "checkout.session.completed": /* create grant(s) */ break;
    case "charge.refunded":            /* revoke grant   */ break;
    case "customer.updated":           /* rekey email    */ break;
    // multi-line-item bundles, dedupe against prior grants,
    // same customer arriving with two different emails
  }
}

Plan four weeks. Not four days.

The cases that broke us were never the happy path. They were bundles containing a template the customer already owned, and refunds arriving after an email change.

5. NativeWind and Reanimated

A boring combination that kept winning:

import Animated, { FadeIn } from "react-native-reanimated";

export function Card({ title }: { title: string }) {
  return (
    <Animated.View entering={FadeIn} className="p-4 rounded-2xl bg-white dark:bg-slate-900 shadow">
      <Text className="text-lg font-semibold text-slate-900 dark:text-white">{title}</Text>
    </Animated.View>
  );
}

Searchable classes, worklets on the UI thread, and an unexpected third benefit: AI assistants get both libraries right on the first attempt.

That last one matters more than we expected, because most of our customers open the template in an AI editor rather than reading it top to bottom. A stack that models well is a stack that gets extended correctly.

6. Demo video beats README

Every template config carries a video. A short edited walkthrough moved conversion more than any pricing test we ran.

Not a screen recording. An edit.

7. Pricing

Single-app licence at $79, with a bundle at a materially better per-app rate. Two things surprised us.

Bundle attach rate is high. Customers who buy one template come back for the bundle rather than buying a second single.

And cheaper templates sold fewer copies, not more. Below a certain price, buyers appear to read the price as a signal about quality, and the ones who don't are not the customers you want anyway.

Scratch versus template

For a buyer starting a new app:

Task	From scratch	With a template
Auth (email, OAuth, Apple)	About a week	Included
Supabase schema and RLS	About a week	Included
Push notifications	Several days	Included, minus certificates
AI feature with streaming and storage	About a week	Included
Design tokens	A few days	Included
Icon, splash, EAS config	A couple of days	Included
Your own payments, if you sell something	About a week	Still yours

That last row is the honest one. A template gets you to a working app quickly. It does not remove the work of charging your own customers, and any comparison table that says otherwise is selling you something.

What we'd do differently

Pick the styling stack on day one
Write the schema before the screens
Record the demo video before launch, not after
One AI job per template, never a chatbot
Test on a clean machine before every release
Price maintenance from the start

Wrap

A year, seven templates, more webhook edge cases than anyone deserves.

The ones that survived contact with customers had real schemas, one focused AI job, and payments that didn't fall over on the first refund. Everything else was decoration, and we learned which was which by shipping the decoration first.

Full write-up with the internal architecture detail is on the Applighter blog.

If you sell templates or plugins, what did maintenance actually cost you in year one? I suspect most people underprice it the same way we did, and nobody publishes the number.