DEV Community: Russel Dsouza

Expo Router File-Based Routing: The Patterns That Matter in a Real App

Russel Dsouza — Thu, 12 Nov 2026 12:11:20 +0000

in Expo Router, your folder structure is your navigation. _layout.tsx files decide how screens are shown (stack, tabs, modal), route groups like (tabs) organize screens without changing URLs, [id].tsx handles dynamic routes, and every screen is deep-linkable automatically. The basics take ten minutes to learn. This guide covers the patterns you actually need once the app has auth, tabs, modals and links coming in from outside.

Most file-based routing tutorials stop at "create app/index.tsx and app/about.tsx". Real apps need more: a tab bar that disappears on detail screens, a login flow nobody can skip, modals that work with the back gesture and push notifications that open the right screen. All of that is solvable with folder structure, once you know the patterns.

The mental model: files are routes, layouts are navigators

Two rules explain almost everything:

Every file in app/ is a route. app/settings.tsx is /settings. app/projects/[id].tsx is /projects/42.
Every _layout.tsx wraps the routes next to it and decides how they're presented: as a stack, as tabs, or as anything custom.

A few special names complete the picture:

index.tsx: the default route for its folder (/ or /projects).
[param].tsx: a dynamic segment, read with useLocalSearchParams().
[...rest].tsx: a catch-all for any depth.
(group)/: a route group. It organizes files and can have its own layout, but doesn't appear in the URL.
+not-found.tsx: what to show for unmatched routes.

Pattern 1: Tabs inside a stack (the structure most apps need)

The classic mobile layout: a bottom tab bar on the main screens, and detail screens that slide in over the tabs, hiding the tab bar. The trick is that the tabs live inside a stack, not the other way round.

app/
├── _layout.tsx            # root Stack
├── (tabs)/
│   ├── _layout.tsx        # Tabs navigator
│   ├── index.tsx          # /          (Home tab)
│   ├── search.tsx         # /search    (Search tab)
│   └── settings.tsx       # /settings  (Settings tab)
├── projects/
│   └── [id].tsx           # /projects/42  (pushed over the tabs)
└── +not-found.tsx

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

export default function RootLayout() {
  return (
    <Stack>
      <Stack.Screen name="(tabs)" options={tabsOptions} />
      <Stack.Screen name="projects/[id]" options={detailOptions} />
    </Stack>
  );
}

const tabsOptions = { headerShown: false };
const detailOptions = { title: 'Project' };

// app/(tabs)/_layout.tsx
import { Tabs } from 'expo-router';

export default function TabsLayout() {
  return (
    <Tabs>
      <Tabs.Screen name="index" options={homeOptions} />
      <Tabs.Screen name="search" options={searchOptions} />
      <Tabs.Screen name="settings" options={settingsOptions} />
    </Tabs>
  );
}

const homeOptions = { title: 'Home' };
const searchOptions = { title: 'Search' };
const settingsOptions = { title: 'Settings' };

Navigating to /projects/42 from any tab pushes the detail screen onto the root stack, so it covers the tab bar and gets a native back gesture. If you put projects/[id].tsx inside (tabs), it would become a tab (or render under the tab bar), which is rarely what you want.

Defining screen options as constants outside the JSX isn't required, but it keeps big layouts readable, and it's a habit that saves you from re-creating option objects on every render.

Pattern 2: Modals

A modal is just a stack screen with a different presentation:

app/
├── _layout.tsx
├── (tabs)/...
└── new-project.tsx        # /new-project, shown as a modal

// app/_layout.tsx (add to the root Stack)
<Stack.Screen name="new-project" options={modalOptions} />

const modalOptions = { presentation: 'modal', title: 'New project' } as const;

Open it with router.push('/new-project') and close it with router.back() (or router.dismiss()). On iOS you get the native sheet with swipe-to-dismiss for free. Because it lives on the root stack, it opens over the tabs from anywhere in the app.

Pattern 3: An auth gate nobody can skip

You want signed-out users to see only the auth screens, and signed-in users to never see them. Put each side in its own group:

app/
├── _layout.tsx
├── (auth)/
│   ├── _layout.tsx
│   ├── sign-in.tsx
│   └── sign-up.tsx
└── (app)/
    ├── _layout.tsx
    └── (tabs)/...

Recent versions of Expo Router include protected routes: wrap screens in Stack.Protected with a guard, and the router won't let anyone navigate to them while the guard is false, including through deep links:

// app/_layout.tsx
import { Stack } from 'expo-router';
import { useSession } from '@/lib/auth';

export default function RootLayout() {
  const { session, isLoading } = useSession();
  if (isLoading) return null; // or keep the splash screen visible

  return (
    <Stack screenOptions={hidden}>
      <Stack.Protected guard={!!session}>
        <Stack.Screen name="(app)" />
      </Stack.Protected>
      <Stack.Protected guard={!session}>
        <Stack.Screen name="(auth)" />
      </Stack.Protected>
    </Stack>
  );
}

const hidden = { headerShown: false };

On older versions without Stack.Protected, the same idea works with a redirect in the protected group's layout:

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

export default function AppLayout() {
  const { session, isLoading } = useSession();
  if (isLoading) return null;
  if (!session) return <Redirect href="/sign-in" />;
  return <Stack />;
}

Either way, the check lives in one layout, not in every screen. That's the main win: you can't forget to protect a new screen, because it inherits its folder's rules.

Pattern 4: Dynamic routes and params done right

// app/projects/[id].tsx
import { useLocalSearchParams } from 'expo-router';

export default function ProjectScreen() {
  const { id } = useLocalSearchParams<{ id: string }>();
  const project = useProject(id); // your data hook
  // ...
}

Three things to know:

Params are always strings. Parse numbers and booleans yourself, and validate them: a deep link can contain anything.
Use useLocalSearchParams, not useGlobalSearchParams, inside screens. The local version only updates when this screen's params change, so screens further down the stack don't re-render every time you navigate.
Pass IDs, not objects. It's tempting to pass a whole project through params, but params are serialized into the URL. Pass the ID and fetch (or read from your cache) on the screen. This is also what makes the screen work when it's opened from a deep link.

To build links with params, prefer the object form, which handles encoding for you:

import { Link } from 'expo-router';

const href = { pathname: '/projects/[id]', params: { id: project.id } } as const;

<Link href={href}>Open project</Link>

Pattern 5: Typed routes

Typos in route strings fail at runtime. Expo Router can generate types for every route in app/ so they fail at compile time instead. Enable it in your app config:

{
  "expo": {
    "experiments": {
      "typedRoutes": true
    }
  }
}

Run the dev server once to generate the types. After that, router.push('/projcts/42') is a TypeScript error, and editor autocomplete lists your real routes. Depending on your SDK version this may already be enabled by default; check your template.

Pattern 6: The same screen in more than one tab

Instagram-style apps open a profile from the Home tab and the Search tab, and in both cases the profile should stay inside that tab's stack. Expo Router handles this with shared routes, using an array-style group name:

app/(tabs)/
├── _layout.tsx
├── (home,search)/
│   ├── _layout.tsx        # a Stack, used by both tabs
│   ├── home.tsx
│   ├── search.tsx
│   └── users/[id].tsx     # one file, available in both tabs
└── settings.tsx

The (home,search) group creates two copies of the stack, one per tab, from the same files. Use useSegments() if a screen needs to know which tab it's in.

Pattern 7: Deep links and notification taps for free

Every route is a deep link automatically. With "scheme": "myapp" in your app config, myapp://projects/42 opens the project screen with the right params, and the protected route rules from Pattern 3 still apply.

That makes push notifications simple: put the route path in the notification's data and navigate to it when the user taps:

import { useEffect } from 'react';
import * as Notifications from 'expo-notifications';
import { router } from 'expo-router';

export function useNotificationRouting() {
  useEffect(() => {
    const sub = Notifications.addNotificationResponseReceivedListener((response) => {
      const url = response.notification.request.content.data?.url;
      if (typeof url === 'string') router.push(url);
    });
    return () => sub.remove();
  }, []);
}

Also handle the case where the app was closed when the notification was tapped, using Notifications.getLastNotificationResponseAsync() on startup. For links from your website (universal links on iOS, app links on Android), you configure your domain once and the same routes just work.

Common mistakes

Putting detail screens inside (tabs) when they should cover the tab bar. Detail screens usually belong on the root stack.
Checking auth in every screen instead of once in a layout.
Passing whole objects as params. Pass IDs; they survive deep links and app restarts.
Forgetting that groups don't change URLs. app/(auth)/sign-in.tsx is /sign-in, not /auth/sign-in, so two groups can't both contain index.tsx at the same level without a conflict.
Using router.push for redirects. After signing in, use router.replace so the back gesture doesn't return to the sign-in screen.

FAQ

Is Expo Router only for Expo apps? It's built on React Navigation and designed for Expo projects. Most new React Native apps start with Expo, so in practice it's the default router today.

Can I still use React Navigation APIs? Yes. Expo Router uses React Navigation under the hood, so navigator options, themes and many hooks carry over.

Does file-based routing work on the web too? Yes. The same app/ folder produces real URLs on the web, which is one of its biggest advantages for apps that ship to web and mobile.

How do I show a screen without a tab bar or header? Move it to the root stack (no tab bar) and set headerShown: false in its options (no header).

Conclusion

File-based routing turns navigation from a config file you maintain into a folder structure you can read at a glance. The patterns that matter in real apps are few: tabs inside a stack, modals on the root stack, an auth gate in one layout, IDs in params, typed routes, shared routes for multi-tab screens, and deep links that come for free.

If you'd like to start from a project that's already structured this way, RapidNative generates React Native and Expo apps with Expo Router, which you can export as a standard project and keep building on.

What's the navigation pattern that took you longest to get right? Share it in the comments.

Native App Conversion: Turning a Lovable (Vite + React + Supabase) App Into React Native and Expo

Russel Dsouza — Wed, 04 Nov 2026 11:17:53 +0000

Originally published on Hashnode.

converting a Lovable app to native isn't a wrapper job and it isn't a rewrite of your backend. You keep Supabase, your database schema, your RLS policies, your types and most of your business logic. You rebuild the UI layer with React Native primitives and NativeWind, replace React Router with Expo Router, re-plumb Supabase auth for a mobile runtime (session storage, token refresh, OAuth redirects through deep links), swap web-only libraries for native ones, and add the pieces the stores require. This guide walks through each layer with the code we actually use.

Lovable, like Bolt and v0, generates a Vite + React + TypeScript single-page app, usually styled with Tailwind and shadcn/ui and backed by Supabase. It's a great stack for the web. It's also exactly the stack that gets rejected under App Store Guideline 4.2 when it's wrapped in a WebView and submitted as an app.

Disclosure: this is written by the team at LetsDeployIt, where native conversion of AI-built apps is our day job. Everything below is the process we follow, so you can do it yourself.

1. Why not just wrap it?

A Capacitor or WebView wrapper ships your existing bundle inside a native shell. It's fast, and for some apps it's fine. For AI-built apps it tends to fail in three places:

Review. Guideline 4.2 rejects apps that are "a repackaged website". A WebView with browser-style scrolling, no native navigation and no native features is the textbook case. More on Guideline 4.2.
Feel. Text inputs, the keyboard, momentum scrolling, back gestures and transitions all behave like a browser, and users notice.
Platform features. Push notifications, secure storage, biometrics and background work are possible through plugins, but every one is a bridge you maintain.

Conversion keeps your data layer and rebuilds the presentation layer natively, which removes all three problems.

2. Audit the Lovable codebase first

Before writing any React Native, split the existing code into what ports and what doesn't. Clone the GitHub repo Lovable syncs to and sort files into four buckets:

Portable as-is: TypeScript types (including generated Supabase types in src/integrations/supabase/types.ts), zod schemas, pure utility functions, date and currency formatting, and data access functions that only call supabase.
Portable with changes: React hooks that use supabase plus browser APIs (localStorage, window, document), and anything using TanStack Query (which works in React Native unchanged, but focus and online handling need wiring).
Rewrite: every component that renders DOM elements, everything under src/components/ui (shadcn), layout and routing.
Replace or drop: web-only libraries (Recharts, rich text editors, drag-and-drop, PDF generation), SEO and marketing pages, and Stripe Checkout for digital goods.

A quick way to size the job:

# Components that render DOM and will need rewriting
grep -rlE "<(div|span|section|button|img|input|form)[ >]" src --include=*.tsx | wc -l

# Browser APIs that need replacing
grep -rnE "localStorage|sessionStorage|window\.|document\." src --include=*.ts --include=*.tsx

# Web-only dependencies to swap
grep -E "\"(recharts|@radix-ui|react-router-dom|react-dropzone|@tiptap|react-dnd)" package.json

3. Scaffold the Expo app

Start from a fresh Expo project with TypeScript and Expo Router rather than trying to bend the Vite project:

npx create-expo-app@latest my-app-native
cd my-app-native
npx expo install nativewind react-native-reanimated react-native-safe-area-context
npx expo install @supabase/supabase-js @react-native-async-storage/async-storage react-native-url-polyfill
npx expo install expo-web-browser expo-auth-session expo-image-picker expo-notifications expo-device

Copy the portable code (bucket 1) into a src/lib or src/shared folder. If you want both apps to keep sharing it, move it into a workspace package in a monorepo; for most AI-built apps, a copy is simpler and fine.

Configure NativeWind so your Tailwind classes keep working. With NativeWind v4, that means the NativeWind preset in tailwind.config.js, a global.css with the Tailwind directives, the Babel preset and the Metro wrapper:

// metro.config.js
const { getDefaultConfig } = require('expo/metro-config');
const { withNativeWind } = require('nativewind/metro');

const config = getDefaultConfig(__dirname);
module.exports = withNativeWind(config, { input: './global.css' });

Copy your tailwind.config theme (colors, fonts, radius) across so the native app matches your brand.

4. The component translation map

Web (Lovable / Vite)	React Native + Expo	Notes
`<div>`, `<section>`, `<span>`	`<View>`, `<Text>`	Every string must sit inside `<Text>`
`onClick`	`onPress` on `<Pressable>`	No hover; use `active:` styles for press state
`<img src>`	`<Image source={image}>` with `{ uri }` or `expo-image`	Remote images need explicit width and height
`<input onChange>`	`<TextInput onChangeText>`	Wrap forms in `KeyboardAvoidingView`
Tailwind CSS	NativeWind	Default flex direction is column; no CSS grid
shadcn/ui, Radix	RN primitives or react-native-reusables	Radix depends on the DOM
React Router	Expo Router	File-based routes in `app/`
`localStorage`	AsyncStorage / SecureStore	Async API; SecureStore has value size limits
`import.meta.env.VITE_*`	`process.env.EXPO_PUBLIC_*`	Inlined at build time, so public by definition
`lucide-react`	`lucide-react-native`	Needs `react-native-svg`
Recharts	victory-native, react-native-gifted-charts	Recharts renders SVG via the DOM
`.map()` in a scrolling div	`FlatList`	Virtualized; required for long lists
Stripe Checkout for digital goods	In-app purchase (StoreKit / Play Billing)	Guideline 3.1.1

Here's a typical card from a Lovable app and its native version:

// Web (Lovable)
<div
  className="flex items-center gap-3 p-4 rounded-xl bg-white shadow hover:bg-gray-50"
  onClick={() => navigate(`/projects/${p.id}`)}
>
  <img src={p.avatarUrl} className="w-10 h-10 rounded-full" />
  <span className="font-medium text-gray-900">{p.name}</span>
</div>

// React Native + NativeWind
import { Pressable, Image, Text } from 'react-native';
import { useRouter } from 'expo-router';

const router = useRouter();
const avatar = { uri: p.avatarUrl };

<Pressable
  className="flex-row items-center gap-3 p-4 rounded-xl bg-white active:bg-gray-50"
  onPress={() => router.push(`/projects/${p.id}`)}
>
  <Image source={avatar} className="w-10 h-10 rounded-full" />
  <Text className="font-medium text-gray-900">{p.name}</Text>
</Pressable>

Three changes do most of the work: flex-row is now explicit (React Native defaults to column), hover: becomes active:, and text moves into <Text>. Shadows deserve a check on both platforms, because iOS uses shadow properties and Android uses elevation.

5. Routing: React Router to Expo Router

Lovable apps define routes in App.tsx with React Router. Expo Router uses the file system instead:

React Router                         Expo Router (app/)
/                    -> Home         (tabs)/index.tsx
/settings            -> Settings     (tabs)/settings.tsx
/projects/:id        -> Project      projects/[id].tsx
/login               -> Login        (auth)/login.tsx
layout with navbar                   (tabs)/_layout.tsx  (bottom tab bar)

The hooks map almost one to one: useNavigate() becomes useRouter() with router.push() and router.back(), useParams() becomes useLocalSearchParams(), and <Link to> becomes <Link href>.

Treat this as a design step, not just a rename. A top navigation bar on the web usually becomes a bottom tab bar with three to five tabs on mobile, and secondary pages become stack screens with a native back gesture. Getting navigation native is one of the biggest things reviewers notice.

Protect routes with a redirect in a layout instead of a wrapper component:

// app/(tabs)/_layout.tsx
import { Redirect, Tabs } from 'expo-router';
import { useSession } from '@/lib/auth';

export default function TabsLayout() {
  const { session, loading } = useSession();
  if (loading) return null;
  if (!session) return <Redirect href="/(auth)/login" />;
  return <Tabs />;
}

6. Supabase on mobile: the part most conversions get wrong

The Supabase client Lovable generates assumes a browser: it stores the session in localStorage, refreshes tokens on a timer that runs while the tab is open, and reads OAuth results from the URL. None of that holds on a phone.

The client

// src/lib/supabase.ts
import 'react-native-url-polyfill/auto';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { createClient } from '@supabase/supabase-js';
import { AppState } from 'react-native';
import type { Database } from './types';

export const supabase = createClient<Database>(
  process.env.EXPO_PUBLIC_SUPABASE_URL!,
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY!,
  {
    auth: {
      storage: AsyncStorage,
      autoRefreshToken: true,
      persistSession: true,
      detectSessionInUrl: false,
      flowType: 'pkce',
    },
  }
);

// Only refresh tokens while the app is in the foreground
AppState.addEventListener('change', (state) => {
  if (state === 'active') supabase.auth.startAutoRefresh();
  else supabase.auth.stopAutoRefresh();
});

Key points:

detectSessionInUrl: false, because there's no browser URL to read.
The AppState listener pauses and resumes token refresh with the app lifecycle, as Supabase recommends for React Native.
Storage choice: AsyncStorage isn't encrypted. If you want the session encrypted at rest, use expo-secure-store, but note it has a per-value size limit that a Supabase session can exceed. The common pattern is to encrypt the session with a key kept in SecureStore and store the ciphertext in AsyncStorage.
Keys: only the anon (publishable) key belongs in the app. EXPO_PUBLIC_ variables are inlined into the bundle, so anything there is readable by anyone who downloads the app. The service role key never leaves the server.

OAuth with deep links

On the web, Supabase redirects back to your site. On mobile, it has to redirect back into your app through a URL scheme. Set "scheme": "myapp" in app.json, add the redirect URL (for example myapp://) to Supabase's allowed redirect URLs, then:

import * as WebBrowser from 'expo-web-browser';
import { makeRedirectUri } from 'expo-auth-session';
import { supabase } from './supabase';

WebBrowser.maybeCompleteAuthSession();
const redirectTo = makeRedirectUri();

export async function signInWithGoogle() {
  const { data, error } = await supabase.auth.signInWithOAuth({
    provider: 'google',
    options: { redirectTo, skipBrowserRedirect: true },
  });
  if (error) throw error;

  const result = await WebBrowser.openAuthSessionAsync(data.url, redirectTo);
  if (result.type !== 'success') return;

  const code = new URL(result.url).searchParams.get('code');
  if (!code) throw new Error('No auth code returned');

  const { error: exchangeError } = await supabase.auth.exchangeCodeForSession(code);
  if (exchangeError) throw exchangeError;
}

With the PKCE flow, the app receives a short-lived code and exchanges it for a session, so tokens never travel in the redirect URL. If you offer Google login on iPhone, you also need Sign in with Apple under Guideline 4.8; on iOS, the native Apple sheet with signInWithIdToken is the smoothest way to add it.

Email links

Magic links and password reset emails point at your website by default. Either point them at a universal link or app link that opens the app, or keep that flow on the web and have the app hand off to it. Decide this early, because it touches your email templates and Supabase's redirect settings.

7. Data fetching, lists and forms

Your data access functions port unchanged, since they're just supabase.from(...) calls. What changes is how results render and how the app reacts to the network.

Lists: replace .map() inside a scrolling container with FlatList, which only renders what's on screen:

<FlatList
  data={projects}
  keyExtractor={(p) => p.id}
  renderItem={({ item }) => <ProjectCard project={item} />}
  onEndReached={fetchNextPage}
  refreshing={isRefetching}
  onRefresh={refetch}
/>

Pull-to-refresh comes almost free and is something users expect on mobile.

TanStack Query: it works in React Native, but it can't see browser focus and online events. Wire focusManager to AppState and onlineManager to @react-native-community/netinfo so queries refetch when the app returns to the foreground or the connection comes back.

Forms: react-hook-form and zod port well; swap inputs for TextInput with onChangeText, wrap screens in KeyboardAvoidingView, and set keyboardType, autoCapitalize, autoComplete and textContentType so the keyboard and password managers behave natively.

8. File uploads to Supabase Storage

The web version uploads a File from an <input type="file">. On mobile you get a local URI from the image picker, then upload its bytes:

import * as ImagePicker from 'expo-image-picker';

export async function pickAndUpload(userId: string) {
  const result = await ImagePicker.launchImageLibraryAsync({
    mediaTypes: ['images'],
    quality: 0.8,
  });
  if (result.canceled) return null;

  const asset = result.assets[0];
  const bytes = await fetch(asset.uri).then((r) => r.arrayBuffer());
  const path = `${userId}/${Date.now()}.jpg`;

  const { error } = await supabase.storage
    .from('uploads')
    .upload(path, bytes, { contentType: asset.mimeType ?? 'image/jpeg' });
  if (error) throw error;
  return path;
}

Keep the userId/ prefix: it lets your Storage policies restrict each user to their own folder, and it makes account deletion straightforward later. Add a photo library usage description in your iOS config, or review will flag it under Guideline 5.1.1.

9. Native features worth adding

These turn a converted app into an app reviewers recognize as native, and users actually feel:

Push notifications with expo-notifications: request permission at a meaningful moment, get an Expo push token, store it against the user, and send from your backend.

import * as Notifications from 'expo-notifications';
import * as Device from 'expo-device';
import Constants from 'expo-constants';

export async function registerForPush(userId: string) {
  if (!Device.isDevice) return;
  const { status } = await Notifications.requestPermissionsAsync();
  if (status !== 'granted') return;

  const projectId = Constants.expoConfig?.extra?.eas?.projectId;
  const { data: token } = await Notifications.getExpoPushTokenAsync({ projectId });
  await supabase.from('push_tokens').upsert({ user_id: userId, token });
}

On Android, create a notification channel; on iOS, EAS can generate and manage the APNs key for you.

Also worth adding: haptic feedback on key actions (expo-haptics), native share sheets, biometric unlock for sensitive screens (expo-local-authentication), an offline state instead of a blank screen, and safe area handling with react-native-safe-area-context so nothing hides under the notch or home indicator.

10. Store requirements to build in, not bolt on

Account deletion (Guideline 5.1.1(v) and Google Play). Do it server-side in an Edge Function, because deleting a user needs the service role key:

// supabase/functions/delete-account/index.ts
import { createClient } from 'npm:@supabase/supabase-js@2';

Deno.serve(async (req) => {
  const authHeader = req.headers.get('Authorization');
  if (!authHeader) return new Response('Unauthorized', { status: 401 });

  // Identify the caller from their own JWT
  const userClient = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    { global: { headers: { Authorization: authHeader } } }
  );
  const { data: { user }, error } = await userClient.auth.getUser();
  if (error || !user) return new Response('Unauthorized', { status: 401 });

  const admin = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  );

  // Storage isn't removed by ON DELETE CASCADE, so clean it up explicitly
  const { data: files } = await admin.storage.from('uploads').list(user.id);
  if (files?.length) {
    await admin.storage.from('uploads').remove(files.map((f) => `${user.id}/${f.name}`));
  }

  const { error: deleteError } = await admin.auth.admin.deleteUser(user.id);
  if (deleteError) return new Response(deleteError.message, { status: 500 });

  return Response.json({ ok: true });
});

The app calls it with supabase.functions.invoke('delete-account'), which sends the user's JWT automatically, then signs out. Make sure your tables reference auth.users with ON DELETE CASCADE, or delete those rows in the function too. Full account deletion guide.

Also build in:

Sign in with Apple (Guideline 4.8) if you offer Google or other social login.
In-app purchase (Guideline 3.1.1) for digital goods; Stripe stays for physical goods and services.
Permission purpose strings for every sensitive permission.

11. Build, update and ship with EAS

Configure build profiles in eas.json:

{
  "cli": { "version": ">= 12.0.0", "appVersionSource": "remote" },
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "distribution": "internal", "channel": "preview" },
    "production": { "autoIncrement": true, "channel": "production" }
  },
  "submit": { "production": {} }
}

Development builds replace Expo Go once you add native modules; they're your day-to-day testing app on a real device.
Over-the-air updates with expo-updates let you ship JavaScript fixes without a store review. Set a runtimeVersion policy so an update never reaches a binary it isn't compatible with, and keep OTA for fixes and small changes, not changes to what the app does.
Production builds go to App Store Connect and Play Console with eas submit. Test through TestFlight and Play's internal testing first, and plan for Google's 14-day closed test if your account is personal and new. Closed test guide.

12. A realistic plan and timeline

For a typical Lovable app with 10 to 20 screens and Supabase:

Audit and scaffold: a day.
Shared code, Supabase client and auth (including OAuth): one to two days.
Navigation and screens: the bulk of the work, roughly a screen or two per few hours once the component patterns are settled.
Native features and store requirements: one to two days.
Builds, TestFlight, store listings and submission: one to two days, plus review time.

The web app keeps running throughout, on the same database, so you can launch native without a migration or a freeze.

FAQ

Can I keep using Lovable after converting? Yes for the web app. The native app lives in its own codebase, so changes made in Lovable won't flow into it automatically. Shared logic and the shared Supabase backend keep the two consistent.

Do I need to change my Supabase schema or RLS? Usually not. The same policies protect the same data. You'll add redirect URLs for mobile OAuth and possibly a table for push tokens.

Can I convert to Flutter instead? You can, but React Native lets you reuse TypeScript types, zod schemas, data functions and much of your component logic, and keeps your team in one language.

Will the converted app pass Guideline 4.2? A genuinely native app with native navigation and features is far less likely to be rejected than a wrapped web app, but review always looks at the whole app, including whether it offers enough value on its own.

Conclusion

Native conversion is mostly a UI rewrite on top of a backend you already have. The details that decide whether it works are the mobile-specific ones: session storage and token refresh, OAuth through deep links, virtualized lists, uploads from local URIs, and store requirements built into the server. Get those right and you have an app that feels native and passes review.

If you'd rather hand the conversion off, LetsDeployIt converts Lovable, Bolt, Base44 and v0 apps to React Native and Expo and takes them through both stores. See plans.

Questions about a specific part of your conversion? Ask in the comments, and we'll answer with code.

9 AI App Builders You Should Definitely Try in 2026 🔥💯

Russel Dsouza — Fri, 30 Oct 2026 07:57:32 +0000

Introduction

A few years ago, no-code meant dragging boxes onto a canvas and connecting them with logic blocks. In 2026, you can describe the app you want in a sentence and an AI builds it for you, often with real code you can keep and change.

That shift has opened app building to founders, designers and product people who never planned to learn a programming language. It has also made experienced developers much faster, because the AI handles the setup and the repetitive parts while they focus on what makes the app different.

Why AI app builders took off

AI app builders took the best part of no-code, the speed, and removed its biggest limit: being stuck inside one platform. Many of them now write standard code in frameworks like React, React Native and Next.js, so you can export your project and keep building on it anywhere.

They're not all aiming at the same thing, though. Some build websites, some build web apps, and only a few build true mobile apps for the App Store and Google Play. Knowing the difference before you start saves a lot of rework later.

Disclosure: this list is from the RapidNative team, so we've put ourselves first. Every other tool here is one we'd happily recommend for the right project.

AI app builders worth trying

1. RapidNative

RapidNative is an AI app builder made for mobile. You describe your app, or start from a sketch or a screenshot, and it generates a React Native app built on Expo. Instead of a website squeezed onto a phone screen, you get a real mobile app for iPhone and Android, written in the same stack many professional mobile teams use.

Because the output is standard React Native code, you're never locked in. You can export it, open it in your own editor and keep building, or hand it to a developer. When you're ready to launch, RapidNative's AppShots generates your App Store screenshots with AI, which takes care of one of the most tedious parts of publishing. If mobile is your goal, this is the place to start.

2. Lovable

Lovable builds full-stack web apps from a chat. You describe what you want, it writes a React frontend, and it connects a Supabase backend for user accounts, data and file storage, either through Lovable Cloud or your own Supabase project.

It's one of the most popular AI builders for SaaS products, dashboards and internal tools, and its visual editing makes small changes easy without prompting. Lovable syncs your code to GitHub, so you can take it anywhere. Keep in mind that it builds web apps, so getting a Lovable app into the App Store means converting it to a native app later.

3. Bolt.new

Bolt.new, from the StackBlitz team, writes, runs and deploys full-stack JavaScript apps right inside your browser tab. There's nothing to install: the whole development environment runs in the browser, and you can watch the AI create files and run your app as it goes.

Bolt supports popular frameworks like React, Next.js and Astro, and you can step in and edit the code directly whenever you like. That makes it a favorite of developers and technical founders who want AI speed without giving up control.

4. v0 by Vercel

v0 started as a tool for generating user interfaces and has grown into a full app builder. It produces React and Next.js code styled with Tailwind CSS and shadcn/ui, which is why its interfaces tend to look polished and modern straight away.

Since v0 comes from Vercel, deploying what you build is a click away, and the code fits naturally into an existing Next.js project. It's an excellent choice for developers who care about design quality and want a strong starting point for the frontend.

5. Base44

Base44 builds complete apps from a prompt with login, database and hosting all built in. There are no outside services to sign up for or connect, which removes the setup step that trips up many first-time builders.

That all-in-one approach makes Base44 especially good for internal tools, simple customer portals and quick prototypes you want to share with a link. It's a strong pick for non-technical founders and teams who want something working today.

6. FlutterFlow

FlutterFlow is a visual builder for mobile and web apps using Google's Flutter framework. You design screens with drag and drop, add logic visually, and use its AI features to generate pages and components from a description.

FlutterFlow exports Flutter code and connects to Firebase and Supabase for data. It suits teams who like building visually and want native mobile apps, with the option to bring in developers for custom code later.

7. Replit

Replit combines an online code editor, an AI agent that can plan and build an app from a description, and hosting in one place. You can watch the agent work, then take over in the editor whenever you want to make changes yourself.

Unlike many AI builders, Replit isn't limited to JavaScript; it supports many programming languages. It's a great fit for builders who want an AI agent and a complete coding environment together.

8. Bubble

Bubble has been one of the best-known no-code platforms for web apps for years. Its visual editor, built-in database and workflow system let you build surprisingly complex apps without writing code, and it now adds AI to generate a first version of your app from a description.

Bubble works differently from the code-generating builders above: your app lives on Bubble's platform rather than as code you export. In return, you get fine-grained no-code control over every workflow, plus a large plugin marketplace and community.

9. Glide

Glide turns spreadsheets and databases into polished apps for teams. Connect Google Sheets, Excel or another data source, pick from ready-made components, and you have a working business app in an afternoon.

Its AI features can summarize, classify and extract information from your data automatically. Glide is ideal for internal apps built on data your team already keeps in a spreadsheet.

Which one should you pick?

The biggest question is whether you need a mobile app or a web app. If you want an app in the App Store and Google Play, start with a mobile builder like RapidNative or FlutterFlow. If the browser is enough, Lovable, Bolt.new, v0 and Base44 are all excellent. Replit suits people who want an AI agent plus a full coding environment, Bubble suits complex no-code web apps, and Glide is perfect for apps built on a spreadsheet.

FAQ

What is the best AI app builder for mobile apps? For native iPhone and Android apps, choose a builder that outputs mobile code, such as RapidNative (React Native and Expo) or FlutterFlow (Flutter). Most other AI builders make web apps.

Can I keep the code an AI app builder makes? With many of them, yes. RapidNative, Lovable, Bolt.new, v0 and FlutterFlow let you export or sync your code. Check each tool's plans, since some limit export to paid tiers.

Are AI app builders free? Most offer a free plan or free credits to try them, with paid plans for more usage and features.

Conclusion

AI app builders have made it possible to go from idea to working app in a day. The trick is picking the right one for where your app needs to live. Web builders shine in the browser, while mobile builders like RapidNative get you a real app for the App Store and Google Play without the rebuild. Try a couple of them on a small idea, and you'll quickly find the one that fits the way you work.

Which AI app builder are you using right now? Tell us in the comments.

Why Was My App Rejected for Account Deletion? (And How to Fix It)

Russel Dsouza — Thu, 29 Oct 2026 10:44:28 +0000

Originally published at letsdeploy.it.

Short answer: your app has a sign-up and no way to delete the account it creates. Apple has enforced this since June 30, 2022, and it is one of the most common rejections for apps built with Lovable, Bolt, Base44 or v0, because the builders add sign-up for you and never add the delete option.

You submit, wait two days, and the review note says your app "supports account creation but does not include an option to initiate account deletion". Usually nothing in the app is broken. Apple just wants people to be able to delete the account they made.

"If your app supports account creation, you must also offer account deletion within the app."
— Apple App Review Guideline 5.1.1(v)

It counts even if sign-up is only email and password, only Google sign-in, or a guest account the app creates on its own. If people can get an account from your app, they need a way to delete it there.

What does Apple accept as account deletion?

Apple accepts a delete option that is easy to find, usually in account settings, and that removes the account and the personal data that goes with it. Its account deletion page spells out the details:

Deactivating or disabling the account isn't enough. You can offer it, but not as the only option.
Delete the whole account record and the personal data tied to it, including content the person shared, such as posts, photos and reviews.
Don't make people call, email or chat with support to delete, unless your app is in a highly regulated field such as banking or health.
A link is fine if deletion finishes on your website, as long as it goes straight to that page.
It doesn't have to be instant. Tell people how long it takes and confirm when it's done.
One confirmation step is fine. Making deletion hard on purpose fails review.
Subscriptions: if the person has an auto-renewing subscription, tell them billing continues through Apple and point them to cancel it first.
Sign in with Apple: if you offer it, revoke the person's Apple tokens when you delete the account.

Does Google Play require account deletion too?

Yes. Google Play has required it since May 31, 2024, and it asks for two ways in, not one:

An in-app path to delete the account and its data, easy to find, for example in settings.
A working web link where people can ask for deletion without the app installed. It must name your app or your developer name.

You give Google that link in the Data safety form in Play Console, under the data deletion questions. If you keep some data after deletion, for fraud prevention or legal reasons, say so in your privacy policy. The launch checklist covers the rest of the Data safety form.

How to add account deletion to your app

Most AI-built apps keep their users in Supabase, so the fix has two halves: a button in the app and a small server function that does the deleting.

Add a Delete account row at the bottom of your account or settings screen, in red so it reads as final.
Open a confirmation that says what gets deleted and how long it takes, with Delete and Cancel.
On Delete, call a server function (a Supabase Edge Function) with the signed-in user's session.
In that function, delete the user's rows in your tables (profiles, posts, bookings, uploads in Storage), then delete the user with Supabase's auth.admin.deleteUser.
Sign the person out and show a short "Your account has been deleted" screen.
Publish a deletion page on your website for Google Play, with your app's name and a form or email to request deletion.
Test it on a fresh account: sign up, add some data, delete, then check the user and their rows are gone in your database.

A passing deletion flow is easy to find (Settings, then Delete account), has one clear confirmation, and leaves the account and its data gone. Google Play also wants a web link to ask for it.

Why a server function: deleting a user in Supabase needs the service role key, and Supabase says never to put that key in the browser or the app. The app asks, the function checks who is asking and deletes only that user.

If your tables point at the user with a foreign key set to delete on cascade, deleting the user removes their rows too. Check that before you rely on it: files in Storage are not removed by a cascade.

Account deletion in Lovable, Bolt, Base44 and v0 apps

The steps are the same whichever builder you used. What changes is where your users are stored:

Builder	Where users usually live	What to ask for
Lovable	Supabase, through Lovable Cloud or your own Supabase project	A Delete account option in settings that calls an Edge Function to delete the user's data and the user
Bolt.new	Supabase, or Bolt Database on newer Bolt Cloud projects	The same, then check the user is gone from the database Bolt set up
Base44	Base44's built-in users	A delete account action, then check the user and their records disappear from your app's data
v0	Usually Supabase, connected through Vercel	The same Edge Function, or a server action in the Next.js app

A prompt that works in most builders:

"Add a Delete account option at the bottom of the settings screen. Ask for confirmation, then delete all of this user's data and their auth account on the server, sign them out and show a confirmation."

Then test it yourself on a fresh account. The builder will say it's done whether or not the user is really deleted.

Builder-specific steps for the stores: Lovable, Bolt.new, Base44 and v0.

What to write back to App Review

Resubmit with a short reply in App Store Connect that tells the reviewer exactly where to look. Reviewers test by hand, so a path they can follow saves a round trip.

Where the option is: "Account deletion is in Settings, then Delete account, at the bottom of the screen."
What it deletes: "It deletes the account and all its personal data."
How long it takes, if it isn't instant.
A demo account in the App Review information, so the reviewer can sign in and try it (Guideline 2.1).

Apps rejected for this are often rejected for something else in the same review. The Guideline 4.2 guide covers the most common one for AI-built apps.

Can you fix it yourself?

Yes. If your builder can add the button and the server function, and you test it on a fresh account, most people get this done in a few hours without help.

Where it gets harder is when deletion has to reach several places: Stripe customers, files in Storage, Sign in with Apple tokens and a web deletion page for Google Play. That's the kind of store work we do when we convert an app to native, and it's covered in our plans.

We convert AI-built web apps into native React Native and Expo apps, add account deletion that really deletes the account and its data, set up the web deletion page and Data safety answers for Google Play, and submit to both stores until approved. See how it works or read the full guide on letsdeploy.it.

How to Get a Lovable App Through Google Play's 12-Tester Closed Test

Russel Dsouza — Mon, 26 Oct 2026 13:13:55 +0000

Originally published at letsdeploy.it.

If your Google Play developer account is a personal one created after November 13, 2023, you need a closed test with at least 12 testers opted in for 14 days in a row before you can apply for production. Google then reviews the application, usually within 7 days. Organization accounts skip the test.

Do you need the 12-tester closed test?

You need it if your Google Play developer account is a personal account created after November 13, 2023. Until you meet the requirement, Play Console keeps Production and Pre-registration locked for your apps.

You finish your Lovable app, open Play Console, and find the publish button behind a two-week test. It catches a lot of first-time publishers, so check your account type before you plan a launch date.

Personal accounts created after November 13, 2023: closed test required.
Personal accounts created before that date: not affected.
Organization accounts: not affected. They need a registered business and a D-U-N-S number.

What counts as 12 testers for 14 days?

At least 12 testers must be opted in to your closed test when you apply, and they must have stayed opted in for the 14 days before that, without a break.

Opted in means the tester accepted your invite through the opt-in link, not only that you added their email.
A tester who opts in, leaves before day 14 and rejoins starts their 14 days again.
Google originally asked for 20 testers. Older posts that say 20 are out of date.

How to set up a closed test for a Lovable app

Lovable builds web apps, and Google Play needs an Android app, so the first step is a native build. We convert Lovable apps to React Native and Expo, which gives you an Android App Bundle (an .aab file) for Play and the same app for the App Store.

Create the app in Play Console and fill in the store listing basics.
Open Testing, then Closed testing, and create a track.
Upload your App Bundle to that track and roll out the release.
Add testers by email list or Google Group, choose your countries, and save. The opt-in link appears once the closed test release is published, which can take a few hours.
Send the opt-in link to your testers. They accept it with their Google account, then install the app from Google Play.

Your listing, content rating and Data safety form are needed for production anyway, so fill them in now. The Lovable launch checklist lists everything else the stores ask for.

Where to find 12 testers for Google Play

Start with people who already care about your app: they stay opted in and give useful feedback, which you need for the production application.

Friends, family and colleagues with an Android phone.
Your own users: the people already using the web version of your Lovable app.
Your waitlist, newsletter or social followers.
Communities where builders swap testing, such as tester-swap groups and forums. Offer to test their app in return.

Invite 15 to 20 people, not 12. Someone always forgets to accept the invite or uninstalls on day 6, and every drop below 12 delays your application.

Closed test problems nobody warns you about

Testers added but not opted in. Adding an email does nothing until that person accepts the opt-in link. Check the count in Play Console, not your invite list.
Google Group members who never joined. Testers in a Google Group must join the group before they can opt in. Check the group lets people outside your organization join, then confirm the opted-in count in Play Console.
Low engagement. Google can ask you to keep testing if testers didn't use the app. Ask them to open it a few times and send you feedback.

Use the 14 days well: fix what testers report and finish your store listing, so the build you send to production is better than the one you started with.

How to apply for production access

Once 12 testers have been opted in for 14 days, apply from the Play Console dashboard. The form has three parts: your closed test, your app, and your production readiness. It asks:

How easy it was to recruit testers.
How testers engaged with the app.
A summary of their feedback and what you changed because of it.
Who the app is for and why it is ready for production.

Answer with specifics: the bugs testers found and what you fixed. Review usually takes 7 days or less. If Google asks for more testing, the usual reasons are fewer than 12 opted-in testers or too little engagement.

Can you do the closed test yourself?

Yes. The closed test is free and every step above is something you can do on your own. What it takes is 12 to 20 willing testers and two weeks of reminding them.

If you would rather not, we run it for you with vetted testers as part of getting your app on Google Play, alongside the native build and the store work. You can also skip it with an organization account if you have a registered business.

FAQ

Do testers have to use the app every day?

No, Google doesn't ask for daily use, but testers must stay opted in for all 14 days, and Google can ask for more testing if they barely used the app.

What happens if a tester leaves before day 14?

They stop counting. You need 12 testers opted in for the full 14 days when you apply, which is why inviting 15 to 20 people is safer.

Does an organization account skip the closed test?

Yes. The requirement only applies to personal accounts created after November 13, 2023. Organization accounts need a registered business and a D-U-N-S number.

How long does Google take to approve production access?

Usually 7 days or less after you apply, sometimes longer. Count on about three weeks from the start of the closed test to production access.

Is it 12 or 20 testers?

Google originally asked for 20, so older guides that say 20 are out of date.

Can I put a Lovable app on Google Play without the closed test?

Only with an organization account or a personal account created before November 13, 2023. Either way, you still need a native Android build of the app.

Found this useful? The full guide on letsdeploy.it is kept up to date when Google changes the rules.

Ship a Live Demo of Your Supabase App That Runs Entirely in the Browser

Russel Dsouza — Fri, 16 Oct 2026 12:40:54 +0000

Every SaaS landing page wants a "Try the demo" button. And every developer who's built one knows the problems that come with it:

A shared demo account that strangers fill with junk (or worse) within a day
A cron job to reset the demo database every night
Real backend costs for people who will never sign up
Rate limits, abuse, and the occasional visitor who deletes everything

There's another way. Run the backend inside the visitor's browser. Each visitor gets their own private copy of your app's database, built from your migrations and seed data. Nothing is shared, nothing needs resetting, and the demo is just static files.

This guide does that for a Supabase app using tinbase, an open-source Supabase-compatible backend that can run in the browser on PGlite (Postgres compiled to WebAssembly).

tinbase is alpha. It covers a large part of the supabase-js surface, but not everything; check the known gaps in the README before relying on a specific feature for your demo.

How does it work?

Your app already talks to Supabase through supabase-js. That client accepts a custom fetch. In demo mode, instead of sending requests over the network, you hand them to a backend running in the same page:

your UI → supabase-js → backend.fetch → Postgres (PGlite, in the browser)

Your components don't change. Only the client setup does.

Step 1: Make the client switchable

Here's a Vite example. In normal mode, the app uses your real Supabase project. In demo mode, it starts an in-browser backend.

// src/lib/supabase.ts
import { createClient, type SupabaseClient } from '@supabase/supabase-js';

const DEMO = import.meta.env.VITE_DEMO === 'true';

export async function getSupabase(): Promise<SupabaseClient> {
  if (!DEMO) {
    return createClient(
      import.meta.env.VITE_SUPABASE_URL,
      import.meta.env.VITE_SUPABASE_KEY
    );
  }

  const { createDemoBackend } = await import('./demo-backend');
  const backend = await createDemoBackend();

  return createClient('http://localhost', backend.anonKey, {
    global: { fetch: (input, init) => backend.fetch(new Request(input, init)) },
  });
}

The dynamic import() matters: visitors to your real app never download the demo backend.

Step 2: Build the demo backend from your migrations

Vite can import SQL files as strings with ?raw, so the demo uses the exact same migrations as production:

// src/lib/demo-backend.ts
import { createBackend } from 'tinbase';
import init from '../../supabase/migrations/20261001000000_init.sql?raw';
import projects from '../../supabase/migrations/20261005000000_projects.sql?raw';
import demoSeed from '../../supabase/demo-seed.sql?raw';

export function createDemoBackend() {
  return createBackend({
    dataDir: 'idb://my-app-demo-v1', // persist in IndexedDB between visits
    migrations: [
      { name: '20261001000000_init', sql: init },
      { name: '20261005000000_projects', sql: projects },
      { name: '99990000000000_demo_seed', sql: demoSeed },
    ],
  });
}

A few choices here:

The demo seed runs as the last migration, so every new visitor starts with the same realistic sample data.
dataDir: 'idb://...' keeps the visitor's changes in IndexedDB, so the demo survives a page refresh. Bump the name (-v2) when you change the seed, and returning visitors get a fresh copy.
If you'd rather every visit start clean, leave persistence out. Check the README for the current in-memory option.

Step 3: Sign the visitor in automatically

A demo shouldn't ask for an email. Anonymous sign-in gives each visitor a real authenticated user, so your RLS policies work exactly as they do in production:

const supabase = await getSupabase();

if (import.meta.env.VITE_DEMO === 'true') {
  const { data } = await supabase.auth.getSession();
  if (!data.session) await supabase.auth.signInAnonymously();
}

If your seed data needs to belong to the visitor, assign it after sign-in, or write your seed to use rows that any authenticated user can read.

Step 4: Build and host it as static files

VITE_DEMO=true npm run build

Deploy the output folder to any static host (GitHub Pages, Netlify, Vercel, Cloudflare Pages) at something like demo.yourapp.com. There's no server, no database, and no bill that grows with demo traffic.

Step 5: Make it obvious it's a demo

Visitors should know their data stays on their device and isn't saved to a real account. Add a small banner:

{import.meta.env.VITE_DEMO === 'true' && (
  <div className="demo-banner">
    Demo mode: everything runs in your browser and stays on this device.
    <a href="https://yourapp.com/signup">Create a real account</a>
  </div>
)}

That banner is also your conversion point: someone who just spent five minutes in a working app is a much warmer lead than someone who watched a video.

What are the trade-offs?

Be honest with yourself about these before shipping:

Download size. WASM Postgres adds several megabytes to the demo build. Lazy-load it, and show a short loading state ("Setting up your demo…").
Memory. WASM Postgres is memory-hungry. Test on an older phone and a low-end laptop.
Feature coverage. Features your app uses that tinbase doesn't support yet (see the README's known gaps, such as MFA, phone auth, or image transforms) need to be hidden or stubbed in demo mode.
No server-side logic. Anything that depends on third-party APIs, emails, or payments should be faked or disabled in the demo.
Not for production. This is a demo and prototyping technique. Your real app keeps using your real Supabase project.

When is this a good fit?

Dashboards, CRUD tools, internal-tool templates, and productivity apps where the value is obvious once someone clicks around
Template or boilerplate products where buyers want to try before they buy
Conference demos and workshops where Wi-Fi can't be trusted

It's a weaker fit for apps whose value depends on other users (social, messaging) or heavy server-side processing.

Wrapping up

A browser-only demo removes the worst parts of "Try the demo": no shared account to vandalize, no nightly reset job, and no backend cost per visitor. Your migrations build the database, anonymous auth signs the visitor in, and your real RLS policies keep working.

Source, benchmarks, and known gaps: tinbase on GitHub. Have you built a "try it now" demo for your app? How did you handle the shared-data problem? Tell me in the comments.

Your EXPO_PUBLIC_ Keys Are Public: A Practical Guide to EAS Environment Variables

Russel Dsouza — Thu, 15 Oct 2026 11:23:04 +0000

Open almost any Expo repo and you'll find a .env file with a mix of things: an API URL, a Supabase key, a Sentry DSN, maybe a Stripe secret key someone added "just for testing."

Some of those are safe to ship inside your app. Some are not. And the EXPO_PUBLIC_ prefix doesn't make anything private. It does the opposite.

This guide sorts it out: which values can go where, how EAS environments and visibility levels work, and one easy-to-miss mistake with OTA updates.

The one rule: anything in the app is public

Every EXPO_PUBLIC_ variable is inlined into your JavaScript bundle at build time. Anyone who downloads your app can extract it. The Expo docs say it plainly: treat client-side code as public, and secret visibility in EAS "does not provide any additional security for values that you end up embedding in your application itself."

So the first question for every variable isn't "how do I hide it?" It's "does the app actually need this?"

Sort every value into one of three buckets

Bucket	Examples	Where it lives
Public, used at runtime	API base URL, Supabase URL and publishable key, Sentry DSN, PostHog project key	`EXPO_PUBLIC_*`
Build-time only	`APP_VARIANT`, bundle ID suffix, `GOOGLE_SERVICES_JSON` file, Sentry auth token for source maps	Non-prefixed EAS variable, read in `app.config.js` or by build tools
Server only	Stripe secret key, Supabase secret/service key, OpenAI key, webhook secrets	Your backend or edge functions. Never the app.

If a key can spend money, read every user's data, or call a paid API, it belongs in the third bucket. The app calls your server, and your server holds the key.

A quick test: if this value leaked on Twitter tomorrow, would you need to rotate it? If yes, it can't be EXPO_PUBLIC_.

How EAS environments work

EAS gives each project three environments by default: development, preview, and production. Each is an independent set of variables, and a variable can belong to one environment or several.

Create variables with eas env:set (it creates or updates):

eas env:set --name EXPO_PUBLIC_API_URL \
  --value https://api.staging.example.com \
  --environment preview --visibility plaintext

eas env:set --name EXPO_PUBLIC_API_URL \
  --value https://api.example.com \
  --environment production --visibility plaintext

Check what's set:

eas env:list --environment production

Pick the right visibility

Visibility	Who can read it	Use for
Plain text	Dashboard, CLI, build logs	`EXPO_PUBLIC_*` values (they're public anyway)
Sensitive	CLI and dashboard (toggle); hidden in logs	Build-time values you need to resolve locally
Secret	Only EAS servers; hidden everywhere else	Tokens only the build needs, like a source-map upload token

Two details catch people out:

Secret variables can't be pulled. eas env:pull skips them, and resolving app.config.js locally needs at least sensitive visibility. If your config reads a variable on your laptop, don't make it secret.
Secret doesn't make an EXPO_PUBLIC_ value private. It hides it in the dashboard, but the value still ships in the bundle.

Connect build profiles to environments

In eas.json, each build profile picks its environment:

{
  "build": {
    "development": {
      "developmentClient": true,
      "environment": "development"
    },
    "preview": {
      "distribution": "internal",
      "environment": "preview"
    },
    "production": {
      "environment": "production"
    }
  }
}

Now eas build --profile preview gets the staging API URL, and --profile production gets the real one, with no .env juggling.

Use build-time variables in app.config.js

Non-prefixed variables are available in app.config.js, which is perfect for running preview and production builds side by side on one phone:

// app.config.js
const variant = process.env.APP_VARIANT ?? 'development';
const suffix = variant === 'production' ? '' : `.${variant}`;

export default {
  name: variant === 'production' ? 'Acme' : `Acme (${variant})`,
  ios: { bundleIdentifier: `com.acme.app${suffix}` },
  android: {
    package: `com.acme.app${suffix}`,
    googleServicesFile:
      process.env.GOOGLE_SERVICES_JSON ?? './google-services.json',
  },
};

Set APP_VARIANT per environment in EAS. Upload google-services.json as a file variable, and the fallback keeps local builds working.

Pull variables for local development

eas env:pull --environment development

This writes the readable variables to a .env file (like .env.local). Add it to .gitignore. The dashboard and EAS become the source of truth, and nobody pastes keys into Slack again.

The OTA mistake: updates read the environment too

Here's the one that bites teams in production.

EXPO_PUBLIC_ values are baked into the JavaScript bundle. An OTA update ships a new bundle, so it gets whatever environment you publish it with:

eas update --channel production --environment production

Publish a production update with the wrong environment, and every production user's app now points at your staging API. The native build was fine; the update replaced the config.

Guard against it:

Always pass --environment explicitly, and match it to the channel.
Put the command in a package script or an EAS Workflow so nobody types it by hand:

{
  "scripts": {
    "update:preview": "eas update --channel preview --environment preview",
    "update:prod": "eas update --channel production --environment production"
  }
}

Log the API base URL on startup in preview builds, so a mismatch shows up in QA, not in support tickets.

A 10-minute audit for your project

[ ] Search the codebase for EXPO_PUBLIC_ and check each one against the three buckets
[ ] Move any secret key out of the app and behind your backend, then rotate it (it has already shipped)
[ ] Use plaintext for EXPO_PUBLIC_*, sensitive for build values you resolve locally, and secret for build-only tokens
[ ] Set environment on every build profile in eas.json
[ ] Make sure .env* files are git-ignored
[ ] Wrap eas update in scripts that always pass --environment

Wrapping up

Environment variables feel like plumbing until one leaks or an update points production at staging. The fix is mostly sorting: public runtime config in EXPO_PUBLIC_, build config in EAS variables, and real secrets on your server where users can't reach them.

If you'd rather start from a project where this is already laid out, RapidNative generates real Expo apps you can export, with config you can drop straight into this setup.

How does your team split config between the app and the server? Share your setup in the comments.

6 Best Ways to Get Your Lovable App into the App Store and Google Play (2026)

Russel Dsouza — Mon, 12 Oct 2026 12:13:29 +0000

Compared on approval risk, how native the result feels, cost, and how much work you'll do yourself

Disclosure: This article is published by LetsDeployIt, which is ranked first below. We've described every other option as fairly as we can, including when it's the better choice.

If you're a developer helping a founder (or yourself) ship a Lovable app to mobile, this is the landscape in 2026, with the trade-offs that actually matter for review.

You built something real with Lovable. It works, people like it, and now they're asking the inevitable question: "Is it in the App Store?"

Here's the catch most people hit first: Lovable builds web apps, not mobile apps. Its own FAQ says it doesn't generate React Native projects, and it suggests two routes to phones: turn your app into a Progressive Web App, or wrap your published URL with a tool like Capacitor and submit that to the stores.

Those aren't your only options, though. Below are six ways to get a Lovable app onto iPhones and Android phones, ranked for the most common goal: a real app in both stores, that passes review, without rebuilding everything yourself.

The quick comparison

#	Option	What you get	App Store approval risk	Your effort	Best for
1	LetsDeployIt	Native React Native rebuild + full submission	Low	Very low	Founders who want a real app, done for them
2	Median.co	Web app in a native shell, plus native plugins	Medium	Low to medium	Apps that can stay web-based inside
3	Capacitor (DIY)	Web app in a native shell you configure	Medium to high	High	Developers who want full control
4	Rebuild yourself with an AI coding tool	Native React Native app you build	Low (if done well)	High	Developers with time and mobile experience
5	Hire a freelancer	Depends on the freelancer	Varies	Medium	Teams with budget and a trusted hire
6	Progressive Web App	Installable website, not in the stores	N/A	Very low	Testing demand before going native

Why "just wrap it" isn't always enough

Before the list, one rule shapes everything: Apple's App Store Guideline 4.2 (Minimum Functionality). Apple rejects apps that are essentially a website repackaged in an app shell, without native, mobile-specific features.

That doesn't make every wrapped app a rejection. Wrappers that add real native features (push notifications, biometrics, offline support, device access) can and do get approved. But a wrapper with nothing added is the most common first-submission rejection for web-based apps, and that risk is why the rankings below look the way they do.

1. LetsDeployIt: native rebuild and submission, done for you

What it is: a done-for-you service that rebuilds your Lovable app as a real native app (React Native and Expo, not a WebView) and submits it to both stores.

How it works:

Bring your Lovable project. Upload the project file or connect GitHub. With GitHub, the mobile app can stay in sync as you keep changing things in Lovable.
It's rebuilt as a native app. Screens, navigation, and gestures are native. Your Supabase backend (database, sign-in, and data) stays exactly as it is, so web and mobile users share the same accounts.
Preview it on your phone for free before you pay anything.
Store submission is handled: certificates and signing, screenshots, privacy labels, Google's Data Safety form, and the review back-and-forth.
You own it. The app is published under your own Apple and Google developer accounts.

Why it's #1: it's the only option on this list that combines a genuinely native app (the lowest Guideline 4.2 risk) with someone else doing the store work. For most founders, the hard part isn't the code; it's the certificates, forms, testers, and rejections. This handles both halves.

Watch out for: you'll still need your own developer accounts ($99 per year for Apple, $25 once for Google), and a rebuild takes longer than wrapping a URL. If you just need something in the store this week and approval risk doesn't worry you, a wrapper is faster.

Best for: non-technical founders, and anyone who wants real users finding them in the App Store without spending weeks on mobile tooling.

→ Preview your Lovable app as a native app, free

2. Median.co: a native shell with plugins

What it is: Median wraps your published Lovable URL inside native iOS and Android shells, then adds device features through a plugin library.

Strengths:

No code changes. You paste your URL and configure the app.
Native features through plugins: push notifications, haptics, biometric login, deep links, and in-app purchases through a RevenueCat plugin.
Automated store setup after you connect your Apple developer account.
Pricing: self-serve plans start at $179 per year, with managed tiers above that.

Watch out for: your app's screens are still your website, so scrolling, buttons, and transitions feel web-like. Median's own guidance is that you need to add enough native functionality to make the case under Guideline 4.2, so plan to use the plugins rather than shipping the URL as-is.

Best for: apps where the web experience is good enough and you mainly need store presence plus a few native features.

3. Capacitor: wrap it yourself

What it is: an open-source tool that packages a web app into native iOS and Android projects. It's the option Lovable's own FAQ names.

Strengths:

Free and open source.
Full control over the native projects, with plugins for device features.
Keeps your existing code.

Watch out for: you do everything yourself: Xcode and Android Studio setup, signing, store listings, privacy forms, and rejections. And the same Guideline 4.2 risk as any wrapper applies, so budget time for adding genuinely native features.

Best for: developers who are comfortable with native tooling and want to own every detail.

4. Rebuild it yourself with an AI coding tool

What it is: recreate your app's screens in React Native and Expo using a coding agent like Claude Code or Cursor, keeping your Supabase backend.

Strengths:

Truly native, with the lowest approval risk when done well.
Your Lovable app is the spec. Every screen and flow is already defined, which speeds up the rebuild.
No service fees.

Watch out for: it's real engineering work. Agents are fast at screens but often miss what reviewers check: permission messages, empty and error states, account deletion, privacy manifests, and in-app purchases. And you still own the whole store submission.

Best for: developers with mobile experience and time to spare.

5. Hire a freelancer

What it is: pay a developer (on Upwork, Fiverr, or similar) to convert and publish your app.

Strengths: a human handles it, and a good freelancer brings experience with review.

Watch out for: quality varies enormously. Many "Lovable to App Store" gigs are wrappers, which brings back the 4.2 risk. Before hiring, ask:

Will it be a native rebuild or a WebView wrapper?
Will the app be published under my developer accounts?
Do I get the full source code?
What happens if Apple rejects it?

Best for: teams with budget and a freelancer they already trust.

6. Turn it into a Progressive Web App

What it is: make your Lovable app installable from the browser. Users tap "Add to Home Screen," and it opens full screen with an icon. Lovable's FAQ lists this as an option.

Strengths: free, immediate, no review, no developer accounts.

Watch out for: it isn't in the App Store or Google Play, so nobody finds you there. Many users never discover "Add to Home Screen," and you can't sell in-app purchases.

Best for: validating demand before you invest in a store app.

How to choose

"I want a real app in both stores, and I don't want to do the mobile work." → LetsDeployIt
"My web app is good enough on phones; I just need store presence." → Median
"I'm a developer and want full control." → Capacitor, or a rebuild with an AI coding tool
"I'm not sure anyone will use it yet." → Start with a PWA, then move to a native app

What will it cost?

Option	Upfront cost	Ongoing cost	Your time
LetsDeployIt	Free preview, then a one-time service fee	Store fees only	A few hours of review and approvals
Median.co	From $179/year (self-serve)	Yearly plan + store fees	A few days
Capacitor (DIY)	Free	Store fees	Days to weeks
Rebuild with an AI tool	Free (tool subscriptions aside)	Store fees	Weeks
Freelancer	Varies widely	Varies	A few hours of managing
PWA	Free	None	Hours

Store fees for every store option: $99 per year for Apple, $25 once for Google.

Before you start: a 5-minute checklist

Whatever you choose, do these today. They take longer than you'd expect, and none of them depend on which option you pick.

[ ] Create your Apple Developer and Google Play accounts (identity checks can take days)
[ ] Write down every service your app uses (Supabase, analytics, payments) and what data each collects; you'll need this for the privacy forms
[ ] Make sure users can delete their account inside the app
[ ] Create a demo account with sample data for reviewers
[ ] If you have a new personal Google Play account, line up 15 to 20 people willing to test for two weeks (Google requires at least 12)

What every option still requires

Whichever route you pick, the stores ask for the same things:

An Apple Developer account ($99 per year) and a Google Play developer account ($25 one time)
A privacy policy at a public URL that matches what your app collects
Apple's privacy details and Google's Data Safety form
Account deletion inside the app, if users can sign up
Screenshots that show the real app
A demo account so reviewers can get past your sign-in screen
For new personal Google Play accounts: a closed test with at least 12 testers for 14 days before the app can go public

Frequently asked questions

Can Lovable publish to the App Store directly?
No. Lovable builds web apps and doesn't generate native mobile projects. You need one of the routes above.

Will Apple reject a wrapped Lovable app?
Not always, but it's a real risk. Apple's Guideline 4.2 targets apps that are just a website in a shell. Wrappers that add meaningful native features have a better chance.

Do I lose my Supabase backend if I rebuild natively?
No. A native rebuild replaces the screens, not the backend. Your database, sign-in, and data can stay exactly as they are.

How long does it take to get into the stores?
For brand-new accounts, plan on two to four weeks from start to live. Google's 14-day closed test for new personal accounts is often the longest single step.

Who owns the app?
Make sure it's published under your developer accounts, whichever option you choose. If someone else's account owns the listing, you don't fully own your app.

Ready to turn your Lovable app into a real iOS and Android app? Preview yours free with LetsDeployIt.

What route did you take with your Lovable app? Drop it in the comments, especially if you've been through Guideline 4.2.

The Supabase Edge Functions Testing Playbook: Unit, Auth, Webhooks, and Local Integration Tests

Russel Dsouza — Thu, 08 Oct 2026 15:19:11 +0000

Most Supabase Edge Functions get tested exactly once: by deploying them and hitting them from the app. That works until a function sends a duplicate charge, emails the wrong user, or quietly returns 500 for anyone who isn't signed in.

Edge Functions are where your app's most sensitive logic tends to live: payments, AI calls with secret keys, webhooks, anything that needs the service role. They deserve better tests than "it worked when I clicked it."

This is a practical playbook: how to structure functions so they're testable, and the five kinds of tests that catch the bugs that matter. Everything here works with the standard Supabase CLI. At the end there's a lighter local option if Docker is slowing your loop down.

Step 0: Split the handler from the server

Almost every Edge Function example puts everything inside Deno.serve:

Deno.serve(async (req) => {
  // 80 lines of logic
});

That's hard to test, because the only way to run the logic is to start a server. Split it into two files instead:

// supabase/functions/summarize/handler.ts
import { createClient, type SupabaseClient } from 'jsr:@supabase/supabase-js@2';

export type Deps = {
  // Everything that talks to the outside world is injectable
  makeUserClient: (authHeader: string) => SupabaseClient;
  summarize: (text: string) => Promise<string>;
};

export function makeHandler(deps: Deps) {
  return async (req: Request): Promise<Response> => {
    if (req.method !== 'POST') {
      return new Response('Method not allowed', { status: 405 });
    }

    const auth = req.headers.get('Authorization');
    if (!auth) return new Response('Unauthorized', { status: 401 });

    let body: { noteId?: string };
    try {
      body = await req.json();
    } catch {
      return Response.json({ error: 'Invalid JSON' }, { status: 400 });
    }
    if (!body.noteId) {
      return Response.json({ error: 'noteId is required' }, { status: 400 });
    }

    // A client acting as the caller, so RLS decides what they can read
    const supabase = deps.makeUserClient(auth);
    const { data: note, error } = await supabase
      .from('notes')
      .select('body')
      .eq('id', body.noteId)
      .single();

    if (error || !note) {
      return Response.json({ error: 'Not found' }, { status: 404 });
    }

    const summary = await deps.summarize(note.body);
    return Response.json({ summary });
  };
}

// supabase/functions/summarize/index.ts
import { createClient } from 'jsr:@supabase/supabase-js@2';
import { makeHandler } from './handler.ts';

const url = Deno.env.get('SUPABASE_URL')!;
const key = Deno.env.get('SUPABASE_PUBLISHABLE_KEY') ?? Deno.env.get('SUPABASE_ANON_KEY')!;

Deno.serve(
  makeHandler({
    makeUserClient: (authHeader) =>
      createClient(url, key, { global: { headers: { Authorization: authHeader } } }),
    summarize: async (text) => {
      const res = await fetch('https://api.example-ai.com/v1/summarize', {
        method: 'POST',
        headers: {
          Authorization: `Bearer ${Deno.env.get('AI_API_KEY')}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({ text }),
      });
      if (!res.ok) throw new Error(`AI provider returned ${res.status}`);
      return (await res.json()).summary;
    },
  })
);

Now the logic is a plain function from Request to Response, with its dependencies passed in. You can call it directly in a test, with fakes, in milliseconds.

Two details in the handler are worth copying into every function:

The user client forwards the caller's Authorization header. Queries then run as that user, and your RLS policies apply. Reach for the service role only when the function genuinely needs to bypass RLS.
Every bad input returns a specific status code. 400 for a bad body, 401 for no auth, 404 when RLS hides the row. Tests can assert on these, and your app can handle them.

Test 1: Unit tests (no server, no database)

Supabase recommends putting function tests in supabase/functions/tests/, named after the function with a -test.ts suffix. Unit tests call the handler directly:

// supabase/functions/tests/summarize-test.ts
import { assertEquals } from 'jsr:@std/assert';
import { makeHandler } from '../summarize/handler.ts';

// A fake Supabase client that returns whatever row you give it
function fakeClient(row: { body: string } | null) {
  return {
    from: () => ({
      select: () => ({
        eq: () => ({
          single: async () => (row ? { data: row, error: null } : { data: null, error: { message: 'not found' } }),
        }),
      }),
    }),
  } as any;
}

const post = (body: unknown, auth = 'Bearer test-token') =>
  new Request('http://localhost/summarize', {
    method: 'POST',
    headers: { Authorization: auth, 'Content-Type': 'application/json' },
    body: JSON.stringify(body),
  });

Deno.test('returns a summary for a readable note', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient({ body: 'long text' }),
    summarize: async () => 'short text',
  });

  const res = await handler(post({ noteId: 'n1' }));
  assertEquals(res.status, 200);
  assertEquals(await res.json(), { summary: 'short text' });
});

Deno.test('rejects requests without auth', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient(null),
    summarize: async () => '',
  });

  const req = new Request('http://localhost/summarize', { method: 'POST', body: '{}' });
  assertEquals((await handler(req)).status, 401);
});

Deno.test('returns 404 when RLS hides the note', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient(null),
    summarize: async () => 'should not be called',
  });

  assertEquals((await handler(post({ noteId: 'someone-elses' }))).status, 404);
});

Deno.test('validates the body', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient(null),
    summarize: async () => '',
  });

  assertEquals((await handler(post({}))).status, 400);
});

Run them:

deno test --allow-all supabase/functions/tests/

These run in well under a second and cover the logic you're most likely to break: validation, auth, not-found handling, and the happy path.

What to unit test in every function:

[ ] Wrong HTTP method → 405
[ ] Missing auth → 401
[ ] Invalid or missing body fields → 400
[ ] Row hidden by RLS → 404, and the expensive call (AI, payment) is not made
[ ] External API failure → a clear error, not an unhandled exception
[ ] Happy path → correct response shape

That fifth one deserves its own test:

Deno.test('surfaces AI provider failures cleanly', async () => {
  const handler = makeHandler({
    makeUserClient: () => fakeClient({ body: 'text' }),
    summarize: async () => { throw new Error('AI provider returned 503'); },
  });

  const res = await handler(post({ noteId: 'n1' }));
  // Decide what you want here and pin it down: 502 is a reasonable choice
  assertEquals(res.status >= 500, true);
});

Writing this test will probably make you add a try/catch around the external call, which is the point.

Test 2: Auth and JWT behavior

By default, Supabase verifies the JWT on every function request before your code runs. You can turn that off per function in supabase/config.toml:

[functions.stripe-webhook]
verify_jwt = false

Turn it off only for functions called by third parties (webhooks) or genuinely public endpoints, and then verify the caller yourself: a webhook signature, a shared secret header, or similar.

For functions that keep JWT verification on, test both sides against a running local backend:

An anonymous request returns 401.
A signed-in user can reach their own data.
User A can't reach user B's data through the function. This is where forwarding the Authorization header pays off: RLS does the work, and your test proves it.

Test 3: Webhook-triggered functions

Database webhooks call your function with a fixed payload shape: type, table, schema, record, and old_record. Save real payloads as fixtures and unit-test against them:

// supabase/functions/tests/fixtures/order-insert.json
{
  "type": "INSERT",
  "table": "orders",
  "schema": "public",
  "record": { "id": "o1", "user_id": "u1", "total_cents": 4200, "status": "paid" },
  "old_record": null
}

Deno.test('sends a receipt for paid orders only', async () => {
  const sent: string[] = [];
  const handler = makeOrderHandler({ sendReceipt: async (id) => { sent.push(id); } });

  const payload = JSON.parse(await Deno.readTextFile(
    new URL('./fixtures/order-insert.json', import.meta.url)
  ));

  await handler(new Request('http://localhost', { method: 'POST', body: JSON.stringify(payload) }));
  assertEquals(sent, ['o1']);
});

Add fixtures for the cases that cause real incidents: an UPDATE where the status didn't change (no duplicate receipt), a DELETE (where record is null), and the same payload delivered twice. Webhooks can retry, so make handlers idempotent and test it.

Test 4: Secrets and environment

Locally, put function secrets in supabase/functions/.env (and add it to .gitignore), or pass a file with --env-file when serving. In production, set them with:

supabase secrets set --env-file ./supabase/functions/.env.production
supabase secrets list

Two tests worth having:

The function fails loudly if a required secret is missing. Read secrets at startup and throw a clear error, rather than discovering undefined in a request to your AI provider.
Secrets never reach the response. A test that serializes every error response and asserts it doesn't contain your key catches the classic return Response.json({ error }) leak.

Test 5: Integration tests against a local backend

Unit tests prove the logic. Integration tests prove the wiring: the real supabase-js client, real JWTs, real RLS, the real function runtime.

The standard way is the Supabase CLI:

supabase start
supabase functions serve --env-file ./supabase/functions/.env

Then invoke through the client, exactly as your app does:

import { createClient } from 'jsr:@supabase/supabase-js@2';
import { assertEquals } from 'jsr:@std/assert';

const supabase = createClient(
  Deno.env.get('SUPABASE_URL') ?? 'http://127.0.0.1:54321',
  Deno.env.get('SUPABASE_PUBLISHABLE_KEY') ?? Deno.env.get('SUPABASE_ANON_KEY')!,
  { auth: { persistSession: false } }
);

Deno.test('anonymous callers are rejected', async () => {
  const { error } = await supabase.functions.invoke('summarize', { body: { noteId: 'x' } });
  assertEquals(error !== null, true);
});

Sign a test user in first to test the authenticated paths.

A lighter local option

supabase start runs a dozen Docker containers, roughly 1.4 GB of RAM on a Mac, and takes about a minute to boot. If that's what keeps you from running integration tests on every change, tinbase is an open-source alternative that runs a Supabase-compatible backend in one process, with no Docker, in about two seconds.

npx tinbase start

It loads functions from supabase/functions/<name>/index.ts, and functions written with Deno.serve(handler) and Deno.env run unchanged, so supabase.functions.invoke() works against it. It also runs database webhooks with the same payload shape and emulates pg_cron and pg_net, so a "cron job calls a function" flow can be exercised end to end.

Be aware of the trade-offs before you switch:

Imports: functions that use npm:, jsr:, or URL imports need to be bundled first. Functions using only web APIs run as-is.
Maturity: tinbase is alpha, built for local development and CI, not production.
Parity: run your integration suite against the real Supabase CLI before deploying.

A common setup is tinbase for the fast inner loop and every pull request, and the Supabase CLI in a nightly or pre-deploy job.

Putting it in CI

# .github/workflows/functions.yml
name: Edge Functions
on:
  pull_request:
    paths: ['supabase/functions/**']

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with: { deno-version: v2.x }
      - run: deno test --allow-all supabase/functions/tests/

Unit tests need nothing but Deno, so they run in seconds on every pull request. Add the integration job (with the Supabase CLI or tinbase) once the unit layer is solid.

The checklist

Structure

[ ] Logic lives in handler.ts; index.ts only wires dependencies and calls Deno.serve
[ ] External calls (AI, payments, email) are injected, so tests can fake them

Unit tests

[ ] Method, auth, and body validation return the right status codes
[ ] RLS-hidden rows return 404 and skip expensive calls
[ ] External failures are handled, not thrown
[ ] Webhook handlers are idempotent, tested with saved fixtures

Security

[ ] User clients forward the Authorization header; service role only when needed
[ ] verify_jwt = false only where you verify the caller another way
[ ] Missing secrets fail at startup; secrets never appear in responses

Integration

[ ] Anonymous, own-data, and other-user's-data cases tested through functions.invoke
[ ] Runs on every pull request that touches supabase/functions/

Edge Functions hold the code you least want to break. An hour spent splitting handlers and writing these tests pays for itself the first time it stops a duplicate charge from reaching production.

What's the bug your Edge Function tests would have caught? I'd like to collect them.

How to Run a Supabase Workshop for 30 People Without a Single Docker Install

Russel Dsouza — Wed, 30 Sep 2026 07:02:02 +0000

If you've ever taught a backend workshop, you know the first 40 minutes. Someone's Docker Desktop won't start. Someone's on an 8 GB laptop and the Supabase stack won't fit. Someone's corporate machine blocks virtualization. Someone's on Windows Home. By the time everyone has supabase start running, you've lost a third of the session and most of the room's energy.

I've run enough of these to want a setup where the whole room has real Postgres with Row Level Security in under two minutes, no Docker anywhere. This is that setup, using tinbase, an open-source, Supabase-compatible backend that runs as one process.

What every student needs installed

Node.js. That's the list.

npx tinbase start

That boots embedded native Postgres 17 (macOS and Linux) with REST, Auth, Storage, Realtime, Edge Functions, and a Studio-style dashboard at http://localhost:54321/_/. About two seconds to boot, about 59 MB of RAM. The official @supabase/supabase-js works unchanged, and it reads the same supabase/migrations/*.sql files the Supabase CLI uses.

On Windows, or if native Postgres can't run for any reason, the same command works with the WASM engine (PGlite):

npx tinbase start --engine wasm

Slower, heavier on memory, but still real Postgres and still no Docker.

The workshop repo structure

Give students one repo with the schema and seed data already written, so the session is about using Supabase, not typing create table:

workshop/
  supabase/
    migrations/
      20260101000000_init.sql
    seed.sql
  app/                 # the frontend (Expo, Next.js, plain HTML, whatever you teach)
  README.md            # "npm install && npx tinbase start"

-- supabase/migrations/20260101000000_init.sql
create table public.posts (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users(id) on delete cascade,
  title text not null,
  body text,
  created_at timestamptz not null default now()
);

alter table public.posts enable row level security;

create policy "read all posts" on public.posts
  for select to authenticated using (true);

create policy "write own posts" on public.posts
  for insert to authenticated with check ((select auth.uid()) = user_id);

create policy "edit own posts" on public.posts
  for update to authenticated using ((select auth.uid()) = user_id);

Every student gets the same database, the same policies, the same seed rows. When someone's exercise breaks, you know it's their code, not their environment.

Exercise 1: the RLS "aha" moment

This is the exercise that makes RLS click, and it only works if every student has their own database with two users in it.

Have each student sign up twice in the app (two emails), create a post as each, then run:

const { data } = await supabase.from('posts').select('*');

as user A. They see both posts, because the read policy is using (true). Then have them try to update user B's post as user A. Zero rows change. No error. Just nothing.

Then have them change the read policy to using ((select auth.uid()) = user_id), re-run the migration, and watch user B's post disappear from A's query.

That five-minute loop teaches more about RLS than an hour of slides. It needs a database each student can break and reset without asking you.

Reset is one command

When someone's database is in a weird state (and someone's always is):

npx tinbase start --memory

In-memory mode boots a fresh database from the migrations and seed every time. Nothing persists, nothing to clean up, and it's the right default for a workshop anyway: students should be able to blow it away and start over in two seconds.

Exercise 2: realtime, in a room full of laptops

Realtime demos usually need a shared server so students see each other's changes. Here's a trick that avoids that: pair students up, and have one of them run tinbase on a port the other can reach on the venue Wi-Fi:

npx tinbase start --port 54321

The partner points their app at http://<partner-ip>:54321. Now two laptops share one database, and a postgres_changes subscription on one shows inserts from the other. Real realtime, no cloud project, no shared credentials to leak.

Exercise 3: an Edge Function that holds a secret

Give students an API key they aren't allowed to put in the client. Have them write supabase/functions/summarize/index.ts, call it with supabase.functions.invoke('summarize'), and confirm the key never appears in the browser's network tab. Plain functions run in-process with no extra setup; functions that use npm: or jsr: imports need bundling first, so keep the exercise dependency-free.

What to tell students about the limits

Be straight with the room, because they'll ask:

tinbase is alpha, built for local dev, CI, prototypes, and teaching. Not production.
It covers roughly 80% of the supabase-js surface. MFA, SSO, phone auth, and pgvector aren't there yet.
Writes go through a single connection, so it's for one person (or one pair), not a class-wide shared server.
The migration files are the same ones they'll deploy to hosted Supabase. That's the point: nothing they learn today changes when they get a real project.

The wrap-up slide

Before the session ends, have everyone create a free hosted Supabase project and run:

supabase db push

against the same supabase/migrations/ folder. The schema and RLS policies they wrote locally are now live in the cloud, unchanged. Students leave with a working backend they built, not a tutorial they followed.

Try it before your next session

npx tinbase start

Source and the coverage table are on GitHub. If you teach with it, I'd like to hear what broke and what landed; workshop feedback is some of the most useful we get.

Every Way to Run Postgres for Local Dev in 2026, Ranked by Weight

Russel Dsouza — Wed, 23 Sep 2026 05:54:51 +0000

"Just run Postgres locally" hides a real decision. In 2026 there are four genuinely different ways to do it, and they differ by two orders of magnitude in weight. Picking wrong doesn't break anything; it just quietly taxes every git clone, every CI run, and every laptop on the team for the life of the project.

Here they are, lightest to heaviest, with the honest trade-offs.

1. Embedded: PGlite (~3 MB)

The newest option and the lightest by far. PGlite is Postgres compiled to WebAssembly, packaged as a library. You don't start a database, you import one:

import { PGlite } from '@electric-sql/pglite'

const db = new PGlite()            // in-memory
// const db = new PGlite('./data') // or persisted to disk
await db.query("select 'hello' as message")

Under 3 MB gzipped, starts in milliseconds, persists to the filesystem or IndexedDB, and supports real extensions including pgvector. This stopped being a curiosity a while ago: it crossed 10 million weekly npm downloads this year, and Prisma, Firebase, and Netlify all ship it as the local engine behind their database products.

Where it wins: test suites (a fresh, real Postgres per test, no containers in CI), instant onboarding, browser playgrounds, coding-agent sandboxes, any environment where Docker isn't available.

Where it doesn't: it's single-connection and single-user. No replication, not a production database, and tools that expect a TCP connection string need an adapter. It's a library, and everything that implies cuts both ways.

2. Native install (~50 to 300 MB)

Homebrew, apt, or Postgres.app. The old way, and still the fastest raw Postgres you can run, since there's no VM and no container layer.

Where it wins: one long-lived database you use daily, maximum performance, lowest conceptual overhead.

Where it doesn't: one global version for the whole machine. Two projects on different Postgres majors means version-manager gymnastics. It pollutes the host, upgrades are a small ritual, and "install Postgres 16 locally" is the onboarding step that fails differently on every teammate's laptop.

3. Docker (~400 MB image, plus the runtime)

The default answer of the last decade. docker compose up, one isolated Postgres per project, any version you like, throw it away when you're done.

Where it wins: version isolation per project, parity with a containerized production setup, and the whole team runs the identical environment from one committed file.

Where it doesn't: the real cost isn't the image, it's the runtime. Docker Desktop idles at gigabytes of RAM on Mac and Windows, licensing applies at larger companies, CI needs service containers with health checks and port juggling, and there are environments (locked-down laptops, cloud IDEs, agent sandboxes) where it simply can't run. You're running a VM to get a process.

4. Cloud dev branches (0 MB local, network required)

Neon-style branching, or your platform's preview databases: every PR gets its own copy-on-write database in the cloud, nothing on your machine.

Where it wins: production-identical infrastructure, instant branches with real data shapes, zero local footprint, great for review apps.

Where it doesn't: no network, no database. Every query pays a round trip, tests share remote state unless you're disciplined about branching, and it's the only option on this list with a monthly bill. It complements a local option more than it replaces one.

The cheat sheet

Use case	Pick
Unit and integration tests	PGlite (fresh DB per test)
CI pipelines	PGlite, or Docker service containers if you need TCP
One daily-driver database	Native install
Multiple projects, multiple versions	Docker
Matching containerized prod	Docker
PR preview environments	Cloud branches
Demos, workshops, browser sandboxes	PGlite

Most teams end up with two: something heavy for prod parity, something feather-weight for the inner loop. That split is the point. The 200 iterations a day don't need the faithful production copy; the last check before deploy does.

The Supabase-shaped footnote

One case the table above doesn't cover: your app doesn't talk to bare Postgres. If you build on Supabase, your client calls the platform's REST, Auth, Storage, and Realtime APIs, so a lightweight Postgres alone doesn't give you a lightweight backend. The official local stack solves it with Docker, about a dozen containers of it.

That's the gap tinbase fills: an open-source (MIT) Supabase-compatible backend that runs the whole API surface on PGlite, in one process, npx tinbase start, up in about two seconds, with the official supabase-js SDK working unchanged. Same idea as row 1 of the table, extended to the entire platform. It's alpha and aimed at local dev and tests, not production, which is exactly the inner-loop slot in the two-tier split above.

Whatever your stack, weigh the setup against how you actually spend your day. The database you iterate against should cost you nothing to start, nothing to reset, and nothing to explain in the onboarding doc.

AI App Builders in 2026: RapidNative vs Bolt vs v0 vs Lovable, an Honest Comparison

Russel Dsouza — Fri, 18 Sep 2026 10:05:38 +0000

These four tools are not four answers to one question; they're answers to different questions
v0: best-in-class React UI, no backend story
Lovable: fastest full-stack web MVP, deep Supabase wiring, web only
Bolt: browser IDE, most framework-flexible (Expo included), deployment is on you
RapidNative: mobile-first; full React Native + Expo apps with the backend wired
Disclosure up front: I work on RapidNative. The competitors' wins below are real wins.

The "AI app builder" category has exploded, and most comparisons read like feature-matrix theater. Having used all four of these for real projects (and shipping one of them), here's the honest version: each tool optimizes for a different job, and picking by hype instead of by job is how you lose a weekend.

v0 (Vercel)

v0 turns prompts into React components with shadcn/ui and Tailwind, and it produces the cleanest, most conventional UI code in the category. If you live in the Next.js/Vercel world, the design fidelity and deployment integration are genuinely excellent.

The boundary is just as clean: it's a frontend tool. No backend generation; your API routes, database, and auth are your problem. That's not a flaw, it's the product's shape.

Pick v0 when: the job is beautiful React UI inside a stack you already own.

Lovable

Lovable is the most complete prompt-to-web-app tool: frontend, Supabase database, auth, even RLS policies, wired together from a description. It's also the most accessible of the four for people who don't write code, which explains its trajectory.

The boundary: it generates web code. React for browsers, not React Native for phones. A Lovable app in a mobile webview is still a website.

Pick Lovable when: the job is a full-stack web MVP, fastest, especially if you're non-technical.

Bolt (StackBlitz)

Bolt gives you an AI pair inside a browser IDE, and it's the most framework-flexible of the group: React, Next.js, Svelte, Astro, and yes, Expo. For a technical user who wants direct code control and iteration speed in a tab, it's the strongest fit.

The mobile boundary is subtler here, and it's where I should be precise since this is my lane: Bolt can generate Expo projects, but mobile is one framework among many rather than the product's center of gravity, and getting from generated code to a store build (EAS setup, certificates, submission) is manual work it doesn't do for you.

Pick Bolt when: you're technical, want an in-browser IDE, and value flexibility across stacks.

RapidNative

Full disclosure again: this is the one I work on, so weigh accordingly.

RapidNative exists for one job: native mobile apps. Prompts, screenshots, PRDs, or sketches in; complete React Native + Expo + TypeScript projects out, with navigation, theming, and the Supabase backend wired, built as apps headed for the App Store and Play Store rather than as websites that might one day get wrapped. You export and own the code.

The honest boundaries: it's not the tool for a web SaaS (use Lovable), not a general-purpose IDE (use Bolt), and if your job is pixel-perfect web UI, v0 will out-design it. Mobile-first cuts both ways.

Pick RapidNative when: the deliverable is an iOS/Android app, not a website.

The actual decision

The category's dirty secret is that the web/mobile split matters more than any feature comparison. Almost every tool in this space builds web apps; if you're shipping to a browser, you have great options and this article barely matters. If you're shipping to the app stores, the field narrows sharply, and "supports Expo" and "built for Expo" are different products.

These tools also compose. Plenty of teams run Lovable or Bolt for their web app and RapidNative for the mobile app, same Supabase underneath. Treating this as a winner-take-all bracket is the feature-matrix brain talking.

Pricing, for completeness: all four land in the same rough $20-25/month ballpark for pro tiers as of writing, with credit systems that vary. Don't pick on price; at these numbers, one saved afternoon pays the annual difference.

The one-line version

Web UI: v0. Full-stack web, fastest: Lovable. Browser IDE with maximum flexibility: Bolt. Native mobile apps, end to end: RapidNative.

What are you building, and which of these did you end up on? Genuinely curious how the split looks in the comments, especially from anyone who's shipped with two of them.