DEV Community: Famitha M A

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.

React Native Testing in 2026: Jest, Detox, and Maestro Compared

Famitha M A — Wed, 06 May 2026 13:58:39 +0000

The React Native testing consensus has fractured. For years it was "Jest for units, Detox for E2E, that's the answer." In 2026, Maestro has crossed 10,000 GitHub stars, Detox holds at 11,800, and most production teams now run a layered combination of all three.

Here's a practical, opinionated breakdown of when to use each — based on actually shipping React Native apps, not just reading the docs.

The TL;DR

Tool	What it's for	Setup time	Flakiness
Jest	Unit + component tests	Built-in	<0.1%
Detox	Gray-box E2E with native synchronization	1-3 days	<2%
Maestro	Black-box E2E with YAML	15 minutes	<1%

If you only read this far: start with Jest + Maestro. Add Detox only when you feel the specific pain it solves.

Jest: the layer everyone keeps

Jest plus React Native Testing Library is the universally accepted baseline. Jest 30 (late 2025) brought meaningful performance improvements, and RNTL 12.x now plays nicely with the New Architecture.

Use it for:

Pure logic (reducers, hooks, utils)
Component render tests with testID and accessibility queries
Mocking native modules without touching a simulator

The ceiling is anything involving the actual rendering pipeline, real native modules, or multi-screen flows.

Detox: powerful, but you'll feel the setup

Detox's superpower is gray-box synchronization — it hooks into your app's internals and waits for the JavaScript thread, network calls, animations, and timers to genuinely idle before firing the next action. That's how Wix runs thousands of Detox tests with sub-2% flakiness.

The catch:

# What setting up Detox actually involves
1. Install detox CLI + detox-cli global
2. Add detox config to package.json (testRunner, apps, devices, configurations)
3. Create separate Detox build for iOS (Podfile, AppDelegate patches)
4. Same for Android (build.gradle changes)
5. Wire up Jest-based test runner with Detox globals
6. Configure CI with macOS for iOS + Android emulator hardware accel

Worth it for native-heavy apps with a dedicated platform team. Painful for two-person teams.

Maestro: the tool indie devs keep choosing

A complete login E2E test in Maestro:

appId: com.mycompany.myapp
---
- launchApp
- tapOn: "Email"
- inputText: "test@example.com"
- tapOn: "Password"
- inputText: "supersecret"
- tapOn: "Log in"
- assertVisible: "Welcome back"

That's the entire file. One CLI install, point at your built app, maestro test login.yaml. Done.

Why teams are picking it up:

Cross-platform by default — same YAML runs on iOS and Android
Built-in flakiness tolerance (auto-retries, waits for content)
Maestro Studio for record-and-playback
Maestro Cloud for parallel real-device runs

The trade-off: it's not a great fit for "verify this specific selector returns the right value when the network is offline." That's still Jest's job.

A practical 2026 stack

Jest                  → every commit, runs in seconds
React Native TL       → component tests for happy + worst-case paths
Maestro               → every PR, covers your top 5-15 user flows
Detox (optional)      → nightly or pre-release, native-heavy flows only

Most mobile teams should ignore the classic 70/20/10 testing pyramid. UI bugs are what users actually see. A 50/20/30 split usually serves better.

The new wrinkle: testing AI-generated apps

A category that didn't exist three years ago: testing React Native code your team didn't write. Tools like RapidNative generate full Expo apps from a prompt or screenshot. The code is real and exportable, but you didn't internalize the structure as you went.

Maestro is a near-perfect fit here. Because the tests are written from the user's perspective ("tap Login, type email, assert Welcome back"), they don't depend on the internal implementation of components you didn't write yourself. You can write a robust smoke test in 5 minutes via Maestro Studio.

Workflow that works:

Export the project, run npm install && npx expo start
Write one Maestro test for the most critical user flow
After the next AI-driven iteration, re-run Maestro — anything that breaks is a real regression
Layer Jest tests on the parts you start modifying by hand

How to actually decide

Solo or small team, JS-heavy app → Jest + Maestro
Large team, native modules, custom animations → Jest + Detox
Both? Critical-path safety net + broad smoke coverage → All three
Testing an AI-generated app you'll iterate on → Jest + Maestro, lean on Maestro Studio

The teams I see struggle most are the ones that pick Detox because it sounds serious, then never finish the setup. A working Maestro suite catching 80% of regressions beats a half-configured Detox setup catching none.

If you're spending more time configuring testing than writing tests, that's a signal — pick the lighter tool, ship, then upgrade when you feel real pain.

What's your current React Native testing stack? Curious how many people have made the Detox → Maestro switch.

Posting instructions for Dev.to:

Best time: Tuesday or Wednesday, 8-10 AM EST (peak Dev.to traffic)
Tags: reactnative, testing, mobile, javascript (Dev.to allows max 4)
Set canonical_url in frontmatter to RapidNative blog URL (do not skip — this protects SEO)
Engage in comments within the first 4 hours; Dev.to weighs early engagement heavily for the homepage
Don't add the schema markup recommendations here — Dev.to handles its own structured data

Mobile App Security Best Practices Every Developer Should Know in 2026

Famitha M A — Thu, 30 Apr 2026 11:48:28 +0000

A single hardcoded API key. A forgotten debug log. A token cached in AsyncStorage instead of the keychain. Any one of these — in an app that took six months to build — can hand an attacker the keys to your users' data on day one of launch.

Mobile is now the dominant attack surface. Industry analysts project mobile-targeted attacks will grow more than 40% by the end of 2026, driven by the explosion of fintech, health, and AI-assistant apps that hold sensitive data on-device. And yet the gap between "we shipped" and "we shipped securely" has never been wider, especially for teams using AI app builders, no-code tools, or React Native templates that abstract the underlying platform away.

This guide is a pragmatic walkthrough of the mobile app security best practices that actually move the needle — ordered roughly by impact-per-hour-of-work, grounded in the OWASP Mobile Application Security Verification Standard (MASVS), and written specifically with React Native and Expo developers in mind.

Photo by FLY:D on Unsplash

What are mobile app security best practices? (40-second answer)

Mobile app security best practices are the controls that protect a mobile app's code, data, and users from theft, tampering, and impersonation. The essential set covers eight areas: secure authentication and session management, encrypted storage of sensitive data, TLS plus optional certificate pinning for traffic, hardened API access with short-lived tokens, no secrets in client code, code obfuscation and tamper detection for high-risk apps, dependency hygiene, and a mobile-specific threat model aligned with the OWASP MASVS framework.

That's the short version. Below is what each one actually looks like in code.

The 2026 Mobile Threat Model in One Picture

Before any checklist, you need a mental model of what you're defending against. A useful simplification: every mobile attack lives in one of four buckets.

Attack surface	What attackers do	Who's most at risk
The device	Extract data from local storage, abuse a stolen unlocked phone, exploit jailbroken/rooted OS	Banking, health, enterprise
The network	Man-in-the-middle, downgrade TLS, intercept tokens on public Wi-Fi	Any app with auth or payments
The app binary	Reverse-engineer the IPA/APK, pull hardcoded secrets, repackage with malicious code	Any app distributing on app stores
The backend	Hit your API directly, abuse misconfigured endpoints, replay old tokens	Every app — your client is not your perimeter

If you can name your top two threats from this table for your product, the rest of this article tells you what to build. If you can't, that's the very first task — the OWASP MASVS gives you a structured way to do it in an afternoon.

1. Authentication and Session Management

Most real-world mobile breaches don't happen because cryptography failed — they happen because authentication failed. Solve this first.

Use a battle-tested identity provider, not your own auth

Roll-your-own auth is one of the few decisions that reliably ages badly. Use Auth0, Clerk, Supabase Auth, Firebase Auth, or AWS Cognito. They handle password hashing, rate limiting, breach detection, and JWKS rotation — all the boring parts that get exploited when DIYed.

Make MFA the default, not the upsell

In 2026, multi-factor authentication is table stakes — not a premium feature. Offer at minimum:

TOTP (Google Authenticator, 1Password, Authy) — universal, free, phishing-resistant when paired with passkeys
Biometric step-up (expo-local-authentication) — Face ID / Touch ID for re-auth on sensitive actions
Passkeys / WebAuthn — the modern default, supported on iOS 16+ and Android 9+

For React Native, expo-local-authentication wraps both platforms in one API and falls back gracefully when biometrics aren't enrolled.

Treat tokens like cash

Access tokens: short-lived (15 minutes is a sane default), JWT, signed with RS256 or EdDSA — never HS256 with a shared secret.
Refresh tokens: longer-lived but rotated on every use with reuse detection. If a refresh token is ever submitted twice, revoke the entire session family.
Logout must invalidate server-side, not just clear the client. A token sitting in memory after logout is still valid until expiry.

Photo by Jonas Leupe on Unsplash

2. Secure Storage: Don't Put Tokens in AsyncStorage

This is the single most common React Native security mistake. AsyncStorage is a glorified key-value file in your app's sandbox. It's not encrypted on iOS by default and is trivially readable on a jailbroken or rooted device.

For anything sensitive — auth tokens, refresh tokens, encryption keys, PII — use the platform keystore.

Use expo-secure-store (or react-native-keychain)

expo-secure-store wraps the right primitive on each platform:

iOS: stores values in the iOS Keychain as kSecClassGenericPassword, encrypted by the Secure Enclave and bound to your bundle ID.
Android: uses Android Keystore-backed encrypted SharedPreferences. Hardware-backed (TEE / StrongBox) when available.

The API is intentionally tiny:

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

await SecureStore.setItemAsync('refreshToken', token, {
  keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  requireAuthentication: true, // Face ID / Touch ID gate
});

const token = await SecureStore.getItemAsync('refreshToken');

What goes where

Data type	Storage	Why
Auth tokens, encryption keys	`expo-secure-store` / Keychain	Hardware-backed, OS-protected
User preferences, theme	`AsyncStorage`	Non-sensitive, fine
Cached API responses (PII)	Encrypted SQLite (e.g., `op-sqlite`)	Encrypt at rest with a Keychain-derived key
Files (images, documents)	App sandbox + file-level encryption	iOS Data Protection class `NSFileProtectionComplete`

Encrypt sensitive databases

If you cache PII offline — messages, health records, financial data — use SQLCipher or op-sqlite with an encryption key generated and stored in Secure Storage. Never hardcode the database key in source.

3. Data in Transit: TLS, HTTPS, and Certificate Pinning

HTTPS everywhere, no exceptions

Both iOS App Transport Security (ATS) and Android Network Security Config now enforce HTTPS by default. Resist the urge to disable them for "convenience" during development. If you genuinely need cleartext for local dev, scope the exception to a single domain and never ship that config to release builds. React Native's official security docs cover the platform-specific config files.

TLS 1.3, AES-256, and modern cipher suites

You don't usually pick these directly — your platform networking stack does — but you should verify:

TLS 1.3 with TLS 1.2 fallback only
HSTS on your APIs
Forward secrecy via ECDHE
Modern AES-GCM or ChaCha20-Poly1305 cipher suites

Run your endpoint through SSL Labs once a quarter. A score below A is a bug.

Certificate pinning for high-risk apps

Certificate pinning ensures your app only trusts your server's certificate (or its issuing CA), even if a malicious root is installed on the device. In React Native, react-native-ssl-public-key-pinning is the standard library — it pins the public-key hash, which is more rotation-friendly than pinning the leaf cert.

Honest take: pinning has a real maintenance cost. Pins must rotate before your TLS cert does, or you'll brick every installed app. For most consumer apps, enforced HTTPS plus HSTS is enough. Pin if you're handling money, health data, or auth tokens for high-value accounts. And always ship pinning behind an over-the-air update mechanism (expo-updates) so you can rotate without an app-store release.

Photo by Markus Spiske on Unsplash

4. API and Backend Security

Your client is not your perimeter. Every input from the mobile app must be revalidated server-side, every authorization decision made server-side, and every secret kept server-side.

Never put secrets in the bundle

Anything bundled into your IPA or APK is publicly readable. Stripe secret keys, OpenAI keys, Twilio tokens, AWS credentials — all of these belong in your backend, behind your authenticated API. The mobile app calls your server, your server calls the third party.

A scary number of teams break this rule because they're moving fast or because an AI builder wired up the integration wrong. Audit your .env files, your Constants.expoConfig.extra payload, and any process.env.* references in client code before every release.

Use OAuth 2.0 with PKCE

If you call third-party APIs on behalf of the user, use OAuth 2.0 with PKCE. PKCE was designed precisely for native apps that can't keep a client secret. expo-auth-session implements it correctly.

Rate-limit and shape traffic at the edge

Your API will be hit directly — not just from your app. Cloudflare, AWS WAF, or your API gateway should enforce:

Per-IP and per-user rate limits
Bot detection on auth endpoints (signup, login, password reset)
Schema validation rejecting unexpected payloads
Anomaly detection on payment and admin endpoints

Validate everything, trust nothing

Server-side, every request body, query parameter, and header is hostile until proven otherwise. Use a schema library (Zod, Yup, Pydantic) to validate inputs before they reach business logic. Store user IDs from the JWT claim, never from a request field — otherwise a user can simply pass userId: 7 and read someone else's data. (This class of bug, broken object-level authorization, is OWASP API #1 for a reason.)

5. Code-Level Defenses

These matter most for apps that handle high-value assets — banking, crypto wallets, paid streaming — and matter little for a B2B internal tool.

Code obfuscation

JavaScript bundles in React Native are readable. Hermes bytecode raises the bar slightly but isn't real obfuscation. For high-risk apps, layer in:

Minification + property mangling (Metro + Terser settings)
Native obfuscation for any custom native modules (ProGuard / R8 on Android, bitcode + symbol stripping on iOS)
Commercial RASP (Runtime Application Self-Protection) like Guardsquare DexGuard or Promon Shield — overkill for most apps, essential for banking

Jailbreak / root detection

A jailbroken or rooted device throws every device-bound assumption out the window. For sensitive apps, detect and respond:

jail-monkey (React Native) gives you boolean signals for jailbreak, debugger attached, mock location, and emulator
Don't crash the app — that's user-hostile and easy to bypass. Instead, raise the friction (require re-auth, disable offline mode, add server-side anomaly score)

Tamper detection and integrity attestation

Use Apple's DeviceCheck / App Attest and Google's Play Integrity API to verify the app binary hasn't been modified and is running on a genuine device. These are server-validated and much harder to spoof than client-side checks.

Disable debug features in production

Strip console.log from release builds (Metro's inlineRequires + Babel transform-remove-console)
Disable React Native debugger and Flipper in release variants
Turn off network inspection tools
Set __DEV__ correctly — don't ship dev-only code paths

6. Dependency and Supply-Chain Hygiene

The npm ecosystem is enormous and hostile. A single malicious post-install script in a transitive dependency can exfiltrate your entire dev environment.

Run npm audit (or Snyk / Socket.dev) on every PR. Block CI on high/critical findings.
Use lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) and never commit edits to them by hand.
Pin to specific versions for security-sensitive packages. Floating ranges (^, ~) are fine for utilities but risky for crypto, auth, and networking libs.
Scan native dependencies too — CocoaPods and Gradle have their own vulnerability databases.
Maintain an SBOM (Software Bill of Materials) so you can audit exposure when the next big CVE drops.

7. The OWASP MASVS Framework

If you take one thing from this article, take this: align your security work to the OWASP Mobile Application Security Verification Standard. It's the industry standard, free, and structured.

MASVS is split into eight control groups (architecture, storage, crypto, auth, network, platform, code, resilience) and three verification levels:

MASVS-L1 — baseline security every app should meet. Most consumer apps target this.
MASVS-L2 — defense-in-depth for apps handling regulated data (banking, healthcare, government).
MASVS-R — anti-reverse-engineering and resilience controls for apps under active threat.

OWASP also publishes the MASTG (Mobile Application Security Testing Guide) with concrete tests, and a dedicated guide for React Native apps since hybrid frameworks aren't the MASTG's primary focus.

Pick a level based on your threat model, then walk the checklist. It's the closest the industry has to a definitive answer for "are we secure enough?"

Photo by Carlos Muza on Unsplash

What AI App Builders Get Right (and What's Still on You)

If you're building with an AI app builder like RapidNative — which generates production-ready React Native and Expo code from natural-language prompts — a real chunk of the security baseline comes pre-wired. Generated code uses Expo's modern SDK defaults: expo-secure-store instead of AsyncStorage for tokens, HTTPS-enforced fetch wrappers, environment-aware config, and modern auth patterns when you connect Supabase or Firebase. Our export pipeline ships clean, auditable code you fully own — no lock-in, no black boxes.

But — and this is the honest part — no AI builder, no template, and no boilerplate can decide your threat model for you. Whether you need certificate pinning, jailbreak detection, or App Attest depends on what your app does and who wants to attack it. The same applies to vibe-coded apps in general; we wrote about the risks and best practices of vibe coding for exactly this reason. Treat AI-generated code as a strong starting point — then run it through the MASVS checklist before you ship.

A Pre-Launch Mobile App Security Checklist

Print this. Pin it above your monitor. Walk it before every release.

#	Control	Quick check
1	No hardcoded secrets in the bundle	`grep` your build output for `sk_`, `Bearer`, AWS keys
2	Tokens in `expo-secure-store`, not `AsyncStorage`	Audit storage calls
3	HTTPS enforced, ATS / NSC unmodified	Check `Info.plist` and `network_security_config.xml`
4	Short-lived access tokens + refresh rotation	Test refresh-token reuse triggers session revocation
5	OAuth 2.0 with PKCE for third parties	`expo-auth-session` with `usePKCE: true`
6	Server-side authorization on every endpoint	Try IDOR with a second test account
7	Rate limiting on auth endpoints	Hammer login with curl; expect 429
8	`console.log` stripped in release builds	Inspect the release bundle
9	`npm audit` clean (no high/critical)	CI gate
10	Dependencies pinned, lockfile committed	`git status` clean after `npm ci`
11	Privacy manifest + permissions justified	iOS 17+ requires `PrivacyInfo.xcprivacy`
12	Crash reporting scrubs PII	Sentry `beforeSend` filter
13	App Attest / Play Integrity wired (if high-risk)	Verify server-side
14	MASVS L1 self-assessment passed	OWASP MAS checklist

Closing Thought: Security Is a Feature, Not a Phase

The biggest shift in mobile security thinking since 2020 is that "we'll add security at the end" no longer works. Modern apps move faster — fueled by AI builders, faster CI, and OTA updates — which means security has to move with them, not after them. Build the right defaults in from day one, align to MASVS, and revisit the checklist before every release.

The good news: the tooling is dramatically better than it was even two years ago. Expo's secure primitives, modern identity providers, integrity APIs, and AI builders that ship safe defaults out of the box mean a small team can ship something genuinely well-secured without a dedicated security engineer.

If you're starting a new React Native or Expo app and want safe defaults baked in from the first prompt, try RapidNative free — describe your idea, get production-ready code, and iterate from there. Pair it with this checklist, and you'll be ahead of the security curve where most launches are still behind.

Want to go deeper on the React Native side? Read What is React Native, and our Expo vs React Native

Building an AI Chat Interface in React Native with Streaming Responses

Famitha M A — Wed, 29 Apr 2026 08:35:40 +0000

Building an AI Chat Interface in React Native with Streaming Responses

Tap "send", wait three seconds, then a wall of text appears at once. That's the difference between an AI chat that feels alive and one that feels broken. Streaming — token-by-token rendering as the model thinks — turns a slow API call into something users perceive as a conversation. On the web, the Vercel AI SDK and useChat make it almost trivial. On React Native, you have to think harder: there's no EventSource in the runtime, FlatList can't be naïve about re-renders, and Markdown doesn't render itself like it does in the browser.

This post walks through a production-ready streaming AI chat in React Native and Expo end-to-end — server endpoint, client wiring, and the mobile-specific gotchas (network drops, scroll behavior, persistence) most tutorials skip.

Stack: Expo SDK 54+, React Native 0.81, the Vercel AI SDK (ai v4.3+), and any major LLM provider — Anthropic Claude, OpenAI GPT, or xAI Grok via the @ai-sdk/* adapters.

Why streaming changes the UX

Streaming isn't a performance optimization, it's a perception fix. A non-streaming chat call that takes 6 seconds feels broken — the user assumes the app froze. The same call streamed token-by-token feels responsive within 200ms because the first words land before the brain decides "this is taking too long."

On mobile this matters more than on web. Cellular latency varies wildly, App Store reviews punish perceived slowness, and a static spinner doesn't telegraph progress the way moving text does.

Architecture: three moving parts

The mobile client — Expo app, holding messages in state, rendering tokens as they arrive.
An edge endpoint — Next.js API route or similar HTTP boundary that holds your provider API key and proxies the stream.
The model provider — Anthropic, OpenAI, Bedrock, etc., emitting SSE chunks.

You never call the provider directly from the mobile app. Your API key would leak into the JS bundle, and most providers reject mobile origins or rate-limit them aggressively. The edge endpoint is mandatory.

Setting up

bunx create-expo-app@latest chat-app --template tabs
cd chat-app
bun install ai @ai-sdk/anthropic zod react-native-markdown-display

Same ai package on server and client — the AI SDK 4 normalizes streaming protocols (x-vercel-ai-data-stream) so both sides speak the same wire format.

The server endpoint

// app/api/chat/route.ts (Next.js)
import { anthropic } from '@ai-sdk/anthropic';
import { streamText } from 'ai';
import { z } from 'zod';

const Body = z.object({
  messages: z.array(z.object({
    role: z.enum(['user', 'assistant', 'system']),
    content: z.string(),
  })).max(50),
});

export async function POST(req: Request) {
  const { messages } = Body.parse(await req.json());

  const result = streamText({
    model: anthropic('claude-sonnet-4-5'),
    system: 'You are a concise, helpful assistant. Use Markdown for code.',
    messages,
    maxTokens: 1024,
  });

  return result.toDataStreamResponse();
}

streamText returns lazily, toDataStreamResponse() emits the AI SDK's data-stream protocol, and Zod validates the message shape. Always cap message count — 50 is a reasonable ceiling — to prevent prompt-injection-via-history-bloat.

For production, add a per-user rate limiter (Upstash sliding window works well) and an auth check before you ever hit the provider. Every dropped request that never reaches the model is dollars saved.

The React Native client

// app/(tabs)/index.tsx
import { useChat } from 'ai/react';
import { FlatList, View } from 'react-native';
import { useRef } from 'react';

export default function ChatScreen() {
  const { messages, input, handleInputChange, handleSubmit, isLoading, stop } =
    useChat({
      api: 'https://your-api.com/api/chat',
      streamProtocol: 'data',
    });

  const listRef = useRef<FlatList>(null);

  return (
    <View style={{ flex: 1 }}>
      <FlatList
        ref={listRef}
        data={messages}
        keyExtractor={(m) => m.id}
        renderItem={({ item }) => <MessageBubble message={item} />}
        onContentSizeChange={() =>
          listRef.current?.scrollToEnd({ animated: true })
        }
      />
      <ChatInput {...{ input, handleInputChange, handleSubmit, stop, isLoading }} />
    </View>
  );
}

Two React Native specifics: handleInputChange expects a synthetic event, so you cast a fake event shape because TextInput only gives you a string. Auto-scroll on onContentSizeChange is correct because each new token expands content height — don't scroll on onChangeText or you'll fight the user when they read earlier messages.

Rendering Markdown

LLMs return Markdown. React Native's Text won't render it. Three options:

react-native-markdown-display — pure JS, fast for chat-sized output, custom renderers for code blocks. Default choice.
@expo/html-elements + Markdown-to-HTML — heavier but reusable if you render web content elsewhere.
Custom parser — only if you need strict typography control.

Don't use react-native-render-html. It's slow and visibly janks during streaming.

Network resilience

Mobile networks drop. A 30-second Claude response can lose its connection three times when the user walks into an elevator.

stop() from useChat calls AbortController.abort() on the underlying fetch — wire it to a stop button. For retries, restart-on-fail is almost always the right call: discard the partial response and re-send. Resume-marker patterns are complex and only worth it for very long generations. Add exponential backoff (1s, 2s, 4s, give up at 8s).

Persistence

useChat keeps messages in memory. Persist them with AsyncStorage:

useEffect(() => {
  if (!isLoading && messages.length > 0) {
    AsyncStorage.setItem('chat:messages', JSON.stringify(messages));
  }
}, [isLoading, messages]);

Don't write on every token (hundreds of writes per response). Debounce to 300ms or only write when isLoading flips to false.

Performance on real devices

A naïve FlatList re-renders the entire conversation per token. At 30 tokens/sec on 50 messages, you drop frames.

Memoize bubbles with React.memo + custom comparator: re-render only on id, content, or isStreaming change.
Use keyExtractor correctly — return message.id, not array index.
Batch updates — wrap mutations in requestAnimationFrame if managing messages manually.

Test on a real low-end Android device. Streaming jank is invisible on M-series Macs and brutal on a $150 Pixel.

Production checklist

Edge endpoint validates with Zod
Per-user rate limit
Stop button visible during isLoading
Markdown renderer with code highlighting
Messages persist across restarts
Auto-scroll on content-size change, not input change
Tested on real low-end Android
Sentry on the streaming endpoint
Stream timeout configured (30s soft cap)

Wrapping up

A great React Native AI chat is mostly mobile craft, not AI craft. Streaming is solved at the SDK layer; the work is rendering tokens smoothly on a $150 Android, persisting messages, surviving cellular handoffs.

If you want to skip the boilerplate, RapidNative generates the streaming endpoint + useChat wiring + Markdown bubbles + persistence layer from a natural-language prompt. Output is plain Expo code you own and can extend.

Cross-Platform vs Native in 2026: Why the Debate Is Actually Over

Famitha M A — Mon, 27 Apr 2026 11:02:53 +0000

Cross-Platform vs Native in 2026: Why the Debate Is Actually Over

Every mobile team has had the same argument for a decade. Swift + Kotlin, or pick a cross-platform framework and eat the "feels slightly off" tax forever?

In 2026, that argument is mostly theater. Here's the technical case, grounded in what actually changed.

The bridge is gone

React Native's historical performance gap came from the async JavaScript bridge. Every call to native had to be serialized and queued.

That's gone. The New Architecture (default in 0.76+) replaces it with:

JSI (JavaScript Interface) — a C++ layer giving JS direct synchronous access to native code
Fabric renderer — composes views synchronously on the UI thread, matching UIKit/Compose
TurboModules — lazy-loaded, directly callable native modules

Result: 60fps (or 120fps on ProMotion) on the same list-scroll and animation workloads that used to stutter. Meta, Shopify, Discord, Microsoft, Coinbase, and Tesla all run production apps on this stack.

API parity is effectively solved

"Native gets new APIs day one" used to mean months of waiting on cross-platform.

In 2026 it means:

Expo Modules API + config plugins let you write Swift/Kotlin and expose it to JS
Community modules ship within weeks of iOS/Android releases
HealthKit, Live Activities, App Intents, Core ML — all have working integrations

The real gap is spatial computing and bleeding-edge launch-day features. Everything else is covered.

UI fidelity — it looks native because it is native

React Native renders actual platform views:

<TextInput> → UITextField / EditText
<ScrollView> → UIScrollView / RecyclerView

Gestures, accessibility, keyboard behavior — handled by the OS. This is why Shopify, Outlook Mobile, and the Meta apps don't feel "off."

Flutter takes the other route — draws its own widgets via Skia/Impeller. Trades native feel for pixel-perfect consistency.

Developer experience: hot reload still wins

SwiftUI previews and Compose live edits closed part of the gap. But:

Sub-second full-app reload on a physical device
Same codebase runs on iOS + Android simultaneously — parity issues surface instantly
No Xcode rebuild, no Gradle sync

A team iterating 10x faster on UI compounds hard over a release cycle.

The 95/5 split

Large production apps don't hit 100% code sharing. Shopify reports ~95%. The remaining 5% is:

Platform-specific integrations
Native modules for perf-critical paths
Store configuration
Occasional platform UI divergence

The useful question is "is 95% enough to justify one codebase?" Almost always yes.

Quick comparison

Dimension	Native	React Native (2026)
Codebases	2	1
Team size	6-8	3-4
UI performance	Native	Native (New Arch)
UI fidelity	Native	Native (same components)
Hot reload	Previews only	Full app, sub-second
Code sharing	0%	90-95%
Talent pool	Swift + Kotlin specialists	Any TypeScript dev

When to still go native

Games / real-time graphics (Metal, Vulkan)
AR/VR / spatial computing (Vision Pro, Quest)
Deep hardware integration (specialized BLE, sensors)
Teams with zero frontend capacity

That's it. "My app is too important" doesn't qualify — Instagram and Shopify are also important.

The AI angle nobody's talking about

TypeScript + JSX is the most densely represented stack in LLM training data. Cross-platform generation works because one React Native file targets both platforms; keeping a SwiftUI file and a Compose file in sync is a much harder AI problem.

This is why AI-native builders like RapidNative can turn a prompt, sketch, or screenshot into a production React Native app in minutes — and why the equivalent on native-only stacks doesn't exist yet.

TL;DR

The debate didn't end because one side won an argument. It ended because the performance gap closed, the tooling overtook native on DX, and the largest apps on earth quietly migrated.

If you're picking a stack for a new mobile app in 2026, the default is React Native + Expo unless you're building a game, an AR/VR app, or have deep native-only expertise.

What's your current stack, and what's keeping you on it? Drop a comment.