React Native mit Expo ist für viele KI-gestützte Projekte der Sweet Spot: eine Codebasis in TypeScript, echte native Oberflächen und mit EAS eine Cloud-Infrastruktur, die Builds und Einreichungen übernimmt. Claude Code kennt das Ökosystem gut, macht aber auch typische Fehler, etwa bei Versionsständen oder Konfigurationsdateien. Hier erfahren Sie, wie Sie Agent und Expo so kombinieren, dass am Ende ein reviewfähiger Build im App Store und im Google Play Store landet, ohne dass Sie Xcode-Interna auswendig lernen müssen.
Projektstart: Kontext vor Code
Starten Sie mit dem offiziellen Expo-Template statt mit einem von der KI frei erfundenen Gerüst. Danach gehört eine CLAUDE.md ins Repository, die die Expo-SDK-Version, den Router, das State-Management und verbotene Pakete festhält. Gerade bei React Native schlägt ein Agent gern Bibliotheken vor, die mit der aktuellen SDK-Version nicht kompatibel sind. Der Hinweis, dass Pakete ausschließlich über den Expo-Installationsbefehl hinzugefügt werden, verhindert viele Versionskonflikte.
Nutzen Sie für neue Features den Plan-Modus. Claude Code beschreibt dann zuerst, welche Screens, Hooks und nativen Module betroffen sind. Wenn ein Feature ein natives Modul ohne Expo-Unterstützung braucht, sollten Sie das früh erkennen, denn dann benötigen Sie einen Development Build statt Expo Go.
app.config und eas.json richtig aufsetzen
Die App-Konfiguration enthält Bundle Identifier, Android-Paketnamen, Versionsnummer, Icons und Berechtigungstexte. Lassen Sie Claude Code diese Datei dynamisch als app.config.ts anlegen, wenn Sie verschiedene Umgebungen wie Staging und Produktion unterscheiden. In der eas.json definieren Sie Build-Profile, typischerweise development, preview und production.
Achten Sie darauf, dass die automatische Versionierung über EAS aktiviert ist. Sonst lehnt App Store Connect den zweiten Upload mit gleicher Build-Nummer ab, und Google Play verweigert einen identischen versionCode. Geheimnisse wie API-Schlüssel gehören in EAS-Umgebungsvariablen, nicht in den Code, den der Agent schreibt.
Builds und Einreichung mit EAS
Der eigentliche Weg in die Stores ist erstaunlich kurz, wenn die Vorarbeit stimmt. Die Reihenfolge sieht so aus:
- Melden Sie sich mit der EAS-CLI an und verknüpfen Sie das Projekt mit Ihrem Expo-Konto.
- Erzeugen Sie mit dem Production-Profil einen iOS-Build; EAS kann Zertifikate und Provisioning Profiles auf Wunsch selbst verwalten.
- Erzeugen Sie den Android-Build als AAB und aktivieren Sie in der Play Console die Play App Signing.
- Reichen Sie beide Builds mit EAS Submit ein; für iOS wird ein App-Store-Connect-API-Schlüssel benötigt, für Android ein Dienstkonto mit Play-Console-Rechten.
- Pflegen Sie Store-Texte, Screenshots, App Privacy Labels und das Data-safety-Formular, bevor Sie das Review anstoßen.
Qualität sichern, bevor der erste Build entsteht
Jeder Cloud-Build kostet Zeit, und ein fehlgeschlagener Build nach zwanzig Minuten Wartezeit ist ärgerlich. Lassen Sie Claude Code deshalb vor jedem Build lokal prüfen, ob TypeScript im strikten Modus fehlerfrei kompiliert, die Tests mit Jest durchlaufen und die Diagnose von Expo keine inkompatiblen Paketversionen meldet. Diese drei Prüfungen lassen sich in einem eigenen Slash Command bündeln, den Sie oder der Agent vor jedem Release aufrufen.
Für interne Tests eignet sich das Preview-Profil mit interner Verteilung. So erhalten Kolleginnen und Kollegen einen installierbaren Build, ohne dass Sie TestFlight oder einen Play-Test-Track bemühen müssen. Sammeln Sie Feedback strukturiert, etwa als Issues im Repository, und lassen Sie Claude Code diese Issues anschließend einzeln abarbeiten. Diese Disziplin zahlt sich spätestens dann aus, wenn das Review-Team von Apple die App zum ersten Mal öffnet und sie auf Anhieb stabil laufen muss.
Wo es in der Praxis hakt
Die meisten Verzögerungen entstehen nicht beim Build, sondern beim ersten Upload in die Play Console: Die allererste Version muss dort meist manuell hochgeladen werden, bevor automatisierte Einreichungen greifen. Neue private Entwicklerkonten brauchen außerdem 12 Tester über 14 Tage im Closed Testing. Bei Apple führen fehlende Demo-Zugänge für das Review-Team, unklare Berechtigungstexte oder ein fehlender Weg zur Kontolöschung zu Ablehnungen.
Mit appsubmitter richten wir genau diese Strecke in Ihrem eigenen Konto ein, inklusive Dienstkonten, API-Schlüsseln und Review-Kommunikation. Braucht die App noch Feature-Arbeit oder ein Production-Hardening, übernehmen das die AI Code Engineers von neooutput. Buchen Sie ein kostenloses 15-Minuten-Erstgespräch, und wir prüfen gemeinsam, wie weit Ihr Projekt von der Veröffentlichung entfernt ist.
Häufige Fragen
Brauche ich für eine Expo-App einen Mac?
Für den Build nicht zwingend, denn EAS Build erstellt iOS-Builds in der Cloud. Ein Mac ist aber für Debugging im Simulator und für manche Prüfungen hilfreich. Für Tests auf echten iPhones genügt ein Development Build.
Ist EAS kostenpflichtig?
Expo bietet einen kostenlosen Einstieg mit begrenzten Build-Kontingenten sowie bezahlte Pläne für mehr und schnellere Builds. Alternativ können Sie lokal oder in einer eigenen CI bauen. Die Store-Gebühren von Apple und Google kommen in jedem Fall hinzu.
Kann Claude Code EAS-Befehle selbst ausführen?
Ja, sofern die CLI installiert und angemeldet ist und Sie die Befehle in den Berechtigungen freigeben. Für Einreichungen empfiehlt sich trotzdem eine bewusste Freigabe durch einen Menschen, da sie direkt Ihr Store-Konto betreffen.