DEV Community: Famitha M A

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

Mobile App Launch Checklist — 25 Things to Verify Before You Hit Publish

Famitha M A — Fri, 15 May 2026 13:13:32 +0000

Mobile App Launch Checklist: 25 Things to Verify Before You Hit Publish

You're staring at the "Submit for Review" button. The icon looks right. Screens feel good on your phone. But something is nagging at you.

That feeling is usually accurate. Most apps don't get rejected for bad code — they get rejected for a missing privacy disclosure, a wrong-resolution screenshot, or a forgotten test build that just trapped your brand-new Google Play account in a 14-day waiting period.

Here are 25 items I run before every submission, grouped into five categories. Save the post, print the list, then hit publish.

Reality check before you start

Apple averages 24–48 hours review in 2026 for repeat developers. Google Play, 1–3 hours. First-time submission from a brand-new dev account? 7–14 days. Always add a 2-week buffer between target launch and first submission to handle one rejection cycle.

A. Build & Bundle (1–5)

Sign a production build — iOS .ipa from your distribution profile; Android .aab (the old .apk is no longer accepted for new apps). On Expo, use EAS Build. On bare RN, generate a keystore and back it up to two locations — losing it kills your ability to update.
Increment version + build numbers — Each upload must bump CFBundleVersion / versionCode. A lower number is the #1 silent rejection.
Test on at least 5 device classes — Old iPhone, current iPhone, budget Android, mid-range Android, tablet. Simulators lie about gestures, network, and performance.
Strip dev code — console.log, hidden gesture menus, hardcoded test users, __DEV__ branches. App Store reviewers actively search for "test" or "demo" strings.
Wire up crash reporting — Sentry, Crashlytics, Bugsnag. Force a crash in a production build and verify it lands in your dashboard before you submit.

B. App Store Metadata (6–10)

Lock app name + subtitle — iOS: 30 + 30 chars. Google Play: 50 + 80 chars. Apple weighs the name field higher than anything else.
Write a real long description — Lead with the value prop. Google Play shows first 80 chars on the card; iOS shows ~170 chars before the "more" tap. Don't waste those characters.
Pick primary + secondary category — Most specific honest fit, not most popular.
Honest age/content rating — Self-assessment for both stores. Lying about UGC or unfiltered web views is the most common second-round rejection.
ASO keyword strategy — iOS keyword field is 100 chars, comma-separated, never duplicate words from your name. Score keywords by relevance × volume ÷ difficulty. Place top 40 only.

C. Visual Assets (11–15)

App icon 1024×1024 PNG, no alpha — Test it at 60×60. If it's unreadable, the icon needs work.
Required screenshot sizes —
- iOS: 6.7-inch (1290×2796), 6.5-inch (1242×2688), iPad 12.9-inch if supported.
- Android: phone (1080×1920 or 1080×2340), 7" and 10" tablets.
- Frame each with a one-line value prop. Bare UI shots convert 20–40% worse.
App preview video (15–30s) — Silent by default on iOS. Show the outcome in the first 3 seconds, not the onboarding flow.
Splash screen = first screen — Apple's guidance. Never gate it on a network call.
Google Play feature graphic (1024×500 PNG) — No iOS equivalent. A blank one screams "amateur."

D. Privacy, Legal & Account (16–20)

Public privacy + support URLs — Must load from anywhere, no auth wall. Use /privacy and /support.
iOS Privacy Nutrition Label — Declare every data type, including what your third-party SDKs collect. Apple maintains an SDK list of trackers needing disclosure.
Google Play Data Safety form — Mismatches with your real SDK behavior are caught silently weeks after launch. App gets unlisted.
ATT prompt (if you use IDFA) — Apple reviews your pre-permission "context primer." Generic copy like "Tap Allow" gets rejected. Explain why the user benefits.
Closed test before production — iOS: 50–200 TestFlight testers, 5–7 days. Android personal accounts: 12 testers, 14 continuous days. This rule traps every solo founder. Plan 3 weeks, not 3 days. (Docs.)

E. Launch Day & Post-Launch (21–25)

Release strategy — Manual (iOS) vs. automatic, plus phased rollout (iOS) or staged rollout (Android). Always phased for first release: 1% → 5% → 20% → 100% over a week.
Analytics + remote-config kill switch — Mixpanel/Amplitude/PostHog/Firebase. Ship a remote flag that disables a broken feature without resubmitting. First time you use it you'll wonder why you didn't always.
Real release notes — "Bug fixes and performance improvements" is malpractice. Three honest bullets. Users actually read these.
Day-one comms — Product Hunt (Tue/Wed), LinkedIn post, X thread, demo video, email to pre-signups, Show HN if technical. Plan it before you submit, because approval arrives at 3 a.m.
Review-reply + crash-triage rotation — Reply to every 1-star within 24h (other users read your reply). Daily 5-min crash triage in Sentry/Crashlytics for two weeks. Keep crash-free rate above 99.5%.

Where an AI app builder compresses the list

Items 1, 4, 11, and 14 — production-clean code, signed bundles, framed visuals, splash screens — are the unglamorous infrastructure that consumes the last two weeks of a launch. If you generated your React Native + Expo app with RapidNative, the codebase ships clean by default (no leftover logs, no debug UI), and EAS Build picks it up first try.

Items 16–20 (privacy + legal) and 21–25 (launch plan) are still on you. Always will be.

TL;DR

Print the 25 items. Run them top-to-bottom. Two-week buffer between target launch and submission. Phased rollout for v1. Reply to every 1-star review. Ship it.

What's the one item that bit you on a previous launch? Drop it in the comments — I'd bet it's #2 or #17.

Build a Fitness Wearable Companion App with React Native (HealthKit + Health Connect)

Famitha M A — Thu, 14 May 2026 07:42:19 +0000

You bought a smartwatch. Within a week, you stopped checking the watch face. The dashboard, the streaks, the weekly chart — all of that lives on the phone.

That phone app is called a companion app, and it's the most underrated piece of any fitness wearable product. The watch captures. The phone interprets, stores, and visualizes.

This post is a code-first walkthrough of how to build one in React Native. We'll cover the architecture, HealthKit (iOS), Health Connect (Android), an optional Apple Watch bridge, and the sync model that doesn't fall over in production.

TL;DR for the impatient:

Read from HealthKit on iOS and Health Connect on Android — you cover 90% of wearables without writing firmware.
Use react-native-health and react-native-health-connect.
Make your backend POST /samples idempotent on the HealthKit UUID. This single rule prevents most sync bugs.
The dashboard UI is the time sink, not the integration. Plan accordingly.

The Architecture (Internalize This Before Writing Code)

[Wearable] → [OS Health Store] → [React Native bridge]
   → [Local DB (SQLite / WatermelonDB)]
   → [Sync queue] → [Backend]
   → [Other devices / Web dashboard]

Three things to internalize:

The OS health store is the source of truth for samples, not your app. If the user reinstalls, HealthKit still has the data. Your local DB is a cache for fast UI plus a write buffer for user-generated samples.
Reads are one-directional, writes are bidirectional. Reads pull from HealthKit/Health Connect. Writes hit both the OS store and your backend.
Background delivery is a constraint, not a feature. iOS will throttle aggressively. Design as if your app wakes every 15–30 minutes, not every second.

Pick Your Wearable Target First

The biggest mistake I see: shipping for "wearables" generically. Each platform has a different data model and review hurdle.

Wearable	Data path	Library	Watch-side code?
Apple Watch	HealthKit	`react-native-health`	Only for watchOS UI
Pixel / Galaxy Watch	Health Connect	`react-native-health-connect`	Only for Wear OS tile
Fitbit	Health Connect / Web API	`react-native-health-connect` + OAuth	No
Garmin	Garmin Health API	OAuth + REST	Optional (Connect IQ)
Whoop / Oura / Polar	Vendor REST APIs	OAuth + REST	No
Custom BLE hardware	Direct BLE	`react-native-ble-plx`	N/A

For most consumer apps, start with HealthKit + Health Connect. They cover every major retail wearable, the user already trusts the permission dialog, and you skip juggling six OAuth flows. Vendor SDKs are a v2 problem.

Step 1 — Scaffold the Expo Project

You need a custom dev client since both health libraries are native modules.

npx create-expo-app fitness-companion --template
cd fitness-companion
npx expo install expo-dev-client
npm install react-native-health react-native-health-connect
npx expo prebuild

In app.json:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSHealthShareUsageDescription": "Read your activity to power your dashboard.",
        "NSHealthUpdateUsageDescription": "Save workouts you log in the app."
      },
      "entitlements": {
        "com.apple.developer.healthkit": true
      }
    },
    "android": {
      "permissions": [
        "android.permission.health.READ_STEPS",
        "android.permission.health.READ_HEART_RATE",
        "android.permission.health.READ_SLEEP",
        "android.permission.health.READ_EXERCISE"
      ]
    }
  }
}

Step 2 — Read Health Data on iOS (HealthKit)

import AppleHealthKit, { HealthKitPermissions } from 'react-native-health';

const permissions: HealthKitPermissions = {
  permissions: {
    read: [
      AppleHealthKit.Constants.Permissions.Steps,
      AppleHealthKit.Constants.Permissions.HeartRate,
      AppleHealthKit.Constants.Permissions.SleepAnalysis,
      AppleHealthKit.Constants.Permissions.Workout,
      AppleHealthKit.Constants.Permissions.ActiveEnergyBurned,
    ],
    write: [AppleHealthKit.Constants.Permissions.Workout],
  },
};

AppleHealthKit.initHealthKit(permissions, (err) => {
  if (err) console.error('HealthKit init failed', err);
});

Fetch today's step count:

const startOfDay = new Date();
startOfDay.setHours(0, 0, 0, 0);

AppleHealthKit.getStepCount(
  { date: startOfDay.toISOString() },
  (err, results) => {
    if (err) return;
    setSteps(results.value);
  }
);

Three production gotchas

Aggregated queries can double-count. If the user has both an Apple Watch and a third-party app writing steps, the default aggregate may count both. Use getSamples with explicit source filtering when accuracy matters.
iOS won't tell you if read permission was denied. getStepCount just silently returns zero. Render an empty state, not an error.
enableBackgroundDelivery needs HKObserverQuery. Budget half a day to wire it up properly the first time.

Step 3 — Read Health Data on Android (Health Connect)

Health Connect replaced the Google Fit dev API in 2025. Pixel Watch and Galaxy Watch already write to it.

import {
  initialize,
  requestPermission,
  readRecords,
} from 'react-native-health-connect';

await initialize();

await requestPermission([
  { accessType: 'read', recordType: 'Steps' },
  { accessType: 'read', recordType: 'HeartRate' },
  { accessType: 'read', recordType: 'SleepSession' },
  { accessType: 'read', recordType: 'ExerciseSession' },
]);

const result = await readRecords('Steps', {
  timeRangeFilter: {
    operator: 'between',
    startTime: startOfDay.toISOString(),
    endTime: new Date().toISOString(),
  },
});

const totalSteps = result.records.reduce((sum, r) => sum + r.count, 0);

Health Connect's permission UX is cleaner than HealthKit's (one consolidated screen), but you can only read the past 30 days unless the user explicitly grants extended history access.

Step 4 — Apple Watch Bridge (Optional)

If you want a watchOS app — say, a quick-start workout button — you need a watchOS target in Xcode bridged to RN via WCSession. The watch app itself is Swift (RN doesn't run on watchOS).

Minimal Swift bridge:

class WatchBridge: NSObject, WCSessionDelegate, RCTBridgeModule {
  static func moduleName() -> String! { "WatchBridge" }

  func session(_ session: WCSession,
               didReceiveMessage message: [String : Any]) {
    if let event = message["event"] as? String, event == "workoutSample" {
      RCTBridge.current()?.eventDispatcher().sendAppEvent(
        withName: "WatchWorkoutSample", body: message
      )
    }
  }
}

On the RN side, subscribe with NativeEventEmitter and update your store. A reasonable v1 scope: start/end workout from the watch face, with samples flowing back live. Anything more (full watch UI, complications) is multi-week work.

For Wear OS, the equivalent is the Data Layer API with MessageClient. Same pattern: native module, JS bridge, event emitter.

Step 5 — The Dashboard UI (Where Time Actually Goes)

Data flows. Now you need the actual app. Standard companion-app screens:

Today — steps, heart-rate ring, active calories, latest workout
Trends — weekly/monthly bar charts
Workouts — list of ExerciseSession / Workout records with detail view
Goals — editable daily targets, local + synced
Settings — permissions, units, connected devices

Stack I'd recommend:

Charts: victory-native (maintained, gesture support, works on both platforms). Skip react-native-svg-charts — unmaintained.
List: virtualize aggressively. Users routinely have thousands of historical workouts.
State: Zustand or Redux Toolkit. Avoid Context for high-frequency updates from health observers.

Honest aside: this is the part of the build that's the least interesting and the most time-consuming. The integration code lands in week one. The dashboard eats the next two-to-three weeks if you write every screen by hand.

The third time I built one of these, I described the spec in plain English to an AI mobile app builder and got a full Expo project — components, navigation, theming — in under an hour, then plugged my HealthKit hooks into it. The tool I used was RapidNative, which generates real React Native + Expo code (not a proprietary runtime — you own the output). Worth a look if the dashboard is the part you'd rather not write by hand.

Step 6 — Sync, Offline, Conflicts

The pattern that survives production:

Local-first writes. WatermelonDB or expo-sqlite. Every user-logged workout → local DB → HealthKit/Health Connect → upload queue.
Pull-based reads from the health store. On app open and on background fetch (~30 min cadence on iOS), pull deltas since last_sync_timestamp, dedupe by UUID, upsert.
Idempotent uploads. Every HealthKit sample has a stable UUID. Make POST /samples a no-op on duplicate UUIDs:

// Backend pseudocode
async function ingestSample(sample) {
  await db.samples.upsert({
    where: { healthkit_uuid: sample.uuid },
    update: { value: sample.value, modified_at: sample.endDate },
    create: { ...sample, healthkit_uuid: sample.uuid },
  });
}

This single rule prevents 90% of the sync bugs that haunt fitness apps.

No cellular uploads by default. Gate behind a setting. Battery-sensitive users uninstall fast.

Edge case that bites everyone: a user edits a workout in the Apple Health app. HealthKit emits an "updated" sample with the same UUID but a new modification date. Your sync code must handle this — most don't, which is why so many fitness apps quietly drift out of sync.

Realistic Timeline

For a single full-stack dev who's shipped React Native before:

Phase	Time
Setup, permissions, HealthKit + Health Connect reads	3–5 days
Dashboard UI (5 screens, charts, theming)	5–8 days
Local DB + backend sync	4–6 days
Apple Watch companion (basic workout start/stop)	5–7 days
Polish + App Store review prep	5–10 days
v1 ship	3–5 weeks

The dashboard phase is the easiest to compress because it has nothing to do with wearables. Scaffolding it with an AI tool can take that week down to a day.

App Store Gotchas That Kill Submissions

PrivacyInfo.xcprivacy is mandatory for any iOS app touching HealthKit (since 2024). Missing it = auto-reject.
HealthKit data cannot be used for advertising or sold. Period.
Health Connect requires a published privacy policy URL in your Play Store listing.
You cannot transmit another user's HealthKit data. "Share with a friend" features need each recipient's own HealthKit permission grants.

FAQ

Can I use Expo for this?
Yes, with a custom dev client. npx expo prebuild then eas build --profile development. Expo Go won't work because of the native modules.

Do I have to ship a watchOS app to support Apple Watch?
No. The watch already writes to HealthKit. Read from HealthKit and you support every Apple Watch user without writing Swift. A watchOS app is only for on-wrist UI.

Google Fit vs Health Connect?
Health Connect replaced Google Fit's dev API in 2025. New apps should use react-native-health-connect.

Can React Native do live heart-rate streaming?
Not via HealthKit (samples arrive on a delay). For real-time streams, either a watchOS app over WCSession or a direct BLE connection via react-native-ble-plx.

Wrap-up

The integration work — HealthKit, Health Connect, WCSession — is irreducible. You write it yourself. The UI on top is boilerplate you've seen in fifty other apps, and it's where most of the calendar disappears.

Start with the system health stores. Make your sync endpoint idempotent. Don't ship a watchOS app until you've validated the phone experience.

If this was useful, drop a comment with what you're building — happy to dig into specific edge cases (sleep data is a rabbit hole, ask me how I know).

Cover photo by Onur Binay on Unsplash.

The Complete Guide to React Native Debugging in 2026

Famitha M A — Tue, 12 May 2026 06:56:39 +0000

The Complete Guide to React Native Debugging in 2026

If you learned React Native debugging before 2025, almost everything you knew is now obsolete. Flipper is dead. The remote JS debugger is gone. And as of React Conf 2025, the New Architecture is no longer optional — it's the only architecture.

This post is what I actually use to debug React Native in 2026, after migrating a handful of older codebases and starting new ones.

TL;DR — the 2026 stack

JS debugging: React Native DevTools (press j in Metro). It's built in.
State / storage: Reactotron (Redux, Zustand, MMKV).
Native: Xcode or Android Studio directly. No middleware.
Production: Sentry / Bugsnag / Crashlytics with source maps.

Four tools. Clear jobs. Compare to the 2022 chaos of Flipper plugins + standalone React Native Debugger + Chrome DevTools + Reactotron and you'll appreciate the simplification.

React Native DevTools, the new default

Ships built-in with RN 0.76+. In the Metro terminal, press j. A Chrome window attaches to your Hermes runtime through the Chrome DevTools Protocol. No Bridge, no proxy.

Five panels matter:

Console — logs, warnings, React component stack traces.
Sources — breakpoints, step-through, source map support.
Network — first-class HTTP inspection (added in RN 0.83).
Performance — flame graphs, JS thread timings, commit phases (RN 0.83).
React Components / Profiler — same panels you know from web.

What it doesn't do: native module inspection (use Xcode/Android Studio) and live UI editing of native views.

Source maps in production

The single most underrated debugging setup. Without them, every production crash looks like 0xb73f4: anonymous (index.android.bundle:1:284731).

For Sentry, one command does the wiring:

npx @sentry/wizard@latest -i reactNative -p ios android

It adds a build phase to Xcode and a Gradle task to Android that uploads source maps on every release build. Skip this and debugging production-only crashes becomes punishment.

Reactotron for state

React Native DevTools doesn't know what Redux is. Reactotron does.

Install the desktop app, add reactotron-react-native + your state plugin, wire it up in a dev-only config file, and you get:

Live timeline of every Redux/Zustand action with diffs
MMKV and AsyncStorage inspection
Custom commands fireable from the Reactotron UI ("log in as test user")
Image overlay mode for designer-developer handoff

Infinite Red kept this alive after Flipper died. Still actively maintained in 2026.

Native debugging without middleware

When the bug isn't in JS, you need native tools.

iOS: open ios/YourApp.xcworkspace in Xcode. Run from Xcode (not Metro). Native breakpoints, NSLog output, Instruments, View Hierarchy Debugger.

Android: open android/ in Android Studio. Logcat filtered by your package name + the Layout Inspector. The Layout Inspector is critical for Fabric layout bugs that look fine in React DevTools but render wrong on device.

A 2026 rule of thumb: if a bug reproduces in __DEV__ but disappears in release builds, it's almost always a native module config issue. Skip React Native DevTools, go straight to Xcode/Android Studio.

Performance profiling in the New Architecture

The Bridge is gone. JSI exposes native objects as JS references. Fabric renders synchronously where it can. Turbo Modules load lazily.

What changes for debugging:

"Too many bridge calls" is no longer a thing.
Frame drops have clearer causes: slow JS commit (React Profiler) or native module blocking UI thread (Performance flame graphs).
Bridgeless mode is the default in every new project.

Profile flow: DevTools → Performance → Record → interact → stop. Hunt for:

JS tasks over 50ms (hot paths — useMemo, useCallback, React.memo)
Frequent re-renders (use Profiler's "Highlight updates")
Heavy commits on navigation (usually useEffect-on-mount doing too much)

Common bugs → right tool

Symptom	First tool
Red screen JS error	DevTools → Console
1-3 second freeze	DevTools → Performance
200 response but no UI update	Network + Reactotron
Production-only crash	Sentry → Issues
Android layout broken, iOS fine	Android Studio Layout Inspector
Image not loading	Xcode/Android Studio console
"Unable to resolve module"	`npx react-native start --reset-cache`

"Works on simulator, broken on device"

Three buckets:

Permissions — simulator auto-grants, device doesn't. Check Info.plist / AndroidManifest.xml.
localhost — on device, localhost is the device. Use LAN IP or ngrok.
Signing / bundle ID — release builds hit signing rules dev builds don't.

Final notes

The 2026 React Native debugging stack is the leanest it has been in years. One built-in debugger, one state inspector, native tools when you need them, a crash reporter for production.

If you start a new project, you only need to install Reactotron and your crash reporter SDK — everything else ships by default. And if you're using an AI builder that outputs Expo apps (full disclosure: I work on RapidNative, an AI mobile app builder), every tool above works on the exported code without modification — there's no proprietary runtime to learn.

What's in your 2026 React Native debugging stack? Curious what people are using for production observability.

React Native i18n: A Practical Guide to Multi-Language Mobile Apps

Famitha M A — Fri, 08 May 2026 10:12:05 +0000

React Native i18n: A Practical Guide to Multi-Language Mobile Apps

Most i18n bugs in React Native apps trace back to two decisions made early: hardcoding strings, and using string concatenation to build sentences. Both feel fine when you're shipping in English. Both are catastrophic the day you add a second locale.

This is the practical playbook I wish I had when I first added Spanish, Japanese, and Arabic to a React Native app: which library to pick, the patterns that scale, and the traps that only show up in production.

TL;DR

Use i18next + react-i18next + expo-localization (or react-native-localize on bare RN).
Never hardcode strings, never concatenate to build sentences.
Use ICU pluralization — count === 1 ? 'a' : 'b' is wrong in most languages.
Plan for RTL from day one with marginStart/marginEnd instead of left/right.
Use namespaces (auth.json, home.json) once you cross ~500 keys.
Format dates/numbers/currencies with the Intl API.
Hook up a translation management service (Crowdin, Lokalise, Locize) before you ship to a third locale.

Why i18n Is an Architectural Decision

Retrofitting translations into a codebase that hardcodes strings everywhere is one of the most painful refactors in mobile development. For a 50-screen app, expect 1-3 weeks of dedicated work to extract strings, set up a translation library, and validate every screen.

The discipline of always using t('home.welcome') instead of "Welcome" from day one means you never have a "what strings did we miss?" problem when you add a second language. It also doubles as a code review smell test.

Picking a Library

Library	Best For	Bundle Size
`i18next` + `react-i18next`	Most apps	~50KB
`react-intl` (FormatJS)	ICU MessageFormat purists	~80KB
LinguiJS	Type-safe, compile-time extraction	~20KB

For 95% of React Native projects, default to i18next unless you have a specific reason not to.

Minimal Setup (Expo)

// i18n.js
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import * as Localization from 'expo-localization';
import en from './locales/en/common.json';
import es from './locales/es/common.json';

i18n
  .use(initReactI18next)
  .init({
    resources: {
      en: { common: en },
      es: { common: es },
    },
    lng: Localization.locale.split('-')[0],
    fallbackLng: 'en',
    defaultNS: 'common',
    interpolation: { escapeValue: false },
    compatibilityJSON: 'v3',
  });

export default i18n;

// App.js
import './i18n';
import { useTranslation } from 'react-i18next';

export default function App() {
  const { t } = useTranslation();
  return <Text>{t('greeting', { name: 'Maria' })}</Text>;
}

7 Patterns That Scale

1. Use interpolation, not concatenation

// Bad
t('hello') + ' ' + user.name + '!'

// Good
t('greeting', { name: user.name })
// en.json: { "greeting": "Hello, {{name}}!" }
// ja.json: { "greeting": "{{name}}さん、こんにちは!" }

2. Use ICU pluralization

English has 2 plural forms, Russian has 3, Arabic has 6. Don't roll your own.

{
  "items_one": "{{count}} item",
  "items_other": "{{count}} items"
}

3. Plan for RTL from day one

Use marginStart/marginEnd instead of left/right.
Mirror directional icons: transform: [{ scaleX: I18nManager.isRTL ? -1 : 1 }].
Switching between LTR/RTL requires an app restart — design your language switcher UX accordingly.

4. Namespace your translations

locales/en/
├── common.json
├── auth.json
├── home.json
└── errors.json

Lazy-load namespaces per screen to reduce startup load on lower-end Android.

5. Format with the Intl API

new Intl.DateTimeFormat(i18n.language, { dateStyle: 'long' }).format(date);
new Intl.NumberFormat(i18n.language, { style: 'currency', currency: 'USD' }).format(amount);

Hermes supports Intl natively as of RN 0.71+. If you're older, use the formatjs polyfill — but upgrade Hermes if you can.

6. Set up a translation pipeline

Hook your locales/ folder to Crowdin, Lokalise, or Locize before you ship to a third language. CI should fail the build on missing keys in production locales.

7. Test with pseudo-localization

Use a "fake locale" that wraps every string in brackets and adds 30% length. Catches truncation, hardcoded strings, and layout breakage before real translators see anything.

How RapidNative Handles This

RapidNative is an AI app builder that generates React Native + Expo code from natural-language prompts. The generated components use translation keys (t('auth.sign_in_button')) instead of hardcoded strings, and the translation JSON is scaffolded alongside the code — so adding a new locale is dropping in a translated JSON file, not refactoring imports.

If you're starting a new project and don't want to build the i18n scaffolding by hand, that's a faster path to "i18n-ready by default."

Wrapping Up

Multi-language support gets dramatically more expensive over time. Build it in from day one — translation keys, ICU plurals, RTL-aware layouts, real translation pipeline — and your app can ship to any market without a future refactor.

What pattern do you wish you'd known earlier? Drop it in the comments — always curious how other teams handle the RTL transition specifically.

How to Add Payment Processing to Your React Native App in 2026

Famitha M A — Thu, 07 May 2026 11:15:16 +0000

How to Add Payment Processing to Your React Native App in 2026

Adding payments to a React Native app sounds simple until you realize there's no single "right way." If you sell physical goods, Stripe is the answer. If you sell digital content consumed inside your app, Apple and Google require their own billing APIs and they take up to 30%. Mix the two and you'll either pay double fees or get rejected during App Store review.

This is the practical guide I wish I'd had the first time. We'll cover the decision tree, set up @stripe/stripe-react-native, add Apple Pay and Google Pay, handle subscriptions with react-native-iap or RevenueCat, build a minimal backend, and test it all without spending a dollar.

The Decision Tree

You sell...	Use this	Fee
Physical goods	Stripe / Braintree	~2.9% + $0.30
Real-world services (rides, etc.)	Stripe / Braintree	~2.9% + $0.30
Digital subscriptions	Apple IAP / Google Play Billing	15–30%
One-time digital unlocks	Apple IAP / Google Play Billing	15–30%

Apple's Guideline 3.1.1 is the source of truth here. Don't skip it.

Step 1: Install the Stripe SDK

npm install @stripe/stripe-react-native
cd ios && pod install

Expo SDK 50+ works via the config plugin. You need a development build — Expo Go can't run native payment modules.

Step 2: Wrap Your App in StripeProvider

import { StripeProvider } from '@stripe/stripe-react-native';

export default function App() {
  return (
    <StripeProvider
      publishableKey={process.env.EXPO_PUBLIC_STRIPE_PUBLISHABLE_KEY!}
      merchantIdentifier="merchant.com.yourapp"
      urlScheme="yourapp"
    >
      <RootNavigator />
    </StripeProvider>
  );
}

Only the publishable key (pk_...) goes in the client. Your secret key never touches the bundle.

Step 3: Create a PaymentIntent on Your Backend

app.post('/payments/create-intent', async (req, res) => {
  const intent = await stripe.paymentIntents.create({
    amount: req.body.amount,
    currency: req.body.currency,
    automatic_payment_methods: { enabled: true },
  });
  res.json({ clientSecret: intent.client_secret });
});

You can't create PaymentIntents from the client. Stripe blocks it because it would let an attacker manipulate the amount.

Step 4: Present PaymentSheet

const { initPaymentSheet, presentPaymentSheet } = useStripe();

async function checkout() {
  const { clientSecret } = await api.createIntent({ amount: 1999 });

  await initPaymentSheet({
    merchantDisplayName: 'Your Store',
    paymentIntentClientSecret: clientSecret,
    applePay: { merchantCountryCode: 'US' },
    googlePay: { merchantCountryCode: 'US', testEnv: true },
  });

  const { error } = await presentPaymentSheet();
  if (!error) showReceipt();
}

PaymentSheet picks the right local methods automatically — cards in the US, iDEAL in the Netherlands, BLIK in Poland. You don't build any of that.

Apple Pay & Google Pay

Both flow through Stripe, they're not separate gateways. To enable Apple Pay:

Create a Merchant ID in the Apple Developer portal.
Generate the processing certificate from Stripe's dashboard.
Add the Apple Pay capability in Xcode.
Pass merchantIdentifier to StripeProvider.

Google Pay is one config flag plus an AndroidManifest.xml meta-data tag. Conversion lifts 20–30% on iOS when Apple Pay is offered.

Subscriptions: react-native-iap or RevenueCat?

For digital content, you have to use Apple/Google IAP. Two practical paths:

react-native-iap (free, DIY backend):

import { initConnection, requestPurchase, finishTransaction } from 'react-native-iap';

await initConnection();
const purchase = await requestPurchase({ sku: 'pro_monthly' });
// validate receipt on your backend, then:
await finishTransaction({ purchase, isConsumable: false });

RevenueCat (free under ~$2.5K MTR, then 1% — handles all the receipt validation, entitlement, and analytics):

import Purchases from 'react-native-purchases';

await Purchases.configure({ apiKey: 'your_key' });
const offerings = await Purchases.getOfferings();
const { customerInfo } = await Purchases.purchasePackage(
  offerings.current.monthly
);
const isPro = customerInfo.entitlements.active['pro'] !== undefined;

Rule of thumb: if you ship subscriptions and don't have a payments engineer, use RevenueCat. The hours you save on receipt validation, server-to-server notifications, and cross-platform entitlement state will pay for it in week one.

Testing Without Real Money

Stripe test cards I use most:

4242 4242 4242 4242 — success
4000 0027 6000 3184 — 3D Secure challenge
4000 0000 0000 9995 — declined (insufficient funds)
4000 0000 0000 0341 — fails on charge

Apple sandbox subscriptions renew at accelerated cadence (1 month = 5 minutes, up to 6 cycles). You can verify your renewal logic in an afternoon.

Pre-Ship Checklist

[ ] Successful card charge end-to-end
[ ] 3D Secure / SCA challenge completes
[ ] Apple Pay / Google Pay works
[ ] IAP purchase + restore + refund tested
[ ] Webhook idempotency (duplicate events don't double-grant)
[ ] Subscription cancellation eventually revokes access
[ ] Network drop mid-purchase doesn't lose the receipt

Common Pitfalls

PCI scope creep — stay in SAQ A by always using PaymentSheet. The moment you build a custom card form, the audit burden explodes.
SCA failures in Europe — let Stripe pick payment methods automatically; custom flows often skip the 3DS challenge.
Idempotency keys — pass one on every server write. Retries that create duplicate intents charge the user twice.
Currency mismatch — store currency next to amount. 1999 is not the same revenue in USD vs JPY.

Wrapping Up

Payments will always require thoughtful backend and compliance work. But the React Native scaffolding around them — paywalls, settings screens, restore-purchase flows — is repetitive plumbing.

If you want to skip the boilerplate, RapidNative generates production-ready React Native + Expo code from a sentence. Describe your paywall, iterate visually, drop in your Stripe and RevenueCat keys, and ship.

What's your stack — Stripe + RevenueCat? Pure react-native-iap? Curious what's working in 2026.

DEV Community: Famitha M A

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

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

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

First, are you actually on the hook?

The 9 technical safeguards, in code terms

The stack that actually has BAAs

React Native specifics

Where AI app builders fit (and don't)

A realistic timeline

TL;DR

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

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

TL;DR

2026 Benchmarks

Zustand: The Pragmatic Default

Redux Toolkit: Still Right for Big Teams

Jotai: Atomic State

The React Native–Specific Bits

Decision Framework

Patterns That Beat the Default

FAQ

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

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

The four screens you actually need

The stack

The map screen is where MVPs die

The listings feed

Property detail screen

Search: don't roll your own

The AI shortcut

Pitfalls

Wrapping up

Mobile App Launch Checklist — 25 Things to Verify Before You Hit Publish

Mobile App Launch Checklist: 25 Things to Verify Before You Hit Publish

Reality check before you start