Codex und Expo: vom Prototyp zum Store-Build

Ein Expo-Prototyp entsteht mit OpenAI Codex oft in wenigen Tagen: Navigation, Formulare, Listen und erste Daten laufen schnell in Expo Go auf dem Smartphone. Der Schritt zum echten Store-Build ist dann ein anderer Arbeitsmodus. Es geht um Konfiguration, native Module, Signierung und Updates. Dieser Ratgeber beschreibt, wie Sie den Übergang mit Codex strukturieren und welche Entscheidungen vor dem ersten Build in der Cloud fallen sollten.

Expo Go ist nicht die fertige App

Expo Go ist ein Testcontainer mit fest eingebauten nativen Modulen. Sobald Ihre App Bibliotheken nutzt, die dort nicht enthalten sind, oder eigene native Konfiguration braucht, wechseln Sie auf einen Development Build. Codex schlägt in Prototypen gerne Pakete vor, die in Expo Go zunächst zu funktionieren scheinen oder Fehler erst später zeigen. Lassen Sie deshalb früh prüfen, ob alle Abhängigkeiten zur verwendeten Expo-SDK-Version passen.

Hilfreich ist eine klare Anweisung in der AGENTS.md: neue Pakete nur über npx expo install, keine manuellen Änderungen in den Ordnern ios und android, Konfiguration ausschließlich über app.config und Config Plugins.

Vom Prototyp zum ersten Store-Build

Diese Reihenfolge hat sich bewährt:

1. Sie lassen Codex App-Name, Bundle Identifier, Android-Package, Icons und Splash Screen in der app.config sauber setzen.
2. Sie legen in der eas.json getrennte Profile für development, preview und production an.
3. Sie verknüpfen das Projekt mit Ihrem Expo-Konto und lassen EAS die Zertifikate und Keystores verwalten oder hinterlegen eigene.
4. Sie erstellen einen Preview-Build und testen ihn intern auf iOS über TestFlight und auf Android über den internen Test der Play Console.
5. Sie erzeugen den Production-Build und übertragen ihn mit EAS Submit an App Store Connect und die Play Console.
6. Sie ergänzen Store-Einträge, Datenschutzangaben und Review-Hinweise und reichen ein.

Updates ohne Review richtig einsetzen

Mit EAS Update lassen sich JavaScript- und Asset-Änderungen ohne neuen Store-Build ausliefern. Das ist praktisch für Fehlerbehebungen, hat aber Grenzen: Neue native Module erfordern immer einen neuen Build, und wesentliche Funktionsänderungen, die am Review vorbeigehen, verstoßen gegen die Regeln der Stores. Definieren Sie eine Runtime-Version, damit Updates nur an kompatible Builds gehen.

Codex kann die Update-Kanäle konfigurieren und Release-Skripte schreiben. Die Entscheidung, was als Over-the-Air-Update und was als neue Version ausgeliefert wird, sollte im Team bewusst getroffen werden.

Ein praktischer Tipp: Halten Sie in der AGENTS.md fest, welche Dateien eine neue native Version erzwingen, etwa Änderungen an Plugins, Berechtigungen oder der Expo-SDK-Version. Codex kann dann bei jeder Aufgabe melden, ob das Ergebnis per Update ausgeliefert werden darf oder einen neuen Store-Build braucht. Das verhindert, dass ein Update an Geräte geht, deren nativer Unterbau nicht dazu passt, und die App beim Start abstürzt. Zusätzlich lohnt sich ein eigener Update-Kanal für interne Tester, über den jede Änderung zuerst läuft.

Häufige Probleme beim Übergang

Der Klassiker sind fehlende Berechtigungstexte: Greift die App auf Kamera, Standort oder Fotos zu, verlangt iOS aussagekräftige Begründungen, und Apple lehnt generische Texte ab. Ebenfalls häufig sind Umgebungsvariablen, die im Prototyp im Code standen. Öffentliche Konfiguration darf über EXPO_PUBLIC-Variablen in die App, geheime Schlüssel gehören ausschließlich ins Backend. Prüfen Sie außerdem, ob Login-Anbieter eingebunden sind; dann gilt Guideline 4.8 und Sie brauchen eine gleichwertige datenschutzfreundliche Option wie Sign in with Apple.

Wer die Pipeline später automatisieren möchte, lässt EAS-Builds per GitHub Actions auslösen. Dann laufen Build und Submit bei jedem Release-Tag reproduzierbar. Vergessen Sie nicht die Kontolöschung: Bietet die App eine Registrierung an, muss sich das Konto nach Guideline 5.1.1 auch in der App löschen lassen. Bei Google Play gilt dasselbe, ergänzt um eine erreichbare Web-Adresse für Löschanfragen. Beides lässt sich gut als eigene Codex-Aufgabe mit klarer Abnahme formulieren.

Unterstützung auf dem letzten Stück

Die AI Code Engineers von neooutput begleiten Expo-Projekte vom Codex-Prototyp bis zur Veröffentlichung, inklusive Architektur-Review und Production-Hardening. Geht es vor allem um Signierung, Store-Einträge und Einreichung, übernimmt appsubmitter.io diesen Teil im eigenen Konto des Kunden. Sprechen Sie uns in einem kostenlosen 15-Minuten-Erstgespräch an.

Häufige Fragen