> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Web- und Mobile-SaaS mit Next.js und Expo bauen (Monorepo-Leitfaden)

Praxisleitfaden für plattformübergreifende SaaS: Next.js 16 und React Native Expo in einem pnpm-Monorepo mit geteiltem Better Auth und Drizzle ORM.

_Veröffentlicht 2026-11-06._
_Aktualisiert am 2026-11-06._

> **Wie teilt man Code zwischen Next.js und Expo in einem Monorepo?**
> Es kommt auf die Modulgrenzen und Bundler-Konfiguration an. Die stabilste Architektur trennt Datenmodelle, Validierungen und API-Verträge mit pnpm und Turborepo in interne Headless-Pakete. Der Next.js 16 Server führt Drizzle ORM direkt gegen PostgreSQL aus, während die Expo-App über getypte Endpunkte kommuniziert und Auth-Tokens sicher via expo-secure-store speichert. supastack liefert dieses Setup schlüsselfertig ohne Konflikte zwischen Metro und Turbopack.

## Die größte Hürde bei Cross-Platform-SaaS: Der Bundler-Konflikt

Jeder Gründer weiß, dass mobile Apps dank Push-Nachrichten und Präsenz auf dem Homescreen die Nutzerbindung und Aktivität drastisch steigern. Doch die Kombination von Next.js und React Native Expo in einem Monorepo birgt Fallstricke.

Next.js nutzt Turbopack oder Webpack für Node- und Edge-Runtimes, während Expo auf den Metro-Bundler für React Native setzt. Unbedachtes Code-Sharing scheitert schnell: Metro versucht Node-Module wie `crypto` zu laden, während Turbopack an mobilen JSX-Mustern scheitert. Die Lösung liegt in strikter Kapselung.


## Headless-Pakete entwerfen: Authentifizierung, Schemata und Verträge

In einem sauberen Monorepo sind Applikationen (`apps/web` und `apps/mobile`) schlanke UI-Schalen. Geschäftslogik und Datenstrukturen liegen in internen Paketen unter `packages/`:

`@supastack/db`: Enthält Drizzle ORM-Tabellen und Migrationen. Nur Server-Runtimes binden die Datenbank an; Clients nutzen ausschließlich die exportierten Typen.

`@supastack/auth`: Konfiguriert Better Auth mit zwei Einstiegspunkten: Server-Routen für das Backend und ein Headless-Client-SDK für Web und Mobile.

`@supastack/config`: Validiert Umgebungsvariablen mit Zod beim Build und verhindert Laufzeitabstürze durch fehlende Konfigurationen.

```
// packages/auth/src/client.ts
import { createAuthClient } from "better-auth/react";
import { expoClient } from "@better-auth/expo/client";

export function createCrossPlatformAuthClient(baseURL: string, storage?: any) {
  return createAuthClient({
    baseURL,
    plugins: storage ? [expoClient({ scheme: "myapp", storage })] : [],
  });
}
```


## Einheitliche Authentifizierung: Cookies im Web, SecureStore auf Mobile

Web und Mobile benötigen unterschiedliche Sitzungsmechanismen. Im Web setzt Next.js HTTP-only-Cookies für automatischen CSRF-Schutz und serverseitiges Rendering.

Auf Mobilgeräten sind Cookies unzuverlässig. Stattdessen speichert die Expo-App nach dem OAuth-Flow einen sicheren Bearer-Token über `expo-secure-store` in Keychain oder Keystore. Mobile API-Aufrufe senden den Header `Authorization: Bearer <token>`, den die geteilte Better Auth Middleware prüft.


## CI/CD und Release-Pipeline: Vercel, EAS Build und Versionsabgleich

Ein gemeinsames Repository ermöglicht synchronisierte Releases. Wird eine Migration in `@supastack/db` übernommen, aktualisiert sich das Next.js-Backend auf Vercel oder Cloud Run innerhalb von Sekunden.

Gleichzeitig kompiliert Expo Application Services (EAS Build) native Builds für Apple TestFlight und Google Play. Feste Paketversionen im Monorepo verhindern die gefürchteten Versionskonflikte getrennter Repositories.