DEV Community: Hugo Rus

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

Hugo Rus — Wed, 16 Sep 2026 04:58:11 +0000

Prompt-on-install caps push acceptance at ~45%; a third-session gate lifts it to ~78%
Session count is a proxy: tie the prompt to a habit moment when you have one
Skip the iOS pre-permission modal (net -6pp in practice)
Already shipped? Linking.openSettings() is your only recovery path

Most React Native tutorials on push notifications skip the single decision that matters most: when to ask.

The default in every boilerplate is to prompt on install day, usually in the onboarding flow. That decision quietly caps your addressable notification audience at whatever fraction of users don't tap "Don't Allow" during the least trusting three seconds of their relationship with your app. Across the RapidNative-built apps we can see, that fraction is about 45%.

Move the prompt to after the third session — or better, tie it to a habit-forming moment — and acceptance climbs to about 78%. The change is a 3-line delta in your app entry file. This post walks through the pattern.

What "the third session" actually means

You don't need a fancy engagement model. Track sessions in AsyncStorage:

import * as Notifications from 'expo-notifications';
import AsyncStorage from '@react-native-async-storage/async-storage';

const SESSION_KEY = 'session_count';
const PROMPTED_KEY = 'push_prompted';

export async function maybeAskForPushPermission() {
  const already = await AsyncStorage.getItem(PROMPTED_KEY);
  if (already) return;

  const rawCount = await AsyncStorage.getItem(SESSION_KEY);
  const count = parseInt(rawCount ?? '0', 10) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));

  if (count < 3) return;

  const { status } = await Notifications.requestPermissionsAsync();
  await AsyncStorage.setItem(PROMPTED_KEY, 'true');
  return status;
}

Call maybeAskForPushPermission() from your root layout's useEffect, not from onboarding. The user sees the prompt on their third open, in a moment where they've already decided your app is worth returning to.

Why the habit-moment version is better

Session count is a proxy. The signal you actually want is "user just completed a meaningful action." Tie the prompt to the completion event instead:

async function onFirstJournalEntrySaved() {
  await AsyncStorage.setItem('has_first_entry', 'true');
  await maybeAskForPushPermission();
}

Now the permission prompt lands in the exact second the user is thinking "I could see myself using this again." Different question in the user's head. Different answer.

The iOS-specific trap: pre-permission modal

The pattern iOS teams reach for — showing your own custom "Would you like push?" modal before triggering the real prompt — has a subtle failure mode. If the user taps "Yes" on your modal and "Don't Allow" on the real one, you cannot re-prompt. iOS is one-and-done.

Skip the pre-modal unless you have data that your specific audience needs it. In our tests it dropped acceptance by 6 percentage points net, because "yes to modal + no to real prompt" was a bigger cohort than "no to modal at all."

What to do if you already shipped with prompt-on-install

You cannot re-prompt users who already denied. But you can:

Add the delayed prompt for new installs.
Build a settings page that deep-links to the iOS Settings > Notifications page for your app, so denied users can re-enable manually. Linking.openSettings() handles this.
Show the deep-link once, in-app, at a habit moment. Don't nag.

The whole thing in ~20 lines

import * as Notifications from 'expo-notifications';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { Linking } from 'react-native';

const SESSION_KEY = 'session_count';
const PROMPTED_KEY = 'push_prompted';

export async function maybeAskForPushPermission(force = false) {
  if (await AsyncStorage.getItem(PROMPTED_KEY)) return;

  const count = parseInt((await AsyncStorage.getItem(SESSION_KEY)) ?? '0', 10) + 1;
  await AsyncStorage.setItem(SESSION_KEY, String(count));
  if (count < 3 && !force) return;

  const { status } = await Notifications.requestPermissionsAsync();
  await AsyncStorage.setItem(PROMPTED_KEY, 'true');
  return status;
}

// Recovery flow for users who already denied
export async function openNotificationSettings() {
  const { status } = await Notifications.getPermissionsAsync();
  if (status === 'denied') await Linking.openSettings();
}

That is the pattern. Session-count gate, tie to a habit moment if you can (pass force = true from the completion event), use Linking.openSettings() for the recovery flow.

Something like RapidNative ships this gate in its generated Expo projects by default, so if you're scaffolding a new app the prompt is already off line 3 before you've written anything.

Don't ship the 45% cap

The point of writing this up is not that it's complex. It's that this is the highest-leverage thing you can do to your push notification stack this quarter, and most React Native tutorials still show you requestPermissionsAsync() on line 3 of the app.

If you've measured acceptance before and after moving the prompt, drop a comment with your numbers. Curious whether the third-session threshold holds across categories or whether it's a journaling/fitness thing.

How to Build an AI-Powered Personal Finance App with React Native and Expo

Hugo Rus — Fri, 04 Sep 2026 13:07:27 +0000

Four Postgres tables + RLS cover 90% of a personal finance MVP
Rules-based categorization first, LLM fallback second (the LLM's job is bootstrapping the rules)
Skip Plaid at v1: manual entry, done well, is a real product
Prompt-scaffold the v1, spend your time on categorization heuristics and first-run UX

Personal finance is one of those categories where the market keeps growing but the incumbents keep frustrating users. Mint shut down, YNAB raised prices, and Rocket Money spent its way to a huge user base. If you're a React Native dev thinking about building in this space, 2026 is a great time. AI-native tooling collapses the scaffolding phase enough that a solo dev can ship a real v1 in a week.

Here's how I'd approach it end to end.

The core data model (Postgres via Supabase)

Four tables cover 90% of what a personal finance app does:

create table accounts (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  name text not null,
  type text check (type in ('checking','credit','cash','savings')),
  currency text default 'USD',
  balance numeric(14,2) default 0,
  created_at timestamptz default now()
);

create table categories (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  name text not null,
  icon text,
  color text,
  monthly_budget numeric(14,2)
);

create table transactions (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  account_id uuid references accounts not null,
  category_id uuid references categories,
  amount numeric(14,2) not null,
  merchant text,
  notes text,
  occurred_at timestamptz not null,
  created_at timestamptz default now()
);

create index on transactions (user_id, occurred_at desc);

Enable RLS on every table with user_id = auth.uid() policies. This is not optional in a finance app. It's the difference between "shipped an MVP" and "leaked a stranger's bank data."

The screen tree

Expo Router, tabs at the root:

(tabs)/index.tsx: home with month spend, budget remaining, category donut, recent transactions
(tabs)/transactions.tsx: list, grouped by day, with search + filter
(tabs)/budgets.tsx: card per category
(tabs)/insights.tsx: charts (I use victory-native for these)
(tabs)/settings.tsx: biometric toggle, currency, CSV export, dark mode
add-transaction.tsx: big number pad, merchant autocomplete, category picker

Add-transaction is the one screen users touch daily. Optimize the hell out of it.

The AI categorization loop

Two layers:

Rules table. Regex on merchant string -> category_id. Covers 70–80% of what you see in practice ("STARBUCKS.*" -> Coffee).
LLM fallback. For unmatched merchants, prompt a model with the merchant + the user's category list, ask for { category_id, confidence }. Store the answer so it becomes a rule. Cache aggressively: the same 100 merchants generate 80% of a user's transactions.

Do the rules first, add the LLM later. It's the correct order because the LLM's whole job is to bootstrap the rules table.

Bank connections: later, not now

Every finance-app tutorial jumps straight to Plaid. Don't. Plaid charges per connected user per month once you're out of the free tier, and it comes with a real support burden ("why does my bank keep disconnecting?"). Ship a well-designed manual tracker first. Add Plaid in v2 as a Pro feature once you have signal that users actually want the automation.

If and when you do connect, use their Link SDK. Never accept bank credentials in your own UI, ever.

The AI-native way to scaffold all of this

I've built React Native apps by hand and by prompting, and there's no serious argument for hand-scaffolding a v1 anymore. Prompt the whole thing:

A personal finance app with tabs: home, transactions, budgets, insights, settings. Home shows monthly spend, remaining budget, category donut chart. Add-transaction has a big number pad, merchant autocomplete, category picker, account selector. Use Supabase for auth + data. Enable RLS. Dark palette, subtle green for income, subtle red for expenses.

Something like RapidNative will spit out a real Expo project: real navigation, real Supabase client, generated types matched to the schema. You spend your time on the actually-hard parts (categorization heuristics, chart clarity, first-run UX) instead of typing useNavigation for the eightieth time in your life.

Whatever tool you pick, verify it exports plain code. You want to own the project, not rent it.

Security checklist before you ship

Biometric unlock (Expo LocalAuthentication), required on cold start after N minutes.
No sensitive fields in Sentry / analytics payloads.
RLS on every table.
HTTPS only (default in Expo, but audit anyway).
Data export + delete-my-account (GDPR/CCPA, also good UX).

What I'd skip on day one

Investment tracking (whole different data shape).
Bill negotiation / subscription cancellation (Rocket Money moat; expensive to build).
Real bank connections (Plaid).
Household / joint budgeting (v2 feature).

Ship view-only + manual + smart categorization. That's a real product.

Try the prompt path first

Even if you're a seasoned dev, prompt the first version before you write a line. Worst case you throw it out. Best case you shave weeks off your MVP. The free tier is enough to see whether the output is close to what you'd build.

Ship soon. The category is wide open. If you're building in fintech-adjacent RN right now, drop a comment with what you're working on. Curious what the categorization edge cases look like in other people's data.

Your app/ folder is your information architecture

Hugo Rus — Wed, 02 Sep 2026 10:37:48 +0000

Information architecture is the deliverable everyone nods along to and nobody enforces. You draw the sitemap in Figma. A developer builds the navigator tree in code. Six weeks later the two have quietly drifted, and onboarding someone new takes a thirty-minute explanation of why Settings lives inside the Account stack when the design has it as a top-level tab.

Expo Router's file-based routing removes that gap. Not by adding process, but by making the folder structure the thing both sides read.

The folder is the sitemap

Here is the shape of a real app:

app/
├── _layout.tsx
├── (tabs)/
│   ├── _layout.tsx
│   ├── index.tsx           # Home
│   ├── explore.tsx         # Explore
│   └── profile/
│       ├── _layout.tsx
│       ├── index.tsx
│       ├── edit.tsx
│       └── settings.tsx
├── (auth)/
│   ├── _layout.tsx
│   ├── login.tsx
│   └── signup.tsx
└── modal.tsx

Open that in any file explorer and the app's shape is visible without reading a line of TypeScript. Three tabs. A nested profile section. An auth flow in its own gated group. A modal at the top level, because it can be presented from anywhere.

Now compare it to RootNavigator.tsx → TabNavigator.tsx → ProfileStack.tsx. The same information exists, spread across three files, and none of them show the shape at a glance. A designer can't open those files and learn anything. They can open the folder tree.

Moving a screen is moving a file

Say you want to promote Settings out of Profile and up to a top-level tab.

mv app/\(tabs\)/profile/settings.tsx app/\(tabs\)/settings.tsx

That's the change. No navigator config to update, no linking config to rewrite, no screenOptions to migrate. The route is now /settings instead of /profile/settings, and with typed routes turned on, every router.push that pointed at the old path either autocompletes to the new one or gets flagged by TypeScript before it ships.

The design intent — this should be top-level — becomes one commit. That matters more than it sounds. When a structural change costs an afternoon of navigator surgery, it doesn't get made. It gets deferred, and the sitemap becomes aspirational.

Layouts are where design lives

Each _layout.tsx defines the header, the tab bar, the presentation style, and the safe-area handling for everything beneath it. That makes it the single file that answers the questions design review actually asks: what does someone see when they enter this section? What's the back affordance? What's the visual container?

In a navigator-based app, those answers are scattered across screenOptions, tab bar props, and headerLeft overrides on individual screens. Reviewing them as a designer means asking a developer to narrate the code. With _layout.tsx, it's one file per section, and you can read it.

A five-minute IA review

We run this weekly. Design and engineering open the app/ folder together and ask three questions:

Does the folder shape still match the sitemap?
Are there orphaned routes — files with no entry point in the UI?
Has any _layout.tsx drifted from its section-header spec?

It used to take the better part of an hour on a navigator-based project, mostly spent reconstructing the tree from three files before anyone could evaluate it. Now the reconstruction step is free.

What we catch is unglamorous and worth catching: the profile stack that grew a fifth screen nobody remembers adding, the modal that got promoted to a full screen but kept its presentation: 'modal' prop, the route that survived a feature cut.

The part that isn't automatic

File-based routing makes drift visible. It doesn't stop it. Groups like (tabs) and (auth) don't appear in the URL, so the folder tree and the navigation model can still diverge if you nest groups aggressively. And a folder structure that mirrors your sitemap perfectly can still describe a bad sitemap.

What changes is the cost of noticing. When the IA is a file tree, anyone on the team can audit it in a minute — and the thing that stops IA reviews from happening is almost never disagreement. It's that nobody can see the current state clearly enough to have the argument.

If you're leading design on a React Native app and you've never opened the app/ folder, open it. It's the most honest artifact you have.

Suraj from the RapidNative Team. We build RapidNative, which generates real React Native and Expo projects from a prompt — file-based routing included.

Real-Time Location Tracking in React Native, Including Live Sharing

Hugo Rus — Fri, 28 Aug 2026 11:17:07 +0000

The moving dot on a delivery app looks trivial. Underneath it: a permission sequence that fails silently if you get the order wrong, a background task the OS actively wants to kill, a battery budget you have to defend, and a connection that has to survive a phone going into a pocket.

Most tutorials stop at watchPositionAsync on a demo screen. This goes through to live sharing between two devices.

Request foreground permission first, background second, and never on launch
Define the background task at module top level, not inside a component
Android needs a foreground service or the OS kills the task within minutes
Use broadcast for live position, not database inserts
Coarsest accuracy and longest interval that still feels responsive

The stack

npx expo install expo-location react-native-maps expo-task-manager
npm install @supabase/supabase-js

expo-location handles foreground and background GPS plus permissions. react-native-maps renders Apple Maps on iOS and Google Maps on Android. expo-task-manager is required for background location. Supabase provides the realtime channel for the sharing half.

Step 1: Permissions

This is where most of the bugs live.

{
  "expo": {
    "plugins": [
      [
        "expo-location",
        {
          "locationAlwaysAndWhenInUsePermission": "Allow $(PRODUCT_NAME) to share your live location.",
          "isIosBackgroundLocationEnabled": true,
          "isAndroidBackgroundLocationEnabled": true
        }
      ]
    ],
    "ios": { "infoPlist": { "UIBackgroundModes": ["location", "fetch"] } }
  }
}

Request foreground first, background second. Always that order.

import * as Location from 'expo-location';

async function requestLocationPermissions() {
  const { status: fg } = await Location.requestForegroundPermissionsAsync();
  if (fg !== 'granted') throw new Error('Location required');

  const { status: bg } = await Location.requestBackgroundPermissionsAsync();
  if (bg !== 'granted') console.warn('Background disabled');
}

And do not request background on app launch. Wait until the user taps something that needs it, like "start sharing". Asking for always-on location from a stranger is how you get a permanent denial on the first screen.

Step 2: Foreground tracking

import { useEffect, useState } from 'react';
import * as Location from 'expo-location';

export function useLiveLocation() {
  const [location, setLocation] = useState<Location.LocationObject | null>(null);

  useEffect(() => {
    let sub: Location.LocationSubscription | null = null;
    (async () => {
      sub = await Location.watchPositionAsync(
        {
          accuracy: Location.Accuracy.BestForNavigation,
          timeInterval: 2000,
          distanceInterval: 5,
        },
        setLocation,
      );
    })();
    return () => sub?.remove();
  }, []);

  return location;
}

Three knobs:

accuracy. Balanced for delivery ETAs, BestForNavigation for anything where a few metres matters.
timeInterval. Minimum milliseconds between fixes.
distanceInterval. Minimum metres moved before firing. Set this to 5 or 10, otherwise a stationary user on a poor fix floods your UI with jitter.

That last one is the difference between a dot that sits still and a dot that vibrates.

Step 3: The map

import MapView, { Marker } from 'react-native-maps';

export function TrackingScreen() {
  const location = useLiveLocation();
  if (!location) return null;

  const region = {
    latitude: location.coords.latitude,
    longitude: location.coords.longitude,
    latitudeDelta: 0.005,
    longitudeDelta: 0.005,
  };

  return (
    <MapView style={{ flex: 1 }} region={region} showsUserLocation>
      <Marker coordinate={region} title="You are here" />
    </MapView>
  );
}

Use region, not initialRegion, if you want the map to follow. For a marker that slides between fixes rather than teleporting, animate the coordinate rather than setting it directly.

Step 4: Background tracking

Define the task at module top level. Not inside a component, not inside a hook. The OS invokes it before your React tree exists.

import * as TaskManager from 'expo-task-manager';
import * as Location from 'expo-location';

const LOCATION_TASK = 'background-location-task';

TaskManager.defineTask(LOCATION_TASK, ({ data, error }) => {
  if (error || !data) return;
  const { locations } = data as { locations: Location.LocationObject[] };
  void sendLocationsToServer(locations);
});

export async function startBackgroundTracking() {
  await Location.startLocationUpdatesAsync(LOCATION_TASK, {
    accuracy: Location.Accuracy.Balanced,
    timeInterval: 10_000,
    distanceInterval: 25,
    foregroundService: {
      notificationTitle: 'Sharing your location',
      notificationBody: 'Tap to open the app.',
    },
    pausesUpdatesAutomatically: true,
    activityType: Location.ActivityType.Fitness,
  });
}

Two non-negotiables. On Android, foregroundService or the OS kills the task within minutes. On iOS, UIBackgroundModes: ["location"] or you get rejected at review.

Step 5: Live sharing

The part most tutorials skip.

A Supabase Realtime channel must be subscribed before it will send anything. Creating a channel and immediately calling send transmits nothing, and it fails quietly, which makes it a genuinely unpleasant afternoon.

import { createClient } from '@supabase/supabase-js';
const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

// create and subscribe once, then reuse
export function createSession(sessionId: string) {
  const channel = supabase.channel(`session:${sessionId}`);
  channel.subscribe();
  return channel;
}

export function shareLocation(channel, loc: Location.LocationObject) {
  return channel.send({
    type: 'broadcast',
    event: 'position',
    payload: {
      lat: loc.coords.latitude,
      lng: loc.coords.longitude,
      heading: loc.coords.heading,
      at: Date.now(),
    },
  });
}

On the observing device:

useEffect(() => {
  const channel = supabase
    .channel(`session:${sessionId}`)
    .on('broadcast', { event: 'position' }, ({ payload }) => {
      setPeerLocation({ latitude: payload.lat, longitude: payload.lng });
    })
    .subscribe();

  return () => { void channel.unsubscribe(); };
}, [sessionId]);

Broadcast, not database inserts. Inserting every fix burns through row quota and forces observers to poll. If you also need history for a breadcrumb trail or route replay, write to a table on a much slower cadence in addition to the broadcast. Two different jobs, two different mechanisms.

Battery

Continuous high-accuracy GPS is one of the most expensive things an app can do, and the cost scales with accuracy and frequency in roughly the way you'd expect.

The ordering that matters:

Config	Relative cost
`BestForNavigation`, 1 to 2s, foreground	Highest
`Balanced`, 10s, background	Moderate
`Lowest`, 30s, background	Lowest

Absolute numbers depend heavily on device, OS version, and whether the screen is on, so measure on your own target hardware rather than trusting anyone's table, including this one.

The rule that generalises: use the coarsest accuracy and longest interval that still feels responsive, and set pausesUpdatesAutomatically: true, which lets iOS suspend tracking when the user has stopped moving. That last flag is close to free and it does more than most tuning.

Pitfalls

Blank map on Android. Missing android.config.googleMaps.apiKey in app config.
watchPositionAsync never fires in the simulator. The iOS simulator has no GPS. Set a custom location from the simulator's location menu.
Permission dialog on every launch. You're calling request* where you should call get* first and only request when the answer is undetermined.
Background works locally, dies in production. Missing UIBackgroundModes on iOS or foregroundService on Android. Both work fine in development, which is what makes this one expensive.

Skipping the plumbing

If you want the scaffold without the permission archaeology, RapidNative generates the Expo and Supabase project from a description, and the output is real React Native you can export and finish wherever you normally work.

The parts above still need understanding. Generated or not, the OS is going to kill your background task if the foreground service isn't configured, and no scaffold argues with that.

What's your background tracking horror story? Mine was a task that worked for three weeks and then stopped, because the notification the foreground service depends on had been silently disabled by the user.

Reanimated vs Moti vs Skia: Which React Native Animation Library Should You Actually Use?

Hugo Rus — Mon, 24 Aug 2026 11:52:58 +0000

Every React Native team eventually asks the same question: Reanimated, Moti, or Skia?

The framing is wrong. These three don't compete, they compose. Here's the mental model that will save you a bad refactor.

Reanimated is the runtime. The other two depend on it.
Moti is a declarative wrapper over Reanimated. Less code, less control.
Skia is a rendering engine, not an animation library. It accepts Reanimated shared values directly.
Install Reanimated and Moti on day one. Add Skia when the design demands it.
Pick per interaction, not per app.

The one-sentence version of each

Reanimated. The animation runtime. Runs worklets on the UI thread through JSI. Everything else you install depends on it directly or indirectly.

Moti. A Framer Motion-style declarative wrapper over Reanimated. Less code for common transitions.

Skia. Google's 2D graphics engine, the one behind Chrome and Flutter, exposed as React Native components. Not an animation library. A rendering engine that happens to animate beautifully when you feed it shared values.

Reanimated in about ten lines

import Animated, { useSharedValue, useAnimatedStyle, withSpring } from 'react-native-reanimated';

const x = useSharedValue(0);
const style = useAnimatedStyle(() => ({
  transform: [{ translateX: x.value }],
}));

// somewhere in a handler:
x.value = withSpring(200);

return <Animated.View style={[styles.box, style]} />;

x is a shared value, and it lives on the UI thread. useAnimatedStyle is a worklet that reruns when x changes. A blocked JS thread doesn't stutter the animation, which is the entire point.

The same thing in Moti

<MotiView
  from={{ translateX: 0 }}
  animate={{ translateX: 200 }}
  transition={{ type: 'spring' }}
/>

Same worklets underneath. Half the code.

That's the trade: you lose direct access to the shared value, which matters the moment you want to drive it from a gesture. For a mount transition you'll never miss it. For a drag you'll rewrite it.

Where each one wins

You need	Use
A fade-in on mount	Moti
A pan gesture moving a card	Reanimated
A skeleton loader	Moti
Pinch-to-zoom on an image	Reanimated
An animated chart with 60+ points	Skia + Reanimated
A shader-driven splash screen	Skia
A stagger animation on a list	Moti
A blur that follows a bottom sheet	Skia + Reanimated

The composition detail people miss

Skia components accept Reanimated shared values as props directly. No createAnimatedComponent, no useAnimatedProps wrapper.

const progress = useSharedValue(0);

// progress updates, Skia canvas repaints, all on the UI thread
<Canvas style={{ flex: 1 }}>
  <Circle cx={progress} cy={100} r={40} color="hotpink" />
</Canvas>

That single fact is what made Victory Native XL and every other modern chart library possible. Before it, animating a canvas meant round-tripping through JS every frame.

The performance gotcha

You will not hit a performance ceiling because you picked the "wrong" library. All three drive animations on the UI thread.

You will hit one if you animate a property that forces a layout pass every frame. Reanimated can push a shared value at 120fps, but if consuming it triggers layout, you're queued behind that layout and you drop frames regardless of which library issued the update.

Animate transform and opacity. Animating width, height, top, or left is the version of this mistake people actually ship, and all three libraries will let you do it.

The rule I use

Pick per interaction, not per app.

A screen with a draggable card and a hero image wants Reanimated for the drag and Moti for the hero. Separate primitives, separate concerns.

The moment you try to standardise on one library, you make one of those two interactions worse. Usually the drag, because that's the one where the abstraction costs you the handle you needed.

Bottom line

Install Reanimated and Moti on day one. Add Skia when the design demands it. Compose freely.

The interesting part of this generalises past animation: the "pick per interaction" rule is roughly how RapidNative decides which primitive to emit for a given screen, since a prompt describing a drag and a prompt describing a fade want different code.

What's your default? I'm curious how many people reach for Reanimated directly on things Moti would handle in three lines, because I did that for about a year.

We Made Checkout 600ms Faster. Not One User Noticed.

Hugo Rus — Wed, 19 Aug 2026 06:41:56 +0000

We spent a sprint on checkout performance. Prefetched tokens, warmed the payment sheet, bundle-split the checkout screen. End-to-end timing improved by roughly 600ms, which is a real number and visible in the traces.

Then we retested with users. Not one person mentioned speed. Not in the sessions where it was faster, and not in the earlier ones where it wasn't.

Everything they did mention fell into one category, and it wasn't performance.

Measurable speed improvements produced zero user comments in moderated retests
Every drop-off users could articulate was a trust problem, not a latency problem
Biometric confirmation changed how users described an otherwise identical flow
Stripe's default decline message reliably reads as "your card is fraud-flagged"
We now review payment flows against four trust questions before touching perf

This is a follow-up. The earlier findings from this testing (the double-tap problem and the total-mismatch problem) are in the first writeup; this post covers what surfaced afterwards.

Users drop off at trust moments, not slow moments

That's the headline and it took us a sprint of wasted effort to learn.

When someone abandons a checkout, they can usually tell you why, and the reason is almost always about confidence rather than time. Nobody says "that took 900 milliseconds and I was unwilling to wait." They say some version of "I wasn't sure what was happening" or "that didn't feel right."

Latency matters when it creates a trust problem. A tap that produces no visible response for half a second reads as a broken button, and the user taps again. That's a trust failure caused by latency, and fixing the latency fixes it. But shaving 600ms off a flow that already felt responsive changed nothing anyone could perceive.

If you have a fixed budget for a payment flow rebuild, spend it on the four things below before you open a profiler.

Biometrics change how the same flow feels

This one surprised us most.

Users describing the flow with a Face ID confirmation on the final tap used the word "safe." The same users describing the flow without it reached for "kind of sketchy," "is this the real app," and "I don't know if it went through."

Same gateway. Same UI. Same latency. The only delta was a native biometric prompt before presenting the sheet.

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

async function confirmAndPay() {
  const hasHardware = await LocalAuthentication.hasHardwareAsync();
  const isEnrolled = await LocalAuthentication.isEnrolledAsync();

  if (hasHardware && isEnrolled) {
    const result = await LocalAuthentication.authenticateAsync({
      promptMessage: 'Confirm your purchase',
      fallbackLabel: 'Use passcode',
    });
    if (!result.success) return;
  }

  await presentPaymentSheet();
}

Note the graceful degradation. Devices without enrolled biometrics fall through to the sheet rather than blocking the purchase, which matters more than it sounds — gating checkout behind hardware some users don't have is a worse problem than the one you're solving.

The interesting part is that nobody asked for this. No user in any session said "I wish this had Face ID." They just described the version without it as untrustworthy, in language they'd never have produced in response to a survey.

Stripe's default decline copy is actively harmful

"Your card was declined."

Technically accurate. In sessions, users read it as your card has been flagged, assumed something was wrong with their account rather than with this transaction, and several closed the app entirely rather than trying another card.

The fix is mapping decline codes to plain language plus a recovery action:

const DECLINE_COPY: Record<string, { message: string; action: string }> = {
  insufficient_funds: {
    message: 'Your bank says there are insufficient funds on this card.',
    action: 'Try a different card',
  },
  incorrect_cvc: {
    message: "The security code didn't match.",
    action: 'Re-enter card details',
  },
  expired_card: {
    message: 'This card has expired.',
    action: 'Use a different card',
  },
  generic_decline: {
    message: 'Your bank declined this charge. This is usually temporary.',
    action: 'Try a different card',
  },
};

Two details that matter more than the copy itself. Attribute the decline to the bank, not to your app, because users who think your app rejected them do not retry. And make the recovery action reopen the sheet with the cart intact, rather than dumping them back at the top of checkout, which is a second abandonment opportunity you built yourself.

Show the real total before the sheet opens

Related to but distinct from the total-mismatch problem in the first writeup: it isn't only that the numbers must match, it's when the user learns the final number.

Fees and taxes computed server-side and revealed inside the payment sheet are technically visible, but by then the user has anchored on the cart price. A higher number appearing at the moment of payment reads as a bait-and-switch even when the delta is trivial. Forty cents is enough.

Compute the full total, including tax and fees, on the cart screen, with a breakdown available on tap. The number the user commits to should be the number they pay.

The four questions we ask now

Before any payment flow work, in this order:

Is the complete total, including all fees, visible before the sheet opens?
Is there a biometric confirmation on the final tap, with a sensible fallback?
Does the tap produce a visible response immediately, ideally by prewarming the sheet?
Are error states mapped to plain-English copy with a working recovery path?

Visual polish, sheet customisation, and perf tuning all come after these. Not because they don't matter, but because in our testing they didn't move the thing we were trying to move.

If you're scaffolding a new project rather than repairing one, starting from checkout screens that already have the biometric gate, prewarmed sheet, and mapped error states wired in removes most of this before it exists. It's part of what RapidNative generates for Expo projects.

What I'd tell past me

Run the sessions before the sprint, not after.

We built the perf work because it was legible, measurable, and felt like the responsible engineering choice. It was also unfalsifiable in the only way that mattered: we could prove it worked in a trace and never prove it worked on a person.

Twelve moderated sessions cost less than the sprint did.

What's the last checkout change you shipped that moved a real number? I'm collecting the ones that worked, and my suspicion is that almost none of them are performance.

How AI Is Making Mobile Accessibility Easier Than Ever

Hugo Rus — Mon, 17 Aug 2026 08:18:54 +0000

The OS is now covering for your mistakes: VoiceOver and TalkBack generate descriptions for unlabeled elements on device
Automated audits catch more than they used to, but still not everything
Generated alt text and captions fill in content nobody authored
The real shift is at code-generation time, where accessibility props come free with the component
None of it replaces turning on a screen reader and trying to complete your own primary flow

The WebAIM Million 2026 report found detectable accessibility failures on 95.9% of the top one million websites, averaging 56 errors per page. Mobile apps fare no better. For every "download now" button on the App Store, there are thousands of screens that fail a basic screen-reader test.

The gap between the number of apps shipping and the number shipping accessibly has been widening for a decade. What changed in the last twenty-four months is that AI, on both sides of the shipping fence, is finally starting to narrow it: sometimes in the runtime layer (the phone itself), sometimes at the tooling layer, and most importantly at the code-generation layer where the app is being built in the first place.

This is a survey of what's actually working in 2026, what still isn't, and what you should assume when writing or generating a mobile app today. AI mobile accessibility isn't one thing. It's four overlapping shifts happening at once.

Why mobile accessibility is harder than the web

Mobile accessibility is harder than web accessibility because native apps don't share a common semantic model. There's no HTML. Each platform has its own accessibility tree (UIAccessibility on iOS, AccessibilityNodeInfo on Android), each screen reader has different gesture conventions, and third-party UI frameworks each introduce their own translation layer. A "correct" label in one framework can be silently dropped by the OS on the other platform.

There are roughly 1.3 billion people worldwide with a significant disability, per the World Health Organization, and most of them own a phone. Touch-first, screen-heavy, notification-driven experiences make almost every category of disability harder: low vision (contrast, dynamic type), blindness (screen reader), motor impairment (small touch targets, gestures), deaf and hard of hearing (video without captions), cognitive (dense UI, poor error recovery).

Compliance pressure is catching up. The European Accessibility Act took effect for consumer-facing digital products in June 2025, so any app doing business in the EU now has a legal obligation. WCAG 2.2 is the current baseline. In the US, ADA Title II requires state and local government mobile apps to meet WCAG 2.1 AA by April 2026.

Regulation without automation is a punishment. AI is what makes the automation possible.

Shift 1: On-device assistive AI is doing the work the app didn't

The phone itself has quietly become a better citizen for users with disabilities.

VoiceOver image descriptions. iOS added an on-device model that generates descriptions for photos and unlabeled UI elements. If an app ships a button with no accessibility label, a mistake that used to leave a blind user with "Button, button, button," VoiceOver will now attempt to describe the icon: "Button, likely a play triangle."

TalkBack image descriptions. Android's TalkBack uses an on-device model to produce contextual descriptions for images, including images inside third-party apps that never bothered to add contentDescription.

Live Captions everywhere. Both platforms now produce real-time captions for any audio playing on the device, in any app. A video without captions is no longer a dead end.

Voice Control got smarter. It now understands intent, not just label matching. "Tap the little heart" works even when the accessibility label is favoriteButton.

The consequence for developers is subtle but important: the floor is rising, but the ceiling isn't. The OS can make a mediocre app tolerable. It can't turn a badly structured screen into a well-structured one. VoiceOver's guess of "Button, likely a heart" will always lose to a labeled "Add to favorites" button that also announces its state.

Shift 2: AI-powered testing catches what humans miss

Accessibility auditing used to be a slow, manual, checklist-driven job: expensive to do well, easy to skip.

Static analysis got better. axe-core, axe DevTools Mobile, and Google's Accessibility Scanner have added ML on top of their rule engines. They now catch things a pure static analyzer couldn't, such as an image whose label is technically present but semantically meaningless (contentDescription="image1.jpg"), or a button that looks tappable but has no accessibility role.

Visual regression plus ML. A category of tools diffs screenshots against a corpus of known-good accessible screens, flagging suspicious contrast ratios, small tap targets, and low-legibility fonts.

LLM-based audits. A newer category runs a model over rendered screens (screenshots plus accessibility tree dumps) and returns natural-language findings: "The 'Sign in with Apple' button has no accessibility label; VoiceOver will announce it as 'Button'." This is the most useful class during development, because it produces something a developer can act on.

None of these replace real users on real devices. But they collapse a first-pass audit from days to minutes, which means the audit actually happens.

The honest limit: WebAIM's own analysis suggests even the best automated tools catch only 30 to 40% of WCAG failures. AI raises that, but not to 100%.

Shift 3: Generative AI creates the missing content

Alt text generation. Vision-language models produce reasonable alt text in one call. Meta's platforms auto-generate it for uploaded images, browsers do it in-page, and screen readers do it when the app forgets.

Captions and audio descriptions. Whisper and its successors made speech-to-text good enough for accessibility-quality captions in most languages. AI-generated audio descriptions of visual scenes are becoming usable for consumer content, though not yet reliable for critical use cases.

Simplified-language modes. LLMs producing plain-language versions of complex content on the fly is a genuine breakthrough for users with cognitive disabilities and non-native speakers.

The pattern: content that was never authored, because authoring it was too expensive or simply forgotten, is now generated at read time. That's a real win. It also creates a subtler failure mode. AI-generated descriptions are only usually correct, and a screen reader confidently reading a subtly wrong description is worse than one that says nothing.

Shift 4: AI-assisted development is where accessibility actually gets fixed

This is the shift that matters most, because it puts accessibility in the code instead of on top of it.

For twenty years accessibility has lost the priority fight against feature velocity. When a team is racing to ship, "add accessibility labels to all the buttons on this screen" is the last-day task that gets cut. When a team isn't racing, the work is boring enough that even senior engineers avoid it.

AI-assisted development inverts that. When a model generates the UI code in the first place, a proper label isn't extra work, it's part of the same generation. Here's the difference in practice:

// What most generators emitted a couple of years ago
<TouchableOpacity onPress={handleFavorite}>
  <HeartIcon />
</TouchableOpacity>

// What accessibility-aware generation emits now
<TouchableOpacity
  onPress={handleFavorite}
  accessibilityRole="button"
  accessibilityLabel="Add to favorites"
  accessibilityState={{ selected: isFavorited }}
  accessibilityHint="Adds this item to your favorites list"
>
  <HeartIcon />
</TouchableOpacity>

The first version is what a screen reader user hits constantly: an unlabeled tap target that announces nothing about what it does or whether it's already active. The second costs the generator four extra props and costs the developer nothing.

This is where RapidNative fits. It generates real React Native and Expo code from a natural language prompt, and the output isn't a webview wrapper, it's native components with actual accessibility props attached. Because the model generating the screen also generates the accessibility layer in the same pass, an image comes out as accessibilityLabel="Sunset over the ocean" rather than a nameless <Image /> someone will theoretically come back to label.

This isn't unique to one tool. A well-prompted Copilot, Cursor, or Claude does the same thing in a hand-written codebase. What generation changes is the default. The path of least resistance shifts from "no labels, ship it" to "labels included, they came free."

What AI still can't do

If you take away one thing, take this: AI raises the floor dramatically, but the ceiling still requires humans.

AI can't tell you if your screen reader flow is usable, only that labels exist. A screen with a "Buy" button labeled "Buy" and a price labeled "$29.99" can be technically compliant and still confusing, because the reading order jumps around.
Generated alt text is generic. "A person" is compliant. "The founder of the company you're about to donate to" is what a sighted user sees. Only a human knows which matters here.
Cognitive accessibility is barely automatable. Overwhelming UIs, confusing flows, error messages written for engineers. A model can flag some of it, but the fix is design work, not a tag.
Live captioning makes contextually catastrophic errors. The wrong medication name, the wrong price, the wrong date. Plausible-but-wrong is a special failure mode for exactly the users you were trying to help.
Motor and cognitive disability are poorly covered. Most tooling targets low-vision and blindness because those map onto structured tests. Touch targets, timing constraints, error recovery, and reading load are much harder to automate.

The right framing: AI is your first line of defense, the intern who catches the obvious stuff at 10x human speed. It doesn't replace the specialist. It makes their work higher-leverage.

A checklist for AI-generated apps

Every interactive element has an accessibilityLabel, plus accessibilityHint and accessibilityRole where appropriate.
Images are labeled or explicitly marked decorative. No unlabeled <Image /> in production.
Text contrast passes WCAG 2.2 AA (4.5:1 body, 3:1 large text). Default palettes usually pass; custom color changes need rechecking.
Dynamic Type and font scaling work. Layouts shouldn't break at 200% text size.
Touch targets are at least 44x44 points. The single most-violated rule in generated code, because models over-index on clean small icons.
Forms have labels, not just placeholders. A placeholder disappears the moment the user types.
Videos have captions, or use the platform's live-caption support.
Test with VoiceOver and TalkBack yourself. Fifteen minutes completing your primary flow with a screen reader on will find things no automated audit will.

Points 3 through 5 are the ones most worth manually verifying after any design tweak, whatever generator you're using.

Where this is heading

WCAG 3.0 moves away from binary pass/fail toward outcome-based scoring, which suits AI evaluation far better. "This screen scores 82% for the low-vision population" is something a model can output. Binary pass/fail isn't.

EAA enforcement in Europe will start producing case law and fines, which changes the internal politics of accessibility work at product companies. It stops being a "when we get around to it" project.

AI-native compliance tooling. Expect tools that sit alongside the development pipeline rather than auditing finished apps: reviewing PRs, gating deploys, producing an audit trail for compliance evidence.

The direction of travel is that accessibility becomes a property of how the app was built, not something painted on afterward.

Ship accessibly by default

Mobile apps haven't been bad at accessibility because developers don't care. The work is invisible, the tests are boring, the labels are last-minute, and the priority always loses to the next feature.

AI doesn't change the priority argument. It changes the cost of doing the right thing. On-device AI covers for oversights, testing AI catches issues before shipping, generative AI fills in missing content, and generative development bakes the props in from the first draft.

If you're building a mobile app in 2026: use a generator that emits accessible code, verify the parts AI can't check (real screen-reader flows, cognitive load, motor targets), and treat the OS-level assistive AI as a backstop rather than a plan.

What's the worst accessibility bug you've shipped and caught later? Mine was a modal that VoiceOver read straight through, announcing the entire screen behind it. Drop yours in the comments.

Porting a Lovable App to React Native: The Translation Table Nobody Gives You

Hugo Rus — Fri, 14 Aug 2026 06:08:28 +0000

You built something in Lovable over a weekend. It works. Now you want it on a phone, and you've discovered the thing the marketing pages skip: Lovable builds React web apps, not React Native ones.

The usual advice is "wrap it in Capacitor." That advice has a failure mode I'll get to. First, the actual work, because if you're going to port this thing you should know what porting means.

Lovable emits React DOM: div, span, input, Tailwind classes, shadcn/ui, react-router
None of those exist in React Native. Not "work differently." Do not exist.
Your Supabase layer ports over essentially unchanged, which is most of your backend work saved
Wrapping in a webview risks an App Store rejection under Guideline 4.2
Budget the port at the UI layer and nowhere else

The Translation Table

This is the part you actually need. Every Lovable-generated component maps to something, or to nothing.

React DOM (Lovable)	React Native
`<div>`	`<View>`
`<span>`, `<p>`, `<h1>`	`<Text>`
`<input>`	`<TextInput>`
`<button onClick>`	`<Pressable onPress>`
`<img src>`	`<Image source>` or `expo-image`
`<a href>`	`<Link>` from expo-router
`<ul>` / `.map()`	`<FlatList>`
`onChange={e => e.target.value}`	`onChangeText={text => ...}`
`localStorage`	AsyncStorage or MMKV
`react-router-dom`	expo-router
Tailwind classes	NativeWind, or `StyleSheet.create`
shadcn/ui	no direct port. gluestack-ui or Tamagui

Two entries there are bigger than they look.

react-router-dom to expo-router is not a swap, it's a restructure. Web routing is a component tree. Expo routing is file-based with native stack and tab semantics underneath. Do this first, before you touch individual screens, or you'll do the screens twice.

shadcn/ui has no port. It's built on Radix, which is built on DOM primitives. Every shadcn component in your Lovable project is a rewrite. This is usually the single largest line item in the whole migration.

What This Looks Like in Practice

Here's a login form the way Lovable writes it:

// Lovable output
export function LoginForm() {
  const [email, setEmail] = useState('');
  const navigate = useNavigate();

  return (
    <div className="flex flex-col gap-4 p-6">
      <h1 className="text-2xl font-bold">Sign in</h1>
      <input
        className="border rounded px-3 py-2"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="Email"
      />
      <button
        className="bg-blue-600 text-white rounded py-2 hover:bg-blue-700"
        onClick={() => navigate('/home')}
      >
        Continue
      </button>
    </div>
  );
}

And the same thing in React Native:

// React Native
import { View, Text, TextInput, Pressable, StyleSheet } from 'react-native';
import { useRouter } from 'expo-router';

export function LoginForm() {
  const [email, setEmail] = useState('');
  const router = useRouter();

  return (
    <View style={styles.container}>
      <Text style={styles.heading}>Sign in</Text>
      <TextInput
        style={styles.input}
        value={email}
        onChangeText={setEmail}
        placeholder="Email"
        autoCapitalize="none"
        keyboardType="email-address"
      />
      <Pressable style={styles.button} onPress={() => router.push('/home')}>
        <Text style={styles.buttonText}>Continue</Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flexDirection: 'column', gap: 16, padding: 24 },
  heading: { fontSize: 24, fontWeight: 'bold' },
  input: { borderWidth: 1, borderRadius: 6, paddingHorizontal: 12, paddingVertical: 8 },
  button: { backgroundColor: '#2563eb', borderRadius: 6, paddingVertical: 8 },
  buttonText: { color: '#fff', textAlign: 'center' },
});

Four things changed that aren't obvious from the table:

The button label needed its own <Text>. You cannot put a bare string inside a Pressable. Every piece of text on screen lives in a Text node, always.
hover:bg-blue-700 vanished. There's no cursor. If you want press feedback you write it, usually via Pressable's style callback.
autoCapitalize and keyboardType appeared. Mobile keyboards are configurable and the defaults are wrong for email. Web never made you think about this.
textAlign: 'center' moved onto the text, not the container. Style inheritance doesn't cascade in React Native. Text styling has to live on the Text node.

That fourth one accounts for a genuinely stupid share of "why does this look wrong" debugging.

Things That Silently Do Nothing

These compile, run, and have no effect. No warning, no error.

// all of this is ignored
<View style={{
  position: 'fixed',        // only absolute and relative exist
  display: 'grid',          // flexbox only
  boxShadow: '0 2px 4px',   // use shadowColor/shadowOffset, or elevation on Android
  cursor: 'pointer',        // no cursor
  overflow: 'scroll',       // you need ScrollView, this won't do it
}} />

That last one bites hard. On the web, content longer than the viewport scrolls by default. In React Native, content that overflows a View is just clipped and gone. If a Lovable screen had a long form, it scrolled for free, and after the port it won't. Wrap it in ScrollView and remember KeyboardAvoidingView, because the on-screen keyboard covers about half the display and users can't see the field they're typing into.

The Good News: Your Backend Ports Clean

If your Lovable app uses Supabase, and it probably does, that entire layer moves over almost untouched. Same supabase-js, same queries, same auth calls, same RLS policies.

// works identically in both
const { data, error } = await supabase
  .from('projects')
  .select('*')
  .eq('user_id', user.id);

You do need to configure storage for native:

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

export const supabase = createClient(url, anonKey, {
  auth: {
    storage: AsyncStorage,
    autoRefreshToken: true,
    persistSession: true,
    detectSessionInUrl: false, // required on native
  },
});

detectSessionInUrl: false stops the client from trying to parse a browser URL that doesn't exist. Miss it and you'll chase a null session for an hour.

So the real scope of the port is: the entire UI layer, all of routing, and none of your data model. That's better than it sounds on day one and worse than it sounds on day three.

Why Wrapping It Is a Trap

The shortcut everyone reaches for is Capacitor or a webview shell. It genuinely works, in the sense that you get a binary.

The problem is App Store Review Guideline 4.2, minimum functionality. Apple rejects apps that are essentially a repackaged website with no native capability. There's no bright line, which is the worst kind of rule to build a launch schedule around. Apps with real offline behavior, push notifications, and device integration get through. A wrapped CRUD dashboard frequently doesn't, and you find out after you've built everything else.

If the app is a genuine web product and you want distribution, a PWA is honest and cheap. If you want an App Store listing that survives review, you want native components underneath.

If You'd Rather Not Do the Port by Hand

The port above is mechanical, which is exactly the kind of work worth handing off. RapidNative converts Lovable projects into React Native and Expo apps and takes them through submission: signing, certificates, screenshots, metadata, privacy labels, data safety forms. You get the source, so this isn't a black box you're stuck with. If either store rejects, they fix and resubmit at no extra cost until it's live, which is the part that actually de-risks the 4.2 problem above. Typical turnaround is one to two weeks.

Whether you hand it off or grind through it manually, the translation table above is what's actually happening underneath. Worth understanding either way, because you'll be debugging it.

The Short Version

Lovable is a good tool pointed at the web. React Native is a different rendering target, not a different flavor of the same one. The port is real work concentrated almost entirely in the UI layer, your Supabase code comes along for free, and the wrapper shortcut trades a week of porting for an unbounded risk at review time.

What tripped you up most on a web-to-native port? I'm collecting the silent-failure list and overflow: scroll is only number two.

React Native i18n in 2026: A Practical Expo Router Playbook

Hugo Rus — Mon, 03 Aug 2026 07:22:27 +0000

If your React Native app only speaks English, you're leaving most of the world's smartphone users on the table. Here's the modern stack for shipping a multilingual Expo app without three days of glue code.

The Stack

react-i18next for translation management (TypeScript-first, the default choice in the RN ecosystem)
expo-localization for device locale detection (or react-native-localize for bare RN)
Intl for dates, numbers, currencies (built into Hermes)
I18nManager for RTL layout flipping

Setup in 4 Steps

1. Install

npx expo install expo-localization
npm i i18next react-i18next

2. Translation files

locales/
  en.json
  es.json
  ar.json

{
  "welcome": "Welcome",
  "cart": {
    "itemCount_one": "{{count}} item",
    "itemCount_other": "{{count}} items"
  }
}

Use the ICU plural suffixes (_one, _other, _few, _many, _zero). Arabic has six plural forms. Get this right on day one.

3. Bootstrap

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

const deviceLocale = Localization.getLocales()[0]?.languageCode ?? 'en';

i18n.use(initReactI18next).init({
  compatibilityJSON: 'v4',
  resources: {
    en: { translation: en },
    es: { translation: es },
    ar: { translation: ar },
  },
  lng: deviceLocale,
  fallbackLng: 'en',
  interpolation: { escapeValue: false },
});

export default i18n;

Two production-important bits: compatibilityJSON: 'v4' for modern plural rules, and escapeValue: false because RN already escapes JSX.

4. Wire into Expo Router

// app/_layout.tsx
import { Stack } from 'expo-router';
import './i18n';

export default function RootLayout() {
  return <Stack />;
}

Then in any component:

import { useTranslation } from 'react-i18next';

const { t } = useTranslation();
<Text>{t('cart.itemCount', { count: 3 })}</Text>
// "3 items"

The Gotchas Nobody Warns You About

Never concatenate around t(). Word order changes across languages:

// ❌ Breaks in Japanese, German, Arabic
<Text>{t('hello')} {user.name}!</Text>

// ✅ Whole sentence is one key
<Text>{t('greeting', { name: user.name })}</Text>

RTL doesn't flip everything. Flexbox auto-flips, but you'll need to fix:

left/right, use start/end
Directional icons, wrap in transform: [{ scaleX: -1 }] when I18nManager.isRTL
Hardcoded textAlign

Hardcoded strings in third-party UI kits. Buttons in libraries like RN Elements ship English defaults. Override or pick i18n-aware libs.

Push notifications aren't localized by the phone. Your backend has to send the localized copy or use OS-level notification categories.

Formatting

Never string-concat dates or currencies. Use Intl:

new Intl.DateTimeFormat(i18n.language, { dateStyle: 'medium' }).format(new Date());
new Intl.NumberFormat(i18n.language, { style: 'currency', currency: 'USD' }).format(29.99);

Add @formatjs/intl-datetimeformat polyfills if you need older Android or less common locales.

Testing Discipline

Turn on saveMissing in dev. react-i18next logs every missing key. Fail CI on any.
Pseudo-localize with en-XA. Surfaces hardcoded strings and 30 to 40% longer text for layout stress-tests.
Snapshot per locale. French, German, and Arabic snapshots catch layout regressions.

Shortcut

If you're starting fresh, RapidNative generates the whole i18n scaffold, provider, layout wiring, translation files, RTL flags, from a natural-language prompt. You get the same setup you'd write by hand, in about 30 seconds.

Otherwise: ship it. It's 2 to 3 days of setup and it opens the app to a much larger share of the market.

How to Build a Pet Care App with React Native (2026)

Hugo Rus — Fri, 31 Jul 2026 10:28:00 +0000

Pet care is a well-scoped React Native project: bounded features, cross-platform demand, forgiving users.
MVP is five features: pet profile, health record, appointment tracker, feeding log, push notifications.
Stack: Expo SDK 52+, TypeScript, Expo Router, Supabase, NativeWind, FlashList.
Store UTC in the database, render local with date-fns-tz, or your 8 AM reminder fires at 3 AM after a flight.
Store next_due_at per row. Rabies schedules differ by jurisdiction.
Realistic timeline: 4 to 6 weeks solo if you know React Native, 10 to 12 if you are learning the stack alongside.

The pet care market keeps growing, and mobile apps are eating an increasing share of it: vet booking, vaccination reminders, feeding schedules. If you've been looking for a well-scoped React Native project to ship, a pet care app is genuinely one of the best options. Bounded feature set, cross-platform relevance, and a user base that's forgiving of a rough v1 as long as it solves a real problem.

Here's the practical build guide, from stack decisions through App Store submission.

Why React Native fits pet care apps

Pet care apps need cross-platform reach (pet owners split evenly between iOS and Android), rich UI (photo-heavy profiles), and native features like push notifications and camera. That is the exact sweet spot for React Native with Expo. They also have a naturally scoped MVP: pet profiles, health records, appointments, reminders. You can ship in weeks, not months.

The MVP feature set

Ship these five features first. Adding a sixth before nailing edge cases (multi-species schedules, deleted pets, timezone-sensitive reminders) is the fastest way to never launch.

Pet profile. Name, species, breed, DOB, weight, photo, microchip ID
Health record. Vaccinations with next-due dates, medications, allergies
Appointment tracker. Vet visits, grooming, boarding with reminders
Feeding log. Food type, portion, schedule
Push notifications. Vaccinations, medications, appointments

The stack

React Native with Expo SDK 52+
TypeScript (non-negotiable for anything you ship)
Expo Router for file-based routing
Supabase for hosted Postgres + auth
NativeWind for Tailwind-style styling
expo-notifications for local push
FlashList (not FlatList) for photo-heavy timelines

Scaffold it

npx create-expo-app@latest pet-care-app --template
# choose "Navigation (TypeScript)"
cd pet-care-app
npx expo install expo-notifications expo-image-picker expo-file-system
npm install nativewind zustand @supabase/supabase-js date-fns

Route structure

app/
  (tabs)/
    _layout.tsx           # Pets | Schedule | Records | Settings
    index.tsx             # pet list
    schedule.tsx
    records.tsx
    settings.tsx
  pet/
    [id].tsx
    [id]/health.tsx
    [id]/appointments.tsx
  appointment/new.tsx
  vaccination/new.tsx

Decide the route tree before writing screens. Nesting everything under (tabs)/pets/[id]/... will bite you when you need to push a full-screen modal.

Data model

Four entities cover the MVP:

Entity	Key fields
`pets`	id, owner_id, name, species, breed, date_of_birth, weight_kg, photo_url
`vaccinations`	id, pet_id, name, administered_at, next_due_at
`appointments`	id, pet_id, type, starts_at, location, notes
`feedings`	id, pet_id, food_name, portion_grams, scheduled_at, given

Two things matter more than you'd expect:

Store next_due_at on the row. Rabies is annual in some jurisdictions, triennial in others. Don't hardcode.
Store UTC in the DB, render local with date-fns-tz. Get this wrong and a reminder set for 8 AM triggers at 3 AM after a flight.

Push notifications the right way

The single feature that separates useful pet apps from forgettable ones:

import * as Notifications from 'expo-notifications';

await Notifications.scheduleNotificationAsync({
  content: {
    title: `${pet.name}'s ${vaccination.name} is due`,
    body: 'Book a vet appointment to stay on schedule.',
    data: { petId: pet.id, vaccinationId: vaccination.id },
  },
  trigger: { date: nextDueAt },
});

Two rules:

Request permissions gracefully. Show a "why" screen before the OS prompt.
Reschedule on AppState.change when the app foregrounds. Timezone and DST drift is real.

The 4 to 6 week problem

Honest timeline for a solo developer: 4 to 6 weeks for a shippable MVP if you're comfortable with React Native. 10 to 12 weeks if you're learning Expo, TypeScript, and Supabase alongside.

Most of that time is boilerplate. Layout, navigation wiring, spacing, empty states, forms. None of it is the interesting part of building a pet care app.

The AI-first shortcut

Tools like RapidNative generate a working React Native + Expo codebase from a natural-language description. The workflow:

Describe the app: "A pet care app with pet profiles, vaccination tracking, appointment reminders, and a schedule tab across all pets."
Get a working app in a few minutes.
Scan a QR code, preview on your real phone.
Click any element to describe changes ("make these cards bigger, add a soft green tint when a task is done").
Export the full React Native + Expo source, or publish directly to the stores.

Same output, a real React Native app, different path. Worth trying on the boring 80% of the build so you can spend time on the interesting 20%.

App Store gotchas specific to pet apps

Three things reviewers catch:

Health claims. Track vaccinations and meds without positioning as a medical device. Be explicit in the description.
Background location. If you add walk tracking, justify the permission concretely: "To log your dog's walk route while your phone is in your pocket."
Screenshots. Empty-state screenshots underperform dramatically. Show real pets with real data.

Use eas submit. It handles both stores and eliminates most rejection loops.

Wrapping up

The features are the easy part. Reliable reminders, offline-first data, and fast photo handling are what separate 5-star pet apps from abandoned ones. Nail those, ship a focused MVP, and let owners tell you what's missing.

The manual scaffold above should get you to a working v1 in about a month.

If you're building something in this space, drop a comment with what you're working on. Curious whether anyone has solved multi-pet, multi-timezone reminders cleanly, because that one still feels unsolved to me.

The 4 Notification Categories Users Actually Whitelist (Based on 60 App Interviews)

Hugo Rus — Wed, 29 Jul 2026 05:06:49 +0000

Users whitelist only four notification categories: someone they know did something involving them, a thing they explicitly set up, a transaction they're expecting, and a time-critical alert from a system they trust.
Everything else — feature announcements, recommendations, streaks, re-engagement, promos — gets muted within two weeks.
Users pattern-match to category, not copy. Better push copy optimizes the wrong variable.
Per-category in-app consent (not one system prompt) moved opt-in from 41% to 73% and dropped 30-day mute rate from 34% to 9% in one test.

Over the last six weeks I interviewed 60 people about their phone's notification settings. I asked each to open Settings → Notifications, scroll through every app, and tell me the story behind why each one was on, off, or set to silent delivery.

The pattern was sharper than I expected. Users don't allow or block push app-by-app. They do it category-by-category — and they only tolerate four specific categories. Everything else gets muted within two weeks.

The four categories users whitelist

Across 60 interviews, people named the same four types of notification as ones they actively want:

1. Someone I know did something involving me. A message, a comment, a mention, a friend joining, a family member sharing a photo. Nearly everyone said they never mute these.

2. A thing I explicitly set up. Alarm, reminder, calendar event, medication, workout time. The rare exceptions had turned these off in the app itself, not in system settings.

3. A transaction I'm expecting. Delivery updates, ride arrival, payment confirmation, booking status. Widely kept on, though several used silent delivery to soften the interruption.

4. A time-critical alert from a system I trust. Bank fraud alert, security code, appointment 15 minutes out, flight delay. Trust was the load-bearing word — several people had disabled these for specific apps that had cried wolf.

Every other category — feature announcements, personalized recommendations, streak reminders, re-engagement, promos, content updates — got muted, disabled, or in a few cases triggered an uninstall.

Why category beats copy

The standard growth advice is "write better push copy." A/B test the emoji, tighten the CTA, personalize with the user's name.

That optimizes the wrong variable.

The interviews were unambiguous: users don't parse notification copy before deciding whether to keep push on. They pattern-match to the category. Once your app has sent two notifications from a category they don't want, they mute the whole app — no matter how good the copy was.

So the design question isn't "how do we write a compelling notification?" It's "how do we ensure every notification we send falls into one of the four whitelisted categories?"

The consent conversation to have in-app

The iOS system dialog is a blunt instrument: one yes/no for all future notifications. What users actually want is category-level consent — which iOS supports through notification categories, but almost no app uses well.

The pattern I now recommend:

import * as Notifications from 'expo-notifications';

type Category = 'social' | 'reminders' | 'transactions' | 'security';

async function setupNotificationCategories() {
  await Notifications.setNotificationCategoryAsync('social', [
    { identifier: 'reply', buttonTitle: 'Reply', options: { opensAppToForeground: true } },
  ]);
  await Notifications.setNotificationCategoryAsync('reminders', []);
  await Notifications.setNotificationCategoryAsync('transactions', []);
  await Notifications.setNotificationCategoryAsync('security', []);
}

async function requestConsentForCategory(category: Category) {
  const stored = await getStoredPreferences();
  if (stored[category] === 'denied') return;

  // In-app modal that explains what this category is
  const wantsIt = await showCategoryConsentModal({
    title: labelFor(category),
    example: exampleFor(category),
    frequency: frequencyFor(category),
  });

  await savePreference(category, wantsIt ? 'granted' : 'denied');

  if (wantsIt) {
    const { status } = await Notifications.getPermissionsAsync();
    if (status !== 'granted') {
      await Notifications.requestPermissionsAsync();
    }
  }
}

The in-app modal does the real work. It shows a concrete example of the notification the user would receive, states roughly how often ("a few times per week," not "occasionally"), and lets them opt in per category rather than for everything at once.

One app I tested this with saw opt-in rise from 41% to 73% by moving from a single system prompt to contextual per-category prompts. More importantly, 30-day mute rate dropped from 34% to 9%.

The signal every PM misses: silent delivery

iOS's "Deliver Quietly" lets users keep receiving your notifications but hide them from the lock screen and Notification Center. It's a soft mute — chosen when someone wants the app's data but not the interruption.

Most PMs don't track it, because iOS doesn't report it. But you can infer it: if a user's open rate on pushes drops to near-zero while their app opens stay steady, they've likely moved you to Deliver Quietly.

Segment those users. They're one bad broadcast away from a full mute or uninstall. For them, cut sends by 60–80% and fire only category 1 and 3 notifications (people-related and transactional). I've seen apps recover full-delivery status this way for a meaningful share of the quietly-delivered segment.

Redesign around user-declared intent

The biggest shift from these interviews: the notifications users keep are tied to intent they expressed inside the product. They set the reminder. They ordered the food. They followed the person. They asked the bank to alert on fraud.

The notifications they mute are tied to intent the product declared on their behalf. "We think you'd love this new feature." "We noticed you haven't opened us in a week." "Here's a personalized recommendation."

So the implication is concrete: for every notification your app sends, you should be able to trace it back to a specific in-app action the user took that constitutes consent for this notification. If you can't, it belongs in the mute pile. If you can, you're building the trust that keeps push on for the lifetime of that user.

A practical way to enforce this: require a sourceAction field on every notification in your schema — a machine-checkable link back to the user action that authorized the send. It's an annoying constraint at first. Then it becomes the reason your app is still on the lock screen six months in, when competitors have been muted.

Run the interviews yourself. Ten users, thirty minutes each. You'll come back with a notification strategy your PM would never sign off on — and your users will actually welcome.

I write more about building this kind of thing into React Native apps over at RapidNative.

Which of the four categories does your app mostly send? And have you ever caught yourself sending from the mute pile?

Introducing tinbase: A Docker-Free, Supabase-Compatible Backend on Real Postgres

Hugo Rus — Mon, 27 Jul 2026 13:30:19 +0000

tinbase is an open-source (MIT) backend that speaks the Supabase API but runs as a single process on real Postgres 17 — no Docker, no container orchestration.
It's supabase-js compatible, so a lot of existing Supabase client code points at it unchanged.
Because it drops the container requirement, it runs where the full stack can't: lightweight CI, low-spec machines, and in the browser.
Built by Sanket Sahu. MIT-licensed and open to contributions.

If you've run Supabase locally, you know the ritual: install Docker, start the stack, wait for Postgres, GoTrue, PostgREST, Realtime, and Storage to spin up, and watch your laptop fans kick in.

For a lot of workflows — quick local iteration, CI, teaching, browser sandboxes — that's more machinery than the task needs.

tinbase is a different bet: the Supabase API surface, on real Postgres, as one process.

What it actually is

tinbase is an open-source backend that provides Supabase-compatible APIs while running as a single process on PostgreSQL 17, with no Docker requirement.

The design goals in one line each:

Real Postgres, not a shim. It runs on Postgres 17, so SQL behavior matches production. No SQLite dialect gaps to trip over when you deploy.
supabase-js compatible. Client code written against Supabase can, in many cases, point at a tinbase instance without changes.
Single process, no Docker. One thing to start. No container stack to orchestrate or resource-tune.
Runs in the browser. Because it sheds the container requirement, tinbase can run in environments a Docker stack simply can't — including in-browser sandboxes.
MIT-licensed. Fully open source. Inspect it, self-host it, contribute to it.

Why single-process, Docker-free matters

The architecture isn't the point — what it unlocks is.

Faster local loops. A single process starts in a fraction of the time an orchestrated multi-container stack takes. The edit-run-test cycle gets shorter.

Cheaper CI. CI runners are memory-constrained and billed by the minute. Spinning up one Postgres-backed process per job is dramatically lighter than booting the full Supabase container set.

Teaching and demos that just run. Workshops and tutorials can hand out a real backend without first walking every participant through installing and configuring Docker. That alone removes the most common "it doesn't work on my machine" failure at the start of a session.

Browser and constrained environments. In-browser IDEs and low-spec machines that can't host the full container stack can still run a real Supabase-compatible backend.

How it compares

If you want a lighter local Supabase, you've probably weighed these:

Option	Real Postgres?	Docker-free?	Supabase-compatible?
Full Supabase CLI stack	Yes	No	Yes
SQLite-based shim	No	Yes	Partial
Hand-rolled Postgres + PostgREST	Yes	Depends	You wire it
tinbase	Yes	Yes	Yes

The gap tinbase fills: the realism of Postgres-backed Supabase, without the Docker overhead, and without dropping to a non-Postgres engine that diverges from production.

Who it's for

Developers who want a fast local Supabase without the container tax
Teams trying to cut CI time and cost
Educators and content authors who need a reproducible backend in a tutorial
Anyone building in a browser sandbox or on constrained hardware

Getting started

tinbase is single-process and Docker-free, so setup is meant to be minimal: install, start the process, and point a supabase-js client at it.

The full documentation and source are at tinbase.dev.

If you've been avoiding local Supabase because of the Docker overhead, this is worth a look — especially for CI and teaching setups.

Running Supabase locally today? What's your current setup — full CLI stack, a shim, or something hand-rolled? Curious what the pain points have been.