DEV Community: Mark F A

Your Supabase Migrations Should Survive Any Postgres. Here's How I Test That.

Mark F A — Mon, 28 Sep 2026 14:59:24 +0000

TL;DR

The only part of your local Supabase setup that should travel to production is supabase/migrations/*.sql. Everything else is disposable.
If a migration only works because you clicked something in a dashboard once, it's not a migration. It's a memory.
I replay every migration against a bare Postgres 17 in CI, with a tiny auth shim, on every PR. It catches ordering bugs, missing extensions, and edited history before they reach a real database.
Once migrations are the contract, your local runtime becomes swappable. That's the real payoff.

Most "Supabase local dev" posts are about the runtime: which containers, how much RAM, how fast it boots. This one is about the thing that outlives every runtime you'll ever use: the folder of SQL files.

The contract is the folder

Here's the only layout that matters:

supabase/
├── migrations/
│   ├── 20260901120000_create_projects.sql
│   ├── 20260905093000_projects_rls.sql
│   └── 20260912174500_add_project_members.sql
└── seed.sql          # local-only data, never runs in prod

Timestamps order the history. Each file runs once, in order, and gets recorded in a history table so it never runs again. That's the whole model, and it's the same model whether the files land on a laptop, a CI box, or hosted Supabase.

You don't need any tooling to create one:

touch "supabase/migrations/$(date -u +%Y%m%d%H%M%S)_add_project_members.sql"

Five rules for migrations that travel

1. Nothing exists unless a migration created it

The classic drift: a column added through a dashboard, a policy tweaked in the UI, a function pasted into a SQL editor. It works on your database. A teammate clones the repo and it doesn't exist.

If it isn't in supabase/migrations, assume it doesn't exist.

2. Declare your extensions

create extension if not exists "pgcrypto" with schema extensions;

Hosted Supabase ships a lot of extensions pre-enabled. A fresh Postgres doesn't. Say what you depend on, in the migration that first needs it.

3. Tables and their RLS ship together

create table public.projects (
  id uuid primary key default gen_random_uuid(),
  owner_id uuid not null references auth.users (id) on delete cascade,
  name text not null,
  created_at timestamptz not null default now()
);

alter table public.projects enable row level security;

create policy "owners read own projects"
  on public.projects for select
  to authenticated
  using ((select auth.uid()) = owner_id);

A table that exists for even one migration without RLS is a table that someone, someday, will query in that window. Same file, every time.

4. Never edit a migration that's already been applied

Applied history is immutable. Want to change it? Write a new migration. Editing an old file means your laptop and production now disagree about what "migration 3" did, and nothing will tell you.

A cheap guard for PRs:

#!/usr/bin/env bash
# scripts/no-edited-migrations.sh
set -euo pipefail
changed=$(git diff --name-only --diff-filter=MR origin/main -- supabase/migrations || true)
if [ -n "$changed" ]; then
  echo "Applied migrations were modified:"
  echo "$changed"
  echo "Write a new migration instead."
  exit 1
fi

5. Schema in migrations, data in seed

Test users, demo rows, and fixtures go in seed.sql. Mixing them into migrations means production eventually gets alice@example.com.

The replay check: bare Postgres 17 + a tiny auth shim

Here's the part I actually rely on. On every PR, CI spins up a vanilla Postgres 17 and replays every migration in order. If a file depends on something no migration created, it fails loudly.

Supabase migrations reference auth.users, auth.uid(), and the anon / authenticated roles, which a bare Postgres doesn't have. So the check loads a minimal shim first:

-- scripts/auth-shim.sql
-- NOT Supabase Auth. Just enough surface for migrations to apply.
create schema if not exists auth;
create schema if not exists extensions;

do $$
begin
  if not exists (select from pg_roles where rolname = 'anon') then create role anon nologin; end if;
  if not exists (select from pg_roles where rolname = 'authenticated') then create role authenticated nologin; end if;
  if not exists (select from pg_roles where rolname = 'service_role') then create role service_role nologin bypassrls; end if;
end $$;

create table if not exists auth.users (
  id uuid primary key default gen_random_uuid(),
  email text,
  raw_user_meta_data jsonb default '{}'::jsonb
);

create or replace function auth.uid() returns uuid
language sql stable as $$
  select nullif(current_setting('request.jwt.claim.sub', true), '')::uuid
$$;

And the replay script:

#!/usr/bin/env bash
# scripts/replay-migrations.sh
set -euo pipefail

psql -v ON_ERROR_STOP=1 -q -f scripts/auth-shim.sql

for f in $(ls supabase/migrations/*.sql | sort); do
  echo "→ $f"
  psql -v ON_ERROR_STOP=1 -q --single-transaction -f "$f"
done

echo "✅ All migrations replayed cleanly on a fresh Postgres"

Wire it into GitHub Actions:

name: migrations
on: [pull_request]

jobs:
  replay:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_PASSWORD: postgres
        ports: ["5432:5432"]
        options: >-
          --health-cmd pg_isready --health-interval 5s --health-retries 10
    env:
      PGHOST: localhost
      PGUSER: postgres
      PGPASSWORD: postgres
      PGDATABASE: postgres
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - run: bash scripts/no-edited-migrations.sh
      - run: bash scripts/replay-migrations.sh

What this catches:

A migration that references a table created in a later file (timestamp mistakes happen)
A missing create extension
Objects that only ever existed in someone's dashboard
Edited history
Plain syntax errors, before a human reviews the PR

What it doesn't catch: real auth behavior, JWT claims, or whether your policies return the right rows. The shim is scaffolding, not Supabase. Test policy behavior against a runtime that actually implements the API.

Why this makes your local runtime swappable

Once the SQL folder is the contract, the local runtime is just "something that applies these files to real Postgres and serves the Supabase APIs on top." You can pick whichever one fits your machine today, and the choice stops being a commitment.

For my own laptop I've been using tinbase, an open-source, Supabase-compatible runtime on real Postgres 17 that runs as a single process without Docker. It reads the same supabase/migrations/*.sql files the Supabase CLI does and tracks them in the same way, so the folder above works unchanged:

npx tinbase start

And app code doesn't change either. It's the regular client pointed at the local URL:

import { createClient } from '@supabase/supabase-js';

export const supabase = createClient(
  'http://127.0.0.1:54321',
  process.env.SUPABASE_ANON_KEY!,
);

Worth being upfront: it's alpha software built for local dev and prototypes, not production. Which is exactly the point of this workflow. The runtime is disposable. The migrations aren't.

When it's time to ship, the same files go to hosted Supabase with the CLI:

supabase link --project-ref <your-project-ref>
supabase db push

No rewrite, no export, no "which version of the schema is real."

The mental model

Migrations are source code. Reviewed, immutable once applied, replayed in CI.
Seed data is a local convenience.
The local runtime is a tool you can swap on a Tuesday afternoon without anyone noticing.

If swapping your local runtime would break something, that's not a runtime problem. It's a migration that isn't telling the whole truth.

What's the worst schema drift bug you've hit between local and production? Dashboard edits, edited migrations, something weirder? Drop it in the comments. 👇

The Bugs That Only Exist Because Your Local DB Isn't Real Postgres

Mark F A — Wed, 23 Sep 2026 11:04:57 +0000

TL;DR

If your local dev database is an emulated or WASM Postgres and you deploy to real Postgres, you're testing against a different engine than you ship on.
The divergences that bite: single-connection tools hide every concurrency bug, WASM builds ship only some extensions, and emulated engines approximate RLS and Postgres-specific SQL instead of running it.
These bugs are invisible locally by definition. They surface in staging or prod, which is the worst place to find them.
The fix isn't Docker's 12-container stack. It's running actual Postgres locally, cheaply.
Match the local engine to the job: embedded/local-first → WASM is perfect; "does this behave like prod" → you need real Postgres.

You wrote the query, it passed locally, tests were green, you shipped. Then prod throws a deadlock, or a CREATE EXTENSION fails, or a row-level-security policy lets through a row it shouldn't. None of it reproduced on your machine.

Here's the uncomfortable reason: your local "Postgres" wasn't Postgres. It was an emulation, a WASM build, or an in-memory reimplementation. Fast and convenient, and subtly different from the engine you deploy on. Those differences are a whole class of bugs that are structurally invisible in local dev.

Let me name the three that cost the most time.

Divergence 1: single-connection tools hide every concurrency bug

This is the big one, and it's structural, not a config you can fix.

pglite (Postgres compiled to WASM, under 3 MB gzipped) is explicitly single-user, single-connection. That's not a knock. It's inherent to the design: Emscripten can't fork processes, so pglite runs Postgres in single-user mode. Brilliant for embedding a SQL engine in the browser or a Node process. But it means that locally, there is only ever one connection.

Which means the entire category of concurrency bugs cannot appear:

Deadlocks between transactions that grab locks in different orders.
Lost updates from two writers racing on the same row.
SELECT ... FOR UPDATE SKIP LOCKED job-queue logic that only reveals its bug under contention.
Serialization failures under SERIALIZABLE isolation.

You can write a broken job worker, run it against a single-connection local DB, watch every test pass, and ship a queue that double-processes rows the moment two workers run in prod. The local engine never had a second connection to expose it.

-- A classic worker pattern. Correct behavior depends entirely on
-- what happens when TWO workers run this at the same time.
BEGIN;
SELECT id, payload
FROM jobs
WHERE status = 'pending'
ORDER BY created_at
FOR UPDATE SKIP LOCKED   -- silently meaningless with one connection
LIMIT 1;
-- ... process, then:
UPDATE jobs SET status = 'done' WHERE id = $1;
COMMIT;

On a single-connection engine, SKIP LOCKED never has anything to skip. The query works, so you assume the logic works. It doesn't.

Divergence 2: the extension is in the docs, not in the build

Real Postgres has a huge extension ecosystem. WASM and emulated builds ship a curated subset, because each extension has to be compiled in or emulated.

pglite includes some (pgvector, PostGIS) but you have to verify anything else is in the WASM build before you rely on it. Single-binary tools make different calls too: some Postgres extensions get skipped or emulated rather than truly run. So this passes locally and fails in CI or prod:

-- Fine on hosted Postgres if the extension is available there.
-- Locally: works, silently no-ops, or errors, depending on your engine.
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX idx_name_trgm ON users USING gin (name gin_trgm_ops);

-- Same story for uuid-ossp, pg_cron, pg_net, http, hypopg...

If your search relies on pg_trgm, your scheduled jobs on pg_cron, or your vector search on a specific pgvector version, "it worked locally" tells you nothing about whether it works where you deploy. You need the local engine to either run the real extension or fail loudly the same way prod would.

Divergence 3: RLS and Postgres-specific SQL get approximated

Row-level security is where "approximately Postgres" gets dangerous, because the failure mode is a security failure, not a crash.

An emulated engine that reimplements Postgres in JavaScript has to reimplement RLS policy evaluation, auth.uid(), SECURITY DEFINER semantics, and the exact order policies combine. Get any of it slightly wrong and a policy that blocks a row locally lets it through in prod, or vice versa. The same applies to the long tail of Postgres-specific behavior: jsonb operator edge cases, generated columns, trigger firing order, type coercion, and NULL handling in composite keys.

The only way to actually test an RLS policy is to run it on the same engine that will enforce it in production. Approximation is not a test.

The real fix: actual Postgres, locally, without the Docker tax

The historical reason people reached for emulated engines is that the "correct" alternative was heavy. Supabase local dev is a 12-container Docker stack that runs around 2.3 GB on disk and over a gigabyte of RAM under load. On a 16 GB laptop, on a train, that tax is real, so people traded fidelity for lightness and inherited the divergence bugs above.

That trade isn't necessary anymore. Tinbase runs a Supabase-compatible backend on real Postgres 17 as a single process, no Docker. Because it's the actual Postgres engine, RLS, auth.uid(), jsonb, triggers, and foreign keys behave the way they do on hosted Supabase, and the official supabase-js SDK works unchanged. The migration is a connection-string swap:

// Before: Docker Supabase local (12 containers, ~2.3 GB)
const supabase = createClient('http://localhost:54321', anonKey);

// After: Tinbase (one process, real Postgres 17)
const supabase = createClient('http://localhost:4000', anonKey);
// same SDK, same anon key format, zero app-code refactor

npx tinbase start
# boots in a couple of seconds; reads your supabase/migrations/*.sql
# and seed.sql the same way the Supabase CLI does

It's open source (MIT) and built by Sanket Sahu at Shaper Studio. It's honest about its edges too: a few extensions it can't compile in (pg_cron, pg_net, http, hypopg) are skipped or emulated rather than silently faked, which is exactly the kind of loud divergence you want to see locally instead of discovering in prod.

So which engine when?

This isn't "emulated bad, real good." It's matching the tool to the question:

Local-first / embedded / in-browser SQL: pglite. Being WASM and single-connection is the feature, not a bug.
A throwaway unit test that just needs SQL to parse: an in-memory engine is fine and fast.
"Does this behave like production?" You need real Postgres locally, whether that's Tinbase's single binary, a native install, or Docker if you're already invested in it.

The mistake isn't using pglite or an in-memory engine. It's using one to answer a question it structurally cannot answer, and calling a green test suite proof.

Your turn

What's the worst "worked locally, broke in prod" database bug you've shipped? I'm betting at least one of you has a SKIP LOCKED story. Drop it in the comments, along with what your current local setup is.****

PGlite Is Great. It Still Is Not Your Local Postgres Stack.

Mark F A — Mon, 21 Sep 2026 09:12:11 +0000

TL;DR

PGlite is real Postgres compiled to WASM: no Docker, no install, starts in milliseconds
It is brilliant for unit tests, CI, and embedded/in-browser databases
It is single connection, speaks no wire protocol out of the box, and ships none of the platform layer (auth, storage, auto API) your app talks to
Use PGlite for tests. Use a real Postgres server (there are single-binary options now) when your app expects a database plus the services around it

What PGlite actually is

PGlite is Postgres compiled to WebAssembly, wrapped in a TypeScript client. Not a Linux VM running Postgres, not a lookalike engine: the actual Postgres query planner and executor, running inside your JS runtime.

import { PGlite } from "@electric-sql/pglite";

const db = new PGlite();
await db.query("select 'hello' as message;");
// { rows: [ { message: "hello" } ] }

That is a working Postgres in two lines. In memory by default, persistable to the filesystem in Node or IndexedDB in the browser, roughly 3 MB gzipped, with extension support including pgvector.

Where it genuinely wins

Unit tests and CI. This is the killer use case. A fresh, isolated Postgres per test, created and destroyed in milliseconds:

import { PGlite } from "@electric-sql/pglite";

test("inserts a user", async () => {
  const db = new PGlite(); // brand new database, every test
  await db.exec("create table users (id serial, email text)");
  await db.query("insert into users (email) values ($1)", ["a@b.co"]);
  const res = await db.query("select count(*)::int as n from users");
  expect(res.rows[0].n).toBe(1);
});

No shared test database, no truncate-between-tests hacks, no container spin-up in CI.

Embedded and in-browser databases. Local-first apps, demos, playgrounds: shipping Postgres inside the page is a legitimately new capability.

Where it stops being your dev database

One connection. Ever. PGlite runs Postgres in single-user mode because WASM cannot fork processes. Your app opens a pool of five connections? Not happening. Two services sharing one dev database? Not happening.

No wire protocol by default. psql, TablePlus, your ORM's normal driver: all of them speak the Postgres protocol over TCP. PGlite is a library call, not a server. There is a socket proxy add-on that bridges this, but at that point you are assembling infrastructure, which was the thing you were avoiding.

No platform layer. If your app is built against a Supabase-style stack, the database is maybe a third of what it talks to. Auth endpoints, row level security backed by real roles, storage buckets, the auto-generated REST API: none of that exists in a bare WASM Postgres. Your app boots, then dies on the first supabase.auth call.

This is the gap single-binary runtimes are filling. Tinbase, for example, is an MIT-licensed single binary that runs a real Postgres server with a Supabase-compatible surface on top: real connections, real wire protocol, no Docker. Same "just run it" feel PGlite gives you, but for the whole stack instead of the engine alone.

The decision table

You need	Reach for
Fresh DB per unit test	PGlite
Postgres in the browser	PGlite
psql / GUI clients / connection pools	Real Postgres server
Supabase-style auth, storage, REST	Supabase-compatible runtime
CI without containers	Either, depending on the two rows above

The honest framing: PGlite is not a worse local Postgres. It is a different shape of Postgres, and the shape matters more than the engine.

Closing

I have moved all my unit tests to PGlite and my app-level dev environment to a single-binary runtime, and the two do not compete at all.

What is your local Postgres setup right now: Docker, WASM, single binary, or "I just point dev at a cloud database and hope"? Drop it in the comments, especially if it is the last one.

Postgres RLS in Local Dev: The Three Silent-Fail Modes That Ship to Prod

Mark F A — Wed, 16 Sep 2026 13:47:19 +0000

TL;DR

RLS has a brutal failure property: when it is misconfigured, everything works. Queries return rows, tests pass, nothing errors
Silent-fail 1: your migration tool (raw SQL, dbmate, Prisma) creates tables with RLS disabled by default
Silent-fail 2: your local dev connection runs as a role with BYPASSRLS, so policies are never exercised even when they exist
Silent-fail 3: views execute with the view owner's privileges, so RLS on the underlying tables is skipped unless you opt in (Postgres 15+)
All three are catchable with about 30 lines of SQL that run at boot in ~50ms

The nasty thing about row level security is that it fails open in development. A missing policy doesn't throw. A bypassed policy doesn't warn. Your app happily reads and writes, your test suite goes green, and the first person to discover the gap is a curious user in production changing an ID in a URL.

Here are the three ways I've seen that happen, and the boot-time check that makes all of them loud.

Silent-fail 1: migrations don't enable RLS

Whatever writes your DDL, the default is the same. This table has no row security:

create table user_notes (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null,
  body text
);

Raw SQL migrations, dbmate, Prisma's generated DDL: none of them add enable row level security for you. You have to remember two lines, every table, forever:

alter table user_notes enable row level security;
alter table user_notes force row level security;

That second line matters more than people think. Without force, the table's owner still bypasses RLS entirely. If your app connects as the role that ran the migrations, you have policies that apply to nobody.

Silent-fail 2: dev is seeded (and queried) under BYPASSRLS

Even with RLS enabled and policies written, they only apply to roles that are subject to them. Superusers and any role with the BYPASSRLS attribute skip the whole mechanism.

And that is exactly how most local stacks are wired: you seed and often query as postgres or an equivalent admin role. So locally, every policy is a no-op. The first connection that actually exercises your policies is the production one, which is the worst possible place to run a policy for the first time.

The fix is to make local dev connect the way production does: as a non-privileged role, with the admin role reserved for migrations only.

Silent-fail 3: views don't inherit RLS (until you ask)

Views in Postgres execute with the privileges of the view's owner, not the querying user. Create a convenience view over a policied table and you have quietly built a door around your own policies:

create view recent_notes as
  select * from user_notes order by created_at desc limit 100;
-- runs as the owner: RLS on user_notes is not applied to callers

Postgres 15 added the opt-in fix:

create view recent_notes
  with (security_invoker = true) as
  select * from user_notes order by created_at desc limit 100;

With security_invoker, the view runs as the caller and RLS applies normally. On anything older than 15 there is no clean equivalent, which is one of several reasons local dev should run the same modern Postgres major as production.

The boot-time check that catches all three

None of these need discipline. They need a tripwire. This runs at application boot (or as the last migration) and fails loudly on all three modes:

do $$
declare bad text;
begin
  -- 1: tables without RLS (or without FORCE)
  select string_agg(tablename, ', ') into bad
  from pg_tables t
  join pg_class c on c.relname = t.tablename
  where t.schemaname = 'public'
    and (not t.rowsecurity or not c.relforcerowsecurity);
  if bad is not null then
    raise exception 'RLS not enabled/forced on: %', bad;
  end if;

  -- 2: non-system roles that bypass RLS
  select string_agg(rolname, ', ') into bad
  from pg_roles
  where rolbypassrls and rolname not like 'pg\_%' and rolname <> 'postgres';
  if bad is not null then
    raise exception 'BYPASSRLS roles present: %', bad;
  end if;

  -- 3: views without security_invoker
  select string_agg(c.relname, ', ') into bad
  from pg_class c
  join pg_namespace n on n.oid = c.relnamespace
  where c.relkind = 'v' and n.nspname = 'public'
    and coalesce(c.reloptions::text, '') not like '%security_invoker=true%';
  if bad is not null then
    raise exception 'Views without security_invoker: %', bad;
  end if;
end $$;

Adjust the allowlists to taste (maybe your migration role legitimately keeps BYPASSRLS; exclude it explicitly so the exception is a decision, not an accident). On a normal-sized schema this runs in tens of milliseconds. It costs nothing and converts all three silent fails into a crash at boot, which is where you want them.

This class of bug is also why I care about local dev running real Postgres with the same defaults as prod. It is one of the reasons we built Tinbase: a single-binary, MIT-licensed, Supabase-compatible local runtime on actual Postgres 17, no Docker, so checks like the one above behave identically on your laptop and in prod, security_invoker included.

The takeaway

RLS is enforcement only when three things are true: the table has it enabled and forced, the connecting role is subject to it, and every view over it runs as the invoker. Each condition fails silently on its own. Check all three mechanically, at boot, every time.

Have you been bitten by a policy that turned out to be decorative? What did the tripwire look like once you built one? Comments are open.

I Replaced Docker Supabase With a 58 MB Binary and Saved 1.5 GB of RAM

Mark F A — Fri, 11 Sep 2026 13:38:28 +0000

TL;DR

Docker-based Supabase local dev quietly costs gigabytes of RAM, minutes of boot time, and a background VM you forget is running until your fans remind you.
I swapped it for a single native binary: real Postgres 17, Supabase-compatible API surface, no Docker anywhere. The executable is 58 MB (92 MB installed).
On my machine, Activity Monitor gave back roughly 1.5 GB. Your numbers will vary; the shape of the win won't.
Not everyone should switch. If your local setup mirrors a self-hosted production stack container-for-container, stay where you are.

The state of local dev in 2026

Somewhere along the way, "run the database locally" turned into "run a container orchestrator locally." The standard Supabase local setup is a Docker Compose stack: Postgres, the auth server, the REST layer, realtime, storage, the studio UI, an API gateway. Each one is a container. On macOS and Windows, all of them live inside a Linux VM that exists solely so containers have somewhere to be.

None of this is wrong. It's a faithful replica of the hosted product, and for some teams that fidelity is exactly the point. But it's worth saying out loud what we normalized: to write a SELECT statement against a local database, my laptop was running a virtual machine.

Why Docker's cost is invisible until it isn't

The tax hides because you pay it in three currencies you don't track:

RAM you never see itemized. The VM reserves memory whether containers are busy or idle. It doesn't show up as "Supabase" in your process list; it shows up as your machine feeling smaller than it is.
Boot time you've stopped noticing. Pull images, start the VM, health-check seven services into readiness. You've built a coffee ritual around it, which is how you know it's too long.
A failure mode that isn't yours. When local dev breaks, the bug report is rarely about your schema. It's the VM not starting, a port collision with a container you forgot, an image version drifting from your teammate's. You end up debugging the harness instead of the app.

The moment it stops being invisible is always the same: you're on battery, on a call, with the stack "idle" in the background, and the fans spin up anyway.

The switch: what changed on my laptop

I moved my local stack to Tinbase, a single-binary, MIT-licensed local dev runtime that speaks the Supabase API surface and runs real Postgres 17 underneath. No containers, no VM, no compose file. The binary is 58 MB; the full install footprint on disk is 92 MB. (Worth being precise, because those two numbers get conflated constantly, including by us.)

The before state, for context, is the standard compose stack everyone recognizes:

# the shape of what I deleted
services:
  db:        # postgres
  auth:      # gotrue
  rest:      # postgrest
  realtime:
  storage:
  kong:      # api gateway
  studio:

The after state is one process in my process list. My app code didn't change: it's the same connection string pattern and the same client SDK talking to a local URL. That's the whole trick of keeping the Supabase-compatible surface; the swap happens under the app, not in it.

Two honest notes on the migration itself. First, I treated it as a local-dev swap only; production still runs where it always ran. Second, I re-ran my migrations from scratch against the fresh Postgres 17 instance rather than trying to transplant a data directory out of a container volume. Cleaner, and it doubles as a test of whether your migrations actually stand alone.

The numbers

I'll give you the one number I actually measured and stand behind: about 1.5 GB of RAM back, per Activity Monitor, comparing my machine with the Docker stack idle versus the native binary idle. That lines up with what we found when we broke down why Supabase local dev needs 2.3 GB of Docker in the first place: most of the cost was never the database.

Boot time went from "start the stack, go do something else" to "it's a native process; it's just on." CI is the same story in a different costume: the job that used to pull and boot images now downloads one binary and runs. I'm deliberately not quoting you a seconds-saved figure for CI because it depends entirely on your runner's cache behavior. Measure yours; the direction is not in doubt.

One benchmark I'd push back on if you see it anywhere, including from me: synthetic query throughput comparisons. It's real Postgres 17 in both cases. The win is everything wrapped around the database, not the database.

What broke, what didn't

Didn't break:

Schema migrations. It's Postgres 17; they ran unmodified.
The client SDK. Same calls, local URL.
Auth flows in dev, RLS policies, the day-to-day query loop.

Needed attention:

Anything in my scripts that assumed Docker existed: docker exec for a psql shell, container-name health checks in a Makefile. All replaceable with direct equivalents, but grep for docker in your repo before you switch, because those assumptions hide in tooling, not app code.
Scheduled jobs and edge functions are the two areas where I'd tell you to verify behavior against your own use case before leaning on them, rather than take a blog post's word for it, mine included. Run your actual workload for a week locally before you delete the compose file for good.

Genuinely different: the debugging experience. When something misbehaves, there's one process and one log. No "is it the container, the network bridge, or the VM" triage tree.

Who should not switch

Honesty section. Stay on Docker if:

Your production is self-hosted Supabase in containers and you want local to mirror it container-for-container. Fidelity to prod is a legitimate reason to pay the tax.
You depend on studio-adjacent tooling in your daily loop and your team's muscle memory is built around the full stack UI.
Your team standardized on devcontainers for everything. One native binary inside a containerized-everything policy is friction, not simplification.
You need multi-service parity tests locally, where the gateway and service boundaries are part of what you're testing.

If none of those describe you, and for most app developers using Supabase as a hosted backend they don't, you're paying a replication-fidelity tax for fidelity you never use.

Where the ecosystem is going

The bigger pattern is that local dev is swinging back toward native. We spent a decade making environments reproducible by making them heavier, and the pendulum is now returning with the reproducibility kept: single static binaries, real databases instead of mocks, the production API surface without the production topology. SQLite's renaissance is part of it. Single-binary Postgres wrappers are part of it. "Compatible surface, native process" is a shape you're going to see a lot more of.

Docker won because it made "works on my machine" a solvable problem. The next round is making it solvable without the VM.

Have you measured what your local stack actually costs while idle? Open your resource monitor right now with everything "not doing anything" and drop the number in the comments. I have a theory the median is worse than anyone thinks.

AI React Native Form Builder: The Complete Data-Entry Stack in 2026

Mark F A — Mon, 07 Sep 2026 12:39:13 +0000

TL;DR

Every mobile app is forms underneath: signup, checkout, onboarding, KYC. The UI is an afternoon; the invisible stack (keyboard geometry, validation, migrations, RLS, typed writes) is where weeks disappear.
Most AI form builders generate a pretty <TextInput> and stop. The useful pattern is generating the whole pipeline from one prompt: SQL migration, RLS policies, regenerated types, controlled state, visible errors, and a real Supabase insert.
Five silent-failure patterns ship broken forms constantly: Alert.alert on web, unchecked { error }, RLS with no policy, stale generated types, and guard clauses that swallow crashes.
Iterate additively (point-and-edit, follow-up prompts) instead of regenerating. Full regenerations lose per-field polish.

Why "just add a form" is never just a form

Ask any React Native developer what's slow about mobile development and forms will be near the top of the list. Not for the reasons the UI suggests. The visible part (labels, inputs, a submit button) is an afternoon. The invisible part is where the calendar goes:

Keyboard geometry. iOS pushes content up; Android resizes; the submit button ends up under the keyboard on one platform and floats wrong on the other. Every screen with a TextInput needs a KeyboardAvoidingView with the correct behavior prop and a ScrollView with keyboardShouldPersistTaps="handled", or it ships broken.
Controlled state. Every field wants a useState slice, an onChangeText handler, a value prop, and a clean way to reset. Formik and react-hook-form abstract this, but they add a dependency graph, and neither handles the mobile-specific ergonomics.
Validation with visible errors. A validator that fails silently is worse than none. Errors have to render on the correct field, at the correct time.
The database half. A form that doesn't persist is a demo. Persisting means a table, columns of the right type, RLS policies (or every query returns zero rows with no error), a typed client, and error handling on the mutation.
Failure modes on web. React Native for Web is not React Native. Alert.alert is a no-op on web. An unhandled promise rejection surfaces on native and disappears on web. AI-generated forms trip over both constantly.

What generation looks like when the whole stack is in scope

Here's the difference between a UI-only form generator and a data-entry generator. Say the prompt is:

Add a customer intake form to my services app. Fields: full name, phone (US format), email, service type (single-select from three options), notes. Save to the database, show it in an admin list, and only let each user see their own submissions.

A UI-only tool gives you a screen with five styled inputs and a submit button that logs to console. Beautiful, useless.

A fullstack AI app builder treats the prompt as an end-to-end contract. In RapidNative's fullstack-supabase template it produces, in one pass:

A SQL migration creating intake_submissions with the right column types, an updated_at trigger, enable row level security, and two policies (select and insert) scoped to auth.uid() = user_id.
Regenerated TypeScript types in src/db/types.ts so client.from('intake_submissions') autocompletes the exact columns you just created.
A form screen wrapped in KeyboardAvoidingView, with controlled TextInput fields, keyboard types set per field (email-address, phone-pad), autofill hints, on-blur validation with inline error text, a spinner-managed submit, and a Supabase insert() call whose { error } is checked and surfaced.
An admin list screen that reads via useQuery from TanStack Query, keyed as ['intake_submissions', userId] so it invalidates cleanly on write.

Prompting for a full-stack form: a five-minute walkthrough

Open a new project with the fullstack-supabase template and drop this prompt into the chat:

Build a "Customer Feedback" screen. Fields: full_name (required), email (required, valid email), rating (integer 1–5, required), message (optional, up to 500 chars). Submit inserts into a feedback table scoped to the current user via RLS. After submit, clear the form and show a green success toast for 2 seconds. Also add an admin list screen that shows the current user's own feedback rows, newest first.

Behind the scenes, the generator runs a four-step LLM pipeline: plan the schema, write the migration, apply it against an in-browser PGlite instance (real Postgres in WASM, not a mock), regenerate types, then write the screens. The reason PGlite matters: pg-mem's Postgres subset used to accept uuid = text comparisons that real Postgres refuses at create policy. The migration would look green while the whole RLS chain quietly failed and every screen came up empty. Switching to PGlite killed a whole class of "works locally, breaks in production" bugs.

What actually lands in your project:

The migration (supabase/migrations/20260904_add_feedback.sql):

create table if not exists feedback (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null default auth.uid()
    references auth.users(id) on delete cascade,
  full_name text not null,
  email text not null,
  rating int not null check (rating between 1 and 5),
  message text,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now()
);

create index if not exists feedback_user_id_idx on feedback(user_id);

alter table feedback enable row level security;

drop policy if exists feedback_select_own on feedback;
create policy feedback_select_own on feedback
  for select using (auth.uid() = user_id);

drop policy if exists feedback_insert_own on feedback;
create policy feedback_insert_own on feedback
  for insert with check (auth.uid() = user_id);

Every piece is deliberate. if not exists on the table and index so a rebuild doesn't throw 42P07. drop policy if exists above each create policy because Postgres has no create policy if not exists. RLS enabled and two policies: enabling RLS without a policy makes every query return zero rows, and the app looks broken with no error anywhere. An index on the foreign key because Postgres doesn't create one and lookups seq-scan without it.

The screen (app/(app)/feedback.tsx), condensed to the shape of what ships:

export default function FeedbackScreen() {
  const { client } = useApp();
  const qc = useQueryClient();

  const [fullName, setFullName] = useState('');
  const [email, setEmail] = useState('');
  const [rating, setRating] = useState<number | null>(null);
  const [message, setMessage] = useState('');
  const [errors, setErrors] = useState<Record<string, string>>({});
  const [submitting, setSubmitting] = useState(false);
  const [success, setSuccess] = useState(false);

  const validate = () => {
    const e: Record<string, string> = {};
    if (!fullName.trim()) e.fullName = 'Required';
    if (!/^\S+@\S+\.\S+$/.test(email)) e.email = 'Enter a valid email';
    if (!rating) e.rating = 'Pick 1–5';
    if (message.length > 500) e.message = 'Max 500 characters';
    setErrors(e);
    return Object.keys(e).length === 0;
  };

  const onSubmit = async () => {
    if (!validate()) return;
    setSubmitting(true);
    try {
      const { error } = await client
        .from('feedback')
        .insert({ full_name: fullName, email, rating, message: message || null });
      if (error) {
        setErrors({ form: error.message });
        return;
      }
      setFullName(''); setEmail(''); setRating(null); setMessage('');
      setSuccess(true);
      qc.invalidateQueries({ queryKey: ['feedback'] });
      setTimeout(() => setSuccess(false), 2000);
    } finally {
      setSubmitting(false);
    }
  };

  return (
    <KeyboardAvoidingView
      behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
      style={{ flex: 1 }}
    >
      <ScrollView
        keyboardShouldPersistTaps="handled"
        contentContainerStyle={{ paddingBottom: 128 }}
        className="bg-background"
      >
        {/* Field JSX with keyboardType, autoComplete, and inline <Text> errors */}
      </ScrollView>
    </KeyboardAvoidingView>
  );
}

Notice what's there: a controlled state slice per field, a validator that runs on submit and populates a per-field error map, KeyboardAvoidingView with the correct per-platform behavior, ScrollView with keyboardShouldPersistTaps="handled", and (the piece most generators miss) the { error } from the Supabase insert is checked and rendered into on-screen state. Not Alert.alert. Not console.error. Visible text the user actually sees.

The hidden 60%: silent-failure patterns that ship broken forms

If a generated form doesn't work and you can't see why, it's almost always one of these five. They compile, they ship, and they produce a button that appears inert with nothing in the console.

1. Alert.alert as the only feedback path. Alert from react-native does nothing on web, and most editor previews are Expo Web. A submit handler whose error branch is Alert.alert('Error', msg); return; is completely invisible in preview. The button just doesn't do anything. Render errors into on-screen state. If you truly want a modal on web, branch on Platform.OS === 'web' and use window.alert or a custom in-app dialog there.

2. Unchecked { error } from the Supabase call. The client returns { data, error }; it does not throw. If you write await client.from('feedback').insert(...) and never destructure error, PostgREST failures (missing column, RLS denial, constraint violation) vanish silently and the UI moves on as if the write succeeded.

3. RLS enabled with no policy. The single most common cause of "the form submits but the list is empty." alter table ... enable row level security without a matching create policy makes every select return zero rows and every insert fail with an ambiguous permission error. Always ship RLS and at least one select policy in the same migration.

4. Stale generated types. src/db/types.ts is generated from the applied migrations. If it drifts (someone edited the migration but didn't regenerate) and client.from('feedback') starts typing every column as never, the fix is to regenerate. Never cast past it with client as any, which buries a real drift between code and database.

5. Guard clauses around things that always exist. if (!client) return; turns what should be a loud crash into a no-op. Only guard on values that are genuinely optional (an unauthenticated user, an empty input), and when you do, setError(...) on the way out so the user sees why nothing happened.

The reason these matter more in AI-generated code than in human-written code is that the model is optimising for "compiles and looks reasonable." A silent failure is, from the model's perspective, indistinguishable from success. The generator has to be trained (or system-prompted) to write the visible-failure form of every one of these patterns, and to refuse the silent form.

Iterating without regenerating

Generation is the start. What matters after is iteration speed, because the second prompt is always "make it look better," and the third is always "add a field."

Two ways to iterate that don't require regenerating the whole screen:

Point-and-edit. Click any element in the preview (a label, an input, the submit button) and describe the change in natural language. The AI edits only that node's props or its style class, so the rest of the file is untouched. Much faster than "regenerate the whole file with X changed," which risks losing edits you already made.
Follow-up prompts. "Add a company field between email and rating, optional, autocomplete=organization." The generator reads the current file, adds the state, adds the JSX, updates the validator, writes an add column if not exists company text migration, and regenerates types. What you don't get is a rewrite of everything else.

Full regenerations lose per-field polish. Additive edits preserve it. Learn to prompt in additive language and you keep the iteration cost near zero.

Beyond the single-screen form: three patterns worth knowing

Multi-step wizards. For onboarding, KYC, or checkout, split a long form across screens with progress. The pattern: one route per step under app/(auth)/onboarding/[step].tsx, state lifted to a React context, and a single insert() at the end. Prompt: "Break this signup into three steps (account, profile, preferences) with a progress bar at the top and a back button on every step except the first."

File uploads (with the web gotcha). ImagePicker returns a blob: or data: URI on web, and expo-file-system cannot read either. Any generated form that uploads a file has to branch on Platform.OS === 'web': on web use await (await fetch(uri)).blob() and take the extension from blob.type; on native, keep the FileSystem base64 path.

Optimistic writes. For chat, likes, reviews, anywhere latency shows: wrap the write in a TanStack Query useMutation with onMutate that updates the cache immediately and onError that rolls back. Prompt: "Make the submit optimistic. Show the new row in the list instantly, and roll back if the write fails."

Comparison: three ways to build a React Native form in 2026

Approach	Setup time	Backend included	Web-safe	Ownership
Hand-written with `TextInput` + Formik + Supabase SDK	2–5 days	You build it	Only if you branch `Alert.alert` yourself	Full code
Boilerplate/template + hand-wiring	1–2 days	Partial (scaffold only)	Sometimes	Full code
AI form builder (fullstack-supabase template)	~5 minutes to a working form	Yes: migration, RLS, types, mutation	Yes: silent-failure patterns blocked at generation	Full code, exportable

A dedicated form library like Formik is a fine choice if you're building a small number of forms by hand. The tradeoff shifts the moment you have more than a handful of forms, or the moment "backend" is part of the definition.

FAQ

How does an AI React Native form builder handle validation?
Validation lives inside the generated component as a validate() function that populates an errors map keyed by field name, rendered as inline <Text> under each input. Fields validate on submit by default; add "validate on blur" to the prompt and the generator wires per-field onBlur handlers. For schema-based validation, prompt for Zod and the generator adds the schema and a safeParse call in validate().

Can AI-generated forms write to a real database?
Yes. In a fullstack template, the generator writes a SQL migration for the target table, enables RLS, creates policies scoped to auth.uid(), regenerates the TypeScript schema, and inserts a client.from('table').insert(...) call in the submit handler with error handling. The write hits a real Postgres in preview (PGlite in WASM), so what you see in the editor is what ships.

What about accessibility on generated form screens?
Generated forms include accessibilityLabel on inputs, keyboard types set per field (email-address, phone-pad, numeric), autocomplete hints (autoComplete="email", "tel", "name"), and inline error text that screen readers surface.

Where to go from here

The takeaway isn't "AI writes forms now." AI has written forms for two years. The takeaway is that the useful surface has moved: from generating the visible pretty layer to generating the whole data-entry pipeline (migration, RLS, typed schema, controlled state, keyboard behaviour, visible errors, and a mutation that actually persists) from one natural-language description, in seconds, into code you own. All on the Expo + React Native stack you already know.

What's the form pattern that's burned you the most: keyboard geometry, silent RLS failures, or something worse? Drop it in the comments.

The Non-Technical Founder's Guide to Mobile App Development in 2026

Mark F A — Mon, 31 Aug 2026 11:02:00 +0000

TL;DR

Four realistic paths in 2026: agency, freelancer, no-code platform, AI-native builder.
Agencies: $45,000–$150,000, 4–7 months. Freelancers: $15,000–$60,000, 2–5 months. No-code: cheap, but you hit a ceiling and never own code. AI-native: real React Native output, days not months.
Three decisions are yours before you hire anyone: cross-platform vs native, launch sequencing, and what you refuse to build in v1.
The 30-day playbook at the bottom assumes the AI-native path. Stretch it a lot for the others.

If you are the engineer someone is about to ask "can you build my app idea," this is the piece to send them. It is written for the founder, but the useful part for you is the section on what they should decide before they land in your inbox.

What actually changed between 2023 and 2026

Three things landed at once.

AI code generation crossed from demo to production output. Models now write React Native and Expo code that boots on TestFlight without a human rewriting it from scratch. Expo tooling (OTA updates, EAS Build, universal links) stopped requiring a senior mobile engineer to configure. And a category emerged between no-code and code generation: describe the app, real code comes out, you own it.

The consequence is that a solo non-technical founder can put a working iOS and Android app in front of paying users in days, on budgets that used to cover only design.

That does not kill the old paths. It means there are four, and picking wrong is the expensive part.

Path 1: agency

Brief them, they design and build, they hand over a codebase. Typically 4–7 months for an MVP. $45,000–$150,000 in 2026 for auth, a backend, and one core workflow. Higher in North America, lower with Eastern European or Latin American shops.

Real upside: polished output, they handle App Store submission, they own the responsibility for shipping. Real downside: you are the least-informed person in every technical meeting, change requests cost money, and if the agency wobbles at month four you are stuck.

Pick this when you have capital, a fixed deadline, and requirements that genuinely need five specialists.

Path 2: freelancer

A senior React Native freelancer runs $60–$120 per hour in the US, less abroad. A lean MVP is 200–500 hours, so $15,000–$60,000 depending on location and scope discipline.

This works when you find the right person. It also generates the most founder horror stories, because "the right person" is hard to source without a technical network, and if you cannot read code you will not find out you inherited a mess until you try to hand it to someone else.

Pick this if you have a specific recommendation, or a technical advisor who can review the code.

Path 3: no-code

Bubble, Adalo, Glide, FlutterFlow. Drag components, configure logic through visual rules. No code output. The app lives in the platform runtime permanently.

You can genuinely build with zero technical background. You also cannot leave without a rewrite, complex logic turns into nested visual conditions, performance trails a native app, and App Store rejections for wrapped apps keep happening.

Pick this if the app is genuinely simple (directory, form-heavy internal tool, booking flow) and will not scale past a few thousand users.

Path 4: AI-native builders

Describe the app in plain English, sketch it, or paste a PRD. An AI generates React Native and Expo code. You own it from day one, preview on your actual phone, and iterate by describing changes.

This is what broke the cost math. Tens of dollars in credits instead of tens of thousands in labor, and evenings instead of quarters. Because the output is standard React Native on Expo, if the thing takes off you hand it to an engineer and they extend it like any other project.

The trade-off is real: these tools are strongest on the common surface area (auth, lists, forms, media, standard navigation) and need human judgment for custom device APIs, complex real-time systems, and novel UI. For a first app, the common surface area is usually the entire product.

The cost table

Comparable MVP in every row: auth, a backend, one core workflow, shipped to iOS and Android. These are ranges, not quotes.

Path	Upfront	Time to v1	Ongoing/mo	Own the code
Agency	$45,000–$150,000	4–7 months	$0 (or retainer)	Yes
Freelancer	$15,000–$60,000	2–5 months	$0 (or hourly)	Yes
No-code	$0–$500	2–6 weeks	$50–$500	No
AI-native	$0–$200	1–5 days	$20–$100	Yes

The low numbers are not typos. An AI-native builder like RapidNative produces a functional MVP for the cost of dinner, because the labor cost collapsed. What still costs money is everything you did not write: $99/year Apple, $25 one-time Google, $0–$50/month backend at MVP scale on Supabase or similar, and paid acquisition.

The three decisions a founder should make before hiring anyone

Cross-platform vs native. Native means Swift plus Kotlin, two codebases, roughly double the cost. Cross-platform means one codebase on React Native or Flutter. In 2026 the answer for almost every startup is cross-platform. The performance gap has effectively closed for standard functionality, and Instagram, Discord, Shopify, and Coinbase all run significant parts of their mobile products on React Native. Legitimate reasons to go native: hardcore graphics, a platform feature with no wrapper yet, or a strategic showcase play. If someone tells a founder otherwise, ask them to name the specific device API they cannot reach.

Launch sequencing. Cross-platform gets you both stores, so this is mostly about order. TestFlight for iOS first, 20–50 users, tune the flow, then submit to both together. Apple's review is stricter, so clearing it early prevents a launch-day surprise.

What you refuse to build. The most valuable technical decision a non-technical founder makes is the cut list. The MVP should do one thing well enough that a user recommends it despite everything missing. If you can name three core workflows, you have too many. Push notifications, IAP, social login past Google and Apple, offline mode: all cheap in v2, all expensive forced into v1.

The 30-day playbook

Assumes the AI-native path. Stretch the timeline substantially for the others.

Days 1–3. One-page PRD: who is the user, what is the single workflow they will thank you for, what does month-one success look like. Show five potential users. Rewrite. Do not skip this.

Days 4–6. Feed the PRD in. Get the core workflow working end to end, polish absent. Test on your own phone via the preview QR. Click, describe the change, watch it happen.

Days 7–10. The unglamorous parts. Auth. Settings screen. Empty states. Error states. This is the difference between a demo and something that feels real.

Days 11–15. Ten people using it. Not user tests, actual usage. Watch them. Note every hesitation. Do not defend your app.

Days 16–20. TestFlight. Same ten plus twenty new ones from the target market.

Days 21–25. Fix the crashes, confusing flows, and typos TestFlight surfaces. Add nothing.

Days 26–30. Submit to both stores. Apple typically clears in under two days, Google is often same-day, both vary. Screenshots and the first line of the description carry most of the conversion weight.

The part engineers actually care about

The reason AI-native builders are worth taking seriously and no-code platforms mostly are not is portability. There is no proprietary runtime and no visual-logic language that exists inside one tool. The exported project is a normal Expo app. You can open it, read it, and extend it without a migration project.

That means the founder who shipped without you in month one is not handing you a rewrite in month six. They are handing you a codebase.

Which is a much better conversation to have.

If you have inherited an app a non-technical founder shipped solo, how did that handoff actually go? Curious whether the "no rewrite required" claim holds up in practice or whether you all have war stories. Drop them in the comments.

Reanimated vs Moti vs Skia: stop picking one

Mark F A — Mon, 31 Aug 2026 11:01:49 +0000

TL;DR

Reanimated runs animation math on the UI thread via worklets. It is the foundation, and you will end up with it installed regardless.
Moti is a declarative wrapper over Reanimated with a Framer Motion-style API. Great for enter/exit, skeletons, staggered lists.
Skia is Shopify's binding to Google's 2D graphics engine. Paths, shaders, blurs. Not an animation library.
These are not competitors. They are three layers of one stack, and most production apps use at least two.
Skia props accept Reanimated shared values directly, with no wrapper component. That single fact is why the combination is everywhere.

The framing problem

Every "X vs Y vs Z" post assumes you are picking one. With these three that assumption is wrong, and it produces two specific failure modes: teams that write 40 lines of Reanimated hooks to fade in a card, and teams that reach for Moti on a pan gesture and then cannot bind it to anything.

Here is what each one actually is at the runtime level.

Reanimated: worklets on the UI thread

Animations that run on the JS thread stutter whenever your app does work. Parsing JSON, rendering a list, handling touch. Reanimated moves the math onto the UI thread using worklets, small JS functions the runtime serializes and executes natively through JSI.

Three pieces:

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

function Card() {
  const offset = useSharedValue(0);

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

  return (
    <Animated.View style={style} onTouchEnd={() => (offset.value = withSpring(100))} />
  );
}

useSharedValue is a reactive primitive living on the UI thread, readable and writable from both sides. useAnimatedStyle is a worklet that re-runs whenever a shared value it reads changes. withTiming and withSpring drive the value over time.

Updates are scheduled against display frames rather than the JS event loop. That is why the animation stays smooth while your JS thread renders a 50-item list.

Wire it to a gesture and you get the thing Reanimated is actually for:

import { Gesture, GestureDetector } from 'react-native-gesture-handler';

const pan = Gesture.Pan().onChange((e) => {
  offset.value += e.changeX;
});

return (
  <GestureDetector gesture={pan}>
    <Animated.View style={style} />
  </GestureDetector>
);

No runOnJS, no bridge hop. The gesture callback is a worklet and it mutates a UI-thread value in the same frame.

The cost: ceremony. Shared values, worklet directives on nested functions, useAnimatedStyle for every animated view. It is more machinery than a fade-in deserves.

Moti: the same thing, four lines

<MotiView
  from={{ opacity: 0, translateY: 20 }}
  animate={{ opacity: 1, translateY: 0 }}
  exit={{ opacity: 0 }}
  transition={{ type: 'timing', duration: 300 }}
/>

Under the hood this is Reanimated. Same worklets, same UI-thread execution. You just never touch useSharedValue for the common cases. You also get AnimatePresence for exits, MotiText and MotiImage, a <Skeleton /> loader, and <Sequence /> for chaining.

Staggering a list is where the ergonomics really show:

{items.map((item, i) => (
  <MotiView
    key={item.id}
    from={{ opacity: 0, translateY: 12 }}
    animate={{ opacity: 1, translateY: 0 }}
    transition={{ delay: i * 50 }}
  />
))}

The cost: the moment you need a live gesture driving the animation, you drop back to raw Reanimated. There is no way to bind a MotiView prop to an ongoing pan translation. useDynamicAnimation exists, but using it puts you back in imperative code and the abstraction stops paying rent.

Skia: not an animation library at all

It is the 2D engine behind Chrome, Flutter, and Android's rendering pipeline, exposed to RN through a declarative component API. You use it for what the view tree cannot express: paths, SkSL shaders, blurs, blend modes, gradients beyond LinearGradient, text on curves.

The detail that matters for this comparison:

import { Canvas, Circle } from '@shopify/react-native-skia';
import { useSharedValue, withTiming } from 'react-native-reanimated';

const cx = useSharedValue(0);
cx.value = withTiming(200, { duration: 600 });

<Canvas style={{ flex: 1 }}>
  <Circle cx={cx} cy={100} r={40} color="hotpink" />
</Canvas>

Skia props accept Reanimated shared values directly. No createAnimatedComponent, no useAnimatedProps. The canvas re-renders on the UI thread as the value changes. That is the pattern under Victory Native XL, Reanimated Carousel, and basically every good animated chart in the ecosystem.

The cost: no Expo Go, so you need a dev client. Roughly 2 MB of native binary. And SkSL is its own idiom with a real learning curve.

Comparison

	Reanimated	Moti	Skia
Type	Animation runtime	Declarative wrapper	2D graphics engine
Runs on	UI thread (worklets)	UI thread (via Reanimated)	UI thread (JSI)
Best for	Gestures, sequences	Enter/exit, transitions	Drawings, shaders
Depends on	None	Reanimated 2/3/4	None
Approx. cost	~150 KB JS + native	~30 KB JS + Reanimated	~2 MB native binary
Expo Go	Yes (SDK 47+)	Yes	No, dev client
Maintainer	Software Mansion	Fernando Rojo	Shopify

What to reach for

Task	Library
Fade in a card on mount	Moti
Drive a value from a pan or pinch	Reanimated
Chain coordinated view animations	Moti
Animated chart with line and dots	Skia + Reanimated
Blur a background as a sheet drags up	Skia + Reanimated
Layout animation on list add/remove	Reanimated 4 `LinearTransition`
Skeleton loader while fetching	Moti `<Skeleton />`
Shader-based splash screen	Skia

The dependency graph makes composition cheap. Moti pulls in Reanimated, so the incremental cost of "adding" Reanimated once you have Moti is zero. Skia is the only real commit, and you pay for it once.

The performance thing nobody mentions

All three run on the UI thread over the same JSI bridge, so raw frame timing is comparable for comparable work. Where it actually breaks in production is almost never the library. It is this pattern:

// This will drop frames
const style = useAnimatedStyle(() => ({
  height: h.value,        // triggers layout every frame
}));

// This will not
const style = useAnimatedStyle(() => ({
  transform: [{ scaleY: h.value }],  // compositor only
}));

Animating a layout property schedules a layout pass on every frame and the "60fps animation" ends up queued behind it. All three libraries let you do this. If you are chasing a stutter, profile before you refactor.

What building an AI generator taught us

We build RapidNative, which turns natural-language prompts into React Native and Expo code. Picking the animation primitive without a human in the loop surfaced two things worth stealing.

Users never say "gesture." They say "make it feel snappy" or "add some polish." We default to Moti for appearance verbs (fade, slide, pop, stagger), escalate to Reanimated the moment a prompt implies user-driven motion (drag, swipe, pull to refresh, pinch), and only pull in Skia for charts, shaders, gradients, or explicitly artistic phrasing.

Composition beats picking a tool. The worst early bug was choosing one library per screen. A screen with a draggable card and an animated hero wants Reanimated for the drag and Moti for the hero. Separate concerns, separate primitives.

That generalizes past AI. Even when a human is choosing, the either/or framing costs you.

FAQ

Is Moti just Reanimated with less code? Mostly. Same worklets, same UI-thread execution, same shared values internally. Moti adds prop-based config, AnimatePresence, sequence orchestration, and prebuilt components.

Can I use Skia without Reanimated? Yes, for static scenes and animations driven by its own value primitives. Almost nobody does, because shared values are the standard driver everywhere else in the app.

Does Reanimated 4 replace Moti? No. The CSS-like syntax narrows the ergonomic gap, but AnimatePresence and the declarative prop API are still more concise for common transitions.

What about the built-in Animated API? Wrong default for new code. JS thread by default, useNativeDriver covers only a subset of transforms and opacity, verbose interpolation, painful gesture integration.

Bottom line

Install Reanimated and Moti. Leave Skia until the design brief demands it. If you are auditing an existing codebase, the two things you will find are Moti calls that should be Reanimated (wired to a gesture later, never rewritten) and Reanimated hooks that should be Moti (fading a card in, 30 unnecessary lines).

Pick the primitive per interaction, not per app.

What is your current animation stack, and have you hit the point where you needed to mix them? Drop a comment with what you are building.

The Complete Guide to Push Notifications in React Native (2026)

Mark F A — Wed, 19 Aug 2026 05:16:15 +0000

TL;DR

Use expo-notifications in 2026, even in a bare React Native workflow. CNG makes the managed/bare distinction mostly irrelevant.
The token identifies a device plus install, not a user. Plan for rotation from day one.
On Android you must create a notification channel before requesting permission, or notifications silently never display.
Android 13+ needs the POST_NOTIFICATIONS runtime permission, and only if your target SDK is 33 or higher.
Never call the system permission prompt cold. It's one-shot. Put a screen you own in front of it.
react-native-push-notification (Zo0r) is dead. Don't start a new project on it.

Push notifications are the single most reliable way to bring a user back into a mobile app. Localytics data pegs day-90 retention at roughly 190 percent higher for apps that use them well, and Airship's 2024 benchmarks show median direct-open rates north of 4 percent across most verticals. Yet notifications are also the feature most React Native teams postpone the longest, because the surface spans two operating systems, two transport providers (APNs and FCM), a set of iOS entitlements that require an Apple Developer account, an Android notification-channel model that changed twice in the last five years, and at least three distinct app states you have to handle differently.

This guide is the version I wish I'd had when I first shipped push in a React Native app. It walks through the full stack (permissions, tokens, sending, receiving, deep linking, rich content, and testing) using the Expo Notifications SDK, which works for both Expo-managed and bare React Native projects on modern Expo SDK versions. Every code sample runs. Every gotcha is one I've actually hit in production.

What "push notifications" actually means

A push notification is a message your server hands to a push service (APNs for Apple, FCM for Google) which then delivers it to a specific device using a device-specific token. The device wakes up even if your app is killed, OS-level code decodes the payload, and either displays a system UI or fires an event into your app process.

Three things follow from that definition, and they cause most of the confusion:

You cannot send a push directly from your React Native app to another user. You need a server.
The token identifies a device plus app install, not a user. When a user reinstalls, logs into a second device, or clears app data, you get a new token. Tokens also rotate for other reasons and can be invalidated by the push service.
What runs inside your app is only half the story. The other half is Apple's or Google's OS-level notification presentation logic, which you configure through payload keys, notification channels, and iOS entitlements.

Local notifications, the kind you schedule from inside the app without a server, use most of the same APIs but skip the token and the push service. This guide covers both, since real apps almost always need both.

The 2026 landscape: which library

There are three real options for React Native in 2026, and the honest recommendation is: use expo-notifications, even if you're not on Expo Go and even if you use a bare React Native workflow.

Library	Best for	Trade-offs
`expo-notifications`	Almost every app	First-class support in both Expo-managed and bare RN via CNG (Continuous Native Generation). Handles APNs and FCM transparently. Actively maintained.
`@react-native-firebase/messaging`	Apps that already use other Firebase products (Firestore, Auth, Analytics) heavily	Google-only transport story; you still need a separate iOS setup for APNs credentials.
`react-native-notifications` (Wix)	Advanced native-side customization needs	Smaller community; more manual native config.

The legacy react-native-push-notification package (Zo0r) is unmaintained and should not be used in a new project.

The rest of this guide uses expo-notifications. Because Expo now supports prebuild (npx expo prebuild) and CNG, you get the same experience whether your project is Expo-managed or bare: the config plugin generates the correct native code for both.

Installing and configuring

Assuming an Expo SDK 52+ project:

npx expo install expo-notifications expo-device expo-constants

expo-device is used to skip token registration on simulators. Apple's push service does not deliver to the iOS simulator on Xcode versions below 14, and even on newer Xcode you need a paid developer account and the Simulator's push testing tools. expo-constants gives you access to easConfig.projectId, which the Expo Push Service needs to route tokens.

Add the config plugin in app.json:

{
  "expo": {
    "plugins": [
      [
        "expo-notifications",
        {
          "icon": "./assets/notification-icon.png",
          "color": "#111827",
          "sounds": ["./assets/notification-sound.wav"]
        }
      ]
    ],
    "ios": {
      "bundleIdentifier": "com.yourco.yourapp",
      "infoPlist": {
        "UIBackgroundModes": ["remote-notification"]
      }
    },
    "android": {
      "package": "com.yourco.yourapp",
      "googleServicesFile": "./google-services.json"
    }
  }
}

Two things to know:

The notification icon must be a monochrome PNG with a transparent background. Android's icon guidelines are strict, and a full-color icon renders as a white square.
On iOS, you need to enable the Push Notifications capability and the Background Modes to Remote notifications capability in your Apple Developer account. If you're using EAS Build, expo-notifications and the UIBackgroundModes config above handle this automatically.

If you're standing up a new project rather than retrofitting an existing one, starting from a config that already builds saves an afternoon. RapidNative generates Expo projects with app.json, the bundle identifier, and the Android package name already in place, so you're editing a working config instead of assembling one from an empty file.

Requesting permission the right way

This is where a lot of implementations lose would-be opt-ins. Apple's system prompt is a one-shot event: if the user taps "Don't Allow," you cannot re-prompt from your app. They would have to go into Settings.

The pattern that works is a pre-permission screen: a screen you own, explaining the value, with a "Turn on notifications" button. Only when the user taps that button do you call the system API.

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

export async function registerForPushNotifications(): Promise<string | null> {
  if (!Device.isDevice) {
    console.warn('Push notifications require a physical device.');
    return null;
  }

  if (Platform.OS === 'android') {
    await Notifications.setNotificationChannelAsync('default', {
      name: 'default',
      importance: Notifications.AndroidImportance.MAX,
      vibrationPattern: [0, 250, 250, 250],
      lightColor: '#111827',
    });
  }

  const { status: existing } = await Notifications.getPermissionsAsync();
  let finalStatus = existing;

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

  if (finalStatus !== 'granted') return null;

  const projectId = Constants.expoConfig?.extra?.eas?.projectId
    ?? Constants.easConfig?.projectId;

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

A few details that matter:

Android 13+ (API 33) requires runtime permission via POST_NOTIFICATIONS. expo-notifications handles this for you when you call requestPermissionsAsync(), but only if your target SDK is 33 or higher.
On Android, you must create a notification channel before you request permission. Otherwise notifications will silently fail to display, even though your token is valid. Channels group notifications so users can mute categories independently in system settings.
You want the Expo push token, not the native APNs or FCM token, unless you're skipping Expo's push service. The Expo token is a single string of the form ExponentPushToken[xxxxxxxxxx] that Expo's service translates to either APNs or FCM at send time.

Where to go next

The setup above gets you a valid token and a permission prompt users actually accept. The next layer is the one that decides whether push works in production: sending from your server, handling the payload in all three app states (foreground, background, killed), routing a tap to the right screen, and testing all of it on real hardware.

What broke first when you shipped push? My money is on the Android channel. Drop yours in the comments.

From Side Project to App Store: A Non-Technical Founder's Guide (2026)

Mark F A — Fri, 14 Aug 2026 06:59:12 +0000

TL;DR

The distance between "I have an app idea" and "it's live on the App Store" collapsed in 2026.
Stack: AI mobile app builder producing real exportable React Native code, Supabase for data, TestFlight and Play Internal Testing for QA, self-submission to both stores.
Validate with 10 real interviews and a landing page before you build anything.
Budget one week for submission. Most rejections are mechanical: privacy label mismatches, placeholder content, first-minute crashes.
Retention beats downloads. Day 30 above 20% means you have something.

Somewhere between 70 and 80 percent of side projects never leave a Notion doc. Not because the ideas are bad. Because the distance between "I have an idea for an app" and "my app is live on the App Store" has always been enormous for anyone who can't code. Hiring a developer costs $20,000 to $80,000. Learning React Native takes six months. Cloning boilerplate templates leaves you stuck the moment you want anything custom.

That distance collapsed in 2026. A non-technical founder can now go from a napkin sketch to a live App Store listing in a matter of weeks, working alone, without writing a line of code, and without shipping a fragile prototype held together with duct tape.

The stack has finally shifted

What is the fastest way for a non-technical founder to build a mobile app in 2026? Use an AI mobile app builder to generate production-ready React Native code from a prompt, sketch, or PRD; back it with a managed database like Supabase; test with TestFlight and Google Play Internal Testing; and submit to both stores yourself. The whole cycle takes weeks, not months, and the code you own is real code, not a walled-garden template.

The old paths were expensive, slow, or extractive. Hire an agency and you were out $30k before a single user tapped the icon. Hire a "technical co-founder" and you gave away 40% of your company for someone who could've been replaced by tooling that didn't exist yet. Learn to code and you spent your first year fighting Xcode installation errors instead of talking to users.

The new stack does three things the old one couldn't:

Generates working, exportable code. React Native and Expo apps you can own, edit, and ship, not throwaway prototypes.
Handles the full stack. Screens, navigation, forms, auth, database, and API integration from one generation pipeline.
Runs a real preview. Hold your phone up to a QR code and use your app on iOS the same day you started.

The bottleneck used to be code. Now the bottleneck is your ability to make product decisions, which is exactly the work a founder should be doing.

Phase 1: Validate without writing a line of code

One to two weeks. Three artifacts: a landing page with a signup form, 10 completed user interviews, and a written product spec.

The 10-user test. Pick 10 people who would actually pay for or use your app. Not friends. Not "the whole world." Ten specific humans. Ask them: "Walk me through the last time you tried to solve [problem]. What did you use? What did you hate about it?" If you can't find 10 people who describe the problem the same way you do, you don't have a product. You have a hunch.

Landing page and waitlist. Spin up a one-pager on Framer, Carrd, or Webflow. Value prop, three screenshots (mock them in Figma if you have to), and a "get early access" form. Push it in one Slack community, one subreddit, and one Twitter thread. If nobody signs up, that's your answer.

Write a real PRD. Not a novel. One page listing: the target user, the top three screens, the data each screen shows, the actions the user can take, and what happens after each action. This becomes the input for the next phase.

Phase 2: Build the first working version

This is where non-technical founders used to get stuck for six months. Now it takes days.

Open an AI mobile app builder. Describe your app in plain English: "A workout tracker where users log sets and reps, see weekly volume, and get streak badges." Watch it generate a working Expo app with screens, navigation, forms, and a database schema. Scan the QR code with your phone. Use the app. Notice five things you want to change. Describe them. Regenerate. Done in an afternoon what would have taken a contractor a month.

Under the hood, the good builders run a multi-step pipeline: interpret the prompt, plan a component tree, generate React Native code, wire up state with Redux or Context, apply theming with NativeWind, and stream the result into a live preview you can interact with in real time. You don't need to know any of that, but knowing it exists is what separates "toy prototype" from "actual app I can submit to Apple."

Four input modes are worth knowing about:

Mode	What it does	Best for
Prompt to app	Describe it, get it	Founders who know what they want
Sketch to app	Draw wireframes, get working screens	Ideas more visual than verbal
PRD to app	Paste your spec, get a full prototype	Founders who already wrote the doc
Screenshot to app	Upload a UX you like, generate something similar	Cloning proven patterns

RapidNative supports all four and exports a real Expo project. Pick the mode that matches how the idea actually lives in your head.

The trick in this phase is ruthless scope-cutting. Every non-technical founder wants push notifications, in-app purchases, social login, offline mode, and dark mode on day one. Build none of that. Notifications and IAP are two-week rabbit holes each, and every screen you add is a screen you'll redesign after your first ten users.

Phase 3: Test on TestFlight and Play Internal Testing

Most founders skip this. Don't. A demo in the simulator is not a real test.

Apple TestFlight. Free, ships from your Apple Developer account, distributes to up to 10,000 external testers via email or a public link. Upload a build (EAS handles this), fill out a short test information form, invite testers. Apple runs a brief review on your first build, usually under 24 hours. After that, updates are near-instant.

Google Play Internal Testing. Also free, ships from Play Console, supports up to 100 internal testers, distributed by Google account email. More forms than Apple up front, but review is essentially zero. Internal builds go live within minutes.

Send invites to your 10 interviewees from Phase 1. After a week of use, ask each of them: What did you use it for? What was confusing? Would you pay $5/month for this?

Instrument analytics before you send it out. Expo has PostHog and Mixpanel SDKs that take five minutes to integrate. You want to know which screens users open, where they drop off, and how long sessions last. This data is worth ten times what people tell you in interviews.

Phase 4: The submission gauntlet

The phase founders fear most and, frankly, the one that trips them up least. Budget one week for both stores.

Apple App Store

Apple Developer Program: $99/year. Individual account is fine to start.
App Store Connect listing: name (30 chars), subtitle (30 chars), keywords (100 chars, comma-separated, invisible to users), description, screenshots (6.7" and 6.5" iPhone minimum), promotional text, support URL, privacy policy URL.
Privacy nutrition label: declare what data you collect, what links to the user, and what's used for tracking. This is the #1 rejection reason for solo founders.
App Tracking Transparency: required if you use third-party analytics that fingerprints devices.
Review time: around 24 hours for 90% of submissions in 2026. Complex or first-time submissions can take 2–4 days.

Google Play Store

Developer account: $25 one-time.
Play Console listing: title (30 chars), short description (80 chars), full description (4000 chars), feature graphic, screenshots, category, content rating questionnaire.
Data Safety form: Google's equivalent of Apple's privacy label. Mismatches with actual behavior get apps pulled later.
Target API level: last two API levels required. Modern Expo apps handle this automatically.
Review time: a few hours to a couple of days for new apps, faster for updates.

Three most common rejections for solo-founder apps: placeholder content still visible ("Lorem ipsum" screens are an instant reject), crashes in the first minute, and misleading metadata. Ship a build you've used yourself for a full week.

Your builder should export a complete Expo project you can submit yourself with EAS or hand to a developer for final packaging. This is where owning real, exportable code matters. You're not trapped inside a proprietary builder that can't produce an actual .ipa or .aab.

Phase 5: Launch and beyond

Getting into the store is not the launch. It's the starting line.

Soft launch first. Go live in one small market (Canada and Australia are common) for two weeks before opening globally. Watch crash rates, retention, and reviews. Fix what breaks. Then flip the geo restriction off.

Pick one launch channel and go deep. Product Hunt, a niche subreddit, an X thread, or an outreach email to 50 users. Not all four in the same day. Product Hunt in particular rewards launches that already have engagement, so warm your list before you post.

Instrument retention, not vanity metrics. Downloads are meaningless. Day 1, Day 7, and Day 30 retention are the numbers that matter. Day 30 above 20% for a consumer app means you have something worth pushing. Below 10% and you iterate on the product, not the marketing.

Iterate fast. Every piece of feedback becomes a prompt. "The signup flow is confusing" becomes a two-minute edit and a new build on TestFlight the same afternoon. Founders who take a week to ship a fix lose to founders who take two hours.

ASO basics. Optimize your app name and subtitle around one high-intent keyword each. Use all 100 characters of the App Store keyword field. Ship screenshots that show the value in the first two frames, since that's what users see on the search page.

Five pitfalls to avoid

Building too much before showing anyone. Every screen you build without a user in front of it is a screen you'll rebuild. Ship five screens to ten users before you build the sixth.
Ignoring review guidelines. Read them once before you submit. The mechanical rejections (privacy label mismatches, missing account-deletion flow, sign-in-with-Apple requirement when you have social login) are easy to avoid and painful to hit.
No maintenance plan. Apple and Google both push OS updates yearly. If you can't ship at least one build every 6 months, your app will start breaking. A maintenance update in 2026 is a 30-minute regeneration, not a week of contractor work.
Undervaluing yourself on price. Free apps monetize on scale you don't have yet. $4.99/month or $29/year is a common indie starting price and it filters out users who were never going to convert.
Skipping the legal basics. Both stores require a privacy policy URL. Termly or Iubenda cost $10–$20 and take 15 minutes. Do it before you submit, not after.

What shipping alone actually looks like now

The old founder journey: idea, then learn to code or raise money or find a co-founder, then build for a year, then ship a bad version, then run out of runway.

The new one: idea, validate in a week, build in a week, test in two weeks, submit in a week, iterate forever. The whole cycle from opening a browser to a live App Store listing can compress into a single month.

You still need judgement: what to build, what to cut, who to talk to, how to price. Those are the parts that make you a founder. Everything else has become tooling.

What phase are you stuck in right now? Validation, building, testing, or submission? Drop it in the comments. Curious how many of you are sitting on a Notion doc that's been there over a year.

How to Build a HIPAA-Compliant App: A Founder's Guide for 2026

Mark F A — Wed, 12 Aug 2026 07:09:30 +0000

TL;DR

There is no HIPAA certification. No stamp, no badge. It's a continuous state you maintain through contracts, controls, and documentation.
Six technical pillars carry most of the weight: encryption at rest and in transit, unique auth with MFA, server-enforced RBAC, tamper-evident audit logs, automatic session logoff, and a signed BAA with every vendor that touches PHI.
Missing BAAs are the most common root cause of HIPAA breaches. They're also the easiest thing for an auditor to check.
You can use LLMs with PHI in 2026, but only with providers that offer a BAA, on the right plan, with identifiers redacted before the call.
The $60k-$300k agency number is real but not the only number. A React Native and Supabase stack can hit a compliant beta in eight to twelve weeks.

Every healthcare founder eventually hits the same wall. You have a real idea, sometimes even paying pilot customers, and then a hospital CTO or a payer's legal team asks the question that stops the conversation: "Is your app HIPAA-compliant?"

Suddenly the six-week MVP plan collides with a body of law from 1996, agencies quoting $150,000 to $300,000 for a "compliant build," and a vendor stack full of tools you love that quietly cannot legally touch patient data.

Here's how you'd actually do it in 2026.

What "HIPAA-compliant" actually means

HIPAA-compliant app development means every point where Protected Health Information (PHI) is created, stored, transmitted, or accessed is covered by administrative, physical, and technical safeguards defined by the HIPAA Security Rule. And every third-party vendor that touches PHI has signed a Business Associate Agreement (BAA) with you.

Compliance is not a certification you buy. There is no "HIPAA-certified" stamp issued by HHS. What exists is the HIPAA Security Rule, the Privacy Rule, and the Breach Notification Rule, plus the Office for Civil Rights that investigates breaches and complaints. Your job is to demonstrate, with documentation, contracts, and technical controls, that you meet every applicable requirement on the day someone asks.

The three rules that shape your architecture

The Privacy Rule governs how PHI can be used and disclosed. It introduces the concept every product designer bumps into first: the minimum necessary standard. Your app collects, displays, and transmits only the PHI required to do its job. If your telehealth app doesn't need a full address to run a video visit, don't ask for it. It also defines patient rights (access, amendment, accounting of disclosures) and every one of those maps to a screen or an endpoint you have to build.

The Security Rule is the one engineers live in. It covers electronic PHI and requires three safeguard categories:

Administrative: risk assessments, workforce training, access management policies, incident response.
Physical: facility access controls, workstation security, device and media disposal.
Technical: access controls, audit logs, integrity controls, transmission security. This is the layer your code implements.

The Breach Notification Rule gives you a legal duty to notify affected individuals within 60 days, notify HHS, and in some cases notify media. "Unsecured" is the operative word. Properly encrypted PHI that gets stolen is generally treated as a much lower-risk event, which is the strongest practical argument that encryption is not optional.

The 6 technical requirements that actually matter

Encryption at rest and in transit. AES-256 server-side and on device. TLS 1.2+ with modern ciphers in flight. Hardware-backed key storage for anything the client persists.
Unique user authentication with MFA. Unique identifier per user, no shared logins, MFA for anyone accessing PHI. Biometrics count as a second factor on the client.
Role-based access control. Patient sees their own record. Nurse sees their unit. Billing clerk sees charge codes but not clinical notes. Enforced on the server, never only in the UI.
Tamper-evident audit logging. Every read and write of PHI logged with who, what, when, and from where. Logs protected from modification, retained six years.
Automatic logoff and session controls. Inactive sessions terminate. On mobile this means a background timer that clears the session and forces re-auth.
Signed BAAs with every vendor that touches PHI. The one most first-time healthcare founders miss.

On mobile, requirement 1 mostly comes down to not persisting PHI in the wrong place:

// DON'T: AsyncStorage is plaintext on disk.
// On Android it's SharedPreferences XML, readable with adb.
await AsyncStorage.setItem('patient_mrn', mrn);

// DO: hardware-backed keychain/keystore, device-bound.
import * as SecureStore from 'expo-secure-store';

await SecureStore.setItemAsync('session_token', token, {
  keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  keychainService: 'com.yourcompany.health.auth',
  requireAuthentication: true, // gates read behind Face ID / biometric
});

Better still: don't persist PHI on the device at all. Keep it in memory, fetch it per session, and let the server be the only durable store. That turns a lost-phone incident into a non-event.

Requirement 5 is the one people forget until an auditor asks. A minimal version:

// sessionTimer.js
import { AppState } from 'react-native';

const TIMEOUT_MS = 15 * 60 * 1000; // 15 min inactivity
let backgroundedAt = null;

AppState.addEventListener('change', (next) => {
  if (next === 'background') {
    backgroundedAt = Date.now();
  }
  if (next === 'active' && backgroundedAt) {
    if (Date.now() - backgroundedAt > TIMEOUT_MS) {
      clearSession();       // wipe in-memory PHI
      navigateToLogin();    // force re-authentication
    }
    backgroundedAt = null;
  }
});

Pair that with a foreground inactivity timer reset on user interaction, and log both the timeout and the re-auth to your audit trail.

The vendor stack that will actually sign a BAA

This is where most guides fail founders. They say "sign a BAA with your vendors" without saying which vendors will sign one, on which plan, at what price.

Layer	HIPAA-eligible option in 2026	Notes
Cloud infrastructure	AWS (BAA free via AWS Artifact, ~150 eligible services), Google Cloud, Azure	AWS is the most-used HIPAA cloud in 2026
Database + auth + storage	Supabase Team ($599/mo) + HIPAA add-on ($350/mo), or self-host	Check current Supabase HIPAA docs
Frontend (mobile)	React Native / Expo, no PHI in the bundle	Most common mobile framework for HIPAA apps
Email (transactional)	AWS SES (BAA available), Paubox, LuxSci	Not SendGrid on standard plans
SMS / voice	Twilio (HIPAA-eligible products only)	Sign a BAA and configure specifically for HIPAA
Push notifications	OneSignal (HIPAA plan), or AWS SNS	Never put PHI in the notification body
Error tracking	Sentry (HIPAA tier), Datadog (HIPAA tier)	Standard tiers do not qualify
Analytics	Server-side only, PHI-free events	Google Analytics does not sign BAAs
AI / LLM	Anthropic (BAA available), AWS Bedrock, Vertex AI, Azure OpenAI	See below

Two rules of thumb. If a vendor's marketing site doesn't say "HIPAA eligible" and their sales team can't produce a template BAA within a day, assume they can't. And HIPAA eligibility is almost always plan-specific, so the free tier you prototyped on almost certainly doesn't qualify.

Can you use LLMs with PHI?

Yes, but only with specific providers, on specific plans, under a signed BAA.

The major model providers now offer HIPAA-eligible tiers. Anthropic offers BAAs for enterprise customers using Claude. AWS Bedrock, Google Cloud Vertex AI, and Azure OpenAI all extend the underlying platform BAA to the models hosted on them. What you cannot do is ship PHI to a consumer API endpoint with no BAA. That's a breach the moment the request is sent, regardless of what the model does with the data.

Even under a BAA, minimize what you send:

// Redact identifiers server-side BEFORE the model call.
const SAFE_FIELDS = ['ageBand', 'sex', 'conditionCodes', 'medications'];

function toModelPayload(patient) {
  return SAFE_FIELDS.reduce((acc, k) => {
    if (patient[k] !== undefined) acc[k] = patient[k];
    return acc;
  }, {});
}

// Allow-list, not deny-list. A deny-list silently leaks
// every new field someone adds to the patient record.

Allow-list beats deny-list every time here. A deny-list quietly leaks whatever field a teammate adds next sprint. And log every prompt and response as part of your audit trail. If your AI features are purely non-PHI (educational content, appointment reminders with no diagnosis), you can often keep them on your regular non-BAA stack, as long as you can prove PHI never crosses that boundary.

The build checklist

Data classification. List every data element. Tag each PHI, non-PHI, or de-identified. Remove fields and prefer tokens over raw values.
Written risk assessment. A Security Rule requirement, not a nice-to-have. Threats, likelihoods, mitigations. Update annually and on material architecture changes.
Pick your HIPAA-eligible stack. Sign BAAs before a single byte of PHI reaches any vendor.
Implement the six pillars. Encryption, MFA, server-side RBAC, audit logs with six-year retention, session logoff, BAAs.
Secure SDLC. Code review, SAST/DAST, dependency pinning, supply chain controls. First thing a serious buyer's security team asks about.
Train your workforce. Security Awareness Training for anyone who could touch PHI. Keep records: dates, curricula, attendees.
Policies and incident response plan. Breach notification, sanctions, contingency, business continuity. Start from a template, then customize.
Third-party pen test before launch. Not required by HIPAA, but every hospital and enterprise buyer will ask for a recent report.
Privacy policy and Notice of Privacy Practices. User-facing documents, not just legal artifacts.
Continuous compliance. Quarterly access reviews, monthly log reviews, annual risk reassessment.

What it costs and how long it takes

Every agency guide says $60,000 to $300,000 and six to twelve months. That's real for a bespoke, agency-built telemedicine app with EHR integration. It's not the only number.

Baseline: whatever a non-HIPAA build of the same feature set would cost.
Add 15-25% for compliance-specific engineering: audit logging, RBAC, session management, encryption plumbing, admin console for access reviews.
Vendor upcharge: roughly $1,000-$3,000/month at MVP scale once you're on HIPAA tiers across the board.
Compliance program: policies, risk assessment, training, pen test, BAA legal review. Budget $10,000-$30,000 year one, roughly half that annually after.

Timelines compress the same way. A modern React Native and Supabase HIPAA stack, with the front-end scaffolded in an AI-assisted tool like RapidNative, can get you from zero to a working compliant beta in eight to twelve weeks. Worth being precise about the boundary, though: a code generation tool accelerates your front-end and scaffolding, not your compliance program. No AI code tool signs a BAA with you, because it doesn't touch your production PHI. And you should not paste PHI into any prompt during development. Scaffold with realistic-but-synthetic data and wire the real backend in your own environment.

What no tool can compress is the compliance program itself: writing your risk assessment, executing your BAAs, getting the pen test scheduled. Start those in parallel with engineering, not after.

FAQ

Is React Native suitable for HIPAA-compliant apps? Yes. Single codebase to native iOS and Android, access to Keychain and Keystore for hardware-backed encryption, biometric APIs for MFA, same TLS stack as native. HIPAA compliance is a property of your architecture and vendor stack, not your mobile framework.

Do I need a BAA with Apple or Google to publish? No. They don't process PHI on your behalf when they distribute your app. You do need to follow their health data policies, and you need BAAs with every cloud, analytics, notification, and backend vendor that actually handles PHI.

Can I use Firebase? Partially. Firebase Auth, Cloud Firestore, and Cloud Functions on Blaze are covered under the Google Cloud BAA when configured correctly. Firebase Analytics, Crashlytics on defaults, and Cloud Messaging with PHI payloads are not. Confirm each service against Google Cloud's current list.

What happens in a breach? Notify affected individuals within 60 days, notify HHS (immediately for 500+ people, otherwise annually), and in some cases notify media in the affected state. OCR fines range from $137 to over $2 million per violation depending on culpability. Encrypted PHI that's lost is generally a much lower-risk event.

Do I need HIPAA if only patients use my app? If you collect health data directly from consumers and aren't acting on behalf of a covered entity, you may not technically be subject to HIPAA. But you're almost certainly subject to the FTC Health Breach Notification Rule, state laws (California's CMIA, Washington's My Health My Data Act), and user expectations. Most direct-to-consumer health apps build to HIPAA-equivalent standards anyway.

The part most teams get wrong

HIPAA has a reputation for being expensive and slow because most teams treat compliance as a phase at the end of the project. It isn't. It's an architectural constraint you build in from day one, and once it's in your foundation the incremental cost is much smaller than the guides suggest.

Scaffold fast so you get to testable UI in days. Choose a HIPAA-eligible stack from the start. Get BAAs signed while engineers are still building. Write the risk assessment early, not the week before your first customer's security review.

What's your stack? Drop it in the comments and I'll flag which pieces will fail an audit. And if you've shipped a HIPAA app already, I want to know which vendor surprised you most by refusing (or agreeing) to sign a BAA.

React Native Authentication in 2026: The Refresh-Token Pattern That Actually Scales

Mark F A — Wed, 12 Aug 2026 06:03:55 +0000

TL;DR

Access token in memory, refresh token in expo-secure-store. AsyncStorage is plaintext on disk. Stop using it for credentials.
Access token: 15 minutes. Refresh token: 30 days. Different signing secrets. The split is about blast radius.
One singleton refreshPromise stops five concurrent 401s from firing five refresh calls (four of which will fail once rotation kicks in).
Always pass an explicit keychainService. Omit it and users get logged out after every TestFlight update, iOS only.
Total cost: roughly 200 lines of app code, no managed auth vendor required.

Most React Native auth tutorials show you how to log a user in. Almost none of them show you how the app behaves at 3 AM when five in-flight requests all hit an expired token at the same time, or how your carefully-stored token silently disappears after a TestFlight update. This post is the pattern that survived three production apps.

Why most tutorials fail

You've seen this pattern a hundred times:

const token = await AsyncStorage.getItem('access_token');
fetch(url, { headers: { Authorization: `Bearer ${token}` } });

Three problems compound in production:

AsyncStorage is not secure. It's plaintext on disk. Any process that can read your app's sandbox can read the token.
No refresh handling. The token expires, users get 401s, and your fix is "log them out and back in." That's a leaky bucket.
Race conditions on refresh. When multiple requests fire while the token is expiring, they all try to refresh at once and only one wins.

The pattern below solves all three.

The two-token model

Issue two tokens from your API on login:

Access token: short-lived (15 minutes), signed with ACCESS_SECRET. Sent with every authenticated request.
Refresh token: long-lived (30 days), signed with a different REFRESH_SECRET. Used only to mint new access tokens.

The point of the split is blast radius. If your access token leaks (network sniffer, log line), the attacker has 15 minutes. The refresh token never leaves the keychain.

Where to store each token

The rule that took me two apps to internalize:

Access token → in-memory only. A module-level variable. It dies with the JS bundle. That's fine. The app will refresh from disk if needed.
Refresh token → expo-secure-store. Backed by iOS Keychain / Android Keystore. Never AsyncStorage.

// tokens.js
import * as SecureStore from 'expo-secure-store';

let accessToken = null;

export const getAccessToken = () => accessToken;
export const setAccessToken = (t) => { accessToken = t; };

export const getRefreshToken = () =>
  SecureStore.getItemAsync('refresh_token', {
    keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
    keychainService: 'com.yourcompany.yourapp.auth',
  });

export const setRefreshToken = (t) =>
  SecureStore.setItemAsync('refresh_token', t, {
    keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
    keychainService: 'com.yourcompany.yourapp.auth',
  });

The two options on SecureStore matter:

WHEN_UNLOCKED_THIS_DEVICE_ONLY: the token is gone if the device is restored onto a new device. Prevents session cloning.
Explicit keychainService: survives TestFlight builds (more on this below).

The refresh middleware pattern

Wrap every authenticated fetch in a middleware that handles 401s transparently:

// authFetch.js
import {
  getAccessToken,
  setAccessToken,
  getRefreshToken,
  setRefreshToken,
} from './tokens';

const API = 'https://your-api.com';
let refreshPromise = null;

async function performRefresh() {
  const rt = await getRefreshToken();
  if (!rt) throw new Error('NO_REFRESH_TOKEN');

  const r = await fetch(`${API}/auth/refresh`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ refresh_token: rt }),
  });

  if (!r.ok) {
    // Refresh token invalid, user must log in again
    await setRefreshToken('');
    setAccessToken(null);
    throw new Error('REFRESH_FAILED');
  }

  const { access_token, refresh_token } = await r.json();
  setAccessToken(access_token);
  await setRefreshToken(refresh_token); // rotation: new RT every refresh
  return access_token;
}

export async function authFetch(url, opts = {}) {
  const doRequest = async () => {
    const headers = {
      ...(opts.headers || {}),
      Authorization: `Bearer ${getAccessToken()}`,
    };
    return fetch(url, { ...opts, headers });
  };

  let response = await doRequest();

  if (response.status === 401) {
    if (!refreshPromise) {
      refreshPromise = performRefresh().finally(() => {
        refreshPromise = null;
      });
    }
    await refreshPromise; // all in-flight 401'd requests await the same refresh
    response = await doRequest();
  }

  return response;
}

The singleton refreshPromise is the piece most tutorials miss. Without it, five concurrent requests hitting an expired token cause five refresh calls. Four of them will 401, because the refresh-token rotation on the first call already invalidated the shared refresh token.

TestFlight and iOS keychain: the accessGroup trap

Here's a bug I've watched three teams hit:

"Users are getting logged out after every TestFlight update, but only on iOS."

The cause: iOS keychain items are scoped by accessGroup. When TestFlight installs a new build, it may preserve keychain access, but only if the keychainService string is consistent across builds. If your code omits keychainService, expo-secure-store generates a random-ish default that changes across builds.

Fix: always pass an explicit keychainService (as in the tokens.js above). Once set, it survives TestFlight promotions, production releases, and version bumps.

While you're at it, add a startup check that re-validates the token against your API:

export async function bootstrapAuth() {
  if (!(await getRefreshToken())) return { authenticated: false };

  try {
    // Try any authenticated endpoint that returns quickly
    const r = await authFetch(`${API}/me`);
    if (r.ok) return { authenticated: true, user: await r.json() };
    return { authenticated: false };
  } catch {
    return { authenticated: false };
  }
}

This way a truly-invalidated session (user was banned server-side, refresh token was revoked) doesn't sit stale in the app UI.

Anti-patterns

Stop doing these:

Storing tokens in AsyncStorage. It's not encrypted. On Android it's SharedPreferences XML, readable with adb.
Bearer tokens in URL query strings. They end up in server logs, analytics captures, and browser history.
A single fetch wrapper per API call. You'll forget one, and that endpoint will silently break auth. Wrap it once at the module level.
Manual logout that only clears the access token. If the refresh token is still in the keychain, the next bootstrapAuth() re-authenticates the user.
Refresh-token rotation without server-side invalidation. If your API doesn't invalidate the old refresh token on rotation, an attacker who steals it can refresh indefinitely.

What to ship first

If you're starting from a fresh React Native app:

Set up the two-token model in your API. djangorestframework-simplejwt, or jose for Node, both handle rotation out of the box.
Copy the tokens.js and authFetch.js above.
Call bootstrapAuth() in your root component's useEffect(() => {}, []).
Add a global 401 → redirect-to-login handler for the terminal case (refresh token invalid).

That's roughly 200 lines of app code. It'll outlive whichever managed auth service you were considering, and the security posture is stricter than most of them. If you'd rather not wire it by hand, RapidNative scaffolds Expo apps with this pattern preconfigured, though the pattern itself is straightforward enough that most teams should own it.