For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /de/docs/mobile/publishing.md (or send Accept: text/markdown).

Im App Store veröffentlichen

Unterscheide einen funktionierenden Build von einer Version, die Nutzer installieren können.

Zu dieser Anleitung fragen

Bereiten Sie Ihre erste Store-Einreichung Schritt für Schritt vor

Erstellen und testen Sie zunächst einen nativen Entwicklungs-Build mithilfe von Mobile-Builds. Eine Store-Einreichung sendet die kompilierte App und ihren Eintrag zur Überprüfung an Google oder Apple; Es ist nicht dasselbe wie das Öffnen einer Expo Go-Vorschau. Sie benötigen Ihr eigenes Expo und relevante Store-Entwicklerkonten, ein getestetes HTTPS-Backend, den endgültigen App-Namen/das endgültige App-Symbol, Screenshots, Supportkontakt und eine öffentliche Datenschutzrichtlinie URL.

Öffnen Sie apps/mobile/app.json im Editor und legen Sie vor dem ersten Upload den App-Namen, Slug, ios.bundleIdentifier und android.package für Ihr eigenes Produkt fest. Öffnen Sie apps/mobile/eas.json und ersetzen Sie bei Bedarf die App-IDs des iOS-Einreichungsteams durch Ihre eigenen. Die mitgelieferten Identifikatoren sind Beispiele. Lesen Sie Mobile Builds für die genauen Felder und bitten Sie Ihren Coding-Agenten, die beiden Dateien vor dem Erstellen zu überprüfen.

Wenn eas nicht installiert ist, führen Sie npm install --global eas-cli aus. Verwenden Sie im Repository-Stammverzeichnis den Anmeldebefehl unten, schließen Sie die Browserauthentifizierung ab, wählen Sie dann den Build-Befehl für eine Plattform in Build aus und senden Sie ihn dann ab. Lesen Sie die Dashboard-Protokolle des Builds. Warten Sie auf eine erfolgreiche .aab- oder .ipa-Datei, bevor Sie mit der Übermittlung beginnen. EAS fordert zur Eingabe von Projektverknüpfungs- und Signaturanmeldeinformationen auf; Diese gehören zu Ihren Konten, nicht zu denen des Kit-Verkäufers.

Nachdem die Binärdatei hochgeladen wurde, öffnen Sie Ihre App in der Play Console oder App Store Connect, füllen Sie die Liste und die erforderlichen Fragebögen aus, fügen Sie Anmeldeanweisungen für funktionierende Prüfer hinzu und reichen Sie sie dann dort zur Überprüfung ein. Das Hochladen eines internen Entwurfs ist keine öffentliche Veröffentlichung. Wenn die Überprüfung es ablehnt, öffnen Sie den genauen Richtlinienlink in der Ablehnung und beheben Sie das Problem, bevor Sie es erneut einreichen.

corepack pnpm --filter @supastack/mobile exec eas login

Konten einmalig einrichten

Für die Store-Einreichung sind drei Konten erforderlich: ein kostenloses Expo-Konto für EAS Build und Submit, eine Entwicklerregistrierung in der Google Play Console und eine Mitgliedschaft im Apple Developer Program für iOS. Installiere die EAS CLI und führe vor dem Build eas login aus. Die Bestätigung beider Store-Anmeldungen kann Tage dauern, beginne daher frühzeitig.

Benenne die Anwendungskennungen vor dem ersten Upload um: android.package und ios.bundleIdentifier werden in apps/mobile/app.json als com.supastack.app ausgeliefert. Google Play sperrt den Paketnamen nach dem ersten Upload; eine falsche Kennung erfordert daher einen neuen App-Eintrag statt einer Umbenennung.

EAS die Signierung verwalten lassen

apps/mobile/eas.json definiert Development-, Preview- und Production-Buildprofile. Im Production-Profil kann EAS den Android-Keystore und das iOS-Distributionszertifikat auf seiner Infrastruktur erzeugen und verwahren. Sieh sie später mit eas credentials ein und halte lokale Keystores aus dem Repository heraus.

Für eine automatisierte Einreichung bei Play wird ein Google-Play-Service-Account-JSON-Schlüssel benötigt, der unter Play Console → Setup → API access mit Veröffentlichungsberechtigung verknüpft ist. Speichere ihn unter apps/mobile/secrets/play-store-service-account.json – dem von eas.json erwarteten Pfad in einem von Git ignorierten Verzeichnis. Der erste Upload einer neuen App erfolgt weiterhin manuell in der Play Console; ab der zweiten Version übernimmt eas submit.

Zuerst bauen, dann einreichen

Builds laufen auf der EAS-Infrastruktur; für die Binärdatei sind Android Studio und Xcode daher nicht erforderlich. Das Production-Profil erzeugt storefertige .aab-Dateien für Play und .ipa-Dateien für den App Store mit versionsnummern, die remote verwaltet werden. Das Preview-Profil erzeugt ein APK für die interne Verteilung und Qualitätssicherung auf physischen Geräten.

Das bereitgestellte Submit-Profil zielt auf den internen Play-Track als Entwurf ab. Tester erhalten nichts, bis du es nach bestandener Prüfung in der Play Console freigibst.

corepack pnpm --filter @supastack/mobile build:android
corepack pnpm --filter @supastack/mobile submit:android

corepack pnpm --filter @supastack/mobile build:ios
corepack pnpm --filter @supastack/mobile submit:ios

# Internal-testing APK for a physical device:
corepack pnpm --filter @supastack/mobile build:android:preview

Formulare der Play Console ausfüllen

Die Play-Prüfung berücksichtigt neben der Binärdatei auch die angegebenen Inhalte: eine öffentliche Datenschutz-URL, das Formular zur Datensicherheit, den Fragebogen zur Inhaltsbewertung, die Zielgruppe und die Kategorie. Beantworte die Datensicherheitsfragen anhand des tatsächlichen App-Verhaltens: Das Kit erfasst die Konto-E-Mail zur Authentifizierung, speichert Sitzungstokens im sicheren Plattform-Speicher und kommuniziert nur mit deiner konfigurierten API. Ergänze, was dein Produkt darüber hinaus erfasst.

Für eine iOS-App, die eine Anmeldung erfordert, stellen Sie App Review ein funktionierendes Demokonto und Anweisungen in den Überprüfungsnotizen zur Verfügung. Lesen Sie die aktuelle Anmeldedienstregel von Apple und ihre Ausnahmen, bevor Sie sich für soziale Anmeldeoptionen entscheiden. Die Anforderungen hängen vom tatsächlichen Anmeldeablauf der App ab. Die offiziellen Richtlinien sind oben im Abschnitt zur ersten Einreichung verlinkt.

Käufe zuerst hinter RevenueCat absichern

Wenn deine App mobile Käufe anbietet, konfiguriere den enthaltenen RevenueCat-Ablauf: Setze MOBILE_PURCHASES_PROVIDER=revenuecat und EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat und hinterlege den passenden öffentlichen iOS- oder Android-SDK-Schlüssel. Die native App unterstützt Kauf und Wiederherstellung; anschließend wird der Zugriff anhand der serverseitig verifizierten Workspace-Berechtigung aktualisiert. Im mobilen Ablauf wird kein Stripe Checkout verwendet. Halte die Paywall deaktiviert, wenn Käufe ausgeschaltet sind oder erforderliche Einstellungen fehlen. Prüfe konfigurierte Store-Produkte sowie Kauf, Wiederherstellung und Aktualisierung der Berechtigung in einem EAS-Development-Build mit Testkonten der Stores. Prüfe die aktuellen Store-Hinweise für die Anforderungen, die für deine App und Regionen gelten.

Checkliste vor der Einreichung

Bestätigen Sie vor dem Absenden alle unten aufgeführten Punkte mit Ihrer eigenen Test-App und Ihrem eigenen Store-Konto.

android.package und ios.bundleIdentifier wurden in eine Kennung umbenannt, die dir gehört
EXPO_PUBLIC_API_URL verweist in der Build-Umgebung auf die Produktions-API
Datenschutzrichtlinie unter einer öffentlichen URL gehostet und im Store-Eintrag verlinkt
Das Formular zur Datensicherheit entspricht der tatsächlichen Datenerfassung: Auth-E-Mail, API-Verkehr und zusätzliche Erfassung durch dein Produkt
Funktionierende Demo-Konto-Anmeldedaten in den Prüferhinweisen für den App Store
Paywall ausgeblendet oder durch eine verifizierte RevenueCat-Berechtigung abgesichert
Deep-Link-Rückkehr, Sitzungswiederherstellung und Abmeldung auf einem physischen Gerät geprüft
Screenshots und Store-Einträge für jeden Store vorbereitet

Nach einer Ablehnung reagieren

Ablehnungen enthalten einen Verweis auf die Richtlinie. Behebe die angegebene Ursache, statt das Symptom zu erraten. Eine Abweichung bei der Datensicherheit bedeutet meist, dass das Formular falsch ausgefüllt wurde, nicht dass die App sich anders verhält. Eine Ablehnung wegen erforderlicher Anmeldung bedeutet oft, dass in den Prüferhinweisen kein Demo-Konto angegeben war. Reiche die App erneut ein und benenne die Korrektur in den Versionshinweisen klar.

Die vollständige Anleitung – Befehle für Zugangsdaten, Reihenfolge der Konsolenschritte und ein Leitfaden für Ablehnungen – liegt im Repository unter docs/mobile-store-submission.md.

Einrichtung und Konfiguration

Für die Veröffentlichung einer nativen App brauchst du Apple- und/oder Google-Entwicklerkonten, App-IDs, Signaturzugänge und die Store-Prüfung. Das Produktionsprofil von EAS erhöht die Store-Buildnummern automatisch; submit.production sendet einen Entwurf an den internen Track von Google Play. Bundle-IDs und App-Schema stehen in apps/mobile/app.config.ts.

Web-Deployments und Store-Releases folgen unterschiedlichen Zeitplänen. Halte die API mit der ältesten unterstützten App-Version kompatibel oder steuere neue Funktionen über serverseitigen Status.

corepack pnpm --filter @supastack/mobile build
eas build --profile production --platform ios
eas build --profile production --platform android
eas submit --profile production --platform ios
eas submit --profile production --platform android

Implementierungsablauf

Richte vor der Aktivierung nativer Käufe das Projekt, die Store-Produkte und die Berechtigung in RevenueCat ein. Der geheime Schlüssel und der Authorization-Wert des Webhooks gehören ausschließlich in die Serverkonfiguration; die iOS- und Android-SDK-Schlüssel sind öffentliche Build-Werte. Deaktiviere Sandbox-Zugriff in der Produktion.

Verwalte Store-Materialien wie Screenshots, Beschreibung, Datenschutzangaben und Kaufhinweise in den Release-Unterlagen des Produkts. RevenueCat-Käufe und Wiederherstellungen werden anhand des aktuellen Server-Abonnentenstatus geprüft, bevor die App Zugriff anzeigt.

Überprüfung und Fehlerbehebung

Teste genau das Artefakt, das du einreichst: Anmelde-Callback, Sitzungswiederherstellung, Kauf und Wiederherstellung, Aktualisierung der Serverberechtigung, Workspace-Wechsel, Deep Links und Offline-Verhalten auf einem echten Gerät. Ein erfolgreicher lokaler Export ist kein store-fertiger Build.

Notiere Buildnummer, Store-Track, Prüfstatus und die API-Umgebung des jeweiligen Releases. Eine abgelehnte Prüfung ist ein Release-Ereignis: Korrigiere Angaben oder Funktionskennzeichen, statt Änderungen zu erraten.

Nächste Oberfläche: Im Tab Desktop wird dasselbe Produkt in der Tauri-Shell vorgestellt.