DEV Community: Famitha M A

Delayed Push Permissions in React Native: Why the Third-Session Prompt Wins

Famitha M A — Wed, 16 Sep 2026 08:19:52 +0000

TL;DR

Asking for push permission on first launch is the single most common way apps burn their one clean shot at the iOS prompt
Waiting until the third session roughly doubles your odds, because the user has now chosen to come back twice
Session counting is a five-line AsyncStorage pattern
Better still: trigger on a habit moment (first save, first completed workout, first message) instead of a raw session count
Skip the custom "pre-permission" explainer modal unless you have data proving it helps. It often does not
If you already shipped the install-time prompt, there is a recovery path via Linking.openSettings()

The default cap

On iOS you get one native permission prompt. Decline it and the OS will never show it again for your app. The user has to dig through Settings to reverse it, which almost nobody does.

So the question is not "how do I ask." It is "when does the user have a reason to say yes."

At install, they don't. They opened your app forty seconds ago. They have no idea what your notifications contain, whether they are useful, or how often they will fire. Blind install-time prompts get rejected constantly, and every rejection is permanent. You are spending an unrecoverable resource at the moment of lowest trust.

What "the third session" actually means

Not "day three." Not "72 hours after install." Session three: the third distinct time the user opens the app. By then they have voluntarily returned twice. They have context. The ask is no longer coming from a stranger.

The mechanic is a counter that increments once per cold start:

import AsyncStorage from '@react-native-async-storage/async-storage';

const SESSION_KEY = 'session_count';

export async function bumpSession() {
  const raw = await AsyncStorage.getItem(SESSION_KEY);
  const count = (parseInt(raw, 10) || 0) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));
  return count;
}

Call it once from your root component:

useEffect(() => {
  bumpSession().then(setSessionCount);
}, []);

Then gate the prompt:

import * as Notifications from 'expo-notifications';

async function maybeAskForPush(sessionCount) {
  if (sessionCount < 3) return;

  const { status } = await Notifications.getPermissionsAsync();
  if (status !== 'undetermined') return; // already asked, never re-burn

  await Notifications.requestPermissionsAsync();
}

The undetermined check matters. It makes the function safe to call on every launch without ever re-triggering anything.

Habit moments beat session counts

Session three is the floor, not the ceiling. A raw counter still fires the prompt at an arbitrary moment. The stronger pattern is tying the ask to the first action that notifications will actually serve:

A task app asks right after the user sets their first due date
A fitness app asks after the first completed workout
A chat app asks when the user sends their first message

At that moment the value proposition is self-evident. "Want a reminder when this is due?" needs no explanation. If your app has a moment like that, use it as the trigger and keep the session count as a fallback for users who never hit it:

async function askAtHabitMoment() {
  const { status } = await Notifications.getPermissionsAsync();
  if (status === 'undetermined') {
    await Notifications.requestPermissionsAsync();
  }
}

Same guard, different call site. That is the whole change.

If you are prototyping this flow, this gating logic is exactly the kind of glue code worth generating rather than hand-writing. RapidNative scaffolds React Native and Expo screens from a prompt, and wiring a permission flow like this into a generated onboarding is a five-minute job.

The pre-permission modal trap

The popular advice says: show a custom in-app modal first ("We'd like to send you helpful reminders!"), and only fire the native prompt if the user taps yes.

The theory is sound. In practice it is easy to get wrong, and plenty of teams have watched it hurt more than help. You are now showing two interruptions instead of one, and the custom modal gives users a free, zero-cost place to say no. Some users who would have shrugged and accepted the native prompt bounce off the softer one first.

If you ask at a habit moment, the context does the explaining and the extra modal is redundant. My take: ship without it, and only add it if your own funnel data says otherwise. Do not cargo-cult it in.

Recovery for already-shipped apps

Already burned the prompt on install? You cannot re-trigger it, but you can route users to Settings at a habit moment instead:

import { Linking } from 'react-native';

async function recoverPush() {
  const { status, canAskAgain } = await Notifications.getPermissionsAsync();

  if (status === 'undetermined' || canAskAgain) {
    await Notifications.requestPermissionsAsync();
  } else if (status === 'denied') {
    // one-tap jump to your app's own settings page
    Linking.openSettings();
  }
}

Pair Linking.openSettings() with a single line of UI ("Turn on reminders in Settings") and fire it only at a moment where the user just tried to do something that needs notifications. Cold recovery rates are low, but warm ones, triggered by intent, are worth shipping.

The whole thing

Counter, guard, trigger, recovery. About 20 lines total, no library beyond AsyncStorage and expo-notifications, and it protects the one prompt you cannot get back.

What trigger moment are you using in your app: session count, habit moment, or something weirder? Drop it in the comments.

How to Add Payment Processing to Your React Native App (2026 Guide)

Famitha M A — Fri, 11 Sep 2026 13:24:35 +0000

TL;DR

Decide first: digital goods (subscriptions, unlocks) or physical goods/services. That decision, not the SDK, determines what you're allowed to use.
Physical goods or services: Stripe + Apple Pay + Google Pay via @stripe/stripe-react-native.
Digital goods: native IAP through RevenueCat (react-native-purchases). US external web checkout and EU alternative processors are now legal, but IAP is still the safe global default.
The client integration is ~30% of the work. Webhooks, idempotency, and receipt validation are the other 70%.
Never test on a live card. Stripe test mode, Apple sandbox testers, and Play license testers cover every failure path.

Every founder building a React Native app hits the same wall: the demo works, users love it, and then someone asks, "So how do people actually pay?" What sounds like a one-afternoon integration turns into a week of reading Apple's guidelines, comparing Stripe versus RevenueCat, and arguing about whether your feature counts as "digital goods." The stack is not the hard part. The rules around the stack are.

The decision that comes before the code

Before you touch an SDK, answer one question: is what your app sells a digital good or a physical good? This is not a UX distinction. It's the rule Apple and Google use to decide whether you're allowed to use Stripe at all.

Digital goods: subscriptions, premium unlocks, in-game currency, credits, cloud storage, ad-removal. Apple and Google have historically required these to go through their native in-app purchase (IAP) system and taken a 15–30% commission (30% for large developers on standard transactions and year-one subscriptions, 15% after year two or under the Small Business Program).
Physical goods and real-world services: t-shirts, meal kits, ride-sharing, bookings. These have always been allowed to use third-party processors like Stripe or PayPal at standard card fees (~2.9% + $0.30).

For a long time, that was the whole story. Then Epic v. Apple in the US and the DMA in the EU cracked it open. As of late 2025, US developers can link out to an external web checkout for digital goods too (Apple still shows a warning sheet), and EU users on iOS can use fully alternative payment providers inside the app. Your practical options in 2026:

Physical/services app: use Stripe (or PayPal, Adyen, Braintree) natively in-app.
Digital goods, US-only: IAP is still simplest, but external web checkout via Stripe is now legal.
Digital goods, EU: alternative in-app payment providers are allowed.
Digital goods, global: use IAP for the safest cross-border coverage, or add a web-checkout fallback.

Pick the answer before you pick an SDK. Everything downstream depends on it.

Payment options compared

Option	Best for	Fees	RN SDK	App Store safe
Stripe	Physical goods, services, B2B	2.9% + $0.30	`@stripe/stripe-react-native`	Yes for physical, conditionally for digital
RevenueCat (wraps IAP)	Subscriptions, digital goods	Free < $2.5k MRR, then 1%	`react-native-purchases`	Yes (uses Apple/Google IAP)
Apple Pay / Google Pay	Fast checkout on top of a processor	Same as processor	Built into Stripe SDK	Yes for physical goods
PayPal / Braintree	Markets where PayPal is preferred	2.9% + fixed	community SDKs	Same rules as Stripe
Native IAP directly	Digital goods, no abstraction	15–30% Apple/Google	`expo-in-app-purchases` / `react-native-iap`	Yes (required by default)

For 90% of React Native apps in 2026, the answer is one of two combos: Stripe + Apple/Google Pay for physical goods or services, or RevenueCat on top of native IAP for subscriptions and digital unlocks. Let's build both.

Setting up Stripe

Stripe's official SDK handles PCI compliance for you (card details never touch your server), supports Apple Pay and Google Pay out of the box, and has first-class Expo support via a config plugin.

Step 1: install.

# Expo (recommended)
npx expo install @stripe/stripe-react-native

# Bare React Native
npm install @stripe/stripe-react-native
cd ios && pod install

With Expo, add the plugin to app.json:

{
  "expo": {
    "plugins": [
      ["@stripe/stripe-react-native", {
        "merchantIdentifier": "merchant.com.yourapp",
        "enableGooglePay": true
      }]
    ]
  }
}

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>
  );
}

The publishable key is safe to ship in the bundle. The secret key never leaves your backend.

Step 3: create a Payment Intent on your server. This is the piece a lot of tutorials skip. Stripe requires a server-side call so the amount is not manipulable from the client.

// Backend: /api/create-payment-intent
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const { amount, currency = 'usd' } = await req.json();

  const paymentIntent = await stripe.paymentIntents.create({
    amount,
    currency,
    automatic_payment_methods: { enabled: true },
  });

  return Response.json({ clientSecret: paymentIntent.client_secret });
}

Step 4: present the Payment Sheet. Stripe's pre-built, PCI-compliant UI supports cards, Apple Pay, Google Pay, and 40+ local payment methods depending on your country.

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

function CheckoutScreen({ amount }: { amount: number }) {
  const { initPaymentSheet, presentPaymentSheet } = useStripe();

  async function pay() {
    const res = await fetch('/api/create-payment-intent', {
      method: 'POST',
      body: JSON.stringify({ amount }),
    });
    const { clientSecret } = await res.json();

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

    const { error } = await presentPaymentSheet();
    if (error) console.log(error.message);
    else Alert.alert('Payment complete');
  }

  return <Button title="Pay" onPress={pay} />;
}

That's a functioning payment flow. Cards, Apple Pay, and Google Pay all light up in the same sheet with no extra integration work. If you'd rather not hand-wire this, RapidNative generates this exact stack (checkout screen, provider, payment intent endpoint, webhook handler) from a plain-English prompt, and the code exports to your own repo.

Handling in-app purchases for digital goods

Selling subscriptions, credits, or premium unlocks? You'll almost certainly go through StoreKit and Google Play Billing. Wiring these APIs directly is painful: different receipt formats, different renewal semantics, different edge cases for pauses, grace periods, refunds, and family sharing. Nearly every serious React Native app in 2026 uses RevenueCat to abstract this away.

Step 1: install.

npx expo install react-native-purchases

Step 2: configure at app start.

import Purchases from 'react-native-purchases';

Purchases.configure({
  apiKey: Platform.OS === 'ios'
    ? process.env.EXPO_PUBLIC_RC_IOS_KEY!
    : process.env.EXPO_PUBLIC_RC_ANDROID_KEY!,
});

Step 3: fetch offerings and present a paywall.

const offerings = await Purchases.getOfferings();
const monthly = offerings.current?.availablePackages.find(
  (p) => p.packageType === 'MONTHLY'
);

if (monthly) {
  const { customerInfo } = await Purchases.purchasePackage(monthly);
  const isPro = customerInfo.entitlements.active['pro'] !== undefined;
}

RevenueCat handles receipt validation, cross-platform sync, subscription state, and analytics. You configure products in App Store Connect and Google Play Console, mirror them in RevenueCat, and let the SDK reconcile everything. The commission is still Apple's or Google's. RevenueCat itself is free below $2,500/month in tracked revenue, then 1%.

One warning: do not route digital-goods subscriptions through Stripe just to dodge the 30% cut globally. Apple will reject the app. The narrow exception (US external web-checkout linking) requires the StoreKit External Purchase Link entitlement plus an explicit user warning sheet. Worth doing at scale, not worth the review risk for a first launch.

Adding Apple Pay and Google Pay

Good news: if you integrated the Payment Sheet above, Apple Pay and Google Pay are already working. The sheet auto-detects device capability and shows the right button.

Two extra steps to get store-approved:

Apple Pay: enable the Apple Pay capability in your Apple Developer account, create a merchant ID (merchant.com.yourapp), and add it to the Expo config plugin. Test on a real device: the simulator doesn't run Apple Pay.
Google Pay: enable Google Pay in the Google Pay Business Console, register your app, and turn on the googlePay flag. Test on a real Android device with a saved card.

Both are free on top of Stripe, and they dramatically improve conversion. Stripe's own data shows one-tap payments increase mobile checkout completion by 60–70%. Treat them as table stakes, not features.

The backend half nobody talks about

Client-side integration is maybe 30% of a real payment system. The other 70% lives on your server:

Webhooks. Stripe (and RevenueCat) push events for every state change: payment_intent.succeeded, invoice.payment_failed, customer.subscription.updated. You need an endpoint that verifies signatures, reads the event, and updates your database. Skipping this is the number-one cause of "user paid but the app says they didn't" bugs.
Idempotency. Payment operations must be safe to retry. Use idempotency keys on Stripe requests and dedupe webhook events by ID. Networks fail; users retry; you cannot charge twice.
Receipt validation. For IAP, Apple and Google receipts must be validated server-side. RevenueCat does this for you. Rolling your own? The App Store Server API docs are your source of truth.
Subscription lifecycle. Grace periods, billing retries, pauses, refunds, and family sharing mean "active" is not a single boolean. Model it as state, not a flag.
Compliance. Even with Stripe absorbing PCI scope, you still need Strong Customer Authentication (SCA) in the EU/UK. The Payment Sheet handles the 3DS challenge automatically, but your backend must handle the requires_action state.

This is where most hand-rolled payment integrations quietly leak revenue.

Testing payments safely

Never run a first payment against a live card. Both Stripe and RevenueCat have first-class sandbox modes:

Stripe test mode: use test API keys and Stripe's published test cards. 4242 4242 4242 4242 for success, 4000 0000 0000 9995 for insufficient funds, 4000 0025 0000 3155 to trigger 3D Secure. Run every failure branch before switching to live keys.
Apple sandbox: create a Sandbox Tester in App Store Connect, sign into it on your test device under Settings → App Store → Sandbox Account, then run TestFlight or a dev build. Sandbox subscriptions renew every 5 minutes instead of monthly, which is how you test renewals in a reasonable amount of time.
Google Play: add license testers in the Play Console, upload to an internal test track, and purchase without being charged.
Real devices: Apple Pay and Google Pay don't work in simulators. Test the payment sheet the way an end user actually sees it.

Write end-to-end tests for the happy path, the SCA path, the network-failure path, the webhook-late path, and the cancellation path. If those five work, you have a payment system. If any of them fails silently, you have a support ticket queue.

Ship payments, not payment bugs

Adding payment processing to a React Native app in 2026 is a solved problem, but only if you make the digital-vs-physical decision first, treat webhooks as first-class code, and test the failure paths as hard as the happy path. Stripe + Apple Pay + Google Pay covers most physical-goods and services apps. RevenueCat covers most subscription apps. The rest is discipline: idempotency, sandbox testing, and a webhook handler you actually trust.

What are you wiring payments into right now? Drop a comment with your stack (and any App Store review horror stories).

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

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

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

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

TL;DR

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

Why OTA is a superpower most teams misuse

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

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

The three update tiers

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

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

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

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

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

Rollback discipline: write the runbook before you push

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

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

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

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

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

Two habits make this actually work:

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

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

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

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

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

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

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

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

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

Safe points, in order of preference:

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

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

EAS channels as a first-class rollout dimension

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

Our channel layout:

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

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

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

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

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

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

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

When OTA vs. a store release

The boundary is mechanical, not judgment-based:

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

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

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

The shortest reliable loop we've settled on

For a Tier 2 change, end to end:

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

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

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

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

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

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

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

Reading a wireframe as a folder tree

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

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

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

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

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

The scaffolding script

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

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

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

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

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

scaffold(tree, './app');

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

What still needs a dev

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

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

Case study

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

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

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

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

The Design System of a Trustworthy React Native Checkout Screen

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

TL;DR

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

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

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

Here's the whole system, with code.

The five zones

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

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

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

Typography: two sizes, that's it

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

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

Color tokens

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

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

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

The three states everyone forgets

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

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

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

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

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

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

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

The two components that carry the screen

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

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

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

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

Ship it in a sprint

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

The rest is plumbing to Stripe or Razorpay.

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

How AI Is Making Mobile Accessibility Easier Than Ever

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

TL;DR

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

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

Why mobile a11y is harder than the web

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

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

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

And the version that actually works with VoiceOver and TalkBack:

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

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

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

Shift 1: the OS started covering for you

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

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

Shift 2: audits got cheap

Three categories worth knowing:

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

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

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

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

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

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

Shift 3: the missing content is now generated

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

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

Shift 4: fix it at generation time

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

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

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

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

What AI still can't do

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

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

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

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

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

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

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

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

Where this goes next

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

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

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

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

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

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

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

The four generations, briefly

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

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

Why mobile lagged the web

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

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

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

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

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

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

What "full app creation" actually produces in 2026

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

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

The four unlocks that made 2026 different

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

Checklist: is a tool actually Generation 4?

If you're evaluating tools in 2026, ask:

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

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

What this means for developers

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

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

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

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

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

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

The five categories of RN offline storage

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

Comparison table

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

The offline-first pattern

Four moving parts:

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

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

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

  syncEngine.wake();
}

Conflict resolution

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

Decision cheat sheet

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

Pitfalls to skip

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

Wrap-up

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

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

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

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

TL;DR

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

The number

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

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

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

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

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

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

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

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

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

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

Where the 77% actually dies: the first session

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

The consistent offenders, with rough measured costs:

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

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

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

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

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

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

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

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

The five real reasons users churn

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

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

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

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

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

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

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

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

A weekly experiment cadence that actually compounds

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

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

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

The bottom line

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

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

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

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

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

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

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

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

The three-app reality

A grocery delivery product is three apps sharing one backend:

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

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

The stack that converges

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

Data model — the parts that matter

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

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

Two invariants worth burning into your brain:

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

Real-time tracking without pain

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

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

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

Customer side: subscribe to the driver row.

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

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

Payments — the substitution problem

Stripe Payment Intents flow:

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

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

The screens

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

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

The subtle bugs to avoid

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

Wrap

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

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

Posting instructions for Dev.to:

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

7 Lessons Shipping React Native Templates

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

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

The templates

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

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

Lesson 1 — Build the substrate before the first template

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

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

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

Lesson 2 — API keys never live in the RN bundle

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

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

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

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

Lesson 3 — One data contract, all templates

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

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

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

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

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

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

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

Structure that works:

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

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

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

Lesson 5 — Keep the entry price low

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

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

Lesson 6 — Docs convert, not screenshots

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

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

Lesson 7 — Stack review

Would pick again:

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

Would skip:

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

For year two

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

Streaming AI Responses to React Native: The Complete Guide

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

applighter.com

React Native Supabase Template: Auth, RLS, Storage

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

applighter.com

Wiring Designers Into Your EAS Preview Loop

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

TL;DR

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

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

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

Why design reviews on Figma miss real device behavior

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

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

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

The one-Slack-command pattern that unblocks designers

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

/preview branch feat/new-onboarding

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

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

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

EAS Update channels for designer-only preview builds

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

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

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

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

The three friction points to remove before you invite designers

Before rolling this out, remove these:

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

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

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

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

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

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

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