DEV Community: RapidNative

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

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

TL;DR

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

The problem

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

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

That reframing changes every downstream decision.

Why not Supabase Realtime

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

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

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

The two-stage auth handshake

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

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

Server side:

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

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

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

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

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

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

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

The event schema

Small and domain-shaped:

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

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

The tabId trick

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

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

Every handler opens with the same guard:

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

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

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

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

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

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

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

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

Every payload shape has a comment above it now.

AI generation as a multi-user event

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

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

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

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

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

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

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

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

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

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

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

Presence, deduped by userId

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

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

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

  this.dispatch(setActiveUsers(deduped));
}

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

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

The team layer underneath

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

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

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

What we deliberately didn't build

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

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

Wrapping up

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

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

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

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.

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

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

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

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

TL;DR

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

Why OTA is a superpower most teams misuse

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

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

The three update tiers

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

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

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

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

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

Rollback discipline: write the runbook before you push

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

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

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

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

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

Two habits make this actually work:

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

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

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

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

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

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

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

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

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

Safe points, in order of preference:

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

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

EAS channels as a first-class rollout dimension

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

Our channel layout:

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

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

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

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

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

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

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

When OTA vs. a store release

The boundary is mechanical, not judgment-based:

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

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

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

The shortest reliable loop we've settled on

For a Tier 2 change, end to end:

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

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

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

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.

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

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

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

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

Reading a wireframe as a folder tree

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

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

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

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

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

The scaffolding script

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

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

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

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

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

scaffold(tree, './app');

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

What still needs a dev

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

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

Case study

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

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

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

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

The 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.

How AI Is Making Mobile Accessibility Easier Than Ever

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

TL;DR

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

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

Why mobile a11y is harder than the web

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

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

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

And the version that actually works with VoiceOver and TalkBack:

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

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

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

Shift 1: the OS started covering for you

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

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

Shift 2: audits got cheap

Three categories worth knowing:

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

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

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

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

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

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

Shift 3: the missing content is now generated

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

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

Shift 4: fix it at generation time

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

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

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

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

What AI still can't do

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

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

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

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

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

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

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

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

Where this goes next

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

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

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

Mobile App Analytics in React Native: What to Track (and What to Skip)

Russel Dsouza — Thu, 13 Aug 2026 05:01:19 +0000

I have shipped enough React Native apps to see the same pattern every time: on launch day someone wires up fifty analytics events and six months later nobody on the team can explain what any of them are for. This is a working developer's guide to instrumenting a React Native or Expo app so the numbers actually mean something.

The Four Buckets

Every useful mobile app metric fits into one of four categories:

Acquisition: installs, CPI, CAC, install source, store conversion.
Activation: activation rate, time to value, onboarding funnel completion.
Engagement and Retention: DAU, MAU, stickiness (DAU/MAU), session length, D1/D7/D30 retention cohorts, churn.
Monetization: ARPU, conversion rate, LTV, trial-to-paid, renewal rate.

Track a couple from each bucket. Skip the rest until you outgrow them.

Technical Metrics That Are Actually Product Metrics

Performance is not a "nice to have." A slow, crashy app poisons every other metric.

Crash-Free Session Rate: target 99.5%+ for consumer, 99.9%+ if you take payment.
ANR Rate (Android only): Play Store visibility suffers when this crosses Google's bad-behavior threshold.
Cold Start Time: under 500ms good, over 1500ms bad. Hermes bytecode substantially cuts JS parse time vs JSC.
API p95 Latency: measured from the client, not the server. The tail is where users feel pain.

The Stack I Actually Use in 2026

Concern	Tool
Product analytics	PostHog (self-hosted) or Amplitude (free tier)
Errors / performance	Sentry
Subscriptions	RevenueCat
Attribution	SKAdNetwork + Play Install Referrer (free, built-in)

All of these have first-class Expo config plugins in 2026. npx expo install @sentry/react-native posthog-react-native react-native-purchases gets you 80% of the way there.

The One Instrumentation Pattern That Scales

Wrap your SDK. Always. Every screen and component should import track() from a single module, never the SDK directly.

// src/analytics/track.ts
import PostHog from 'posthog-react-native';

type EventName =
  | 'signup_completed'
  | 'paywall_viewed'
  | 'subscription_started'
  | 'workout_logged';

type EventProps = Record<string, string | number | boolean>;

export function track(event: EventName, props: EventProps = {}) {
  PostHog.capture(event, props);
}

export function identify(userId: string, props: EventProps = {}) {
  PostHog.identify(userId, props);
}

Rules I have learned the hard way:

Event names are verbs, past tense. paywall_viewed, not paywall.
User properties are stable, few, semantic. plan, cohort_week, platform_version. That is enough for 90% of segmentation.
No PII in event names or properties. Not even hashed. Just don't.
Type the event names. If your event schema is a type, refactoring becomes safe. Untyped strings are how event soup starts.

Metrics I Have Deleted From Every Dashboard

Total installs, unless you are showing it next to activated installs.
Screen views as a KPI. Useful for debugging nav, useless as a headline.
"Engagement" as a single number. It's a portfolio, not a scalar.
App Store rating without volume and recency alongside it.

Rule: for every metric, name the decision it drives, the owner of that decision, and the cadence they act on it. Can't do all three? Delete.

Privacy: The 2026 Baseline

PrivacyInfo.xcprivacy is mandatory if any of your SDKs touch required-reason APIs. Most analytics SDKs do. Skip this and your App Store submission gets rejected.
Consent for EU: non-negotiable for behavioral events. Use Klaro if you want an OSS option.
First-party > third-party: server-side event streams from your app to your own backend are increasingly the safe default. PostHog and Amplitude both support this.

Where to Go From Here

If you're starting from scratch, spin up an app with an AI React Native builder like RapidNative. It scaffolds Expo apps with the wrapper pattern above, and event schemas become just another thing you can prompt for. Faster than doing the boilerplate by hand, and consistent across every screen.

If you already have an app, delete half your events tomorrow. You'll be fine.

Which metric have you deleted from a dashboard and never missed? That list is more useful than any tracking plan; drop yours in the comments.

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.

The State of Mobile AI in 2026 — From Code Generation to Full App Creation

Famitha M A — Thu, 06 Aug 2026 07:55:07 +0000

In 2023, AI could complete a line of code. In 2026, AI can build the entire mobile app — screens, backend, auth, camera access, and a signed IPA ready for the App Store.

That's not marketing copy, it's a specific technical shift, and it happened faster than most of us in mobile expected. This post walks through the four generations of AI coding tools, why mobile lagged the web by three years, and what specifically broke open in 2026.

The four generations, briefly

Gen 1 (2021-2023): Autocomplete. Copilot. AI completes the next line. Human owns the file.
Gen 2 (2023-2024): Single-file generation. Cursor, Claude Code. AI generates entire files. Human is the integrator.
Gen 3 (2024-2025): Web full-stack. Lovable, v0, Bolt. Prompt to deployed web app.
Gen 4 (2026): Mobile end-to-end. Prompt to submission-ready native React Native + Expo app.

Every generation compressed the space between "I have an idea" and "users are running my app." Gen 4 is the first one where a non-engineer can complete that arc entirely for native mobile.

Why mobile lagged the web

Web AI moved fast because the web is forgiving. Mobile is not. Each of the following cost the ecosystem roughly a year:

Two platforms, not one. React Native shares ~80% of code across iOS and Android. The other 20% is where the pain lives: permissions, keyboard behavior, safe areas, gestures, notches. A model has to reason about platform divergence explicitly.

Native APIs are gated. Camera on web is getUserMedia. Camera on mobile is expo-camera + permission strings in app.json + runtime prompts + a config plugin. Any wrong step and it doesn't build.

Preview is genuinely hard. Web preview is an iframe. Mobile preview needs Metro, a matching JS engine (Hermes), and streaming updates without a full rebuild.

The App Store is a wall. Apple's Guideline 4.2 rejects "wrapped websites." Web-first tools with a "mobile export" button hit this and bounced. Gen 4 had to output real native code from day one.

Fullstack means fullstack. Real mobile means auth that survives app suspend/resume, secure token storage in the OS keychain, offline sync, and a data layer that handles being genuinely offline. Gen 3 tools papered over most of this — they targeted the web, which rarely needs it.

What "full app creation" actually produces in 2026

Layer	Output
Screens	React Native + navigation, gestures, safe areas
State	Redux / Zustand / Context, chosen by complexity
Backend	Provisioned Supabase project + schema + RLS + types
Auth	Keychain-backed session, deep links, sign-in flows
Data	Migrations, seed data, offline-first where relevant
Device	Camera, GPS, push, biometrics with correct config plugins
Preview	QR-code preview on real iOS and Android devices
Export	Clean React Native + Expo source, runs anywhere
Ship	Signed IPA/AAB, submitted to App Store + Play

Every row above is a place a Gen 3 "mobile export" tool fails. Every row is now Gen 4 table stakes.

The four unlocks that made 2026 different

Frontier models got good at multi-file reasoning. The current generation of frontier models can hold an entire codebase in context and reason about change propagation. Prerequisite for full app gen.
Streaming output made iteration feel instant. SSE + progressive component mounting turns "AI generation" from a batch job into a conversation.
LLM-native tooling replaced ported IDEs. Virtual filesystems the AI writes into, sandboxed runners that typecheck and lint before feedback loops back to the model, multi-step LLM pipelines. The model is the CPU; the surrounding system is the OS.
Someone had to actually build the mobile-specific infrastructure. This is the moat. Producing an Expo project that installs, builds, previews on a real device, submits to a store, and comes back with a valid receipt is a stack of ten problems requiring ten specialists.

Checklist: is a tool actually Generation 4?

If you're evaluating tools in 2026, ask:

Does the output run on a real phone via QR code, or just in a browser iframe?
Does the tool generate backend + auth in the same prompt as the frontend?
Can you export the code and run it locally without the vendor?
Does the tool handle App Store submission or stop at "here's your code"?
Does the tool support device features — camera, push, GPS, biometrics — out of the box?

Most tools calling themselves "mobile AI app builders" in 2026 fail at least two. The ones that pass are the ones defining what AI mobile app development means for the rest of the decade.

What this means for developers

Senior mobile engineers have not been displaced — the ceiling of what you can build solo has moved up, not down. The mechanical work (screen scaffolding, auth boilerplate, Expo config, navigation setup) collapses to a prompt. The architectural work (data modeling, performance profiling, complex state machines, offline sync semantics) is still where craftsmanship compounds.

The developers who ship the most in 2026 are the ones who treat AI as a code CPU and spend their time on the parts that matter.

Try it out: rapidnative.com — describe an app in plain English, get a real React Native + Expo app on your phone in minutes. Free tier is 20 credits, no credit card.

How to Build a Pet Care App with React Native (2026)

Mark F A — Fri, 31 Jul 2026 09:29:50 +0000

TL;DR

Pet care is a well-scoped React Native project: bounded MVP, cross-platform users, forgiving early adopters.
Stack: Expo SDK 52+, TypeScript, Expo Router, Supabase, NativeWind, expo-notifications, FlashList.
Store next_due_at on the vaccination row, not derived — vaccination schedules vary by jurisdiction.
Store UTC in the DB, render local with date-fns-tz, and reschedule reminders on AppState.change.
Honest timeline: 4–6 weeks solo, most of it boilerplate.

The pet care market keeps growing, and mobile apps are eating an increasing share of it — vet booking, vaccination reminders, feeding schedules. If you've been looking for a well-scoped React Native project to ship, a pet care app is genuinely one of the best options: bounded feature set, cross-platform relevance, and a user base that's forgiving of a rough v1 as long as it solves a real problem.

Here's the practical build guide, from stack decisions through App Store submission.

Why React Native fits pet care apps

Pet care apps need cross-platform reach (pet owners split evenly between iOS and Android), rich UI (photo-heavy profiles), and native features like push notifications and camera — the exact sweet spot for React Native with Expo. They also have a naturally scoped MVP: pet profiles, health records, appointments, reminders. You can ship in weeks, not months.

The MVP feature set

Ship these five features first. Adding a sixth before nailing edge cases (multi-species schedules, deleted pets, timezone-sensitive reminders) is the fastest way to never launch.

Pet profile — name, species, breed, DOB, weight, photo, microchip ID
Health record — vaccinations with next-due dates, medications, allergies
Appointment tracker — vet visits, grooming, boarding with reminders
Feeding log — food type, portion, schedule
Push notifications — vaccinations, medications, appointments

The stack

React Native with Expo SDK 52+
TypeScript (non-negotiable for anything you ship)
Expo Router for file-based routing
Supabase for hosted Postgres + auth
NativeWind for Tailwind-style styling
expo-notifications for local push
FlashList (not FlatList) for photo-heavy timelines

Scaffold it

npx create-expo-app@latest pet-care-app --template
# choose "Navigation (TypeScript)"
cd pet-care-app
npx expo install expo-notifications expo-image-picker expo-file-system
npm install nativewind zustand @supabase/supabase-js date-fns

Route structure

app/
  (tabs)/
    _layout.tsx           # Pets | Schedule | Records | Settings
    index.tsx             # pet list
    schedule.tsx
    records.tsx
    settings.tsx
  pet/
    [id].tsx
    [id]/health.tsx
    [id]/appointments.tsx
  appointment/new.tsx
  vaccination/new.tsx

Decide the route tree before writing screens. Nesting everything under (tabs)/pets/[id]/... will bite you when you need to push a full-screen modal.

Data model

Four entities cover the MVP:

Entity	Key fields
`pets`	id, owner_id, name, species, breed, date_of_birth, weight_kg, photo_url
`vaccinations`	id, pet_id, name, administered_at, next_due_at
`appointments`	id, pet_id, type, starts_at, location, notes
`feedings`	id, pet_id, food_name, portion_grams, scheduled_at, given

Two things matter more than you'd expect:

Store next_due_at on the row. Rabies is annual in some jurisdictions, triennial in others. Don't hardcode.
Store UTC in the DB, render local with date-fns-tz. Get this wrong and a reminder set for 8 AM triggers at 3 AM after a flight.

Push notifications the right way

The single feature that separates useful pet apps from forgettable ones:

import * as Notifications from 'expo-notifications';

await Notifications.scheduleNotificationAsync({
  content: {
    title: `${pet.name}'s ${vaccination.name} is due`,
    body: 'Book a vet appointment to stay on schedule.',
    data: { petId: pet.id, vaccinationId: vaccination.id },
  },
  trigger: { date: nextDueAt },
});

Two rules:

Request permissions gracefully — show a "why" screen before the OS prompt.
Reschedule on AppState.change when the app foregrounds. Timezone/DST drift is real.

The 4–6 week problem

Honest timeline for a solo developer: 4–6 weeks for a shippable MVP if you're comfortable with React Native. 10–12 weeks if you're learning Expo/TypeScript/Supabase alongside.

Most of that time is boilerplate — layout, navigation wiring, spacing, empty states, forms. None of it is the interesting part of building a pet care app.

The AI-first shortcut

Tools like RapidNative generate a working React Native + Expo codebase from a natural-language description. The workflow:

Describe the app: "A pet care app with pet profiles, vaccination tracking, appointment reminders, and a schedule tab across all pets."
Get a working app in a few minutes.
Scan a QR code, preview on your real phone.
Click any element to describe changes ("make these cards bigger, add a soft green tint when a task is done").
Export the full React Native + Expo source, or publish directly to the stores.

Same output — a real React Native app — different path. Worth trying on the boring 80% of the build so you can spend time on the interesting 20%.

App Store gotchas specific to pet apps

Three things reviewers catch:

Health claims. Track vaccinations/meds without positioning as a medical device. Be explicit in the description.
Background location. If you add walk tracking, justify the permission concretely: "To log your dog's walk route while your phone is in your pocket."
Screenshots. Empty-state screenshots underperform dramatically. Show real pets with real data.

Use eas submit — it handles both stores and eliminates most rejection loops.

Wrapping up

The features are the easy part. Reliable reminders, offline-first data, and fast photo handling are what separate 5-star pet apps from abandoned ones. Nail those, ship a focused MVP, and let owners tell you what's missing.

If you've shipped a pet app — or any app where reminders are the core value — how did you handle timezone drift on scheduled notifications? Drop a comment, I'd like to hear what actually held up in production.

Build a News Aggregator App with AI Recommendations (React Native + Expo)

Mark F A — Wed, 29 Jul 2026 06:43:33 +0000

The average reader engages with about 4% of the news they scroll past. The remaining 96% is duplication, noise, or algorithmically boosted outrage. That gap is the whole reason a well-built AI news aggregator still has room in the market — and thanks to modern tooling, it's now a weekend project instead of a quarter-long roadmap.

Here's the architecture that keeps showing up in successful indie news apps, plus a shortcut for shipping one fast.

The four layers you actually need

Ingestion — NewsAPI, RSS, publisher APIs, GDELT.
Understanding — embeddings, categorization, dedup.
Ranking — hybrid: content + collaborative + recency decay + diversity.
Presentation — reader mode, saves, offline, push, deep links.

Skip any layer and you have a directory nobody opens. Nail all four and you have a daily habit.

Reference tech stack

Layer	Choice
Client	React Native + Expo
Feed API	NewsAPI + curated RSS
Storage	Postgres (Supabase)
Embeddings	OpenAI `text-embedding-3-small`
Vector search	pgvector
Push	Expo Notifications
Offline	AsyncStorage

Nothing exotic. The hard part is the product decisions, not the pieces.

Building it fast

The traditional way: npx create-expo-app, set up navigation, build 12 screens by hand, wire the API, add state management, style everything, then start on the ranker.

The 2026 way: describe the app in a prompt to an AI app builder (I've been using RapidNative for this kind of thing) and get a working Expo project as output — real code, exportable, no lock-in. Then hand-tune the parts that actually matter (the ranker, the sources, the cold-start UX).

A prompt that produces a strong first version:

Build a news aggregator app called Skim. Vertical feed of article cards with hero image, source logo, headline, summary. Top pill row for categories: For You, Top, Tech, Business, Science, Sports. Tap opens a reader-mode view with share, save, and "More like this." Bottom tabs: Feed, Search, Saved, Profile. Dark theme, pull-to-refresh, shimmer loading.

You get a working multi-screen app in about a minute, previewable on your phone via QR.

The recommendation engine

Once you have a live feed, add three ranking signals:

Content-based. Embed each article. Store a rolling user "taste vector" as the mean of embeddings of articles they read/saved/lingered on. Cosine-similarity a new article against the user vector. Solves cold-start well.

Collaborative. Once you have enough interaction data, "users who read X also read Y" is often stronger than pure text similarity — it captures fun, authority, contrarianism, things the text doesn't.

Recency + diversity re-ranking. Multiply scores by exp(-age_hours / half_life) with a 12–24h half-life. Then, when selecting the top N, penalize each candidate by its similarity to already-selected items. This is what stops the feed from becoming five versions of the same story.

Rough weights I've seen work: 0.4 * content + 0.3 * collab + 0.2 * recency + 0.1 * diversity. Tune with real data.

Cold-start UX matters more than ranker quality

The first five swipes decide whether a new user comes back tomorrow. Default to a strong editorial mix (top stories across categories) on session 1–2. Bring personalization online after session 3. Every good news app I've studied does some version of this.

The retention features people underinvest in

Save-for-later with offline caching (people read on the subway)
"Why am I seeing this?" per-story explainer
Explicit topic mute/follow controls
Weekly digest push or email
Notifications capped at 3–5/day, gated on the user's taste vector

Copyright, briefly

Show headline + short summary + hero image + link back. Don't cache full article bodies at scale without a license. Reader mode is fine if fetched on-device (Instapaper pattern).

The full workflow

If you want to see this in action end-to-end, RapidNative turns the prompt above into a real Expo project you can extend. Free tier is 20 credits, no card. The exported code is standard Expo — you own it.

Happy to answer questions on the ranker specifics in the comments.