DEV Community: Hugo Rus

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.

How to Prototype a Mobile App in Hours (Wireframe React Native)

Hugo Rus — Fri, 24 Jul 2026 09:34:12 +0000

The wireframe → clickable prototype → coded prototype pipeline collapses into a single step.
Four phases: capture the wireframe (20–40 min), generate the base app (2–3 min), iterate visually (1–2 hrs), ship to real hardware (30 sec).
Traditional first testable build: 2–4 weeks. AI-native: 1–3 hours. Most of the compression is eliminating role handoffs.
Best wireframe input isn't a sketch — it's a competitor screenshot, or a precise written paragraph.

The three artifacts most guides conflate

One clarification that trips up most prototyping conversations:

Wireframe — static layout. No interactivity.
Clickable prototype — hotspots wired between static screens (Figma, InVision). Can't run real logic.
Working prototype — real React Native code, real navigation, real state, installable on device via QR.
Production app — the working prototype plus backend, auth, analytics, store listing.

Most "prototyping" tutorials stop at rung two. The interesting compression is going from rung one straight to rung three.

The four-phase workflow

1. Capture the wireframe (20–40 min)

Any medium that captures screens, elements, and tap behaviour works: hand sketch, whiteboard photo, Excalidraw, Figma frame, competitor screenshot, or a written paragraph.

Treat the wireframe as disposable. Its job is to be input to the generator, not a deliverable.

2. Generate the base app (2–3 min)

Feed the wireframe plus a one-paragraph description into an AI mobile app builder. You get back a live React Native + Expo app with routing, styled screens, and stubbed data.

It's about 70% right — good enough to iterate against.

3. Iterate visually (1–2 hours)

The base app has ~30% wrong. Point-and-edit is the accelerator: click any element in the live preview, describe the change ("make cards rounder, move price to top-right"), and the underlying code updates. Product teams typically do 30–50 micro-iterations in the first hour.

Two rules for this phase:

Don't accept the first version of any screen.
Don't over-specify visuals before validating flow. Colours are cheap; navigation is expensive.

4. Ship to real hardware (30 sec)

Scan a QR code, install into a preview client on iPhone or Android, and use the app on real hardware.

This is where the bugs Figma can't show you actually surface: thumb-tap zones, safe areas, keyboard behaviour, dark mode.

Traditional vs. AI-native

For a 5-screen MVP:

Phase	Traditional	AI-native
Wireframing	4–8 hours	20–40 min
Hi-fi design	2–5 days	Skipped
Clickable prototype	4–8 hours	Skipped
Coded prototype	1–3 weeks	2–3 min
Iteration cycle	1–3 days per round	30 sec to 2 min
Real-device install	4–8 hours (Xcode/TestFlight)	30 sec (QR)
First testable build	2–4 weeks	1–3 hours

The compression is mostly the elimination of role handoffs. When one operator drives the whole loop, the "waiting for someone else" hours evaporate.

Which wireframe inputs convert best

Ranked worst → best by signal-to-noise:

Napkin sketch photo — works, but expect nuance loss. Pair it with a written description.
Whiteboard photo — better. Whiteboards force larger, more legible drawings.
Excalidraw / FigJam — excellent. Digital media produce clean shapes and labels.
Figma frame — very good. Layout and hierarchy transfer cleanly.
Written PRD paragraph — underrated. A precise three-to-four sentence description often beats a bad sketch.
Competitor screenshot — highest signal. It's already a mobile UI, so layout, typography, and interaction all transfer.

Hour by hour: a food-delivery MVP in one afternoon

Two-person team, five screens (restaurant list → detail → cart → checkout → order tracking):

0:00–0:30 — Whiteboard sketch, phone photo.
0:30–0:38 — Upload plus a one-paragraph description. Base app generated.
0:38–1:20 — First iteration pass. Point-and-edit, roughly 40 changes.
1:20–1:35 — QR install on both team phones. Two nav bugs surface; fixed in 3 minutes.
1:35–2:20 — Send the QR to three test users, collect feedback in a shared doc.
2:20–3:15 — Second iteration pass. Address the top ten UX notes.
3:15–3:30 — Publish a shareable preview URL, drop it in Slack.

Three and a half hours end to end, iOS and Android, on real phones.

When not to use this workflow

The AI loop isn't universal. Stay traditional when:

Novel interaction patterns with no precedent. Generators pattern-match; no pattern means no output quality.
Regulated industries (medical, aviation, financial trading) that need documented decision trails.
Pixel-perfect exec-review demos with no budget for a "70% then iterate" opening state.

For the other 90% — CRUD apps, marketplaces, social, dashboards, internal tools — the compressed loop wins on speed, iteration count, and cost.

If you want to run the loop end to end, RapidNative does the sketch/prompt/screenshot → React Native + Expo → QR-preview pipeline in one editor.

What's your current wireframe-to-code gap? Curious whether the competitor-screenshot trick works as well for others as it has for me.

Recruiting 12 Real Testers for Your Google Play Closed Test (Without Buying Them)

Hugo Rus — Wed, 22 Jul 2026 11:02:33 +0000

Buying testers fails three ways: Play's fraud detection flags dormant accounts, bought testers never open the app (so engagement doesn't count), and you're dependent on a third party to satisfy a store requirement.
Three source pools that work: your existing audience (highest quality), community trades on r/androiddev and r/indiedev (fastest), and your personal network (last resort).
A warm-list invite converts 40–50%. Anonymous forums convert 5–10% — which is why you need multiple pools.
Play watches for meaningful engagement, not just opt-ins. Four touches over 14 days keeps testers active.

You need 12 opted-in testers for 14 days before Google Play will let you ship. Buying them looks like the shortcut.

It usually isn't. Play's ML is good at spotting bought accounts, and it will silently reset your 14-day counter.

Here's how to recruit 12 real humans in 3–4 days instead.

Why paid services fail

The tester-service business exists, and some of it works. Most of it has three failure modes:

Play's fraud detection flags dormant or newly created accounts. Your test "has 12 testers" but Play doesn't count them.
The testers opt in and never open the app. The engagement signal doesn't register.
You're now dependent on a third party to satisfy a store requirement. If they turn shady, your launch is stuck.

And even when it works, you've spent $50–200 on 12 accounts that will never use your app again. You had to do the harder work anyway — you just paid extra for the privilege.

The three source pools

1. Your existing audience (highest quality)

Newsletter subscribers, followers, Discord or Slack members. Even 200 subscribers converts to 10–15 testers with a good ask.

If you don't have this: start building one on day one of your next project. This requirement is a recurring tax, not a one-off.

2. Community trades (fastest)

r/androiddev — weekly beta-swap threads
r/indiedev — weekly "test my app" threads
Indie Hackers — milestones section
Discord communities in your product's category (game dev, productivity, etc.)

The trade is simple: "I'll test your app, you test mine." Both parties get closer to their 12, and communities enforce reciprocity so quality stays high.

3. Personal network plus amplification (last resort)

Friends, colleagues, family — then their networks via a "know anyone with an Android who'd help?" broadcast. This usually gets you the last three or four you need.

The invite template

Subject: Would you spend 5 minutes to help me launch my app?

Hey [name],

I'm launching [app name] on Android next month. Google now requires 12 testers for 14 days before I can ship publicly.

If you have an Android phone and 5 minutes, you'd be helping me a lot by:

Clicking this link: [tester opt-in URL]

Installing when the app appears in your Play Store

Opening it a couple of times over the next 2 weeks

That's the whole ask. You'll get free access to the paid version as a thank you.

[your name]

This converts 40–50% on a warm list. Anonymous forums convert 5–10% — which is exactly why you need more than one pool.

Keeping them engaged for 14 days

Play watches for meaningful engagement. If your 12 testers opt in and never open the app, the requirement isn't satisfied.

Day 1: Welcome message with "here's what to try" (two or three specific flows).
Day 5: A genuine "what's confusing so far?" ask. This gets you feedback and another session.
Day 10: Preview of what's shipping in the next update. Another reason to open.
Day 14: Thank you, plus "the app goes to production tomorrow."

Four touches, each with real value. Not spam.

Turning testers into first users

Your 12 testers just spent 14 days with your app. That's the highest-quality feedback pool you will ever have. Before the closed test ends:

Send a proper survey. Not "rate 1–5." Ask: "What almost stopped you from using this?" and "What would you tell a friend it does?"
Ask for a testimonial, with permission to quote.
Ask whether they'd upgrade to paid at launch. Their answer is your first real customer signal.

The reframe

You started this hunting 12 accounts to satisfy Google. You finish with 12 engaged real users, genuine feedback, a few testimonials, and possibly your first paying customers.

The Play requirement is annoying. The discipline it forces is actually a launch playbook.

If you're stuck at "have the app, need the testers," letsdeploy.it handles the release side so you can focus on recruiting. The 12 humans still have to come from you.

How did you find your 12? I'm curious which pool actually worked — the swap threads or the personal network.

7 Things That Break When You Convert a Web App to React Native

Hugo Rus — Wed, 22 Jul 2026 09:51:38 +0000

There is no div, no span, and no cascading CSS. Every layout primitive changes.
localStorage, window, document, and most browser APIs simply don't exist.
flexDirection defaults to column, not row. This one silently breaks every layout you wrote.
Routing, image handling, forms, and scrolling all need native equivalents.
None of it is hard individually. It's the volume that kills weekend projects.

AI web app builders got very good very fast. You can describe an app to Lovable, v0, or Bolt and have a working web product the same afternoon.

Then you try to put it on the App Store, and you discover the thing nobody mentions: a web app and a native app share a language, not a platform. They both run JavaScript. Almost nothing else transfers.

I've done this conversion enough times to know exactly where it hurts. Here are the seven things that break, in roughly the order you'll hit them.

1. Every HTML element is gone

There is no div. No span. No p, h1, button, ul, or img.

React Native has its own primitives, and the mapping isn't one-to-one:

// Web
<div className="card">
  <h2>Title</h2>
  <p>Body text</p>
  <img src={url} />
</div>

// React Native
<View style={styles.card}>
  <Text style={styles.title}>Title</Text>
  <Text>Body text</Text>
  <Image source={{ uri: url }} />
</View>

The important gotcha: all text must be wrapped in <Text>. A bare string inside a <View> throws. On web you can drop text anywhere; here it's a hard error, and it's the single most common first crash.

2. CSS doesn't cascade — and half of it doesn't exist

React Native uses a JavaScript style object, not a stylesheet. That means:

No cascade. A style on a parent doesn't inherit down to children. Set fontSize on a View and the Text inside ignores it.
No selectors. No classes, no descendants, no :hover, no media queries.
No units. Numbers are density-independent pixels. padding: 16, not padding: '16px'.

const styles = StyleSheet.create({
  card: {
    padding: 16,
    borderRadius: 12,
    backgroundColor: '#fff',
  },
});

Also missing: float, grid, position: fixed, and most of the box model shorthand you're used to. Flexbox is the layout system — essentially the only one.

3. `flexDirection` defaults to `column`

This is the one that quietly wrecks everything.

On the web, display: flex defaults to flex-direction: row. In React Native, every View is already flex, and the default direction is column.

So every horizontal row you built on the web stacks vertically after the port, and you won't get an error — just a layout that looks wrong everywhere at once.

// You have to be explicit
<View style={{ flexDirection: 'row', alignItems: 'center' }}>

Budget an afternoon just for this.

4. Browser APIs don't exist

No window. No document. No localStorage. No fetch cookies, no DOM measurement, no alert().

The replacements:

Web	React Native
`localStorage`	`AsyncStorage` (or `expo-secure-store` for anything sensitive)
`document.querySelector`	refs
`window.location`	Expo Router / React Navigation
`alert()`	`Alert.alert()` from `react-native`
CSS media queries	`useWindowDimensions()`

fetch does survive, which is a small mercy — your API layer mostly ports as-is.

5. Routing is a different model

URL-based routing doesn't exist natively. There's no address bar and no history object.

Expo Router gets you closest to a web mental model — it's file-based, so app/profile/[id].tsx maps to /profile/42 — but you still have to think in stacks and tabs rather than pages. Back isn't "previous URL," it's "pop the stack."

Deep links also need real configuration on both platforms (URL schemes, Universal Links on iOS, App Links on Android). That's a genuine chunk of work with no web equivalent.

6. Scrolling and lists are explicit

On the web, content overflows and the browser gives you a scrollbar for free. In React Native, nothing scrolls unless you say so.

<ScrollView>{/* short content */}</ScrollView>

<FlatList
  data={items}
  keyExtractor={(item) => item.id}
  renderItem={({ item }) => <Row item={item} />}
/>

And use FlatList (or FlashList) for anything long — ScrollView renders every child at once and will tank your frame rate on a list of 500 items.

7. Forms and keyboards need real work

<input> becomes <TextInput>, and it needs configuration the browser handled implicitly: keyboardType, autoCapitalize, autoComplete, secureTextEntry, returnKeyType.

Then there's the keyboard itself. On mobile it physically covers the bottom of the screen, so your submit button disappears behind it unless you wrap the form in KeyboardAvoidingView with different behavior values per platform.

There is no web equivalent to this problem, and it catches everyone once.

What this actually adds up to

Individually, none of these are hard. A competent React dev can work through any one of them in an hour.

The problem is that there are seven of them, and they compound — plus certificates, provisioning profiles, screenshots at five device sizes, a privacy nutrition label, and a reviewer who might say no anyway.

That's the honest reason so many AI-built web apps never reach a store. The build was a weekend. The port and the submission are a different project entirely.

If you'd rather not do that project, RapidNative converts Lovable apps into real React Native + Expo builds and handles the full App Store and Play Store submission — signing, screenshots, metadata included. You get the source code and keep ownership of it, and if your app uses Supabase, the native build points at the same project with no migration.

Which of these seven got you first? For me it was flexDirection — I spent two hours convinced my styles weren't applying at all.