DEV Community: RapidNative

The Complete Guide to Offline Storage in React Native (2026)

Famitha M A — Wed, 22 Jul 2026 09:28:13 +0000

Most React Native apps treat the network as an always-on dependency, and it shows the moment a request stalls. Offline storage isn't one library — it's a stack: key-value stores for preferences, secure enclaves for tokens, structured DBs for domain data, and query caches for server state. This post walks through the whole stack and the offline-first pattern that ties it together.

The five categories of RN offline storage

Key-value — AsyncStorage (compat) or MMKV (default). MMKV is ~30x faster and supports sync reads.
Secure — expo-secure-store or react-native-keychain. Backed by iOS Keychain / Android Keystore.
Structured — expo-sqlite, op-sqlite (JSI, synchronous), WatermelonDB (reactive + sync), Realm (Atlas Device Sync).
File system — expo-file-system for media. Never base64 blobs into KV storage.
Server-state cache — TanStack Query + persistQueryClient, backed by MMKV.

Comparison table

Library	Type	Perf	Encryption	Best for
AsyncStorage	KV	1x	Community fork	Legacy/compat
MMKV	KV	~30x	Built-in	New default
expo-secure-store	Secure KV	—	OS keychain	Tokens
op-sqlite	SQL	JSI	SQLCipher	Structured data
WatermelonDB	Reactive DB	Lazy	SQLCipher	Large offline lists + sync
Realm	Object DB	Fast	Yes	Atlas Device Sync

The offline-first pattern

Four moving parts:

Local-first reads — UI always reads from local store. Network populates store; store renders UI.
Optimistic writes — UI updates immediately, before the server acks.
Mutation queue — Durable list (SQLite or MMKV) of pending server-side changes with client IDs.
Sync engine — Background worker drains the queue with exponential backoff, reconciles conflicts.

async function markMessageAsRead(id: string) {
  db.write(() => {
    db.messages.update(id, { readAt: Date.now(), pendingSync: true });
  });

  await mutationQueue.enqueue({
    kind: 'message.markRead',
    payload: { id, readAt: Date.now() },
    clientId: uuid(),
  });

  syncEngine.wake();
}

Conflict resolution

LWW — timestamps, newest wins. Fine for most consumer apps.
Server-authoritative — reject stale writes with a version mismatch.
CRDTs — Yjs, Automerge. Overkill unless you're building a collaborative editor.

Decision cheat sheet

Prefs / JWT? → MMKV + expo-secure-store
Instant-open cached lists? → TanStack Query + persistQueryClient on MMKV
Thousands of offline records? → op-sqlite (or WatermelonDB for reactive)
Cross-device sync? → WatermelonDB or Realm
Media? → expo-file-system + metadata in SQLite

Pitfalls to skip

Blocking JS thread with async AsyncStorage at startup
Blobs in KV stores
No cache-wipe on logout
Infinite retry loops in the mutation queue
Persisting Redux state without a schema version

Wrap-up

Offline-first isn't a defensive posture — it's a performance strategy. Reading from local storage beats a round-trip every time, and a good sync engine hides the network from your users. Pick each layer deliberately and this becomes a solved problem, not a recurring one.

I built RapidNative, an AI mobile app builder that generates production-ready React Native code you can extend with any of these libraries. Would love feedback from anyone using MMKV + TanStack Query in production.

5 Places Sensitive Data Leaks in a React Native App (and How to Plug Them)

Russel Dsouza — Tue, 21 Jul 2026 07:49:01 +0000

The leaks that matter usually aren't in production code — they're in the workflow around it.
Five common ones: AsyncStorage for tokens, real user data in design mockups, multi-stage AI pipelines, logs and crash reports, and bundled permissions.
Two greps that find real bugs today: AsyncStorage.setItem near token, and console.log(user / console.log(token / console.log(prompt.
Model consent by purpose, not by OS permission. Camera consent is not AI-summarization consent.

Data protection posts usually focus on the shipped binary. Encrypt this, pin that certificate, wrap the API client. All correct, all necessary — and all too late if the leak happened three weeks earlier in a design mockup.

We build AI-generated React Native apps at RapidNative, and the interesting security bugs almost never live in production code. They live in the space between code, design, and AI workflows. Here are five leak points we've watched teams miss.

1. AsyncStorage for anything sensitive

The classic. AsyncStorage is convenient, unencrypted key-value storage. A user session token in AsyncStorage is one rooted device or one iCloud backup extraction away from being replayed.

Fix: use expo-secure-store (Keychain on iOS, Keystore on Android) for anything that unlocks an account.

import * as SecureStore from 'expo-secure-store';

export async function saveSessionToken(token) {
  await SecureStore.setItemAsync('session_token', token);
}

If your codebase greps positive for AsyncStorage.setItem and token, that's your first PR.

2. Real user data in design prototypes

A designer opens Figma, needs a realistic list, and pastes 20 rows from the production customer export. Now customer names sit in the design file, which sits in a Figma team folder, which was shared to a contractor's personal email nine months ago.

Fix: a synthetic data script committed to the repo. npx generate-mocks users 20 should be faster than exporting production data. Make the fast path the safe path.

3. Multi-stage AI workflows

Voice memo lands. Transcription service returns text. A second model extracts tasks. Teammates get pinged.

That's four handoffs, and the security review probably only covers the API endpoint at step 1.

Fix: draw the pipeline as boxes, list what data each box sees, and confirm each hop has access controls tied to the user's actual consent — not a bundle. Camera consent is not AI-summarization consent.

4. Logs and crash reports

Sentry, Bugsnag, Datadog, or whatever log aggregator you use sees everything the app hands it. Session tokens in Authorization headers. AI prompt bodies with user text. Full user IDs in breadcrumbs.

Fix: scrub before you send. Most SDKs support a beforeSend hook.

Sentry.init({
  beforeSend(event) {
    if (event.request?.headers) delete event.request.headers.Authorization;
    return event;
  },
});

Grep your codebase for console.log(user, console.log(token, and console.log(prompt. That's your second PR.

5. Bundled permissions

You ask for camera on onboarding: "we need this for document capture." The user agrees. Six months later a new AI-summarization feature ships that also uses camera frames.

Same permission, different purpose. Legally shaky (GDPR Article 25 asks for data minimization by design), and practically a betrayal of what the user thought they said yes to.

Fix: model consent as a first-class type, keyed on purpose rather than on OS permission:

type ConsentEvent = {
  userId: string;
  action: 'granted' | 'withdrawn';
  policyVersion: string;
  purpose: 'document-capture' | 'ai-summary' | 'marketing';
  surface: 'onboarding' | 'settings' | 'feature-gate';
  timestamp: string;
};

Ship a new feature, ask again for that purpose. A one-line inconvenience for the user beats the €7.1B in GDPR fines the EU has issued as of January 2026.

The pattern

Notice what the five have in common: none of them are broken TLS, weak crypto, or a mangled JWT signature. They're all workflow leaks.

Encryption and pinning are table stakes. The bugs that leak your customer's data in 2026 are the ones nobody put in the security review — because they happen in Figma, in a Slack DM, in a Sentry payload, or in an AI pipeline diagram that was never drawn.

Draw the diagram. Grep the logs. Model consent. Ship.

Full source with the OWASP and NIST references: rapidnative.com/blogs/data-protection.

Which of the five would your codebase fail right now? Mine failed #4 the first time I checked.

You Don't Need 10 Refactoring Tools. Pick 2 From This Decision Tree.

Russel Dsouza — Tue, 21 Jul 2026 07:35:58 +0000

Answer three questions — scope of change, how type-heavy your codebase is, and who runs it — and the tool choice collapses to two.
Solo TS-heavy repo: VS Code + ts-morph. Small team, one repo: WebStorm + jscodeshift. Multi-repo org: ast-grep + Sourcegraph Batch Changes.
You can skip Babel, Comby, OpenRewrite/Moderne, and ReSharper unless you're in their specific ecosystem.
Tool sprawl is a symptom: if you're debating 10 tools, the real gap is that nobody's defined what's worth automating.

Every "best refactoring tools" post in 2026 gives you the same 10 names and lets you sort them out.

But 51% of developers now use AI coding tools daily, and the refactoring-tools market is on track from $1.74B to $5.82B by 2033. That growth means more tools, not clearer choices.

Here's a smaller frame. Answer three questions, pick two tools, ignore the rest.

The 3 questions

Scope of the change?

One file, minutes of work: your IDE
Same rewrite across many files: a codemod
Same rewrite across many repos: a batch orchestrator

How type-heavy is your codebase?

Loose JS or mixed languages: AST / pattern tools
Strict TypeScript: type-aware transforms

Who runs it?

Solo: CLI is fine
Team: you need a shared recipe and review flow

The 2-tool stacks

Solo dev, TypeScript-heavy React Native repo. Pick VS Code (rename, quick fixes, everyday cleanup) and ts-morph (type-aware programmable rewrites for the times VS Code's rename gives up). Two tools, both free, both scriptable.

Small team, one repo, repetitive structural changes. Pick WebStorm (symbol-aware preview so nobody merges a broken rename) and jscodeshift (AST codemods for the "convert 200 class components to hooks" problem). WebStorm covers day-to-day, jscodeshift covers migrations.

Multi-repo org, needs consistency. Pick ast-grep (structural search-and-replace fast enough to run in CI) and Sourcegraph Batch Changes (turns a codemod into PRs across every repo). One writes the change, the other ships it everywhere.

What you can skip

Babel, if you're not building a plugin. It's a compiler with a refactoring side-quest, not a refactoring tool.
Comby, if your repo is mostly one language. Its edge is cross-language pattern matching.
OpenRewrite and Moderne, if you're not on the JVM. Excellent recipes, wrong ecosystem.
JetBrains ReSharper, if you're not shipping .NET backends. If you are, you already own it.

The real lesson

Tool sprawl is a symptom.

If your team is debating which of 10 refactoring tools to standardize on, the actual problem is that nobody has defined what kinds of changes are worth automating.

Pick a scope, pick a scale, pick two tools. Ship a codemod. Learn what breaks. That's the loop.

If you want the full 10-tool breakdown with when-to-use-each, we wrote it up here.

What's your two-tool stack? Drop it in the comments — curious what people actually settle on.

Why 77% of Your App's Users Are Gone in 3 Days (and the real fix isn't another tactic)

Famitha M A — Mon, 20 Jul 2026 09:19:50 +0000

TL;DR

77% of users who install your app stop using it within 72 hours. Most of that churn happens inside the first session.
2026 cross-industry medians: Day-1 = 26%, Day-7 = 11%, Day-30 = 5.4%. Subscription apps retain ~2.5x better at D30.
The five real churn causes: no "aha moment", ad/product mismatch, no external trigger, crashes/slow loads, and one-and-done intent (which is fine).
The uncomfortable part: you probably already know the tactics. The real bottleneck is that your experiment cycle takes 3 weeks while your cohort churns in 3 days.
Fix the cycle time, not the tactics list.

The number

77% of the users who install your app stop using it within 72 hours. Not a month. Not a week. Three days.

That stat traces back to Andrew Chen's analysis at a16z, and every benchmark report since (Adjust, AppsFlyer, Sensor Tower) lands in the same neighborhood. The 2026 numbers, by vertical:

Vertical	Day 1	Day 7	Day 30
Social & Communication	30%	15%	8%
Gaming (Casual)	27%	10%	4%
Finance & Fintech	33%	18%	12%
Health & Fitness	24%	10%	6%
E-commerce & Retail	22%	8%	4%
Productivity	29%	14%	10%
Subscription Apps (all)	35%	22%	14%
Cross-category median	26%	11%	5.4%

Two things worth noticing: subscription apps retain 2.5x better at Day 30 (paywalls are a commitment device), and fintech beats casual gaming 3x at D30 (utility beats entertainment on retention, almost always).

Make sure you're measuring the same thing as the benchmarks

Retention has three variants, and teams routinely fool themselves by measuring one internally and comparing against another:

Classic — user came back on exactly day N. Punitive, but it's what the benchmarks above use.
Rolling — user came back on day N or later. More forgiving.
Bracket — user came back anywhere in days N–M. Useful for weekly cohorts.

If you want to sanity-check your own numbers, classic Day-N retention is one query away:

-- Classic Day-N retention per install cohort
WITH installs AS (
  SELECT user_id, DATE(install_time) AS cohort_day
  FROM app_installs
),
activity AS (
  SELECT DISTINCT user_id, DATE(event_time) AS active_day
  FROM app_events
)
SELECT
  i.cohort_day,
  COUNT(DISTINCT i.user_id) AS cohort_size,
  COUNT(DISTINCT CASE WHEN a.active_day = i.cohort_day + INTERVAL '1 day'
        THEN i.user_id END) * 100.0 / COUNT(DISTINCT i.user_id) AS d1_retention,
  COUNT(DISTINCT CASE WHEN a.active_day = i.cohort_day + INTERVAL '7 day'
        THEN i.user_id END) * 100.0 / COUNT(DISTINCT i.user_id) AS d7_retention
FROM installs i
LEFT JOIN activity a USING (user_id)
GROUP BY 1
ORDER BY 1;

Segment this by acquisition channel before you conclude anything. A cohort with 15% D7 overall might be 30% from organic and 4% from one bad Facebook creative. That's not a retention problem — that's an ad-relevance problem wearing a retention costume.

Where the 77% actually dies: the first session

The churn isn't spread evenly across 72 hours. Roughly 60–70% of it happens inside the first session. Users don't drift away over three opens — they open once, hit friction, close, never return.

The consistent offenders, with rough measured costs:

Signup wall before showing value: –30-40% of installers on that screen alone
Phone verification: another –15-20%
Push permission prompt on Day 0 (before any value): ~4x lower opt-in vs. asking after value
More than five onboarding screens: ~20% more churn vs. three or fewer

The cheapest fix in mobile is deferring everything. Guest mode instead of a signup wall:

// Instead of gating the app behind auth, persist a local guest identity
import AsyncStorage from '@react-native-async-storage/async-storage';
import { v4 as uuid } from 'uuid';

export async function getOrCreateGuestId() {
  let id = await AsyncStorage.getItem('guest_id');
  if (!id) {
    id = `guest_${uuid()}`;
    await AsyncStorage.setItem('guest_id', id);
  }
  return id;
}

// Later, when the user actually signs up, merge the guest state
export async function upgradeGuestToUser(userId) {
  const guestId = await AsyncStorage.getItem('guest_id');
  if (guestId) {
    await api.mergeAccounts({ from: guestId, to: userId });
    await AsyncStorage.removeItem('guest_id');
  }
}

Same logic for push permissions — ask after the user has experienced value, not on launch:

// Don't request on app open. Trigger contextually, e.g. after first "aha" action
async function requestPushAfterValue(trigger) {
  const alreadyAsked = await AsyncStorage.getItem('push_prompted');
  if (alreadyAsked) return;

  if (trigger === 'first_workout_completed') {
    // Pre-permission soft prompt first — protects your one real OS prompt
    const wants = await showSoftPrompt(
      "Want a reminder before your streak breaks?"
    );
    if (wants) {
      await requestNotificationPermission();
    }
    await AsyncStorage.setItem('push_prompted', 'true');
  }
}

The five real reasons users churn

Skip the twenty-tactic listicles. Churn comes from a small set of root causes:

They never hit the "aha moment." Duolingo: first lesson done. Instagram: first personalized feed. Fintech: first balance after bank link. Users who reach it retain at 3-5x the rate of users who don't. Your entire first session should be a speedrun to that moment.
The ad promised something the app isn't. Invisible in aggregate, obvious when you segment by channel (see the SQL above).
No external trigger. Apps that survive past D7 almost always reach out — a push tied to a real event (someone messaged you, your streak's about to break), not "hi, we miss you." Apps that rely on being remembered lose to apps that reach out.
Crashes and slow screens. Users don't file bug reports; they uninstall. And crashes disproportionately hit your heaviest users, because they hit more code paths.
They got what they came for. One-time intent (check a flight, convert a currency once) isn't a retention failure. Segment churn by intent before you panic.

The part nobody writes: your bottleneck is cycle time, not tactics

Here's the uncomfortable truth: you already knew most of the above. Everyone's read the same posts. Everyone has the Notion doc of retention experiments. So why is the median D30 still 5.4%?

Because most teams can't ship a retention experiment in under three weeks.

Week 1: spec + Figma + design review. Week 2: implementation + new tracking event + QA. Week 3: ship to 20%, wait for the cohort to season, analyze. By the time you know whether the shorter signup form moved D1, the cohort you wanted to save has been gone for two and a half weeks. You're permanently fighting the last war — with eighteen more experiments queued behind this one.

Duolingo runs hundreds of A/B tests a year. Netflix ships micro-experiments continuously. The gap isn't ideas — it's that they ship an experiment in a day and you ship one a month.

This is where tooling actually changed the math. Building in an AI-native stack like RapidNative means the guest-mode experiment above is a prompt — "make signup optional, add continue-as-guest, persist state locally" — with a working build on a real device via QR code in under a minute, instead of a sprint. When iteration cost collapses that far, the strategy flips: you stop hoarding experiments and start running them in parallel.

A weekly experiment cadence that actually compounds

If your iteration cost is low enough, this rhythm works:

Monday AM — pull last week's cohorts, segmented by channel and onboarding variant. Find the biggest first-session drop-off.
Monday PM — one hypothesis, one line: "changing X to Y improves D1 by Z% for cohort A."
Tuesday — build the variant.
Wednesday — ship to 50% of new installs.
Next Monday — cohort's seasoned. Ship the winner or kill it. Next experiment.

That's ~5 experiments a month, 60 a year. Even at a 1-in-5 hit rate you're compounding at a pace nobody on a three-week cycle can touch.

The bottom line

Retention in 2026 isn't a knowledge problem. The benchmarks are public and every founder can recite why users churn. The teams that win are the ones shipping retention experiments faster than their cohorts churn.

Stop asking "which tactic should we prioritize?" Start asking "what's the smallest experiment we can put in front of real users this week?"

What's your team's actual experiment cycle time — days or weeks? And what's the one onboarding change you've been meaning to test forever? Drop it in the comments, I'm curious what's stuck in everyone's backlog. 👇

How to Build a Grocery Delivery App with React Native + Expo (2026)

Famitha M A — Fri, 17 Jul 2026 07:00:25 +0000

How to Build a Grocery Delivery App with React Native + Expo (2026)

If you've ever tried to build an Instacart-style app from scratch, you know the pain: three apps to ship (customer, driver, admin), a real-time tracking layer, payments, dispatch, and the ever-fun "handle a driver going offline mid-delivery."

Here's a practical stack and a build sequence that keeps the moving parts to a minimum.

The three-app reality

A grocery delivery product is three apps sharing one backend:

Customer app — browse, cart, checkout, track
Driver app — accept orders, navigate, capture proof of delivery
Admin dashboard — inventory, dispatch, disputes

Combine them into one and you'll spend the next quarter untangling permission logic. Keep them separate.

The stack that converges

Mobile: React Native + Expo (one codebase, iOS + Android, OTA updates)
Backend: Supabase (Postgres, auth, realtime, RLS)
Payments: Stripe Payment Intents + Stripe Connect for driver payouts
Maps: Google Maps SDK + Directions API + Distance Matrix
Push: Expo Push → Twilio SMS for critical alerts
Realtime: Supabase realtime channels (no custom WebSocket server)

Data model — the parts that matter

-- The critical detail: capture price at purchase time
create table order_items (
  id uuid primary key default gen_random_uuid(),
  order_id uuid references orders(id),
  product_id uuid references products(id),
  quantity int not null,
  price_at_purchase int not null,  -- never join back to products.price_cents
  substitution_preference text check (
    substitution_preference in ('allow','contact','refund')
  )
);

-- Append-only audit log = free source of truth for status timeline
create table order_events (
  id uuid primary key default gen_random_uuid(),
  order_id uuid references orders(id),
  event_type text not null,
  metadata jsonb,
  created_at timestamptz default now()
);

Two invariants worth burning into your brain:

Never resolve order_items.price by joining back to products. Prices change; receipts must not.
Never trust the client's clock for delivered_at. Use now() in Postgres. You will thank yourself the first time a dispute goes to your inbox.

Real-time tracking without pain

Driver side: capture location every 5–15 seconds, back off when stationary.

import * as Location from 'expo-location';
import { supabase } from './supabase';

await Location.startLocationUpdatesAsync('driver-location', {
  accuracy: Location.Accuracy.Balanced,
  timeInterval: 10_000,
  distanceInterval: 30,
  foregroundService: {
    notificationTitle: 'Delivery in progress',
    notificationBody: 'Sharing your location with the customer',
  },
});

Customer side: subscribe to the driver row.

useEffect(() => {
  const channel = supabase
    .channel(`driver:${driverId}`)
    .on('postgres_changes', {
      event: 'UPDATE',
      schema: 'public',
      table: 'drivers',
      filter: `id=eq.${driverId}`,
    }, ({ new: driver }) => {
      setDriverPosition({ lat: driver.current_lat, lng: driver.current_lng });
    })
    .subscribe();
  return () => { channel.unsubscribe(); };
}, [driverId]);

Refresh ETA every 30 seconds via Distance Matrix — not on every location ping, or you'll blow through your rate limit before lunch.

Payments — the substitution problem

Stripe Payment Intents flow:

First order: create a Stripe Customer, attach a SetupIntent to save the card off-session.
Checkout: create a PaymentIntent with confirm: false.
Only confirm after the order is packed. Never authorize before you know items are available.

The substitution policy question you must answer on day one: pre-authorize subtotal × 1.15 to cover swaps (Instacart's approach) or refund the diff (better UX, more work). Either works; pick one and communicate it at checkout.

The screens

Nine screens ship a customer app: Onboarding + Address, Home, Category Listing, Product Detail, Cart, Checkout, Order Tracking, Order History, Profile.

Writing these by hand from scratch is a 6–8 week grind. If you want to skip the JSX, prompts to an AI mobile app builder generate them in an afternoon and export clean React Native you can extend by hand. I've been using RapidNative for this and shipping the boring UI in a day so I can spend the rest of the sprint on dispatch logic.

The subtle bugs to avoid

Client-side timestamps. Always now() in the DB.
Trusting the driver's app to update order status. Use Postgres triggers on order_events to update orders.status atomically.
Reading inventory from products.inventory_count at checkout. Race conditions. Use a serializable transaction or SELECT ... FOR UPDATE.
Rendering the map on every location ping. Debounce marker updates.

Wrap

React Native + Expo + Supabase + Stripe + Google Maps is boring, well-documented, and consolidated for a reason. The wins in this space come from operational density and freshness, not from the tech stack. Ship the MVP, get it in front of ten customers, iterate.

If you want the whole architecture in one place (data model, screen list, prompt sequence), the full walkthrough is on our blog.

Posting instructions for Dev.to:

Best time: Tuesday–Thursday, 8–10 AM ET
Community: Also cross-post to #reactnative and #tutorial Dev.to tags
Engagement: Reply to every comment in the first 24 hours; Dev.to's algorithm weights early engagement
Cover image: Use the Unsplash URL in frontmatter or upload a screenshot of the finished app
After posting: Share in r/reactnative and r/expo with the Dev.to link (Reddit tolerates Dev.to links better than direct-to-marketing links)

7 Lessons Shipping React Native Templates

Famitha M A — Fri, 17 Jul 2026 06:51:33 +0000

Seven React Native templates in one year, all on Expo SDK 54 + Supabase + NativeWind. This is the technical retrospective — seven lessons with code.

The templates

Weather ($49, 5 screens)
Fitness ($89, 12+ screens)
LearnHub ($89, 9 screens)
RideNow ($99, 8 screens)
Food Delivery ($79, 5 screens)
AI Voice Notes ($79, 16+ screens) — Whisper
Chat with PDF ($79, 16+ screens) — RAG

All share one substrate. That's the whole point.

Lesson 1 — Build the substrate before the first template

Weather was our first template. Five screens, no auth, no DB. It didn't need Supabase. We built it against Supabase anyway.

Rationale: template two would need auth, RLS, edge functions, and a marketing page contract. Building that infra for a template that didn't need it looked wasteful for two weeks. It paid for itself by template three.

If you want to build a template business, spend the first sprint on infra you won't use. It's the least glamorous advice I have.

Lesson 2 — API keys never live in the RN bundle

Both AI templates route through Supabase Edge Functions. The customer's OpenAI or Anthropic key sits at the edge. Client calls the function; function holds the key; RLS enforces per-user rate limits.

// Bad: key in the client
const openai = new OpenAI({ apiKey: EXPO_PUBLIC_OPENAI_KEY })

// Good: client calls edge function
const res = await fetch(`${SUPABASE_URL}/functions/v1/ai-chat`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${session.access_token}` },
  body: JSON.stringify({ messages }),
})

EXPO_PUBLIC_* bakes into the bundle. Anyone can strings your .ipa and pull it out. This is not theoretical — it happens weekly to indie apps.

Lesson 3 — One data contract, all templates

Every template's marketing page on our site renders from the same TypeScript interface:

export interface ProductData {
  slug: string
  name: string
  tagline: string
  screenshots: Screenshot[]
  pricing: PricingTier[]
  features: Feature[]
  testimonials: Testimonial[]
  faqs: FAQ[]
  techStack: TechItem[]
}

Sixty-three lines. Every template's config satisfies it. Every marketing component consumes it. Zero forks.

Before this contract, we had five copies of the pricing card. A fix on one wasn't a fix on all. After the contract: one component, one bug fix, seven templates updated.

Lesson 4 — Ship CLAUDE.md, AGENTS.md, .cursorrules

Every template ships with agent-readiness files. Short, opinionated, points to lib/data/types.ts and lists invariants.

Result: support tickets about "the agent broke something in your template" dropped noticeably. Not because agents got smarter — because they had a map.

Structure that works:

# CLAUDE.md
## Invariants
- Do not touch `lib/data/types.ts` — it's the shared contract
- Every new screen goes in `app/(tabs)/`, wired via Expo Router
- Edge functions in `supabase/functions/`, never in the client

## File map
- app/apps/config/*.config.ts — template configs
- app/apps/components/ — shared marketing UI
- app/apps/lib/data/ — data layer

## When adding a feature
1. Update the config type first
2. Then update the config value
3. Then update the UI that reads it

Lesson 5 — Keep the entry price low

Templates range $49–$99. Temptation: raise everything to $99. Support-per-dollar is worse at $49.

Reality: $49 buyers come back for $79–$99 templates. The cheap template is a paid trial. Kill it and the funnel collapses.

Lesson 6 — Docs convert, not screenshots

Analytics: converting buyers spend more time in /docs than on the marketing page. Specifically the "how do I swap the AI provider" sections.

Writing docs first also forces you to design the escape hatch before the feature. If you can't write the "how do I swap this" section, the feature isn't done.

Lesson 7 — Stack review

Would pick again:

Expo SDK 54, RN 0.81 — new arch stable
NativeWind v4 — kills styling drift across templates
Supabase — auth, Postgres, edge, storage, one bill
TanStack Query v5 — replaced Redux everywhere
Expo Router v6 — file-based routing

Would skip:

Zustand for state that TanStack Query handles. Two templates had Zustand stores that were purely query-cache reinventions. Removing them cost more than not adding them.

For year two

Config file exists before any RN code does
Docs written before the feature
CLAUDE.md written during design

Streaming AI Responses to React Native: The Complete Guide

Streaming AI Responses to React Native: The Complete Guide. Build fluid, conversational UIs with SSE, edge functions, & robust client-side rendering.

applighter.com

React Native Supabase Template: Auth, RLS, Storage

How Applighter ships React Native templates with Supabase auth, RLS policies, and Storage already wired — clone, run migrations, build features.

applighter.com

Wiring Designers Into Your EAS Preview Loop

Famitha M A — Wed, 08 Jul 2026 08:15:28 +0000

TL;DR

Figma reviews miss everything that's a function of the real device — touch targets, scroll momentum, keyboard behavior, font substitution, dark-mode transitions.
Wrap eas build --profile designer-preview in a Slack slash command so designers trigger their own preview builds without engineering.
Use an EAS Update designer-preview channel to push JS-only changes to an already-installed build — no reinstall, no rebuild.
Remove three friction points first: the install step, the "which build is this?" question, and the "is this update live yet?" question.
Measure review-loop time, not build time.

Our mobile design reviews used to happen in Figma. Then a build would ship, the designer would see it on their phone a day later, and we'd realize the touch target was 8dp too small or the sheet animation felt wrong on Android. The fix was obvious in hindsight: put designers directly into the EAS preview loop so they see the change on a real device before signing off.

Here's how we wired it up and what actually moved the needle.

Why design reviews on Figma miss real device behavior

Figma reviews catch layout, spacing, and color drift. They miss everything that's a function of the device:

Touch target size and reachability on the specific phone the designer holds every day
Momentum and rubber-banding on real ScrollViews
Keyboard behavior (especially on iOS Safe Area vs Android IME resize)
Actual font rendering — system font substitution differs by OS version
Dark-mode transitions in a real app vs mocked screens

Every one of these has bitten us. And every one of them is invisible until a designer scrolls, taps, and feels the app on their own device.

The one-Slack-command pattern that unblocks designers

The unlock was making it possible for a designer to trigger their own preview build without asking engineering. We wrapped eas build --profile designer-preview --platform ios in a Slack slash command:

/preview branch feat/new-onboarding

The command dispatches a GitHub Action that runs eas build against the named branch, then posts the QR code + install link back into the Slack thread when it completes.

# .github/workflows/designer-preview.yml (excerpt)
name: designer-preview
on:
  workflow_dispatch:
    inputs:
      branch: { required: true }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { ref: ${{ inputs.branch }} }
      - uses: expo/expo-github-action@v8
        with: { expo-version: latest, token: ${{ secrets.EXPO_TOKEN }} }
      - run: eas build --profile designer-preview --platform ios --non-interactive --no-wait

The critical detail: --profile designer-preview in eas.json should be internal distribution, not TestFlight — TestFlight has an approval delay that breaks the loop.

EAS Update channels for designer-only preview builds

Once you have preview builds working, the second unlock is EAS Update for JS-only changes. Configure a designer-preview channel in eas.json:

{
  "build": {
    "designer-preview": {
      "channel": "designer-preview",
      "distribution": "internal",
      "env": { "EXPO_PUBLIC_ENV": "designer" }
    }
  }
}

Any JS/TSX change (which is 80% of what designers care about — spacing, colors, typography, animation curves) can now be pushed to their existing installed build with eas update --channel designer-preview --branch feat/spacing-fix. No new install, no new build. The designer opens the app, pulls to refresh, sees the change.

This compressed our design-iteration loop from ~1 build/day to ~4-6 JS pushes/hour when we're in an active review.

The three friction points to remove before you invite designers

Before rolling this out, remove these:

The install step. Designers should not have to install Expo Dev Client from scratch every time. Ship one Dev Client build a week, keep it stable, and use EAS Update on top of it.
The "which build is this?" question. Add a corner label to your app in the designer env showing the branch name + short commit hash. A useConstants() hook + a semi-transparent Text component is enough:

import { Constants } from 'expo-constants';
const { manifest } = Constants;
// In your root layout:
<Text style={styles.watermark}>
  {manifest?.extra?.branch} · {manifest?.extra?.commit}
</Text>

The "is this update live yet?" question. Show the last-updated timestamp somewhere the designer can find (a debug menu, a settings screen). Nothing kills trust in the loop like reviewing an old version.

Conclusion: measure the review-loop time, not build time

After wiring this up, our design-to-shipped-mobile-build time dropped roughly 40%. But the metric that actually mattered wasn't build time — it was review-loop time: how long between "designer flags a change" and "engineer knows if the fix is right."

Measure that instead of build time and you'll instrument the right optimizations. Faster builds are useful; a designer who can review on-device without waiting for engineering is transformative.

Are you running designers through your EAS loop, or still bouncing builds over Slack manually? Drop a comment with how your review loop works — especially if you've found a cleaner way to handle the "which build is this?" problem.

How to Build a HIPAA-Compliant Healthcare App in React Native (2026 Guide)

Famitha M A — Tue, 30 Jun 2026 13:12:04 +0000

How to Build a HIPAA-Compliant Healthcare App in React Native (2026 Guide)

A single HIPAA violation in 2026 can cost up to $2,190,294. Per violation. Not per incident.

If you're a React Native developer building a telemedicine, patient portal, or health-tracking app that handles Protected Health Information (PHI), this is the technical playbook I wish someone had handed me before I started. Code-first, no hand-waving.

The 60-Second Mental Model

HIPAA applies if you're a covered entity (provider, payer, clearinghouse) or a business associate (vendor processing PHI on their behalf). It splits into three rules:

Privacy Rule → who can see PHI
Security Rule → technical, admin, and physical safeguards on ePHI
Breach Notification Rule → what you do when something goes wrong

The Security Rule is where 90% of your code lives.

Step 1: Tag Your Data Surface Before You Write Code

Open a spreadsheet. Write down every field your app stores, sends, or displays. Tag each one:

Bucket	Example	HIPAA controls
PHI	`patientName`, `dob`, `medicalRecordNumber`	Full controls (encrypt, log, RBAC)
De-identified	Aggregated stats with no identifiers	None required
Non-PHI	UI preferences, app version	Standard hygiene

This exercise also tells you what NOT to send to Sentry, PostHog, Mixpanel, or any non-BAA vendor. A stack trace with a patient's name in a URL parameter is a breach.

Step 2: Lock In a HIPAA-Eligible Stack

You cannot build a compliant app on a non-eligible backend. Decision matrix:

Layer	Pick	Watch out for
Hosting	AWS / GCP / Azure (HIPAA-eligible services only)	Default Vercel & Netlify don't sign BAAs on free tiers
Auth	AWS Cognito, Auth0 Enterprise	Firebase Auth (free tier) won't sign
DB	RDS, Aurora, Firestore Enterprise	Enable encryption-at-rest
Storage	S3 with SSE-KMS	Never use public buckets
Email/SMS	AWS SES, Twilio HIPAA tier	Default Twilio is not covered
LLM	Anthropic, OpenAI API, AWS Bedrock	Consumer ChatGPT is NOT covered
Push	OneSignal HIPAA tier, AWS SNS	Never put PHI in payloads

Rule of thumb: free tiers are almost never HIPAA-eligible. Budget the paid tier from day one.

Step 3: The React Native Patterns That Matter

Encryption at rest

// ✅ Tokens, secrets
import * as SecureStore from 'expo-secure-store';
await SecureStore.setItemAsync('auth_token', token);

// ✅ Large cached data
import { open } from 'react-native-mmkv';
const storage = new MMKV({
  id: 'phi-cache',
  encryptionKey: await getKeyFromKeychain(),
});

// ❌ Never
import AsyncStorage from '@react-native-async-storage/async-storage';
await AsyncStorage.setItem('patient', JSON.stringify(patient)); // plaintext on disk

TLS + cert pinning

import { fetch } from 'react-native-ssl-pinning';

await fetch('https://api.yourapp.com/patients', {
  method: 'GET',
  sslPinning: { certs: ['cert-fingerprint'] },
  headers: { Authorization: `Bearer ${token}` },
});

Background screen lock

import { useEffect, useState } from 'react';
import { AppState, Modal, View } from 'react-native';
import { BlurView } from 'expo-blur';

export function usePrivacyScreen() {
  const [isInactive, setIsInactive] = useState(false);

  useEffect(() => {
    const sub = AppState.addEventListener('change', (state) => {
      setIsInactive(state !== 'active');
    });
    return () => sub.remove();
  }, []);

  return isInactive ? (
    <Modal visible transparent>
      <BlurView intensity={80} style={{ flex: 1 }} />
    </Modal>
  ) : null;
}

PHI doesn't show up in the iOS app switcher.

Session timeout + biometric re-auth

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

const INACTIVITY_LIMIT = 15 * 60 * 1000; // clinician = 15min

async function ensureBiometric() {
  const result = await LocalAuthentication.authenticateAsync({
    promptMessage: 'Confirm to access patient data',
    fallbackLabel: 'Use passcode',
  });
  if (!result.success) throw new Error('Auth failed');
}

Push notifications: no PHI in payloads

// ❌ Breach
{ body: "Dr. Patel: your diabetes follow-up is at 2pm" }

// ✅ Generic notification, fetch detail in-app
{ body: "You have a new appointment" }

Audit logs

Every read, write, login, export. Server-side, immutable, 6-year retention. Minimum schema:

type AuditEntry = {
  timestamp: string;
  actorId: string;
  action: 'view' | 'create' | 'update' | 'delete' | 'export';
  resourceType: string;
  resourceId: string;
  sourceIp: string;
  deviceId: string;
  outcome: 'success' | 'failure';
};

Ship to S3 with Object Lock or CloudWatch with retention policies. The app should have no permission to delete from this log.

Step 4: Where AI App Builders Fit

I work on RapidNative, an AI builder that generates React Native + Expo apps from a prompt. Honest take on what it can and can't do for HIPAA:

Speeds up massively:

Patient flows, intake forms, dashboards, scheduling, chat scaffolds
State management, navigation, RBAC scaffolds
Real-time iteration with a clinical advisor in the loop

Doesn't do (and no AI builder does):

Sign your BAA
Provision your HIPAA-eligible AWS environment
Write your privacy officer's policy
Replace a security audit

It compresses ~8-12 weeks of UI work into days. Your team spends the recovered time on compliance work that actually needs human judgment. Code exports cleanly so you can audit and pen-test it like any hand-written code.

Common Pitfalls That Will Bite You

Storing PHI in AsyncStorage. It's plaintext. Use SecureStore or encrypted MMKV.
Default Sentry without scrubbing PHI. Your stack traces are walking breaches.
Free-tier auth providers. Most don't sign BAAs.
Push notification bodies. They sit unencrypted on Apple/Google servers.
Background screen exposure. Patient names in the app switcher.
Logging request/response bodies on backend. Logs are PHI too.
Using consumer ChatGPT for AI features. Use API tier + BAA, or Anthropic, or Bedrock.

The Checklist

✅	Control
☐	Data tagged: PHI / de-identified / non-PHI
☐	BAAs signed for every PHI-touching vendor
☐	Encryption at rest via SecureStore + encrypted MMKV/SQLite
☐	TLS 1.3 + certificate pinning
☐	MFA + biometric re-auth
☐	15/30-minute session timeouts
☐	Background screen blur
☐	Server-enforced RBAC
☐	Immutable audit log, 6-year retention
☐	PHI-free push notification payloads
☐	Annual risk assessment + penetration test
☐	Documented breach response plan

Try it

If you want to scaffold a healthcare flow in minutes (and then wire it to a compliant backend on your own timeline), give RapidNative a try. Free, no credit card.

Originally published on rapidnative.com/blogs.

Mobile App Analytics for React Native — What to Track, What to Ignore

Russel Dsouza — Wed, 27 May 2026 07:42:39 +0000

Stop tracking 60 events. Pick 6–10. Define your activation event before you write any tracking code. Watch the cohort retention curve, not total installs. One product analytics SDK + one crash tool. Defer attribution until you spend on ads.

Most React Native apps don't die from bad code. They die from invisible problems — users who never finished onboarding, a checkout step that lost half the funnel, a feature nobody opened after week one. You can't fix what you can't see.

The trap is that "set up analytics" gets pushed to next sprint, then the sprint after, then forever. By the time you actually look at your numbers, you've shipped three months of features blind. This post is the minimum viable analytics setup you should have running before you push to TestFlight.

The five questions every mobile app has to answer

AARRR — Acquisition, Activation, Retention, Referral, Revenue. Old framework, still right.

Stage	Question	What you'd actually track
Acquisition	How do users find us?	Installs by channel, CPI
Activation	Did the first session land?	Onboarding complete, first key action
Retention	Do they come back?	D1/D7/D30, DAU/MAU
Referral	Do they bring friends?	Invite rate, viral coefficient
Revenue	Does any of this pay?	ARPU, LTV, conversion to paid

You don't need a metric in every row on day one. You need to know which row is leaking the worst, and you can only know that if you can see all five.

The single most important event: activation

Pick a behavior that strongly correlates with week-two retention. Examples from real apps:

Dropbox: "one file in one folder on two devices"
Facebook (early): "seven friends in ten days"
Fitness app: "logged one workout in first 48h"

Write this down before you write any tracking code:

A user is activated when they ___ within ___ minutes/days of installing.

This is the highest-leverage exercise in your first three months. Get this right and every other product decision becomes legible: does this change move more new users to activation?

Track this in your React Native app

A minimal event schema for any consumer mobile app. Pick a tool (Firebase, Amplitude, Mixpanel, or PostHog — they all have RN/Expo SDKs) and instrument these first:

// events.ts — your single source of truth
export const Events = {
  APP_OPEN: 'app_open',
  SIGN_UP_COMPLETE: 'sign_up_complete',
  ONBOARDING_COMPLETE: 'onboarding_complete',
  ACTIVATION: 'activation',          // your one defined event
  PURCHASE_COMPLETED: 'purchase_completed',
  SHARE_INITIATED: 'share_initiated',
  PUSH_RECEIVED: 'push_received',
  PUSH_OPENED: 'push_opened',
} as const;

export type EventName = typeof Events[keyof typeof Events];

Tracking helper that's tool-agnostic, so you can swap providers without a rewrite:

// analytics.ts
import * as Posthog from 'posthog-react-native';

export const track = (event: EventName, props?: Record<string, unknown>) => {
  if (__DEV__) console.log('[track]', event, props);
  Posthog.capture(event, props);
};

// attach user properties at sign-up
export const identify = (userId: string, traits: Record<string, unknown>) => {
  Posthog.identify(userId, traits);
};

Call sites stay clean and typed:

// in OnboardingScreen.tsx
import { track, Events } from '@/lib/analytics';

const handleComplete = async () => {
  await saveProfile();
  track(Events.ONBOARDING_COMPLETE, {
    flow: 'signup_v2',
    steps_skipped: skippedSteps.length,
  });
  navigation.replace('Home');
};

Three things this does that ad-hoc SDK calls don't:

Snake_case event names enforced via the const object — no Purchase / purchase / purchasedItem drift.
Single switch point for swapping providers — change analytics.ts, every call site keeps working.
DEV logging so you can verify events in the Metro console before they hit production.

User properties (do this once, slice everything forever)

The biggest analytics regret most teams have is not setting user properties on day one. Once they're attached, every event you've ever tracked becomes sliceable by them retroactively.

// on first install
identify(userId, {
  install_source: 'organic',         // or attribution source
  signup_date: new Date().toISOString(),
  platform: Platform.OS,             // 'ios' | 'android'
  app_version: DeviceInfo.getVersion(),
});

// on plan change
identify(userId, { plan: 'pro' });

Now you can ask "what's D7 retention for organic-install Pro users on iOS?" without touching tracking code again.

The chart that matters more than DAU

The single most useful chart in mobile analytics is the cohort retention curve — a triangle where each row is the install week and each column is the percentage of that cohort still active N weeks later.

If the curve flattens around D30, you have something. If it keeps dropping toward zero, you don't — no matter what the install counter says. Most analytics tools (Amplitude, Mixpanel, PostHog) ship this view out of the box; Firebase requires a bit more setup.

Vanity metrics to delete from your dashboard

These always go up, which is exactly why they're useless for decisions:

Total installs
Total registered users
Total screen views without context
Followers on social
Average time in app, isolated

Replace each with a ratio or a cohort:

- Total installs (12,438)
+ 30-day retained users from last month's installs (1,247 / 9,800 = 12.7%)

- Page views (84,221)
+ Screen views per session for activated users (median 14)

- Average session length (4m 12s)
+ % of sessions where activation event fired (38%)

The discipline of converting absolute numbers to ratios is the difference between a dashboard and a decision-making tool.

Day-one stack (don't overthink this)

✅ ONE product analytics SDK   → Firebase | Amplitude | Mixpanel | PostHog
✅ ONE crash tracker            → Sentry (or Crashlytics)
✅ 6–10 events                  → not 60
✅ Snake_case names             → enforced in a const object
✅ User properties attached     → on sign-up + on plan change

⏸️ Attribution (AppsFlyer/Adjust) → defer until you spend on paid acquisition
⏸️ Session replay               → defer until activation rate stabilizes
⏸️ A/B testing platform         → defer until you have a hypothesis worth testing

Stack three analytics tools on launch day and you'll end up with three half-broken instrumentations and zero confidence in the data.

The build–measure–learn loop, for real

The teams that compound are the ones who decided, on day one, which question they were trying to answer — and built the tracking against that question first. They didn't install Mixpanel and then figure out what to track. They figured out the activation event first, then picked the tool, then built the screens.

If you're earlier than that — still figuring out what the app even is — the bigger lever is speed of iteration, not analytics tooling. The faster you can put a build in front of real users and watch what they do, the sooner you'll know what to instrument in the first place. RapidNative generates real React Native + Expo source from a prompt — meaning you ship, instrument with the snippets above, watch what happens, and iterate in hours instead of sprints. The code is yours, so swapping in PostHog or Amplitude is just a normal RN package install.

Quick FAQ

How many events should a new app track?
6–10. Tracking 60 on day one almost guarantees none of them will be reliable.

What's a good D1 retention rate?
Rough rule: 25–40% for consumer apps. The shape of the curve matters more than any single day — does it flatten, or keep falling?

Do I need a paid tool for an MVP?
No. Firebase is free, has solid RN/Expo SDKs, and covers events, funnels, and retention. Most MVPs don't outgrow it until they have meaningful revenue.

Mixpanel vs Amplitude vs PostHog for React Native?
All three have first-class RN SDKs. Amplitude has the strongest cohort UI for product-led growth teams. Mixpanel has mature reports and a generous free tier. PostHog is open-source-friendly and self-hostable if you care about data ownership. Firebase is the free default if integrated with the rest of Google's stack matters more than UI polish.

What are you tracking in your React Native app right now — and which event do you wish you'd instrumented from day one? Drop a comment with your activation event; I'm collecting examples from the indie dev side.

How to Build a HIPAA-Compliant Healthcare App in React Native (2026)

Famitha M A — Wed, 27 May 2026 06:21:14 +0000

How to Build a HIPAA-Compliant Healthcare App in React Native (2026)

I've spent the last few years watching healthcare startups ship apps that wouldn't survive a five-minute OCR audit: plaintext PHI in CloudWatch logs, Firebase pulling double duty as analytics and PHI database, and "we'll add a BAA later" as a roadmap item. So here's the actual developer checklist for shipping a HIPAA-compliant React Native + Expo app in 2026.

First, are you actually on the hook?

HIPAA applies if you are a Covered Entity (provider, plan, clearinghouse) or a Business Associate (vendor processing PHI on behalf of a CE). A consumer wellness app where users self-report data and you have no provider contracts is usually out of scope. The second a clinic signs up, you're in. Get this in writing from a lawyer before you build anything.

The 9 technical safeguards, in code terms

1. Encryption everywhere

TLS 1.3 minimum on the wire. Pin certs with react-native-ssl-pinning.
AES-256 at rest in the DB.
On device: react-native-keychain for credentials, expo-secure-store for tokens. Never AsyncStorage for PHI.

2. Unique auth + MFA

One identity per human. No shared logins.
MFA via TOTP or push (not SMS) for any account touching PHI.

3. RBAC, not "is_admin"

Bake roles into your data model from migration #1. Retrofitting RBAC into a healthcare app is the worst kind of refactor.

4. Immutable audit logs

Every PHI read, write, export, print. Append-only table or log stream. Six-year retention.

5. Auto logoff

15-minute inactivity timeout for providers, configurable per role.

6. Integrity controls

Row-level audit trails or CDC. Be able to prove a chart wasn't tampered with.

7. Transmission security

Push notifications: never put PHI in the body. The notification can say "New message," not "Lab result: positive."

8. Device controls

MDM integration for shared/clinic devices. Remote wipe.

9. Risk analysis

A document. Annual. OCR audits start here. NIST SP 800-66 is the template.

The stack that actually has BAAs

The single biggest compliance lever is vendor selection. Every component touching PHI needs a BAA.

Layer	What works	What to avoid
Cloud	AWS, GCP, Azure	Anything that won't sign a BAA
DB	RDS, Supabase Team+, Aiven	Firebase Firestore (no BAA)
Auth	Cognito, Auth0 Enterprise, Stytch	Free tiers
Analytics	Heap, Amplitude Enterprise, self-hosted PostHog	Google Analytics, Firebase Analytics
Error monitoring	Sentry Business+	Free Sentry
AI	Anthropic (BAA), Bedrock, Azure OpenAI	OpenAI free/standard
Email	Paubox, AWS SES + BAA	Mailchimp, SendGrid free
Video	Daily.co, Twilio Video, Zoom Healthcare	Vanilla Zoom

If a vendor won't sign a BAA, they don't see PHI. Maintain two analytics streams: a PHI-free one for general behavior and a fully BAA-covered one for anything PHI-adjacent.

React Native specifics

Use EAS Update for OTA security patches — critical for incident response when the App Store review queue is 3 days deep.
react-native-encrypted-storage for any local PHI cache.
Scrub PHI from Sentry breadcrumbs with beforeSend.
Disable screenshots on PHI screens via react-native-prevent-screenshot or FLAG_SECURE on Android.
Biometric unlock for patient apps is fine; providers should re-auth more aggressively.

Where AI app builders fit (and don't)

The patient-facing UI — onboarding, intake forms, appointment screens, messaging — has zero compliance value on its own. It's pixels. The compliance value lives in the backend (where PHI is stored, accessed, audited).

So a sane workflow:

Generate the React Native UI fast with a tool like RapidNative (exportable Expo code).
Wire it to your own BAA-covered backend (RDS + Cognito + KMS + audit logging).
The builder never sees PHI; you own the deployed code and the data layer.

This is the same logical split as using Figma for design or Storybook for components.

A realistic timeline

Weeks 0–2: legal scoping, BAAs, initial risk analysis
Weeks 2–4: backend architecture with RBAC + audit logging from day one
Weeks 4–12: feature build (this is where AI builders compress UI work the most)
Weeks 12–16: penetration test, training, BAA paperwork with launch customers
Ongoing: quarterly access reviews, annual risk analysis, incident response drills

Budget for an MVP: $70k–$250k all-in, with 15–25% compliance overhead vs. a comparable non-HIPAA app.

TL;DR

Confirm you're actually in scope.
BAAs before code.
RBAC and audit logging from migration #1.
Encrypt in transit (TLS 1.3) and at rest (AES-256). No PHI in logs.
Two analytics streams: PHI-free and BAA-covered.
Use AI builders for UI scaffolding (no compliance value), hand-build the backend (all the compliance value).
Annual risk analysis. Document everything.

What's your stack looking like? Drop a comment with what you're building — especially curious how others are handling the analytics split and PHI scrubbing in Sentry.

DEV Community: RapidNative

The Complete Guide to Offline Storage in React Native (2026)

The five categories of RN offline storage

Comparison table

The offline-first pattern

Conflict resolution

Decision cheat sheet

Pitfalls to skip

Wrap-up

5 Places Sensitive Data Leaks in a React Native App (and How to Plug Them)

1. AsyncStorage for anything sensitive

2. Real user data in design prototypes

3. Multi-stage AI workflows

4. Logs and crash reports

5. Bundled permissions

The pattern

You Don't Need 10 Refactoring Tools. Pick 2 From This Decision Tree.

The 3 questions

The 2-tool stacks

What you can skip

The real lesson

Why 77% of Your App's Users Are Gone in 3 Days (and the real fix isn't another tactic)

The number

Make sure you're measuring the same thing as the benchmarks

Where the 77% actually dies: the first session

The five real reasons users churn

The part nobody writes: your bottleneck is cycle time, not tactics

A weekly experiment cadence that actually compounds

The bottom line

How to Build a Grocery Delivery App with React Native + Expo (2026)

How to Build a Grocery Delivery App with React Native + Expo (2026)

The three-app reality

The stack that converges

Data model — the parts that matter

Real-time tracking without pain

Payments — the substitution problem

The screens

The subtle bugs to avoid

Wrap

7 Lessons Shipping React Native Templates

The templates

Lesson 1 — Build the substrate before the first template

Lesson 2 — API keys never live in the RN bundle

Lesson 3 — One data contract, all templates

Lesson 4 — Ship CLAUDE.md, AGENTS.md, .cursorrules

Lesson 5 — Keep the entry price low

Lesson 6 — Docs convert, not screenshots

Lesson 7 — Stack review

For year two

Related

Streaming AI Responses to React Native: The Complete Guide

React Native Supabase Template: Auth, RLS, Storage

Wiring Designers Into Your EAS Preview Loop

Why design reviews on Figma miss real device behavior

The one-Slack-command pattern that unblocks designers

EAS Update channels for designer-only preview builds

The three friction points to remove before you invite designers

Conclusion: measure the review-loop time, not build time

How to Build a HIPAA-Compliant Healthcare App in React Native (2026 Guide)

How to Build a HIPAA-Compliant Healthcare App in React Native (2026 Guide)

The 60-Second Mental Model

Step 1: Tag Your Data Surface Before You Write Code

Step 2: Lock In a HIPAA-Eligible Stack

Step 3: The React Native Patterns That Matter

Encryption at rest

TLS + cert pinning

Background screen lock

Session timeout + biometric re-auth

Push notifications: no PHI in payloads

Audit logs

Step 4: Where AI App Builders Fit

Common Pitfalls That Will Bite You

The Checklist

Try it

Mobile App Analytics for React Native — What to Track, What to Ignore

The five questions every mobile app has to answer

The single most important event: activation

Track this in your React Native app

User properties (do this once, slice everything forever)

The chart that matters more than DAU