Mobile App mit KI bauen: von Expo bis in die Stores

Am schnellsten baust du eine Mobile App mit KI, indem ein Coding-Agent ein React-Native-Projekt mit Expo aufsetzt, du jede Änderung mit Expo Go auf deinem eigenen Handy ausprobierst und ein gehostetes Backend wie Supabase oder Firebase nutzt. Der Agent schreibt Bildschirme, Datenschicht und Anmeldung; du testest auf dem Gerät, gibst Fehler zurück und erledigst die Store-Schritte. Die Veröffentlichung braucht weiterhin Entwicklerkonten bei Apple und Google und deren Review-Prozesse.

Dieser Beitrag geht den ganzen Weg von einem leeren Ordner bis zu den Stores: welchen Stack ich wähle und warum, den ersten Prompt für den Agenten, wie ich auf dem Handy teste, Auth und Benachrichtigungen, Veröffentlichung und wo Agenten am häufigsten stolpern.

Erwartungen zuerst klären

Es gibt einen echten Unterschied zwischen Vibe Coding einer Website und einer Mobile App. Im Web bist du fertig, wenn der Code läuft. Mobil liegt über dem Code eine Plattformschicht: Build-Tools, Signaturzertifikate, Berechtigungen, Store-Regeln. Den Großteil des Codes erledigt der Agent bequem; für die Plattformseite brauchst du Augen und Hände.

Die gute Nachricht: Mit den richtigen Tools berührst du die meiste dieser Plattformschicht in den ersten Wochen gar nicht.

Welcher Stack: Expo, Flutter oder nativ

Es gibt drei Hauptwege.

Für Einsteiger ist meine Antwort klar: React Native + Expo. Der Grund liegt weniger in technischen Vorzügen als in der Geschwindigkeit des Feedbacks. Der Agent ändert etwas, und du siehst es Sekunden später auf deinem Handy. Je kürzer diese Schleife, desto besser funktioniert Vibe Coding.

Flutter ist eine gute Wahl, wenn du Dart kennst oder dein Team es schon nutzt. Nativ ergibt nur mit einem konkreten Grund Sinn, etwa Kameraverarbeitung, aufwendige Grafik oder tiefe Plattformintegration.

Schritt 1: Einrichtung

Was du brauchst:

• Node.js (ein LTS-Release) und einen Paketmanager
• Einen Coding-Agenten: Claude Code, Codex, Gemini CLI oder einen anderen Coding-Agenten
• Expo Go auf deinem Handy, aus dem App Store oder von Google Play
• Git, damit sich jeder Schritt des Agenten rückgängig machen lässt

Lege das Projekt selbst an. Agenten, die ein Grundgerüst von Grund auf bauen, greifen manchmal zu veralteten Templates:

npx create-expo-app@latest habits
cd habits
git init && git add -A && git commit -m "initial scaffold"
npx expo start

Im Terminal erscheint ein QR-Code. Scanne ihn mit der Kamera auf dem iPhone oder in Expo Go auf Android, und die App öffnet sich auf deinem Handy. Rechner und Handy müssen im selben WLAN sein. Kommt dir das Netzwerk in die Quere, versuche npx expo start --tunnel.

Schritt 2: Der erste Prompt

Der erste Prompt prägt jede Entscheidung, die der Agent danach trifft. Lässt du Lücken, füllt er sie mit seinen eigenen Vorlieben. Ich schreibe etwa Folgendes:

This is an Expo (React Native, TypeScript) project. We're building a
simple habit tracker.

Screens:
1. Today: list of habits, each with a "done" button
2. Add: create a habit with a name and a daily goal
3. History: calendar view of the last 30 days

Rules:
- Use expo-router for navigation and follow the existing app/ folder.
- Keep data on the device for now (AsyncStorage). Backend comes later.
- Add packages with npx expo install, not npm install.
- Don't add native packages that don't run in Expo Go; ask first.
- Run npx tsc --noEmit after each step and fix the errors.
- When done, list the files you changed.

Zwei Zeilen zählen am meisten. npx expo install wählt die Paketversion, die zu deinem Expo SDK passt, und Agenten überspringen es ständig. Die Regel „keine Pakete, die nicht in Expo Go laufen“ hält dich aus nativen Builds heraus, bis du sie wirklich brauchst.

Schritt 3: Auf dem Handy testen und iterieren

Solange npx expo start läuft, lädt die App auf deinem Handy neu, während der Agent Dateien bearbeitet. Die Schleife:

1. Probiere es auf dem Handy aus und notiere, was falsch ist.
2. Sag dem Agenten genau Bescheid: „Auf dem Add-Bildschirm verdeckt die Tastatur den Speichern-Button, auf dem iPhone.“
3. Erscheint der rote Fehlerbildschirm, kopiere den Text wörtlich zum Agenten. Ein Screenshot funktioniert auch; die meisten Agenten können Bilder lesen.
4. Committe jeden Schritt, der funktioniert.

Teste auf iOS und Android. Derselbe Code verhält sich unterschiedlich: Safe-Area-Insets, Tastaturverhalten, Zurück-Taste, Schatten. Hast du nur ein Handy, nimm für die andere Plattform einen Android-Emulator oder (auf dem Mac) den iOS Simulator.

Schritt 4: Backend mit Supabase oder Firebase

Willst du Daten über Geräte hinweg teilen und Nutzerkonten, brauchst du ein Backend. Schreibe keinen eigenen Server; nimm ein gehostetes:

• Supabase: auf PostgreSQL aufgebaut. Datenbank, Auth, Dateispeicher und Echtzeit-Updates. Passt gut, wenn du SQL kennst oder lernen willst.
• Firebase: Googles Plattform. Firestore-Dokumentendatenbank, Auth, Messaging. Eng ins Mobile-Ökosystem integriert.

Lass den Agenten es Schicht für Schicht bauen, nicht alles auf einmal:

We're moving to Supabase. For now, only do this:
1. Write a SQL file under supabase/migrations that creates habits and
   completions tables. Every row has a user_id.
2. Enable Row Level Security on both tables so a user can only read
   and write their own rows.
3. Don't change the app code yet. Show me the SQL; I'll apply it.

Überspringe den RLS-Teil nicht. Der Supabase-Schlüssel in einer Mobile App ist per Design öffentlich; deine Daten schützen die Regeln in der Datenbank, nicht die Geheimhaltung dieses Schlüssels. In Firebase übernehmen Security Rules dieselbe Rolle.

Schritt 5: Auth

Die Anmeldung per E-Mail ist am einfachsten; Supabase und Firebase bieten sie beide. „Mit Google anmelden“ und „Mit Apple anmelden“ brauchen mehr Einrichtung: Redirect-URIs, ein App-Scheme und die Registrierung in der Konsole jeder Plattform.

Eines solltest du wissen: Nach den App-Store-Richtlinien kann Apple von dir, wenn deine App einen Social-Login eines Drittanbieters anbietet, zusätzlich „Mit Apple anmelden“ oder eine gleichwertige datenschutzfreundliche Option erwarten, mit einigen Ausnahmen. Prüfe die aktuellen Regeln vor der Einreichung.

So bitte ich um Auth:

Add email + password sign-in with Supabase Auth.
- If there's no session, redirect to the sign-in screen.
- Store the session with expo-secure-store.
- Put a sign-out button on the Settings screen.
- Error messages should be clear and in plain English.
Don't add Google or Apple sign-in yet.

Schritt 6: Push-Benachrichtigungen

Push-Benachrichtigungen fressen auf Mobilgeräten mehr Zeit als alles andere. In Expo beginnst du mit expo-notifications:

npx expo install expo-notifications expo-device

Was du wissen solltest:

• Lokale Benachrichtigungen („erinnere mich jeden Abend um 21 Uhr“) brauchen keinen Server und sind mit Abstand am einfachsten. Für einen Habit-Tracker reichen sie oft völlig.
• Remote Push heißt, einen Push-Token zu holen, ihn auf deinem Server zu speichern und von dort zu senden. Auf iOS braucht das ein Apple-Developer-Konto und die Push-Capability.
• Teste das Benachrichtigungsverhalten auf einem echten Gerät. Die Unterstützung für Benachrichtigungen in Simulator und Expo Go kann eingeschränkt sein und ändert sich mit der Zeit.

Bitte den Agenten zuerst um lokale Benachrichtigungen, sieh sie funktionieren und geh dann zu Remote Push über.

Schritt 7: Builds und die Stores

Expo Go ist für die Entwicklung; die Stores bekommen eine echte App-Binärdatei. Expos Cloud-Dienst EAS baut sie für dich:

npm install -g eas-cli
eas login
eas build:configure
eas build --platform android
eas build --platform ios

Der große Vorteil von Cloud-Builds ist, dass du Xcode und das Android SDK nicht selbst einrichten musst. Den iOS-Build kannst du sogar ohne Mac erzeugen.

Apple:

• Eine kostenpflichtige, jährliche Mitgliedschaft im Apple Developer Program.
• Ein App-Eintrag in App Store Connect mit Screenshots, Beschreibung, URL der Datenschutzerklärung und der Datenangabe „App Privacy“.
• Verteile zuerst über TestFlight an dich und ein paar Tester und reiche dann zur Prüfung ein.
• Ablehnungen sind normal. Häufige Gründe: Abstürze, fehlender Datenschutztext, dünne „Website-Wrapper“-Apps und Apps, die das Anlegen eines Kontos erlauben, aber nicht dessen Löschung.

Google:

• Eine einmalige kostenpflichtige Registrierung für die Google Play Console plus Identitätsprüfung.
• Ein Store-Eintrag, der Fragebogen zur Inhaltseinstufung und das Formular „Data safety“.
• Neue persönliche Entwicklerkonten müssen vor der Produktion womöglich einen geschlossenen Test mit einer bestimmten Zahl von Testern über einen bestimmten Zeitraum durchführen; prüfe die aktuelle Regel in der Konsole.

eas submit erleichtert das Senden der Builds an beide Stores, aber die Store-Formulare füllst du weiterhin selbst aus. Lies sie, statt sie dem Agenten zu überlassen; anzugeben, welche Daten deine App erfasst, liegt in deiner Verantwortung.

Wo Agenten Probleme haben

Das ist die Liste der Stellen, an denen ich beim Vibe Coding von Mobile Apps die meiste Zeit verloren habe.

Native Build-Fehler

Gradle, CocoaPods, Xcode-Versionen, Android-SDK-Level. Diese Fehler sind lang, laut und umgebungsspezifisch. Der Agent sieht das Xcode auf deinem Rechner nicht; er rät. Das hilft:

• Füge die vollständige Fehlerausgabe ein, nicht nur die ersten Zeilen. Die eigentliche Ursache steht oft weiter unten oder mittendrin.
• Nutze EAS Build, wo du kannst; die Umgebung bleibt fest.
• Lass den Agenten die Ordner ios/ und android/ nicht von Hand bearbeiten. In Expo werden diese meist aus der Konfiguration erzeugt, dauerhafte Änderungen gehören also in app.json oder ein Config Plugin.

Signierung und Zertifikate

Zertifikate, Provisioning Profiles und Bundle Identifier auf iOS; ein Keystore auf Android. Agenten geben hier zuversichtliche, aber falsche Anweisungen. Credentials von EAS verwalten zu lassen, ist der glatteste Weg. Verlierst du deinen Android-Upload-Key, wird das Ausliefern von Updates für dieselbe App zum echten Kopfzerbrechen, also sichere ihn.

Versionskonflikte

Der Agent nutzt eine Paket-API aus der Zeit seines Trainings; dein Projekt hat vielleicht eine andere Version. npx expo install --check listet nicht passende Pakete auf. Es hilft, dem Agenten zu sagen: „Prüfe zuerst die Version in package.json und schreibe dann gegen die Doku dieser Version.“

Nur auf einer Plattform testen

Der Agent schreibt ein Layout, das auf iOS funktioniert und auf Android überläuft. Sieh dir jede Funktion auf beiden an.

Alles auf einmal verlangen

„Füge Auth, Benachrichtigungen und Zahlungen hinzu“ lässt alle drei halb fertig. Ein Feature nach dem anderen, dazwischen committen.

Sicherheit zählt mobil noch mehr

Alles, was du in eine Mobile App legst, landet auf dem Gerät des Nutzers, wo es entpackt und gelesen werden kann. Also:

• Lege nie Secrets ins App-Bundle. In Expo werden Umgebungsvariablen, die mit EXPO_PUBLIC_ beginnen, ins Bundle eingebettet und damit öffentlich. Der service_role-Schlüssel von Supabase, der geheime Schlüssel eines Zahlungsanbieters oder ein KI-API-Schlüssel dürfen nie in der App ausgeliefert werden; sie gehören auf die Serverseite, zum Beispiel in eine Edge Function.
• Halte Secrets in einer .env-Datei und prüfe, dass .env in .gitignore steht.
• Füge API-Schlüssel nie in den Chat ein. Sag dem Agenten, welche Umgebungsvariable er lesen soll, nicht den Schlüssel selbst.
• Teste deine Datenbankregeln. Melde dich mit einem zweiten Konto an und prüfe, ob du die Daten des ersten Kontos lesen kannst.
• Lies die Befehle, die der Agent ausführt, besonders eas, git push, Löschungen und Datenbankbefehle, bevor du sie bestätigst.

So mache ich das mit AgentVera

Du kannst all das in einem einfachen Terminal tun. Bei Mobile-Projekten lasse ich gern mehrere Agenten nebeneinander laufen, und das mache ich in AgentVera:

• Getrennte Agenten in getrennten Worktrees. Zum Beispiel arbeitet Claude Code in einem Git-Worktree an Supabase-Schema und Edge Functions, während Codex in einem anderen Bildschirme baut. Das Git-Panel zeigt die Änderungen jedes Branches.
• Ein Terminal im Raster. npx expo start bleibt in einem Pane offen, sodass du die Ausgabe von Metro neben den Agenten siehst; dafür ist das Panel Editor und Terminal da.
• Review vor dem Merge. Das automatische Code-Review lässt ein zweites Modell jeden Turn des Agenten prüfen; den Diff solltest du trotzdem selbst lesen.
• Die Datenbank. Füge die Postgres-Verbindung von Supabase im Datenbank-Manager hinzu, um Tabellen und Zeilen zu prüfen, die der Agent angelegt hat.
• Token-Tracking. Lange Build-Logs blähen den Kontext schnell auf; die Token-Nutzung ist pro Pane sichtbar.

AgentVera baut nicht für dein Handy und reicht nicht bei den Stores ein; dieser Teil bleibt bei Expo und den Store-Konsolen.

Kurze Checkliste

• Expo-Projekt von dir angelegt, erster Commit in Git
• Der erste Prompt nennt Bildschirme, Regeln und die Vorgabe npx expo install
• Jedes Feature auf dem Handy getestet, auf beiden Plattformen
• RLS in Supabase oder Security Rules in Firebase aktiviert und getestet
• Keine geheimen Schlüssel im App-Bundle
• Android-Keystore gesichert
• Datenschutzerklärung und Store-Datenangaben bereit

Fazit

Eine Mobile App mit KI zu bauen ist heute ein realistisches Ziel, aber es endet nicht bei „schreib mir eine App“. Beginne mit Expo, sieh jede Änderung mit Expo Go auf dem Handy, nutze ein gehostetes Backend, füge Features einzeln hinzu und übernimm die Plattformschritte selbst: Signierung, Store-Formulare, Review. Zum Prüfen dessen, was der Agent geschrieben hat, siehe KI-Code-Review, zum parallelen Betrieb von Agenten Git-Worktrees für parallele Agenten.