DEV Community: Chloe

Docker Alternatives in 2026: What to Use Instead (and When You Actually Need To)

Chloe — Fri, 09 Oct 2026 09:34:35 +0000

TL;DR

"Docker" is three layers: the runtime, the engine/CLI, and Docker Desktop. Most people only need to replace Docker Desktop.
On a Mac? OrbStack if $8/user/month is fine, or Colima if you want free and terminal-only.
Want free with a GUI, at any company size? Podman Desktop or Rancher Desktop.
Running Linux servers? Podman (daemonless, rootless). For minimal CI runners, nerdctl.
Your Dockerfiles, Compose files, and images keep working. OCI standards make switching low-risk.
Sometimes you don't need containers at all. There's a section on that below.

Docker didn't invent containers, but for a decade it basically was containers.

That started to change in 2021. Docker Inc. announced that Docker Desktop would require a paid subscription for commercial use at companies with more than 250 employees or $10M in revenue. Overnight, a lot of teams learned the difference between "Docker the format" and "Docker the product."

Five years later, the ecosystem has sorted itself out. You can keep your Dockerfiles, your docker compose habits, and your registry workflow, and swap out almost everything underneath. Here's what to swap in, grouped by what each tool actually replaces.

First: which Docker are you replacing?

"Docker" is three layers stacked on top of each other:

The runtime (containerd + runc) creates and runs the containers. It's open source and shared by almost everyone, Kubernetes included.
The engine and CLI is the docker command plus the daemon it talks to.
Docker Desktop is the macOS/Windows app that bundles a Linux VM, a GUI, and the licensing that started all of this.

Most "I want a Docker alternative" requests mean layer 3. Some mean layer 2. Almost nobody needs to replace layer 1.

Figure out which layer you mean, and the choice gets much easier.

Engine and CLI alternatives

Podman

Podman is the most complete drop-in replacement for the Docker engine.

It's daemonless, so there's no long-running root process.
It's rootless by default. That's why security-focused teams and most Linux distros have moved to it.

The CLI mirrors Docker closely enough that a single alias covers most day-to-day work:

# macOS: Podman runs inside a small Linux VM
brew install podman
podman machine init
podman machine start

# Linux: install from your distro's package manager, no VM needed

alias docker=podman
docker run --rm -p 8080:80 nginx   # actually Podman

Podman also has native pods: groups of containers that share a network namespace. It can generate Kubernetes YAML from running containers, which is handy if you're heading toward k8s anyway:

podman pod create --name web -p 8080:80
podman run -d --pod web nginx
podman kube generate web > web-pod.yaml

Two sibling tools round it out:

Buildah builds images without a daemon.
Skopeo inspects and copies images between registries without pulling them.

Trade-offs: podman compose has improved a lot, but it still differs from Docker Compose on some edge cases. Some third-party tools also still expect a Docker socket at a fixed path.

nerdctl (containerd directly)

If you're happy to go one layer lower, nerdctl gives you a Docker-compatible CLI that talks straight to containerd. Many of the desktop tools below use it internally.

nerdctl run -d -p 8080:80 --name web nginx
nerdctl compose up -d

You also get containerd features that Docker doesn't expose, such as lazy image pulling and image encryption. It's a great fit for Linux servers and CI runners where you want as few moving parts as possible.

Docker Desktop alternatives (macOS and Windows)

Most of the real choice happens here. On a Mac or a Windows machine you always need a Linux VM somewhere, and how that VM is managed makes a big difference to speed and battery life.

OrbStack (macOS)

OrbStack has effectively become the default on Mac. It's a commercial tool, but the performance gap is real:

It uses roughly a third of Docker Desktop's memory.
It starts in under two seconds.
File sharing and port forwarding work without configuration.
It can run full Linux VMs alongside containers, and it includes Kubernetes (via K3s).

brew install orbstack
# your existing docker / docker compose commands just work

It's free for personal use and $8/user/month for commercial use. That's cheaper than Docker Desktop, but not free for teams.

Trade-offs: macOS only, and closed source.

Colima (macOS and Linux)

Colima is the free, no-frills option. It's a thin wrapper around Lima that starts a VM running either the Docker engine or containerd, and you keep using your normal docker CLI.

brew install colima docker
colima start --cpu 4 --memory 8 --vm-type vz --mount-type virtiofs
docker ps

It's terminal-only, and you'll tune CPU, memory, and mount type yourself. In return it's stable and fully open source.

Lima

Lima is the layer underneath Colima. It runs Linux VMs on macOS with automatic file sharing and port forwarding.

brew install lima
limactl start
lima uname -a

Use it directly when you want full control over the VM, or several VMs running different runtimes. It isn't a container tool on its own, but many of the tools in this list are built on it.

Finch (AWS)

Finch is AWS's open-source bundle of Lima, containerd, nerdctl, and BuildKit. Think of it as a more opinionated Colima: one install, no daemon, and a finch command that works like docker.

brew install --cask finch
finch vm init
finch run --rm public.ecr.aws/finch/hello-finch

It's a reasonable choice if you're an AWS shop and want a big vendor behind your tooling.

Rancher Desktop

Rancher Desktop is the pick for Kubernetes-first developers:

It's free and open source.
It has a GUI.
It runs a local k8s cluster that you can pin to the same version as production.
You can switch the runtime between containerd and the Docker engine.

brew install --cask rancher

It's heavier than the CLI tools because Kubernetes always comes along. If you live in kubectl anyway, that's a feature rather than a cost.

Podman Desktop

Podman Desktop is the GUI companion to Podman, now well into its 1.x releases with strong Red Hat backing. It manages containers, pods, images, and Kubernetes connections.

brew install --cask podman-desktop

It's the natural choice if you already use Podman on Linux and want the same model on your laptop. Like Rancher Desktop, it's free at any company size and has a GUI.

Apple's container tooling (macOS)

This one is worth watching. At WWDC 2025, Apple open-sourced a native container CLI and a Containerization framework. Unlike everything else in this list, they run each container in its own lightweight VM, which isolates containers from each other more strongly.

container system start
container run --rm docker.io/library/alpine:latest echo hi

It's still early, and the tooling around it is thin. Expect other tools to start building on it.

Sometimes you don't need a container at all

A lot of local Docker usage isn't really about containers. It's "I need Postgres plus some backend services running so I can develop." The Supabase local stack is a good example: about 12 containers and roughly 2.3 GB of Docker images, just to run your app's backend on a laptop.

If that's your situation, you can skip the container layer entirely. tinbase is an open-source, Supabase-compatible backend that runs as a single process:

npx tinbase start

import { createClient } from '@supabase/supabase-js'

// same SDK, pointed at the local process — no Docker
const supabase = createClient('http://127.0.0.1:54321', ANON_KEY)

const { data } = await supabase
  .from('todos')
  .select('*')
  .eq('done', false)

What you get:

Real Postgres, with Row Level Security, Auth, Storage, and Realtime.
Your existing setup: it reads your supabase/migrations folder, and the official supabase-js SDK works unchanged.

Trade-off: it's alpha. That's fine for local dev and prototypes, but not production-ready yet.

The broader lesson goes beyond Supabase. Before you choose a Docker replacement, check whether the thing you're running actually needs to be a container.

Quick decision guide

You want...	Use
Fastest, smoothest Mac experience, and $8/user/month is fine	OrbStack
Free at any company size, with a GUI	Podman Desktop or Rancher Desktop
Free, lightweight, terminal-only on Mac	Colima
Local Kubernetes that matches production	Rancher Desktop
Daemonless, rootless engine on Linux servers	Podman
Minimal CI runners	nerdctl + containerd
Full control over the VM	Lima
Local Postgres backend, no containers	A single-process alternative (see above)

One piece of advice

Whatever you pick, pick it as a team.

Five developers on five different local setups is a support burden that will quickly cost more than you saved on licensing. Agree on one tool, script the setup, and move on:

# scripts/setup-containers.sh
#!/usr/bin/env bash
set -euo pipefail
brew install colima docker docker-compose
colima start --cpu 4 --memory 8 --vm-type vz --mount-type virtiofs
docker context use colima
echo "✅ containers ready"

And remember that none of this touches your Dockerfiles, your Compose files, or your images. OCI standards made this whole ecosystem possible, and they're why switching is much less scary than it sounds.

What's your team running locally in 2026? Did you leave Docker Desktop, or decide it was worth paying for? Drop it in the comments. I'm especially curious whether anyone has moved real workloads onto Apple's container yet. 👇

Authentication in React Native, Explained Like You're Building It Tonight

Chloe — Wed, 07 Oct 2026 10:38:34 +0000

TL;DR

Don't store tokens in AsyncStorage. Use expo-secure-store, which uses the iOS Keychain and Android Keystore.
Keep auth state in one place, a React context that knows three things: loading, signed in, signed out.
Let your router do the gatekeeping. With Expo Router, Stack.Protected hides screens the user shouldn't see.
Wrap fetch once so every request gets the token, and a 401 triggers one refresh instead of ten.
Biometrics unlock a session. They don't create one.

Grab a coffee. By the end you'll have an auth flow you actually understand.

Why auth feels weird in React Native

If you're coming from the web, you're used to the browser doing a lot of quiet work for you. Cookies get sent automatically. httpOnly cookies keep JavaScript away from your session. Refresh the page and you're still logged in.

In React Native, none of that is free. There's no cookie jar you'd want to rely on, and no httpOnly safety net. Your app is responsible for holding the token, protecting it, and sending it.

That sounds scary, but it boils down to four jobs:

Get a token when the user logs in.
Store it somewhere safe.
Decide which screens to show based on whether you have it.
Send it with requests, and get a new one when it expires.

Let's do them one at a time.

The 30-second token refresher

Most backends give you two tokens:

Token	Lives for	Used for
Access token	Minutes (e.g. 15 min)	Sent on every API request
Refresh token	Days or weeks	Trading in for a new access token

Short-lived access tokens limit the damage if one leaks. The refresh token keeps users from logging in every 15 minutes. Your app's job is to juggle both without the user ever noticing.

Step 1: Store tokens safely

First, install the storage library:

npx expo install expo-secure-store

Now a tiny wrapper so the rest of your app never talks to storage directly:

// auth/tokenStorage.ts
import * as SecureStore from 'expo-secure-store';

const ACCESS_KEY = 'auth.accessToken';
const REFRESH_KEY = 'auth.refreshToken';

export type Tokens = { accessToken: string; refreshToken: string };

export async function saveTokens({ accessToken, refreshToken }: Tokens) {
  await SecureStore.setItemAsync(ACCESS_KEY, accessToken);
  await SecureStore.setItemAsync(REFRESH_KEY, refreshToken);
}

export async function getTokens(): Promise<Tokens | null> {
  const accessToken = await SecureStore.getItemAsync(ACCESS_KEY);
  const refreshToken = await SecureStore.getItemAsync(REFRESH_KEY);
  if (!accessToken || !refreshToken) return null;
  return { accessToken, refreshToken };
}

export async function clearTokens() {
  await SecureStore.deleteItemAsync(ACCESS_KEY);
  await SecureStore.deleteItemAsync(REFRESH_KEY);
}

Why not AsyncStorage? Because AsyncStorage is plain, unencrypted storage. It's perfect for "dark mode: on" and terrible for "here are the keys to this user's account."

💡 SecureStore is meant for small values like tokens, not big JSON blobs. If you need to cache a user profile, put the profile in AsyncStorage and keep only the tokens in SecureStore.

Step 2: One context to rule your auth state

Every screen needs to answer the same question: is this person logged in? Let's give them one place to ask.

// auth/AuthContext.tsx
import React, { createContext, useContext, useEffect, useState } from 'react';
import { saveTokens, getTokens, clearTokens } from './tokenStorage';

type AuthState = {
  isLoading: boolean;
  isSignedIn: boolean;
  signIn: (email: string, password: string) => Promise<void>;
  signOut: () => Promise<void>;
};

const AuthContext = createContext<AuthState | null>(null);

const API_URL = 'https://api.example.com';

export function AuthProvider({ children }: { children: React.ReactNode }) {
  const [isLoading, setIsLoading] = useState(true);
  const [isSignedIn, setIsSignedIn] = useState(false);

  // On app start: do we already have tokens?
  useEffect(() => {
    (async () => {
      const tokens = await getTokens();
      setIsSignedIn(!!tokens);
      setIsLoading(false);
    })();
  }, []);

  async function signIn(email: string, password: string) {
    const res = await fetch(`${API_URL}/auth/login`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ email, password }),
    });

    if (!res.ok) {
      throw new Error('Invalid email or password');
    }

    const { accessToken, refreshToken } = await res.json();
    await saveTokens({ accessToken, refreshToken });
    setIsSignedIn(true);
  }

  async function signOut() {
    await clearTokens();
    setIsSignedIn(false);
  }

  return (
    <AuthContext.Provider value={{ isLoading, isSignedIn, signIn, signOut }}>
      {children}
    </AuthContext.Provider>
  );
}

export function useAuth() {
  const ctx = useContext(AuthContext);
  if (!ctx) throw new Error('useAuth must be used inside <AuthProvider>');
  return ctx;
}

Notice the isLoading flag. Without it, your app briefly thinks the user is logged out while it reads storage, and they see the login screen flash for a split second. Small thing, very noticeable.

Step 3: Let the router guard the doors

If you're on Expo Router, you can describe which screens are allowed instead of manually redirecting all over the place.

A simple folder setup:

app/
  _layout.tsx
  sign-in.tsx
  (app)/
    _layout.tsx
    index.tsx
    profile.tsx

And the root layout:

// app/_layout.tsx
import { Stack } from 'expo-router';
import { AuthProvider, useAuth } from '../auth/AuthContext';

function RootNavigator() {
  const { isLoading, isSignedIn } = useAuth();

  if (isLoading) return null; // or keep your splash screen up

  return (
    <Stack screenOptions={{ headerShown: false }}>
      <Stack.Protected guard={isSignedIn}>
        <Stack.Screen name="(app)" />
      </Stack.Protected>

      <Stack.Protected guard={!isSignedIn}>
        <Stack.Screen name="sign-in" />
      </Stack.Protected>
    </Stack>
  );
}

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

That's it. When isSignedIn flips to true, the sign-in screen becomes unreachable and the user lands in (app). Sign out, and the reverse happens. No router.replace() sprinkled across ten files.

Using React Navigation directly instead? Same idea: render a different set of <Stack.Screen>s based on isSignedIn. Don't navigate to the login screen; just stop rendering the protected ones.

Step 4: The login screen

Nothing fancy, just honest UX: a loading state, an error message, and a disabled button while we wait.

// app/sign-in.tsx
import { useState } from 'react';
import { View, TextInput, Button, Text, ActivityIndicator } from 'react-native';
import { useAuth } from '../auth/AuthContext';

export default function SignIn() {
  const { signIn } = useAuth();
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [error, setError] = useState<string | null>(null);
  const [submitting, setSubmitting] = useState(false);

  async function handleSubmit() {
    setError(null);
    setSubmitting(true);
    try {
      await signIn(email.trim(), password);
    } catch (e: any) {
      setError(e.message ?? 'Something went wrong');
    } finally {
      setSubmitting(false);
    }
  }

  return (
    <View style={{ flex: 1, justifyContent: 'center', padding: 24, gap: 12 }}>
      <TextInput
        placeholder="Email"
        autoCapitalize="none"
        keyboardType="email-address"
        textContentType="emailAddress"
        value={email}
        onChangeText={setEmail}
      />
      <TextInput
        placeholder="Password"
        secureTextEntry
        textContentType="password"
        value={password}
        onChangeText={setPassword}
      />
      {error && <Text style={{ color: 'crimson' }}>{error}</Text>}
      {submitting ? (
        <ActivityIndicator />
      ) : (
        <Button title="Sign in" onPress={handleSubmit} />
      )}
    </View>
  );
}

Little details that matter: autoCapitalize="none" (nobody wants John@gmail.com), and textContentType so iOS can offer saved passwords.

Honestly, the login, signup, and forgot-password screens are the most repetitive part of this whole flow. If you'd rather spend your time on the auth logic than on pixel-pushing form layouts, you can describe the screens to RapidNative and get React Native UI code to drop the useAuth() hook into.

Step 5: Attach the token, and refresh it without chaos

Here's where many apps get messy. The access token expires, five requests fail with 401 at the same time, and all five try to refresh. Now you've got a race condition and possibly a logged-out user.

The fix: one shared refresh promise.

// api/client.ts
import { getTokens, saveTokens, clearTokens } from '../auth/tokenStorage';

const API_URL = 'https://api.example.com';

let refreshPromise: Promise<string | null> | null = null;

async function refreshAccessToken(): Promise<string | null> {
  const tokens = await getTokens();
  if (!tokens) return null;

  const res = await fetch(`${API_URL}/auth/refresh`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ refreshToken: tokens.refreshToken }),
  });

  if (!res.ok) {
    await clearTokens();
    return null;
  }

  const next = await res.json();
  await saveTokens(next);
  return next.accessToken;
}

export async function apiFetch(path: string, options: RequestInit = {}) {
  const tokens = await getTokens();

  const doRequest = (token?: string) =>
    fetch(`${API_URL}${path}`, {
      ...options,
      headers: {
        'Content-Type': 'application/json',
        ...(options.headers ?? {}),
        ...(token ? { Authorization: `Bearer ${token}` } : {}),
      },
    });

  let res = await doRequest(tokens?.accessToken);

  if (res.status !== 401) return res;

  // Everyone waits on the same refresh
  if (!refreshPromise) {
    refreshPromise = refreshAccessToken().finally(() => {
      refreshPromise = null;
    });
  }

  const newToken = await refreshPromise;
  if (!newToken) return res; // refresh failed, caller handles sign-out

  return doRequest(newToken);
}

Now anywhere in your app:

const res = await apiFetch('/me');
const user = await res.json();

One small homework item: when the refresh fails, your AuthContext should find out and flip isSignedIn to false. A simple event emitter or an onAuthFailure callback you register from the provider works great.

Step 6: "Sign in with Google/Apple" in one breath

Social login deserves its own post, but here are the rules that keep you out of trouble:

Use the provider's SDK or expo-auth-session with the PKCE flow.
Never ship a client secret in your app. Anything in your bundle can be extracted. Secrets live on your server.
Exchange the provider's token with your backend and get your access/refresh tokens back. From there, everything above stays the same.
If you offer other social logins on iOS, check Apple's rules on also offering Sign in with Apple.

The nice part: once you have your own tokens, Steps 1–5 don't care how the user logged in.

Bonus: Face ID / fingerprint unlock

Biometrics are a great "welcome back" experience, but they are not a login method on their own. They prove a finger or face is present, not who the user is to your server.

The right pattern: user logs in normally once, then biometrics gate access to the tokens you already stored.

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

export async function unlockWithBiometrics() {
  const hasHardware = await LocalAuthentication.hasHardwareAsync();
  const isEnrolled = await LocalAuthentication.isEnrolledAsync();
  if (!hasHardware || !isEnrolled) return true; // fall back gracefully

  const result = await LocalAuthentication.authenticateAsync({
    promptMessage: 'Unlock your account',
  });
  return result.success;
}

Call it on app launch before reading tokens, and you've got a smooth, secure "open app, glance at phone, you're in" flow.

Common mistakes (I've made most of these)

Storing tokens in AsyncStorage or Redux Persist. Use SecureStore.
Logging tokens with console.log. They end up in crash reports and screen recordings.
Navigating to login on logout instead of letting the auth state decide what renders. You get weird back-button bugs.
No isLoading state, which causes the login-screen flash on startup.
Refreshing tokens in parallel. Use one shared promise.
Trusting the client. Your app hiding a screen is UX, not security. The server must check every request.

Wrapping up

React Native auth isn't magic. It's four small jobs: get the token, store it safely, guard the screens, and keep the token fresh. Get those right and everything else, from social login to biometrics, plugs in on top.

What are you using for auth right now: your own backend, Firebase, Supabase, Clerk, something else? Drop a comment with what you're building. I'm curious what's working (and what's hurting) for you. 👇

React Native Accessibility: The 2026 WCAG 2.2 Guide (Every Criterion Every Prop)

Chloe — Mon, 05 Oct 2026 08:40:27 +0000

TL;DR

The legal pressure is real. The DOJ's ADA Title II rule names mobile apps and WCAG 2.1 AA explicitly (deadlines now April 2027 / April 2028). The EU's EAA has been live since June 2025 and points to WCAG 2.2 AA via EN 301 549.
React Native maps almost 1:1 to native a11y APIs. accessibilityLabel becomes the iOS accessibility label and the Android content description. You already have the tools.
WCAG 2.2 adds four mobile-relevant criteria: Focus Not Obscured, Dragging Movements, Target Size (24×24 min), and Accessible Authentication.
Five bugs cause most failures: unlabeled Pressables, modals that don't trap focus, visual-only form errors, custom switches with no state, and low-contrast text on gradients.
Test in four layers: ESLint on every commit, a VoiceOver/TalkBack walkthrough on every UI PR, and Accessibility Inspector/Scanner plus axe before every store submission.

Why this suddenly matters

Accessibility used to be the "we'll get to it" ticket. Three things changed that.

1. The DOJ Title II rule. Published in April 2024, it's the first U.S. federal regulation to name mobile apps alongside websites and tie them to a specific standard: WCAG 2.1 AA. In April 2026 the DOJ pushed the deadlines back a year. Public entities with 50,000+ population now have until April 26, 2027, and smaller entities until April 26, 2028. The requirements themselves didn't change. State procurement contracts already cite WCAG 2.1 AA as a pass/fail checkbox, so if you build B2G apps you're in scope today.

2. The European Accessibility Act. In force since June 2025, it covers private-sector products like banking, e-commerce and transit apps. It references EN 301 549, which is harmonized with WCAG 2.2 AA. If you ship to EU users above the small-business threshold, it applies to you.

3. Litigation. Mobile app accessibility lawsuits more than doubled between 2022 and 2025. Courts keep treating apps as places of public accommodation under ADA Title III. Insurers have started asking about accessibility testing before writing cyber-liability policies.

So: you need an a11y audit in your release checklist, run on every store build, with a report you can point to.

The entire React Native a11y toolbox

WCAG 2.2 has 86 success criteria across three conformance levels (A, AA, AAA). For Level AA you need to pass the 55 A and AA criteria, minus a few web-only ones like skip links. Everything else maps to this prop surface:

<Pressable
  accessible={true}
  accessibilityLabel="Save changes"
  accessibilityHint="Saves your draft"
  accessibilityRole="button"
  accessibilityState={{ disabled: false, busy: isSaving }}
  accessibilityValue={{ min: 0, max: 100, now: 42 }}
  importantForAccessibility="yes"        // Android
  accessibilityLiveRegion="polite"        // Android
>
  <Text>Save</Text>
</Pressable>

That's it. The hard part isn't the API. It's knowing which prop satisfies which criterion, and making those props the default so nobody ships a screen without them.

The four criteria new in WCAG 2.2 that hit native UIs:

Criterion	Level	What it means in an app
2.4.11 Focus Not Obscured (Min)	AA	Focused element can't be fully hidden by sticky headers, bottom sheets or the keyboard
2.5.7 Dragging Movements	AA	Every drag gesture needs a non-drag alternative
2.5.8 Target Size (Min)	AA	Targets at least 24×24 (aim for 44×44 iOS / 48×48 Android)
3.3.8 Accessible Authentication (Min)	AA	No cognitive tests to log in. Allow paste and password managers

Perceivable + Operable: criterion → code

1.1.1 Non-text Content (A)

Label meaningful images and hide decorative ones.

// Meaningful
<Image source={avatar} accessibilityLabel="Profile photo of Priya" />

// Decorative: hide on both platforms
<Image
  source={divider}
  accessibilityElementsHidden={true}               // iOS
  importantForAccessibility="no-hide-descendants"  // Android
/>

1.3.1 Info and Relationships (A)

A styled View with an onPress is invisible to screen readers as a control. Declare the role.

<Text accessibilityRole="header" style={styles.h1}>Settings</Text>

<Pressable accessibilityRole="link" onPress={openTerms}>
  <Text>Terms of service</Text>
</Pressable>

1.4.3 Contrast (Minimum) (AA)

Body text needs 4.5:1. Large text (18pt+, or 14pt+ bold) needs 3:1. The classic React Native failure is text on a gradient hero that passes at the top and fails at the bottom. Use semantic tokens so a palette change doesn't mean re-auditing every screen:

// theme.js: pairs pre-checked for AA contrast
export const colors = {
  textPrimary: '#1A1A1A',
  surface: '#FFFFFF',
  textOnBrand: '#FFFFFF',
  brand: '#0B5FFF',
};

1.4.4 Resize Text + 1.4.10 Reflow (AA)

Text must scale to 200% without clipping. allowFontScaling is on by default, so leave it alone. Fixed heights are what break:

// ❌ clips at large Dynamic Type sizes
<View style={{ height: 48 }}><Text>{label}</Text></View>

// ✅ grows with the text
<View style={{ minHeight: 48 }}><Text>{label}</Text></View>

2.1.1 Keyboard (A)

Hardware keyboards are a real case on iPads, foldables and Android devices with Bluetooth keyboards. TextInput's onKeyPress covers most of it. Any custom gesture needs an alternative, which also covers 2.5.7 below.

2.4.3 Focus Order (A) + 2.4.11 Focus Not Obscured (AA)

Focus order follows the view hierarchy, which usually matches the visual order. It breaks when you use absolute positioning or zIndex. Modals need to trap focus:

<View
  importantForAccessibility={modalOpen ? 'no-hide-descendants' : 'auto'}
  accessibilityElementsHidden={modalOpen}
>
  {/* background screen */}
</View>

<Modal visible={modalOpen}>
  <View accessibilityViewIsModal={true}>{/* modal content */}</View>
</Modal>

For 2.4.11, keep focused inputs above the keyboard:

<KeyboardAvoidingView
  behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
  style={{ flex: 1 }}
>
  <ScrollView keyboardShouldPersistTaps="handled">{/* form */}</ScrollView>
</KeyboardAvoidingView>

2.5.8 Target Size (AA)

The usual offender is a 16pt icon button with no padding. hitSlop enlarges the touch area without changing the visuals:

<Pressable
  onPress={close}
  hitSlop={{ top: 14, bottom: 14, left: 14, right: 14 }}
  accessibilityRole="button"
  accessibilityLabel="Close"
>
  <Icon name="x" size={16} />
</Pressable>

2.5.7 Dragging Movements (AA)

react-native-draggable-flatlist won't give you an alternative for free. The cleanest RN-native fix is custom accessibility actions, which screen reader users reach through the VoiceOver rotor or the TalkBack actions menu:

<View
  accessible
  accessibilityLabel={`${item.title}, position ${index + 1}`}
  accessibilityActions={[
    { name: 'moveUp', label: 'Move up' },
    { name: 'moveDown', label: 'Move down' },
  ]}
  onAccessibilityAction={({ nativeEvent }) => {
    if (nativeEvent.actionName === 'moveUp') move(index, index - 1);
    if (nativeEvent.actionName === 'moveDown') move(index, index + 1);
  }}
>
  {/* draggable row */}
</View>

Add a visible long-press menu with the same options for sighted users who can't drag.

Understandable + Robust: forms, roles, state

These are the failures that get apps sued, because they stop people from completing a transaction.

3.3.1 Error Identification + 3.3.3 Error Suggestion

A red border means nothing to a screen reader. Announce the error:

import { AccessibilityInfo } from 'react-native';

function onSubmit() {
  if (!email) {
    setError('Email is required');
    AccessibilityInfo.announceForAccessibility('Email is required');
    return;
  }
}

<TextInput
  accessibilityLabel={error ? `Email, error: ${error}` : 'Email'}
  value={email}
  onChangeText={setEmail}
/>

3.3.2 Labels or Instructions (A)

Placeholder-only inputs fail because the placeholder disappears when you type. Use a persistent label. On Android you can link the two with accessibilityLabelledBy + nativeID:

<Text nativeID="emailLabel">Email</Text>
<TextInput
  accessibilityLabel="Email"            // iOS
  accessibilityLabelledBy="emailLabel"  // Android
/>

3.3.8 Accessible Authentication (AA, new in 2.2)

Let password managers do their job, and never block paste:

<TextInput
  secureTextEntry
  textContentType="password"   // iOS
  autoComplete="password"      // Android + iOS
  contextMenuHidden={false}    // keep paste available
/>

4.1.2 Name, Role, Value (A)

Custom controls need all three. Miss one and the control fails:

<Pressable
  onPress={() => setEnabled(!enabled)}
  accessibilityRole="switch"
  accessibilityLabel="Dark mode"
  accessibilityState={{ checked: enabled }}
>
  {/* visual toggle */}
</Pressable>

VoiceOver reads it as "Dark mode, switch, on." 👌

4.1.3 Status Messages (AA)

Toasts and "Saved" confirmations should be announced without moving focus:

<Text accessibilityLiveRegion="polite">{statusMessage}</Text> // Android

useEffect(() => {
  if (statusMessage) AccessibilityInfo.announceForAccessibility(statusMessage); // iOS + Android
}, [statusMessage]);

The 4-layer testing workflow

You can't claim compliance you can't demonstrate.

Layer 1: Lint on every commit.

npm i -D eslint-plugin-react-native-a11y

{
  "plugins": ["react-native-a11y"],
  "extends": ["plugin:react-native-a11y/all"]
}

This catches missing labels, invalid roles and unlabeled inputs. It won't catch contrast or focus order, and no linter can.

Layer 2: Screen reader walkthrough on every UI PR. Turn on VoiceOver (Settings → Accessibility → VoiceOver) or TalkBack, close your eyes, and complete each primary flow. It takes about 20 minutes per flow and catches more real bugs than anything else on this list.

Layer 3: Platform auditors before release. On iOS, use Xcode → Open Developer Tool → Accessibility Inspector. On Android, use Google's Accessibility Scanner. Both flag contrast, missing labels and small targets.

Layer 4: Automated regression. axe DevTools Mobile plugs into Appium and runs WCAG 2.2 rulesets against built apps. It's pricey, but it's how you prove compliance at CI speed on a big app.

If you ship weekly, that's roughly a 2-hour a11y pass per release.

The 5 bugs I see in almost every RN audit

#	Bug	Fix
1	Icon-only `Pressable` with no label	`accessibilityLabel` + `accessibilityRole="button"`
2	Modal doesn't trap focus	`accessibilityViewIsModal` (iOS) + hide background (Android)
3	Form errors are visual only	`AccessibilityInfo.announceForAccessibility()`
4	Custom switch reads as "button"	`accessibilityRole="switch"` + `accessibilityState={{ checked }}`
5	Low contrast on gradients	Semi-opaque overlay behind text, or move the text

Bugs 1–4 are all "forgot a prop" bugs, which makes them a defaults problem more than a skills problem. Your component library and codegen should require these props on interactive elements so the accessible path is the easy path. Some generators already work this way. RapidNative, for example, outputs screens with accessibilityRole, accessibilityLabel, accessibilityState and hitSlop already filled in. Contrast (bug 5) is harder to automate because it depends on your palette, but AA-checked semantic tokens get you most of the way.

Build it in, don't bolt it on

Retrofitting a 40-screen app that shipped without a11y props takes 2–4 weeks of focused work. Building those props in from day one costs close to nothing. The cheapest fix is upstream:

Make accessibilityLabel and accessibilityRole required in your design-system components (TypeScript helps here).
Turn on eslint-plugin-react-native-a11y with errors, not warnings.
Ship AA-safe color tokens and hitSlop defaults in your base Button and IconButton.

Then do the one thing that beats every tool: spend 20 minutes with VoiceOver on your current build.

What's the worst a11y bug you've found in your own app? Drop it in the comments 👇

File-Based Routing Explained (Next.js, Expo Router & Why Your Folder Is Now Your Router)

Chloe — Wed, 30 Sep 2026 07:21:48 +0000

TL;DR

File-based routing = your folder structure is your route config. No routes.js, no giant switch statement.
The core conventions are nearly universal: index → /, [param] → dynamic segment, [...rest] → catch-all, (group) → organize without changing the URL, _layout / layout → shared UI.
Next.js (web) and Expo Router (mobile) use almost the same mental model, so you can learn it once and use it everywhere.
The gotchas: route groups, layout nesting, and where auth guards live. We'll cover all three with code.

The old way: routes as config

If you've been writing React for a while, you've written something like this:

// App.jsx — the "before" picture
import { BrowserRouter, Routes, Route } from "react-router-dom";

export default function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/blog" element={<BlogIndex />} />
        <Route path="/blog/:slug" element={<BlogPost />} />
        <Route path="/settings" element={<SettingsLayout />}>
          <Route path="profile" element={<Profile />} />
          <Route path="billing" element={<Billing />} />
        </Route>
        <Route path="*" element={<NotFound />} />
      </Routes>
    </BrowserRouter>
  );
}

It works. But now you have two sources of truth: the file where the component lives, and the config that says where it's mounted. Rename a file, forget the config, and you get a broken route that nobody notices until prod.

File-based routing deletes the second source of truth.

The new way: the folder is the router

Here's the same app with file-based routing (Next.js App Router):

app/
├── layout.tsx            → wraps everything
├── page.tsx              → /
├── blog/
│   ├── page.tsx          → /blog
│   └── [slug]/
│       └── page.tsx      → /blog/:slug
├── settings/
│   ├── layout.tsx        → shared settings shell
│   ├── profile/page.tsx  → /settings/profile
│   └── billing/page.tsx  → /settings/billing
└── not-found.tsx         → 404

No config file. You look at the tree, you know the URLs. New dev joins the team? They ls app/ and they understand the whole app's navigation in ten seconds.

The conventions (they're basically universal)

Once you learn these five patterns, you can read almost any file-based router.

Pattern	Meaning	Example URL
`index` / `page`	The root of a folder	`/blog`
`[id]`	Dynamic segment	`/blog/hello-world`
`[...slug]`	Catch-all (1+ segments)	`/docs/a/b/c`
`(group)`	Folder for organization, not in URL	`(marketing)/about` → `/about`
`layout` / `_layout`	Shared UI wrapping children	nav bars, tabs, auth shells

Dynamic segments

The bracket name becomes a param you can read:

// app/blog/[slug]/page.tsx  (Next.js 15+)
export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPost(slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </article>
  );
}

Heads up: in Next.js 15, params became a Promise in server components. If you're upgrading from 14 and suddenly getting undefined, that's why.

Catch-all routes

Great for docs sites where depth is unknown:

// app/docs/[...slug]/page.tsx
export default async function Docs({
  params,
}: {
  params: Promise<{ slug: string[] }>;
}) {
  const { slug } = await params;
  // /docs/getting-started/install → ["getting-started", "install"]
  const doc = await getDocByPath(slug.join("/"));
  return <DocRenderer doc={doc} />;
}

Want it to also match /docs with no segments? Use double brackets: [[...slug]].

Route groups (the one everyone gets confused by)

Parentheses mean "this folder exists for me, not for the URL":

app/
├── (marketing)/
│   ├── layout.tsx    → marketing header + footer
│   ├── page.tsx      → /
│   └── pricing/page.tsx  → /pricing
└── (app)/
    ├── layout.tsx    → sidebar + auth check
    └── dashboard/page.tsx → /dashboard

/pricing and /dashboard both live at the top level of the URL, but they get completely different layouts. That's the real superpower of groups: different shells without ugly URL prefixes like /app/dashboard.

Same idea, now on mobile: Expo Router

Here's where it gets fun. React Native used to be the land of createStackNavigator and deeply nested navigator config. Expo Router brought file-based routing to mobile, and the conventions are almost identical:

app/
├── _layout.tsx           → root Stack
├── (tabs)/
│   ├── _layout.tsx       → bottom tab bar
│   ├── index.tsx         → Home tab  (/)
│   └── profile.tsx       → Profile tab (/profile)
├── post/
│   └── [id].tsx          → /post/123
└── +not-found.tsx        → 404

Differences worth noting: layouts are _layout.tsx (underscore), screens are named files instead of page.tsx, and special files use a + prefix (+not-found.tsx, +api.ts for API routes).

The root layout

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

export default function RootLayout() {
  return (
    <Stack>
      <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
      <Stack.Screen name="post/[id]" options={{ title: "Post" }} />
    </Stack>
  );
}

Tabs via a route group

// app/(tabs)/_layout.tsx
import { Tabs } from "expo-router";
import { Ionicons } from "@expo/vector-icons";

export default function TabLayout() {
  return (
    <Tabs>
      <Tabs.Screen
        name="index"
        options={{
          title: "Home",
          tabBarIcon: ({ color, size }) => (
            <Ionicons name="home" color={color} size={size} />
          ),
        }}
      />
      <Tabs.Screen
        name="profile"
        options={{
          title: "Profile",
          tabBarIcon: ({ color, size }) => (
            <Ionicons name="person" color={color} size={size} />
          ),
        }}
      />
    </Tabs>
  );
}

Notice (tabs) doesn't show up in the URL. Same exact rule as Next.js route groups.

Reading params and navigating

// app/post/[id].tsx
import { useLocalSearchParams, Link } from "expo-router";
import { View, Text } from "react-native";

export default function PostScreen() {
  const { id } = useLocalSearchParams<{ id: string }>();

  return (
    <View style={{ padding: 16 }}>
      <Text>Post #{id}</Text>
      <Link href={`/post/${Number(id) + 1}`}>Next post →</Link>
    </View>
  );
}

And the bonus you get for free: every screen is deep-linkable. myapp://post/42 just works, because the URL was the route all along. With config-based navigation, you'd be hand-writing a linking config for that.

Where do auth guards go?

This is the question I see most. Answer: in the layout that wraps the protected routes. Groups make this clean.

// app/(app)/_layout.tsx  — Expo Router
import { Redirect, Stack } from "expo-router";
import { useSession } from "@/lib/auth";

export default function AppLayout() {
  const { session, isLoading } = useSession();

  if (isLoading) return null; // or a splash screen
  if (!session) return <Redirect href="/sign-in" />;

  return <Stack />;
}

Everything inside (app)/ is now protected. Everything outside it (sign-in.tsx, marketing screens) isn't. One file, one rule, zero per-screen checks.

In Next.js you'd typically do the same check in middleware.ts (runs before render) or in the group's layout.tsx with a redirect() from next/navigation.

If you'd rather skip the scaffolding

Honestly, the most tedious part of file-based routing isn't learning it, it's setting up the initial tree: root layout, tab group, auth group, a couple of dynamic screens, wiring the icons. It's the same 10 files every time.

I've been using RapidNative for that part: you describe the app, and it generates a React Native + Expo project with the Expo Router structure already in place, so you start at "customize the screens" instead of "create _layout.tsx again". Worth a look if you spin up mobile prototypes often.

Gotchas I've hit (so you don't have to)

1. Two files, one route. app/about.tsx and app/about/index.tsx both resolve to /about. Pick one convention and stick with it.

2. Groups don't isolate URLs. (marketing)/pricing and (app)/pricing would collide, since both become /pricing. Groups change layouts, not paths.

3. Colocating non-route files. In Next.js App Router, only page.tsx becomes a route, so you can safely drop components/ or utils.ts next to it. In Expo Router, every file in app/ is a route, so keep helpers outside (src/components, lib/), or prefix with _ where supported.

4. Layouts persist. A layout doesn't remount when you navigate between its children. Great for keeping tab state, surprising if you expected a useEffect in the layout to fire on every navigation.

5. Typed routes are worth turning on. Both Next.js and Expo Router can generate types from your file tree, so href="/pots/123" (typo) fails at compile time instead of at runtime:

// app.json (Expo)
{
  "expo": {
    "experiments": {
      "typedRoutes": true
    }
  }
}

Should you use file-based routing?

My take:

New project? Yes. Default to it. The discoverability alone pays for itself.
Big existing app on config routing? Migrate only if navigation bugs are an actual pain point. It's a real refactor, especially on mobile.
Need wildly dynamic, runtime-defined routes (e.g. a CMS defining the whole URL space)? Use a catch-all and resolve inside, or stay with config. File-based routing assumes your routes are known at build time.

The biggest win isn't fewer lines of code. It's that the answer to "where does this URL live?" is always "look at the folder."

What's your setup: Next.js, Expo Router, SvelteKit, Nuxt, or still hand-rolling routes? And what's the weirdest routing bug you've shipped? Drop a comment, I read all of them. 👇

Running Real Postgres Locally Without Docker (with Tinbase)

Chloe — Mon, 28 Sep 2026 06:35:29 +0000

TL;DR

Docker Supabase on an 8 GB laptop: 12 containers, ~1.6 GB RAM idle, 45 s cold boot
Tinbase: one ~58 MB binary, real Postgres 17, ~100 MB RAM idle, ~2.5 s cold boot
supabase-js works with zero code changes: swap one env var
Migrate an existing project with supabase db dump | tinbase import
RLS, edge functions, and realtime use the same contract as hosted Supabase
Not for you if you live in the Supabase dashboard or need Storage image transforms

Disclosure: I work on Tinbase. It's MIT-licensed and not affiliated with Supabase. It matches the supabase-js client contract, it's not a Supabase replacement.

Why bother

Most of us run local Postgres via Docker. On an M1 Air with 8 GB RAM, the Docker Supabase stack eats 1.6 GB of RAM at rest and takes 45 seconds to cold boot. That's a lot of headroom to give up for a dev environment, and it's brutal in CI or on a workshop laptop.

Tinbase is a single binary that runs real Postgres 17 plus Supabase's auth, realtime, and edge-function layers. Here's the whole setup, start to finish.

Install

macOS / Linux:

curl -fsSL https://tinbase.dev/install.sh | sh
tinbase --version
# tinbase 0.9.4

Windows: grab the .exe from the releases page. Single binary either way.

Start

mkdir -p ~/tinbase-data
tinbase start --data-dir ~/tinbase-data
# server listening on http://localhost:8080
# postgres available at postgresql://postgres@localhost:5432/postgres

Boot time: ~2.5 s cold, ~800 ms warm. supabase start is ~45 s cold on the same machine.

Verify it's real Postgres

psql postgresql://postgres@localhost:5432/postgres -c 'select version();'
#              version
# --------------------------------------------------
#  PostgreSQL 17.1 on x86_64-apple-darwin ...

Not PGlite (Postgres compiled to WASM with the client-server pieces cut out). Not SQLite with a Postgres wire adapter. Actual Postgres 17.

Use it with supabase-js

Any existing Supabase project works by changing one env var:

# .env.local
SUPABASE_URL=http://localhost:8080
SUPABASE_ANON_KEY=eyJ...  # printed by `tinbase start`

Code is unchanged:

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
);

const { data, error } = await supabase
  .from('projects')
  .select('*')
  .eq('tenant_id', 'a-uuid');

Same client, same auth flow (supabase.auth.signInWithPassword), same realtime subscriptions, same RLS. For a typical Next.js + Supabase codebase the migration is one env var plus one dump/import.

Migrate an existing Supabase project

From your existing Docker Supabase project:

# 1. Dump schema + data
supabase db dump --file dump.sql --data-only=false

# 2. Load into Tinbase
tinbase import --file dump.sql

# 3. Verify
psql postgresql://postgres@localhost:5432/postgres -c '\dt'

If you rely on Supabase-specific extensions or hooks that Tinbase doesn't support yet, tinbase import prints a warning listing each one. The current compatibility matrix is in the import docs, so check that before you commit an afternoon to it.

Postgres extensions

Enabled by default:

Extension	What it's for
`pgvector`	embeddings
`pg_trgm`	fuzzy text match
`pg_stat_statements`	query profiling
`unaccent`	accent-insensitive search
`pgcrypto`	`gen_random_uuid()`, `crypt()`, `digest()`
`uuid-ossp`	legacy uuid helpers

Check what's loaded:

select extname from pg_extension order by extname;

Enable anything else the normal way:

create extension if not exists postgis;

RLS behaves identically

Because it's real Postgres, RLS policies work exactly as they do on hosted Supabase. This is the piece I trust most:

alter table projects enable row level security;

create policy projects_tenant_scope on projects for all
  using (tenant_id = (select tenant_id from profiles where user_id = auth.uid()));

auth.uid() is provided by Tinbase's auth layer and matches the Supabase contract. If your policies pass locally against Tinbase, they pass in hosted Supabase.

Edge functions

Tinbase runs edge functions in an embedded V8 (not a Deno subprocess). Cold start is ~15 ms.

// functions/hello.ts
export default async (req: Request) => {
  return new Response(JSON.stringify({ msg: 'hi' }), {
    headers: { 'content-type': 'application/json' },
  });
};

tinbase functions serve
# functions listening on http://localhost:8080/functions/v1
curl http://localhost:8080/functions/v1/hello
# {"msg":"hi"}

Same HTTP surface as Supabase Edge Functions, same client call (supabase.functions.invoke('hello')).

Realtime subscriptions

supabase
  .channel('projects')
  .on(
    'postgres_changes',
    { event: 'INSERT', schema: 'public', table: 'projects' },
    (payload) => {
      console.log('new project:', payload.new);
    }
  )
  .subscribe();

Same client, same channel API, same event payloads. The realtime server inside Tinbase is a Go implementation of the Supabase realtime spec and consumes the same logical replication stream from Postgres.

When Docker Supabase is still the right call

Being honest about the trade-offs:

You use the local Supabase dashboard heavily. Tinbase doesn't ship one yet. tinbase studio is planned, not shipped.
You depend on Supabase Storage's image transformation pipeline. Tinbase storage is plain file I/O, no on-the-fly transforms.
Your team is fine with the Docker setup and RAM isn't a constraint. Nothing to fix.

For laptop dev, workshops, CI, and demo environments, the single-binary story won on every axis that mattered to me: RAM, boot time, disk, distribution.

Try it

curl -fsSL https://tinbase.dev/install.sh | sh

Source is on GitHub under tinbase-dev/tinbase (MIT).

If you try it against a real project, drop a comment with what broke, what didn't, and what your supabase start cold boot was before. The import warnings are the part I most want feedback on.

What React Native Devs Actually Struggle With: A Year of Support Tickets

Chloe — Fri, 25 Sep 2026 08:24:16 +0000

We tagged and categorized every customer support ticket that came into Applighter for twelve months. Not tweets. Not surveys. Real developers, stuck on real code, mid-shipping a real app. The result is a very different picture of react native common problems than what you'll find in the annual community surveys — because people file tickets when they're bleeding, not when they're reflecting.

The short version: React Native developers don't mostly struggle with React Native. They struggle with the ten things around it — EAS credentials, Supabase RLS, Xcode signing, Android package name mismatches, Metro caches, environment variable leaks, App Store rejections for NSPhotoLibraryUsageDescription, and voice-model latency on Android. The core framework is fine. The perimeter is a minefield.

Methodology (in one paragraph so you can skip it)

We track tickets in a lightweight tag taxonomy: platform:ios|android|web, layer:build|backend|ui|auth|payment|ai, severity:blocker|degraded|question, and template:<slug>. Between the seven starter templates we sell — from the Weather App to the AI Voice Notes template — that's a few thousand tickets spread across a wide slice of the ecosystem: Expo SDK 50 through 53, Supabase, NativeWind, Stripe licensing, and a rotating cast of AI providers. We threw out feature-request tickets, refund questions, and anything that turned out to be a typo. What's left is signal: the reproducible, teachable friction that developers hit when they take a working starting point and try to ship it.

The ranked list: what React Native devs struggle with

Here's the top ten, sorted by ticket volume. The percentage is share of total in-scope tickets. We'll take each one below and say what it actually is, and what the fix looks like.

Rank	Problem	Share	Layer
1	EAS Build fails on first run	18.4%	build
2	Supabase RLS returning empty arrays after auth	12.1%	backend
3	Environment variables not reaching the native binary	9.7%	build
4	Metro bundler cache poisoning after dependency bump	7.8%	build
5	iOS Info.plist permission strings missing → App Store reject	6.9%	ios
6	Android package name conflicts on rename	6.2%	android
7	Push notifications silently not delivering on Android	5.8%	native
8	AI streaming stalls / dropped tokens	5.1%	ai
9	Stripe webhook not firing to Supabase Edge Function	4.4%	payment
10	Voice transcription latency on mid-range Android	3.9%	ai

The rest of the tail (about a quarter of volume) is spread across dozens of one-off issues: font loading order, NativeWind class caching, Reanimated worklet crashes on old Fabric versions, and the ever-popular "why is my white screen white."

1. EAS Build fails on first run (18.4%)

The #1 problem people hit isn't in React Native at all. It's the first time they try to actually build an installable binary.

The ticket pattern is almost always the same: they clone the template, run bunx expo prebuild, then eas build --profile development --platform ios — and the build dies in the "Install pods" step with a version mismatch. Or worse, it dies in a Fastlane step with a signing error, and Fastlane's error messages are famously not aimed at humans.

The root causes cluster into three buckets:

Expo SDK vs. newArchEnabled mismatch. The dev cloned an SDK 50 template into an SDK 53 CLI without running expo doctor.
iOS Simulator vs. device profile confusion. People pick --platform ios and don't realize the default profile targets a physical device with provisioning that hasn't been set up yet.
Missing EXPO_TOKEN in CI. If you're building from a CI job, EAS won't authenticate.

What we did on our side: every template config now pins Expo SDK versions inside package.json, plus a preflight script (scripts/preflight.sh) that runs expo doctor and blocks the build if anything is red. Ticket volume in this category dropped 42% quarter-over-quarter after we shipped the preflight.

Actionable takeaway: before you file a Discord post, run bunx expo doctor and paste the output. Nine times out of ten, it names the file that's wrong.

Docs: the official Expo troubleshooting page at docs.expo.dev/build-reference/troubleshooting covers most of the actual error strings.

2. Supabase RLS returns empty arrays after auth (12.1%)

The second-most-common ticket makes people think Supabase is broken. It isn't. Their Row Level Security policy is silently doing exactly what it was designed to do: filter out every row that doesn't match auth.uid(), including the ones they think should match.

The ticket almost always reads: "I'm signed in, I can see my user ID, but select * from projects returns []." And then a screenshot of the Supabase table, full of rows.

The fix falls into four checks:

Is your Authorization: Bearer <access_token> actually being sent? Log the raw fetch headers, not the client abstraction. Half the time the token is undefined.
Does your RLS policy use auth.uid() or auth.jwt() ->> 'sub'? The two behave differently when you have anon-key requests mixed in.
Are you querying with the service_role key in a client bundle? (You should not be. But we do see it.)
Is your session refreshing? Sessions expire in an hour by default. If the client isn't refreshing, subsequent requests silently fall to anon role.

For everyone shipping a Supabase-backed app on iOS or Android, we wrote up the full pattern in our guide to Supabase auth in React Native. Bookmark that if you're touching auth.

The Supabase docs on RLS at supabase.com/docs/guides/database/postgres/row-level-security are the canonical reference — but the mental model shift ("policies are WHERE clauses that always run") is the hard part.

3. Environment variables don't reach the native binary (9.7%)

This one is sneaky. Everything works in Expo Go. Everything works in the simulator. Then the developer runs eas build, installs the standalone .ipa, launches — and the API base URL is undefined.

Root cause: Expo does not automatically pull .env into a production build. You have to declare secrets in EAS Secrets or push them via eas.json env blocks, and you must prefix runtime-safe variables with EXPO_PUBLIC_. Anything without that prefix is dropped from the client bundle at build time.

The tell: console.log(process.env.API_URL) prints in Metro but is undefined in the standalone app. The pattern almost always resolves by renaming API_URL → EXPO_PUBLIC_API_URL and re-building.

4. Metro cache poisoning after dependency bump (7.8%)

You updated a package. The app crashes with an inscrutable error. Nothing you do fixes it. Then a friend on Discord says "try --reset-cache" and it works.

We see this so often that our templates now ship with a bun reset script that runs:

watchman watch-del-all
rm -rf node_modules ios/Pods .expo
bun install
bunx expo prebuild --clean

If you don't have this scripted, you'll type it wrong at 2am and blame yourself. Don't. Metro's cache invalidation is genuinely aggressive and genuinely wrong sometimes. React Native itself is famously an "if in doubt, wipe caches" ecosystem — Metro's own docs admit as much.

5. iOS Info.plist permission strings (6.9%)

The App Store review rejection nobody sees coming. Apple's automated review will reject builds that use the camera, microphone, photo library, or location and don't have a corresponding NSXxxUsageDescription string in Info.plist.

The ticket flow: dev submits build to TestFlight, it uploads fine, they get an email saying "your app has been rejected," and the reason is something like "your app uses the camera but doesn't say why."

The fix is easy. Add the strings to your app.json:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSCameraUsageDescription": "This app needs camera access to scan documents.",
        "NSMicrophoneUsageDescription": "This app records voice notes."
      }
    }
  }
}

The mistake we most often see is developers writing generic strings ("This app uses the camera"). Apple has started rejecting those too. Say why, in a sentence a regulator could quote back.

6. Android package name mismatch on rename (6.2%)

The template ships as com.applighter.starter. The developer wants com.acmecorp.myapp. They change it in app.json and half the Android build system stops working.

The problem: on Android, the package name lives in about six places — app.json, android/app/build.gradle, AndroidManifest.xml, the directory structure under android/app/src/main/java/, google-services.json (if you use Firebase), and the OAuth redirect URI. Change it in one, forget the others, and the build succeeds but the app crashes on launch with a ClassNotFoundException.

Our renaming guide covers every location, but honestly the safest move if you're on managed Expo is: delete the android/ folder, change the config, run expo prebuild --clean. Let the tooling regenerate it.

7. Android push notifications silently not delivering (5.8%)

The insidious one. Everything looks like it's working: expo-notifications returns a valid Expo push token, you send a POST to the Expo push API, you get back "status": "ok" — and the notification never appears on the device.

The Android-specific tickets almost always trace to one of these:

Missing FCM setup. Expo's push service is a proxy; on Android it still needs your FCM credentials configured in the Expo dashboard.
Battery optimization killing the process. Xiaomi and Samsung devices in particular have aggressive background restrictions that suppress notifications from apps the user hasn't opened in 24 hours.
Notification channel not created. Android 8+ requires you to create a channel before you can post to it.

We covered the full stack in The Definitive Guide to Push Notifications in Expo. If you're shipping push, read that end-to-end before you spend a week debugging.

8. AI streaming stalls or drops tokens (5.1%)

Specific to the AI templates — the Chat with PDF template, the AI Voice Notes template, and the AI Calorie Tracker.

The pattern: streaming works locally with fetch + getReader(), but on the device it stalls after a few hundred tokens or drops the last chunk. Almost always the culprit is React Native's fetch polyfill: it doesn't support ReadableStream the way the browser does. You need to use expo-fetch or the underlying XMLHttpRequest progress events, and buffer manually.

We walked through the full pattern in Streaming AI Responses to React Native. The short answer: expo/fetch or a Server-Sent Events shim. Don't fight the platform fetch.

9. Stripe webhook doesn't fire to Supabase (4.4%)

Stripe → Supabase Edge Function webhooks failing is almost always one of three things:

Signing secret from Stripe dashboard doesn't match the one in the Edge Function env.
Edge Function is behind Supabase's default auth. You need to explicitly mark it public in supabase/config.toml.
The Stripe webhook endpoint is pointing at the deploy branch preview URL, not production.

These are boring, but they're a nontrivial share of our support load — enough that we now include a test-webhook.sh script that fires a dummy checkout.session.completed event so you can verify end-to-end before you go live.

10. Voice transcription latency on mid-range Android (3.9%)

The last one on the list is a hardware reality more than a bug. Real-time voice transcription (Whisper, Deepgram, whatever) on a $300 Android device is slower than on an iPhone Pro. Users assume the app is broken. It's not — it's just that the STT model is either running on a slower CPU or over a slower network connection to a cloud endpoint.

The fixes we recommend:

Chunk audio at 4-second intervals instead of 10 (feels more responsive even if wall-clock latency is the same).
Show a token-level typing indicator so the user knows the app is alive.
Fall back to a smaller model tier for older devices.

We build this fallback into the AI Voice Notes template by default: deepgram-nova-2 for iOS ≥ iPhone 12 and modern flagship Android, whisper-small for everything else, config-driven.

What this tells us about the ecosystem

The pattern is clear: React Native itself, the framework, is not what most developers struggle with. The framework has stabilized. What developers hit is the seam between the framework and everything around it — build tooling, native permissions, backends, push infrastructure, AI providers, and platform-specific device quirks.

That's why we started Applighter in the first place. A UI template that gives you screens doesn't solve any of these ten problems. A full-stack template that ships with a working Supabase backend, a working push notification setup, a working Stripe webhook, and a working streaming AI pipeline solves eight of them out of the box.

Here's how the two approaches compare in terms of what tickets you'd actually file:

Problem	Blank Expo template	UI-only kit	Applighter template
EAS build config	You write it	You write it	Preflight-scripted
Supabase RLS policies	You write them	Not included	Included + tested
Push notifications	You wire it	Screens only	Full FCM + APNs
Stripe → Supabase webhook	You build it	Not included	Ships with test script
iOS Info.plist strings	You add them	Missing	Pre-declared
Streaming AI	You debug fetch	Not applicable	expo/fetch by default
Env variable propagation	You learn the hard way	Same	Documented in README

Some folks would rather build these seven layers themselves and learn everything on the way up. That's a completely reasonable choice. Others would rather buy the layers and spend their time on their actual product idea. That's also reasonable. What isn't reasonable is buying a "template" that gives you nothing but screens and thinking you've bought a foundation. (For an honest look at that market, see reactnativetemplates.com and similar aggregators — most of what's listed is a UI kit calling itself a template.)

What we changed based on the data

Because we get to see this data and most template vendors don't, we made concrete changes over the year:

Added bunx expo doctor and a preflight script to every template's postinstall, killing 42% of build-related tickets.
Shipped a docs/troubleshooting.md in every template repo with the exact ten problems above, pre-answered.
Added a bun reset script so the cache-poisoning ticket has a one-command fix.
Pinned Expo SDK versions and included an upgrade path doc for the next minor.
Baked FCM and APNs setup into every template's setup guide with real screenshots, not "consult the Expo docs."
Ship RLS policies as part of the initial migration — no dev should have to invent them.

None of this is glamorous work. It's the exact same set of concerns a real production engineering team would prioritize — because "hard to ship" is a bug, not a marketing feature.

Takeaways for developers

If you're building a React Native app right now, the empirical priority order for what you should invest a day learning:

EAS Build config — this is where you'll die first. Learn eas.json and profiles before you write your second screen.
Supabase RLS — or whatever backend auth model you're using. Get the mental model right on day one.
The env variable propagation model — because "works in dev, undefined in prod" is a 3am problem.
The Metro cache reset command — put it in a script.
App Store rejection rules — read Apple's list of common rejections before submission.

If you're building on top of a starter, pick one whose vendor tracks this data and iterates on it. If your template hasn't had a commit in 4 months, that's not "stable" — that's "abandoned." See our honest comparison of the market for how to evaluate.

FAQ

What is the most common problem React Native developers face in 2026?
Based on our year of support ticket data, EAS Build failures on first run are the single most common category (18.4% of tickets). The core framework issues are far less common than the tooling around it.

Are Expo templates production ready?
Expo's own official templates are production ready as starting points but are intentionally minimal. Third-party templates vary enormously — some ship full backends, tests, and push notification setup; others ship only screens and call themselves templates. Read the source before you buy.

Why do Supabase queries return empty arrays even when the table has rows?
Almost always because Row Level Security policies are filtering the rows out. Confirm the Authorization header is being sent, verify auth.uid() matches the row's owner column, and log the raw request to check the session hasn't expired.

How do I stop my Expo app from breaking after upgrading dependencies?
Run bunx expo doctor after every upgrade. Pin your Expo SDK version explicitly in package.json. Clear Metro cache with a scripted reset command rather than typing it by hand.

Is React Native still worth using in 2026?
Yes — the framework is more stable than ever and the ecosystem has matured on debugging, performance, and toolchain. The remaining friction is in the seam between the framework and native platform/backend infrastructure. That's solvable with better templates and better tooling — which is exactly what we spend our year building.

Ready to skip the ticket queue and start with a template that already handles the top ten? Browse the Applighter catalog or read our refund policy if you want to try one risk-free.

OTA Updates That Actually Save You: A 2026 Playbook for Shipping JS Fixes Without the App Store

Chloe — Wed, 23 Sep 2026 05:55:53 +0000

Why most OTA setups fail the first real emergency

Teams add expo-updates in week one, publish a couple of bundles, and call it done. Then a checkout bug hits production on a Friday night, and the "fix it in five minutes" promise turns into two hours of wondering which build is listening to which channel, whether the fix is compatible with the installed binary, and why half the users still have the old code. The goal of OTA isn't "can push JS". It's time-to-fixed-user. Everything below optimises for that number.

The five must-haves

Separate channels per environment. At minimum preview and production, mapped in eas.json build profiles. Every binary should know exactly which channel it listens to, and nobody should be able to reach production users by accident from a laptop.
A runtime version policy you can trust. Use runtimeVersion: { policy: "fingerprint" } so any native change (a new module, a config plugin, a permission) automatically produces a new runtime version. An OTA bundle then only reaches binaries that can actually run it. Hand-bumped version strings are how you ship JS that calls a native module that isn't there.
Staged rollouts. Push to 10% of production, watch crash rates and key events for an hour, then widen. A bad bundle to 10% of users is an incident. A bad bundle to 100% is a postmortem.
A one-command rollback. Know before you need it: republish the previous good update, or roll back to the bundle embedded in the binary. Write the command in your README. At 11 PM nobody wants to read CLI docs.
Error recovery plus crash reporting tied to the update ID. expo-updates can fall back when a new bundle crashes on launch, but you still need Sentry (or similar) tagging every event with the update ID and channel. Otherwise "crash rate went up" can't be traced to "update X caused it."

The five mistakes to avoid

One channel for everything. If staging and production binaries share a channel, your QA build is your production build. Split them on day one.
OTA-ing native changes. Upgraded a library with native code? That needs a store build. The fingerprint policy guards this, but only if you don't override it "just this once."
Forcing reloads mid-session. Calling reloadAsync() the moment a download finishes wipes forms, carts and scroll position. Apply on next cold start by default, and reserve immediate reloads for critical fixes behind a friendly prompt.
Skipping code signing. Signed updates mean the app rejects any bundle your key didn't sign. It takes a certificate and two config lines. Do it before you have users, not after an incident.
Treating OTA as your release strategy. OTA is for fixes and small iterations. Shipping major features over the air bypasses review in ways store guidelines frown on, and it trains the team to skip proper releases. Ship features in binaries; use OTA for fixes.

The bad-bundle test

Publish an update to your preview channel that throws on launch. Then check four things: the app recovers to the last working bundle, your crash tool shows the error tagged with the update ID, you can roll back with one command, and the next good update reaches the device. If any step needs Slack archaeology or a store resubmission, your OTA setup is a demo, not a safety net.

A pragmatic 2026 OTA config

Updates: expo-updates with EAS Update, Expo SDK 53+.
Runtime version: fingerprint policy, no manual overrides.
Channels: preview and production, bound per build profile in eas.json.
Check strategy: check on launch, apply on next cold start; useUpdates() for an optional "Update ready, restart?" banner.
Safety: code signing enabled, staged rollouts on production, rollback command in the README.
Observability: Sentry with the update ID and channel as tags on every event.
CI: GitHub Actions publishes to preview on merge to main; promotion to production is a manual, reviewed step.

What's next

The best OTA setup is the one you've already rehearsed. Every team eventually ships a broken bundle; the ones that recover in minutes are the ones who tested rollback on a quiet Tuesday. RapidNative ships with these OTA defaults wired in: channels, fingerprint runtime versions, and rollback scripts. Grab it or wire your own. The rehearsal matters more than the repo.

Postgres for local dev: one container, one Makefile

Chloe — Mon, 21 Sep 2026 05:45:00 +0000

Most local database setups fail in one of two ways. Either everyone shares a staging database and steps on each other's data, or the repo ships a 200-line compose file with six services that nobody fully understands. You need neither. One Postgres container, plain SQL migrations, and a reset command that runs in seconds will carry you a long way.

The container

# docker-compose.yml
services:
  db:
    image: postgres:17
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: app_dev
    volumes:
      - pgdata:/var/lib/postgresql/data
    command: >
      postgres
      -c fsync=off
      -c synchronous_commit=off
      -c full_page_writes=off
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app_dev"]
      interval: 2s
      retries: 15

volumes:
  pgdata:

Pin the major version to whatever you run in production. postgres:latest is how you discover a version mismatch at deploy time. (If you pin 18 or later, the image expects the volume mounted at /var/lib/postgresql instead.)

The three -c flags trade durability for speed. Your dev data is disposable, so take the trade, and never copy those lines into a production config.

# .env
DATABASE_URL=postgres://app:app@localhost:5432/app_dev

This one variable is the only thing your app knows about the database.

Migrations are SQL files

migrations/
  001_users.sql
  002_sessions.sql
  003_add_user_timezone.sql
seed.sql

They're numbered, append-only, and written in plain SQL. No ORM-generated diffs, no DSL to learn. When you need to know what the schema looks like, you read the files.

The reset command

include .env
export

ADMIN_URL = postgres://app:app@localhost:5432/postgres

db-up:
    docker compose up -d --wait db

db-reset: db-up
    psql $(ADMIN_URL) -c "DROP DATABASE IF EXISTS app_dev WITH (FORCE)"
    psql $(ADMIN_URL) -c "CREATE DATABASE app_dev"
    for f in migrations/*.sql; do \
      psql $(DATABASE_URL) -v ON_ERROR_STOP=1 -q -f $$f || exit 1; \
    done
    psql $(DATABASE_URL) -v ON_ERROR_STOP=1 -q -f seed.sql

db-shell:
    psql $(DATABASE_URL)

make db-reset is the primitive everything else rests on. If it's fast, nobody hoards a precious local database they're afraid to touch. After a bad migration, a branch switch, or a weird state, you reset and move on.

It also means every migration gets replayed from zero on every reset, so your migration history is continuously tested instead of only tested in production.

Tests: template databases

Don't run tests against app_dev, and don't truncate tables between tests. Postgres can clone a database at the file level:

-- once per test run, after migrating app_template
CREATE DATABASE test_a1b2c3 TEMPLATE app_template;

-- when the test finishes
DROP DATABASE test_a1b2c3;

Cloning a small schema takes tens of milliseconds. Each test, or each test worker, gets a real, isolated, fully migrated database, which means no mocks and no shared state. It also removes "passes alone, fails in the suite." The one catch is that nothing can be connected to the template while it's being cloned, so migrate it and then leave it alone.

Where this breaks

This setup is right for projects that:

Use stock Postgres or extensions with a published image
Have a seed dataset small enough to rebuild in seconds
Run on a single database

It gets less comfortable when:

You need extensions. Swap the image (pgvector/pgvector, postgis/postgis) instead of building your own until you truly have to.
Performance bugs hide behind tiny data. A query that's instant on 50 seed rows can be a sequential scan on 5 million. Keep a script that generates volume with generate_series, and check EXPLAIN ANALYZE against it before shipping anything query-heavy.
Your production is managed Postgres. Hosted providers restrict superuser and some extensions. If your migrations assume superuser locally, they'll fail on deploy, so run them as a non-superuser role in dev too.
You run several projects. They'll all want port 5432, so give each project its own host port in compose and its own DATABASE_URL.

Each of these changes a line or two, and the shape of the setup stays the same.

Wrap-up

Local database setups fail when they're slow or fragile, because people stop resetting them, and then every machine drifts into its own private schema. A fast reset and a versioned container prevent that, and template databases keep tests isolated.

For a batteries-included setup with Postgres, auth, and realtime prebundled, tinbase.dev is worth a look. And if the thing you're building on top of that database is a mobile app, RapidNative generates a full-stack React Native app from a prompt. Otherwise, the compose file and Makefile above will have you running in ten minutes.

Make the reset cheap. Everything else follows.