DEV Community: Famitha M A

The Design System of a Trustworthy React Native Checkout Screen

Famitha M A — Thu, 20 Aug 2026 09:59:52 +0000

TL;DR

Checkout is the most emotionally loaded screen in your app. Design it like it.
Five zones: header, amount, line items, payment method, sticky Pay button.
Two type sizes. Not three. Not five.
No custom fonts on this screen. They delay the render of the total.
Never green on the Pay button. Never red outside errors.
The three states everyone skips: loading, error, success. Specs below.

Most React Native checkout screens I audit are functional and forgettable. A stack of <View> and <Text> in the app's default theme. The user taps through and either succeeds or bounces.

But this is where the user hands you money. Every pixel choice either builds trust or leaks it.

Here's the whole system, with code.

The five zones

┌─────────────────────────────┐
│  ← Back        Order summary │  Zone 1: Header (32pt height)
├─────────────────────────────┤
│                             │
│  Total                      │
│  $42.87 USD                 │  Zone 2: Amount (dominant type)
│                             │
├─────────────────────────────┤
│  Item 1              $30    │
│  Item 2              $10    │  Zone 3: Line items (collapsed)
│  Tax                 $2.87  │
├─────────────────────────────┤
│                             │
│  [ Apple Pay ]              │  Zone 4: Payment method
│  [ Card ending 4242 ]       │
│  [ + Add payment method ]   │
│                             │
├─────────────────────────────┤
│  [    Pay $42.87 USD    ]   │  Zone 5: Pay button (sticky)
└─────────────────────────────┘

Zone 5 stays sticky above the keyboard. Zone 2 collapses when the keyboard opens so the Pay button never leaves the viewport.

<KeyboardAvoidingView
  behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
  style={{ flex: 1 }}
>
  <ScrollView contentContainerStyle={{ flexGrow: 1 }}>
    <AmountBlock total={total} currency={currency} compact={keyboardVisible} />
    <LineItems items={items} />
    <PaymentMethods methods={methods} onSelect={setMethod} />
  </ScrollView>
  <PayButton total={total} currency={currency} onPress={handlePay} />
</KeyboardAvoidingView>

Typography: two sizes, that's it

export const type = {
  amount: {
    fontSize: 32,
    fontWeight: '600' as const,
    letterSpacing: -0.5,
  },
  body: {
    fontSize: 15,
    fontWeight: '400' as const,
  },
};

Platform system font only. SF Pro Display on iOS, Roboto on Android. Skip expo-font entirely on this screen. Custom font loading is real work on a cold boot, and anything that delays the render of the total is worth cutting. If you want a number for your own app, profile it instead of trusting a blog post.

Color tokens

import { PlatformColor, Platform } from 'react-native';

export const color = {
  background: Platform.select({
    ios: PlatformColor('systemBackground'),
    android: '#FFFFFF',
  }),
  text: Platform.select({
    ios: PlatformColor('label'),
    android: '#111111',
  }),
  // Brand primary only if it clears 4.5:1 on white. Otherwise black.
  payButton: contrastRatio(brandPrimary, '#FFFFFF') >= 4.5 ? brandPrimary : '#000000',
  errorBg: '#FFF4F4',
  errorText: '#B00020',
};

Never use red for anything except errors. Never use green on the Pay button. Users associate green with "Buy" but not with "you're about to spend money," which is a subtle difference that still shows up in testing.

The three states everyone forgets

Loading. Swap the label, disable the button, and escalate the copy on a timer. An indeterminate spinner alone reads as a frozen app.

function usePayingLabel(processing: boolean) {
  const [elapsed, setElapsed] = useState(0);

  useEffect(() => {
    if (!processing) return setElapsed(0);
    const id = setInterval(() => setElapsed((e) => e + 1), 1000);
    return () => clearInterval(id);
  }, [processing]);

  if (!processing) return null;
  if (elapsed >= 8) return 'This is taking longer than usual, please wait.';
  if (elapsed >= 2) return 'Contacting your bank...';
  return null; // button label already says "Processing..."
}

Error. Full-width bar above the Pay button. One human sentence, one recovery action. Never the raw API code.

{error && (
  <View style={{ backgroundColor: color.errorBg, padding: 12 }}>
    <Text style={{ color: color.errorText, fontSize: 15 }}>
      Your card was declined by your bank.
    </Text>
    <Pressable onPress={resetToPaymentMethod}>
      <Text style={{ color: color.errorText, fontWeight: '600' }}>Try again</Text>
    </Pressable>
  </View>
)}

Success. Full-screen replacement: large checkmark, order ID, amount, timestamp, email receipt button. Hold 3 seconds minimum before any auto-dismiss so the user feels the transaction land.

The two components that carry the screen

// Pay button
<Pressable
  style={{
    height: 52,
    borderRadius: 12,
    backgroundColor: color.payButton,
    justifyContent: 'center',
    alignItems: 'center',
    marginHorizontal: 16,
  }}
  onPress={handlePay}
  disabled={!ready || processing}
>
  <Text style={{ color: 'white', fontSize: 17, fontWeight: '600' }}>
    {processing ? 'Processing...' : `Pay ${formatCurrency(total, currency)}`}
  </Text>
</Pressable>

// Amount block
<View style={{ paddingHorizontal: 16, paddingVertical: 24 }}>
  <Text style={{ fontSize: 13, color: subtle, marginBottom: 4 }}>Total</Text>
  <Text style={type.amount}>
    {formatCurrency(total, currency)}{' '}
    <Text style={{ fontSize: 13, color: subtle }}>{currency}</Text>
  </Text>
</View>

Note the 24pt of vertical padding above the total and the 16pt horizontal margin on the button. Those are the two anchor values on the 8pt grid. Density signals cheapness. Whitespace signals trust.

If you're scaffolding a fresh app rather than retrofitting one, RapidNative generates the screen structure and theme tokens up front, so you're wiring Stripe on day one instead of rebuilding the amount block by hand again.

Ship it in a sprint

Day 1: Audit the current checkout against the five zones. Find what's missing.
Day 2: Rebuild the amount zone and the Pay button. Do these first, they carry most of the perceived trust.
Day 3: Build the three states.
Day 4: Test with five people. Watch where they pause.
Day 5: Ship.

The rest is plumbing to Stripe or Razorpay.

What does your checkout look like right now? Drop a comment with the ugliest part of yours and I'll tell you which zone it belongs to.

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.

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.

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.

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.

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.

Zustand vs Redux vs Jotai: React Native State Management in 2026

Famitha M A — Tue, 19 May 2026 14:02:18 +0000

Zustand vs Redux vs Jotai: React Native State Management in 2026

Pick the wrong state library for React Native in 2026 and you'll pay in cold-start time on a $150 Android, re-renders that drop your list from 60fps, and a long tail of useEffect bugs. Three libraries cover ~95% of production apps today: Zustand, Redux Toolkit, and Jotai. Here's how they actually compare on mobile.

TL;DR

Use Zustand for most new React Native apps (1.2KB, no boilerplate, perfect Hermes compat)
Use Redux Toolkit for 10+ engineer teams or compliance-heavy apps
Use Jotai when you have hundreds of independent UI pieces (forms, canvases)

The modern default is Zustand + TanStack Query — Zustand for UI state, TanStack Query for server state.

2026 Benchmarks

Library	Bundle gzipped	Weekly downloads	Memory (1000 components)	Parse time
Zustand	1.2 KB	14.2M	2.1 MB	8 ms
Jotai	2.1 KB	~5.4M	1.8 MB	9 ms
RTK + react-redux	13.8 KB	9.8M	3.2 MB	34 ms

Zustand crossed Redux Toolkit in weekly downloads in 2025. On a Samsung Galaxy A14, RTK's parse cost shows up as visible TTI regression.

Zustand: The Pragmatic Default

import { create } from 'zustand';

export const useCart = create<CartStore>((set) => ({
  items: [],
  addItem: (item) => set((state) => ({ items: [...state.items, item] })),
}));

No provider, no reducer, no dispatch. Selectors are what make it fast — components only re-render when their selected slice changes.

For React Native specifically: persistence is one line with AsyncStorage or MMKV:

import { persist, createJSONStorage } from 'zustand/middleware';
import AsyncStorage from '@react-native-async-storage/async-storage';

export const useCart = create(persist<CartStore>(
  (set) => ({ /* ... */ }),
  { name: 'cart', storage: createJSONStorage(() => AsyncStorage) }
));

Swap to react-native-mmkv (5-10× faster) by changing one line.

Redux Toolkit: Still Right for Big Teams

import { createSlice, configureStore } from '@reduxjs/toolkit';

const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [] as Item[] },
  reducers: {
    addItem: (state, action) => { state.items.push(action.payload); },
  },
});

export const store = configureStore({ reducer: { cart: cartSlice.reducer } });

When to use it:

10+ engineers — predictable structure stops merge chaos
Time-travel debugging matters (fintech, complex forms)
You need RTK Query for cache normalization

When not to: solo dev, MVP, or anywhere bundle size matters. The 13.8KB cost is real on RN.

Jotai: Atomic State

import { atom, useAtom } from 'jotai';

const itemsAtom = atom<Item[]>([]);
const totalAtom = atom((get) => get(itemsAtom).reduce((s, i) => s + i.price, 0));

The Total component only re-renders when totalAtom's value changes. The dependency graph is implicit in get.

Use Jotai for:

Form-heavy screens (each input = one atom = surgical re-renders)
Visual editors / canvases
Anywhere "many small reactive pieces" describes your UI

Skip it for global app settings or simple stores — Zustand's mental model is easier for those.

The React Native–Specific Bits

Hermes compatibility: All three work. Redux Toolkit's Immer relies on Proxy, which was historically slower on Hermes; that gap has closed but heavy nested updates are still measurably slower.

New Architecture (Fabric/JSI): No library breaks. Lower-overhead libraries (Zustand, Jotai) see proportionally bigger wins from Fabric's synchronous layout.

Persistence:

Zustand: persist middleware, one line, async non-blocking
Redux: redux-persist (3rd party, maintenance backlog) or manual
Jotai: atomWithStorage per atom

Cold start on low-end Android: Saving 25ms parse time by picking Zustand over RTK isn't dramatic, but on a screen that already feels slow it shows.

Decision Framework

Solo / MVP / <10 engineers → Zustand
Form-heavy or canvas-heavy → Jotai
10+ engineers or compliance → Redux Toolkit
Mostly fetching server data → Zustand + TanStack Query
Unsure → Zustand (easy to migrate later)

Patterns That Beat the Default

Zustand + TanStack Query — UI state in Zustand, server state in TanStack. ~90% of modern RN apps.
Jotai atoms + Zustand for settings — atoms for forms/canvases, Zustand slice for theme/auth/locale.
Redux Toolkit + RTK Query for everything — if you're going Redux, go all in. Half-and-half duplicates logic.

FAQ

Is Zustand better than Redux for React Native? For most apps in 2026, yes. 12× smaller, no provider, perfect Hermes compat. Redux Toolkit still wins for large teams or strict auditing.

Does Jotai work with React Native? Yes. Zero React Native–specific dependencies. Runs on Hermes, JSC, and Expo. atomWithStorage handles AsyncStorage.

Should I use Redux for a new RN app? Only if you already know it deeply, your team is large, or you need RTK Query's cache. Otherwise Zustand is the default.

If you're scaffolding a new React Native app and want the state layer wired up automatically, RapidNative ships Zustand + AsyncStorage + TanStack Query out of the box. Production-ready Expo code, exportable, no boilerplate.

What state library do you ship in production? Drop it in the comments — I'm curious how the split is looking on bigger teams in 2026.

How to Build a Property Listing App Like Zillow with React Native

Famitha M A — Mon, 18 May 2026 07:36:09 +0000

How to Build a Property Listing App Like Zillow with React Native

Zillow's mobile apps serve ~220M monthly unique users and show 157 homes per second. Behind that scale is a surprisingly small core: four screens, one map, one search index. Here's how to build the same thing in React Native + Expo — once the manual way, and once with AI doing the boilerplate.

The four screens you actually need

Strip Zillow down to its load-bearing parts:

Listings feed — paginated FlatList of property cards
Map view — react-native-maps with price-bubble markers
Property detail — photo carousel + agent contact CTA
Saved + profile — favorites synced to auth

Everything else (mortgage origination, 3D tours, AR staging) is post-PMF.

The stack

npx create-expo-app@latest zillow-clone
npx expo install react-native-maps expo-location expo-router expo-image

Pair with Supabase for auth/data and Algolia for search. That's the modern default for React Native real estate apps in 2026.

The map screen is where MVPs die

react-native-maps is easy. Making it survive 1,000+ markers on a mid-range Android device is the actual engineering work. Three patterns that hold up:

Cluster at low zoom (react-native-maps-super-cluster or H3 grids)
Price bubbles, not pins — users want prices, not red drops
Debounce onRegionChangeComplete by 300-400ms before refetching

<MapView onRegionChangeComplete={debouncedFetch}>
  {listings.map((l) => (
    <Marker
      key={l.id}
      coordinate={{ latitude: l.latitude, longitude: l.longitude }}
    >
      <PriceBubble price={l.price} />
    </Marker>
  ))}
</MapView>

Without debouncing, every pan fires a query storm and your Supabase logs cry.

The listings feed

FlatList, not ScrollView. Set initialNumToRender={6} and windowSize={5}. Use expo-image instead of the default Image — it gives you caching, blur placeholders, and WebP for free. Property listings average 25-40 photos; the default Image component will hate you for it.

Property detail screen

app/listing/[id].tsx with Expo Router. Dynamic routes give you shareable URLs which matter later for deep links from push notifications ("Price drop on 123 Main St!").

Structure: photo carousel → price + facts → sticky "Contact agent" → description → amenities → mortgage estimate → similar listings. Lazy-load everything below the photo gallery.

Search: don't roll your own

The temptation is to write ILIKE queries on Postgres for filters. It works until you have ~5,000 listings, then latency explodes. Wire up Algolia or Typesense before you cross 1,000 records.

The AI shortcut

If 3-6 weeks of scaffolding sounds painful, RapidNative scaffolds all four screens, the map, and the navigation tree from a prompt:

Build a property listing app like Zillow. Listings feed with photo, price, beds/baths cards. Map tab with price-bubble markers. Detail screen with photo carousel and contact agent button. Saved homes and profile tabs.

You watch it render in live preview, point-and-edit anything you don't like, scan a QR code to test on your real phone, then export the full React Native + Expo project. It's not a runtime — it's actual code you own.

Pitfalls

Don't scrape MLS data. Use IDX/RETS agreements or licensed aggregators (Bridge, Realtyna, Estated).
Don't ship without expo-image. Default Image perf on listings with 30+ photos is brutal on Android.
Don't write search yourself. Algolia free tier handles 10K records before you pay a dollar.

Wrapping up

The Zillow surface area is intimidating; the Zillow core is four screens. Start with the scaffolding — manually or with AI — and earn the right to add the fancy stuff once users actually retain.

Full template + code: RapidNative Real Estate starter

DEV Community: Famitha M A

The Design System of a Trustworthy React Native Checkout Screen

TL;DR

The five zones

Typography: two sizes, that's it

Color tokens

The three states everyone forgets

The two components that carry the screen

Ship it in a sprint

How AI Is Making Mobile Accessibility Easier Than Ever

TL;DR

Why mobile a11y is harder than the web

Shift 1: the OS started covering for you

Shift 2: audits got cheap

Shift 3: the missing content is now generated

Shift 4: fix it at generation time

What AI still can't do

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

Where this goes next

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

The four generations, briefly

Why mobile lagged the web

What "full app creation" actually produces in 2026

The four unlocks that made 2026 different

Checklist: is a tool actually Generation 4?

What this means for developers

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

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