Alexgub84/store-publishing

Was macht store-publishing?

Dieses Verfahren wurde zuletzt am 08.11.2026 mit der echten Google Play Console und App Store Connect getestet. Beide Konsolen ändern ihre Oberflächen, Feldnamen und Navigation ohne Vorankündigung – wenn ein untenstehender Schritt nicht mit dem übereinstimmt, was Sie sehen, erstellen Sie ein Issue in diesem Repository, anstatt zu raten, und senden Sie einen PR mit der Korrektur, falls Sie eine finden.

0. Entscheiden Sie, welchen Pfad Sie gehen

Situation	Gehe zu
App wurde noch nie eingereicht, kein Eintrag in einer Konsole	§1, dann §2, §3, §4
App ist bereits gelistet, ein neuer Build muss veröffentlicht werden	§5 (der Wiederholungspfad)
Kontofrage (Einzelperson vs. Organisation, Übertragung, Paketname)	§6
Prüfer kann sich nicht anmelden, oder die App wurde abgelehnt	§7

Überall geltende Regel: Jeder Upload benötigt Versionshinweise in jeder Listing-Sprache, in der die App ausgeliefert wird. Lassen Sie niemals ein Feld „Neuerungen“ leer – ein leeres Feld wird von einem Prüfer als ungetesteter Build gewertet.

1. Checkliste für die Ersteinrichtung (beide Stores)

Führen Sie diese in der angegebenen Reihenfolge durch; jeder Schritt entsperrt den nächsten.

1. Entwicklerkonten existieren und sind verifiziert. Die App sollte von dem Konto veröffentlicht werden, das tatsächlich das Produkt besitzt – der Herausgeber der Aufzeichnung, nicht ein gemeinsames oder Agenturkonto, das für nicht zusammenhängende Apps verwendet wird. Apple lehnt insbesondere Apps ab, die wie von einer kommerzialisierten Vorlage oder einem App-Generierungsdienst aussehen, wenn sie unter einem Konto eingereicht werden, das viele nicht zusammenhängende Produkte enthält, und separat (Richtlinie 5.2.1) erwartet Apple, dass der IP-Inhaber derjenige ist, der einreicht. Siehe §6 für die Entscheidung Einzelperson vs. Organisation.
2. Rechtliche Seiten leben auf der Produktionsdomain: eine Datenschutzerklärung, Nutzungsbedingungen und eine Seite zur Kontolöschung, wenn die App eine Registrierung ermöglicht. Beide Stores fragen nach diesen URLs; das Datensicherheitsformular von Google verlinkt die Löschseite direkt. Holen Sie die Zustimmung zum rechtlichen Text von demjenigen ein, der das Produkt besitzt, bevor Sie ihn in einer Einreichung verwenden – es ist eine geschäftliche Entscheidung, keine technische.
3. Ein echtes App-Symbol, kein Framework-Standard – beide Stores lehnen ein unverändertes Standard-Symbol als minderwertig ab oder markieren es als solches. Benötigte Assets: das adaptive/Vordergrund-Symbol im Binärprogramm, ein 512×512 Play-Symbol, ein 1024×500 Play-Feature-Grafik und ein 1024×1024 Apple-Symbol im Asset-Katalog (keine Transparenz – Apple flacht es ab, normalerweise auf Schwarz).
4. Ein Demo-Konto für die Überprüfung, wenn die App eine Anmeldung erfordert. Es benötigt: eine feste Kennung (Telefon, E-Mail oder Benutzername) mit einem festen Einmalcode oder Passwort, der nur für diese Kennung gilt, einen vorbereiteten Demo-Zustand, den der Prüfer tatsächlich testen kann, und keine ausgehenden Nebenwirkungen (keine echten SMS, keine echte Zahlung). Speichern Sie die Anmeldedaten außerhalb der Konsolenseiten selbst – niemals als Klartext in den App-Überprüfungsnotizen, wo sie zu einer dauerhaften, weithin lesbaren Aufzeichnung werden. Überprüfen Sie, ob die Anmeldung gegen den exakten Build, der eingereicht wird, jedes Mal vor der Einreichung funktioniert.
5. Ein Dateninventar: ein Dokument (im Repository, in einem Wiki, wo immer das Team Spezifikationen aufbewahrt), das jeden Datentyp auflistet, den die App sammelt, warum und durch welches SDK. Das Datensicherheitsformular von Google und das App-Datenschutzformular von Apple werden AUS DIESEM DOKUMENT ausgefüllt, niemals aus dem Gedächtnis – und wann immer die App eine neue Berechtigung oder ein neues Analyse-/Diagnose-SDK erhält, ändert sich das Inventar in derselben Änderung, die die Berechtigung hinzufügt, und beide Formulare werden vor der nächsten Einreichung neu erstellt. Eine Diskrepanz zwischen dem, was die Formulare sagen, und dem, was das Binärprogramm tatsächlich tut, ist ein häufiger, vermeidbarer Ablehnungsgrund.
6. Google Play – App erstellen, dann „App einrichten“ von oben nach unten durchgehen: Datenschutzerklärung-URL, App-Zugriff (öffentlich oder eingeschränkt mit dem Überprüfungskonto und Anweisungen), Werbeerklärung, Fragebogen zur Altersfreigabe (wahrheitsgemäß aus dem tatsächlichen Verhalten der App beantwortet), Zielgruppe und Alter, Erklärung zu Regierungs-Apps, Erklärung zu Finanzfunktionen, Gesundheitserklärung, Datensicherheit (aus dem Inventar), Werbe-ID-Erklärung. Play App Signing akzeptieren, damit Google den App-Signaturschlüssel hält und der Upload-Schlüssel ersetzbar bleibt. Den Haupt-Store-Eintrag ausfüllen (Name, Beschreibungen, Symbol, Feature-Grafik, mindestens 2 Telefon-Screenshots). Dann einen geschlossenen Testtrack und ein Release erstellen, bevor die Produktion berührt wird.
7. Apple – die explizite App ID registrieren, den App-Eintrag in App Store Connect erstellen (Name, SKU, primäre Sprache), App-Informationen ausfüllen (Kategorie, Inhaltsrechte, Altersfreigabe), App-Datenschutz (aus dem Inventar), Preise und Verfügbarkeit, die Versionsseite (Screenshots, Beschreibung, Schlüsselwörter ≤100 Zeichen, Support-URL, Urheberrecht), App-Überprüfungsinformationen (Anmeldeanweisungen falls erforderlich, Überprüfungskontakt, Notizen) und eine Veröffentlichungsoption auswählen (manuelle Veröffentlichung ist die sicherere Standardeinstellung – sie legt die Entscheidung „Live gehen“ in einen separaten, bewussten Klick nach der Genehmigung). Für TestFlight-Builds entweder die Export-Compliance-Frage jedes Mal beantworten oder ITSAppUsesNonExemptEncryption=false einmal zur Info.plist hinzufügen, wenn das zutrifft, um die Frage nicht wiederkehren zu lassen.
8. Beide frühzeitig einreichen. Die Überprüfung dauert Stunden bis Tage in jedem Store, und die erste Überprüfung ist normalerweise der Zeitpunkt, an dem die eigentlichen Probleme auftauchen – planen Sie mindestens eine Ablehnung und eine erneute Einreichung ein, insbesondere bei Apple.

2. Erstellen des Release-Pakets

Unabhängig von der Toolchain – Flutter, React Native, Expo oder ein natives Swift/Kotlin-Projekt – bauen Sie aus einem sauberen Checkout des exakten Commits, der veröffentlicht wird, niemals aus einem Arbeitsverzeichnis mit nicht committeten Änderungen. Nicht committete Änderungen, die in ein Store-Binärprogramm gelangen, sind im Nachhinein sehr schwer zu bemerken.

• Android: Erstellen Sie ein signiertes Release-AAB (niemals ein APK für einen Store-Upload), mit einer Build-Nummer (versionCode oder Äquivalent), die streng höher ist als die zuletzt ausgelieferte. Überprüfen Sie, ob der im Bundle eingebettete Paketname mit dem des Ziel-Play-Kontos übereinstimmt, bevor Sie hochladen – ein nicht übereinstimmender Paketname führt beim Upload zu einem Fehler.
• iOS: Archivieren und exportieren (oder direkt von der Archivierungsstufe an App Store Connect hochladen), signiert unter der richtigen Apple Developer Program-Mitgliedschaft (dem „Team“, zu dem die Zertifikate der App und der App-Eintrag gehören), mit einer Build-Nummer, die streng höher ist als die zuletzt ausgelieferte, und der exakten Bundle-Kennung, mit der der App Store Connect-Eintrag erstellt wurde. Automatische Signierung unter dem richtigen Team vermeidet die meisten Zertifikatsprobleme.
• Beide: Richten Sie den Build auf die Produktions-API/Backend aus, nicht auf ein Staging- oder lokales – überprüfen Sie, ob dies tatsächlich im Binärprogramm fest codiert ist, nicht nur als Build-Flag übergeben wird, das möglicherweise stillschweigend auf einen Standardwert zurückfällt. Halten Sie iOS und Android auf derselben Build-/Versionsnummer, wenn das Produkt eine gemeinsame Versionszeichenfolge hat, damit ein Support-Gespräch über „Version 2.3“ auf beiden Plattformen dasselbe bedeutet.

3. Screenshots

Nur echte Aufnahmen – Apples Richtlinie 2.3.3 lehnt explizit Mockups und Marketing-Composites ab, die als Screenshots präsentiert werden. Das zuverlässige Muster ist ein automatisierter UI-Test, der die eigentliche App ausführt, sich mit dem Überprüfungskonto gegen ein echtes (nicht gemocktes) Backend anmeldet, zu jedem Bildschirm navigiert und das Bild aufnimmt – niemals ein Handyfoto eines Simulators.

Typische zu unterstützende Gerätegrößen (überprüfen Sie vorher die aktuellen Store-Anforderungen, diese ändern sich): ein großes modernes iPhone (Apples aktuelle „größte“ Anforderung), ein iPad, wenn die App iPad unterstützt, und ein repräsentatives Android-Telefon und/oder -Tablet für Play. Apple leitet in den meisten Fällen kleinere iPhone-Größen automatisch aus dem größten Satz ab.

Wählen Sie einen kleinen Satz (5-8 Bilder), der die Geschichte des Produkts in der richtigen Reihenfolge erzählt: eine Listen- oder Startansicht, einen zentralen Strukturbildschirm, eine einzelne Einheit/Detailansicht, den Hauptworkflow in Bearbeitung, einen abgeschlossenen/Erfolgszustand und gegebenenfalls Einstellungen. Überspringen Sie reine Anmeldebildschirme und leere Zustände – sie sagen nichts darüber aus, was die App tut.

Bekannte Fallstricke, toolchain-unabhängig:

• Ein Debug-Build zeigt oft ein sichtbares Debug-Band oder Wasserzeichen – schalten Sie es vor der Aufnahme aus.
• Eine Simulator- oder Emulatorsitzung kann einen vorherigen Login über Neuinstallationen hinweg beibehalten; melden Sie sich explizit innerhalb des Tests ab oder löschen Sie zuerst den Simulator-/Emulatorzustand.
• Das erneute Navigieren zum „selben“ Bildschirm mit unterschiedlichen Parametern rendert einen zustandsbehafteten Bildschirm manchmal nicht sauber neu; navigieren Sie zwischen den Aufnahmen durch einen übergeordneten Bildschirm.
• Das gleichzeitige Ausführen von zwei Aufnahmesitzungen aus demselben Projektverzeichnis führt tendenziell zu Konflikten bei generierten Build-Artefakten; verwenden Sie separate Arbeitskopien, wenn Sie parallel arbeiten.

4. Update-Flow (App bereits gelistet)

Siehe §5 für die dedizierte Wiederholungs-Release-Checkliste. Die Kurzversion: Ein neuer Build erhält eine streng höhere Build-Nummer als der zuletzt ausgelieferte, das Dateninventar-Diff seit dem letzten Release entscheidet, ob die Datenschutzformulare aktualisiert werden müssen, Versionshinweise werden nie übersprungen, und das Demo-Konto für die Überprüfung wird vor jeder Einreichung auf der exakten Umgebung, auf die das neue Binärprogramm verweist, erneut verifiziert.

5. Der Wiederholungspfad – ein Release, wenn die App bereits live ist

Ein Release = ein Durchlauf durch diese Liste, von oben nach unten.

Vorbedingungen (stoppen, wenn eine davon fehlschlägt)

• Der ausgelieferte Code wird tatsächlich in der Produktion bereitgestellt, wobei alle Datenbankmigrationen bereits angewendet wurden – ein Deploy und eine Migration sind nicht derselbe Schritt, und das Bereitstellen vor der Migration (oder gar nicht Migrieren) erzeugt einen Build, der mit einem Backend kommuniziert, das nicht dafür bereit ist.
• Das Demo-Konto für die Überprüfung meldet sich gegen die Produktion an und erreicht den Demo-Zustand, den ein Prüfer sehen müsste.
• Das Dateninventar-Diff seit dem letzten ausgelieferten Build wird überprüft. Jede neue Zeile bedeutet, dass sich die Datenschutzformulare VOR der Einreichung ändern, nicht erst, nachdem eine Ablehnung darauf hinweist.
• Apples Version-Slot ist frei. Wenn eine vorherige Version auf „Ausstehende Entwicklerveröffentlichung“ oder noch in Überprüfung sitzt, lässt App Store Connect Sie die nächste Versionszeile überhaupt nicht erstellen. Veröffentlichen oder stornieren Sie die ausstehende zuerst – es gibt keine Option „Halten Sie diese, reichen Sie stattdessen den neueren Build ein“.
• Die Versionszeichenfolge und Build-Nummer sind festgelegt: Build-Nummer = letzte ausgelieferte + 1 auf jeder Plattform; die Versionszeichenfolge wird nur erhöht, wenn eine Änderung vorliegt, die ein Benutzer tatsächlich bemerken würde.

Versionshinweise

Schreiben Sie sie basierend auf dem, was tatsächlich ausgeliefert wurde (die zusammengeführten Änderungen seit dem letzten Release), nur für den Benutzer sichtbare Elemente, etwa 4-8 Aufzählungspunkte, in jeder Sprache, die das Listing unterstützt – überprüfen Sie, was das Listing tatsächlich hat, bevor Sie mehrere Sprachen annehmen; ein Listing mit nur einer Sprache lehnt ein Feld für Versionshinweise für eine Sprache ab, die es nicht hat. Bei Apple ist das Hinzufügen einer ganzen neuen Sprache zu einem Listing ein eigenes Projekt (Name, Untertitel, Beschreibung, Schlüsselwörter und ein eigener Screenshot-Satz) – gehen Sie niemals davon aus, dass es nur eine Textfeldänderung ist.

Screenshots

Erstellen Sie sie nur neu, wenn sich die Bildschirme tatsächlich auf eine Weise geändert haben, die ein Käufer bemerken würde. Ansonsten lassen Sie den vorhandenen Satz unverändert. Wenn Sie sie ersetzen, ersetzen Sie den gesamten Satz in derselben Reihenfolge wie zuvor, anstatt anzuhängen – die meisten Konsolen begrenzen die Anzahl der Screenshots pro Listing, daher riskiert ein teilweiser Austausch, diese Grenze zu erreichen.

Konsolen

Google Play: Wenn sich das Inventar geändert hat, aktualisieren Sie zuerst das Datensicherheitsformular. Dann: den relevanten Test- oder Produktionstrack → ein neues Release erstellen → das AAB hochladen → Versionshinweise in jeder konfigurierten Sprache → das Release überprüfen → die Einführung starten (behandeln Sie „Einführung starten“ als bewusste, bestätigte Aktion – es ist der eine irreversible Klick im Play-Ablauf). Eine Produktionseinführung kann prozentual gestaffelt und pausiert werden, wenn nach einigen Prozent etwas falsch aussieht.

Apple App Store Connect: Den neuen Build zuerst an TestFlight anhängen (Export-Compliance, „Was zu testen“), dann entweder die bestehende Versionsseite bearbeiten (wenn sich die Versionszeichenfolge nicht geändert hat und die vorherige Version noch nicht veröffentlicht wurde) oder eine neue Version erstellen (nur möglich, wenn derzeit keine Version auf „Für Einreichung vorbereiten“ geparkt ist – siehe die Vorbedingung oben). Überprüfen Sie erneut, ob die App-Überprüfungsinformationen noch korrekt sind, überprüfen Sie erneut den App-Datenschutz, wenn sich das Inventar geändert hat, wählen Sie den neuen Build aus, füllen Sie „Neuerungen“ aus und reichen Sie zur Überprüfung ein. Behandeln Sie „Zur Überprüfung einreichen“ genauso wie Plays Einführungsklick – eine bewusste, bestätigte Aktion, nichts, was automatisch ausgelöst wird.

Aufzeichnung

Welche Aufzeichnungen das Team auch immer für Releases hat (ein Changelog, ein Release-Issue, eine Tabelle), sollte Folgendes enthalten: die ausgelieferten Versionen und Build-Nummern, Upload-Zeiten, welcher Track/welche Phase, wer die Einführung oder Einreichung bestätigt hat, und das Überprüfungsergebnis, sobald es bekannt ist. Erhöhen Sie die eigene Versionsdatei des Projekts, um der tatsächlich ausgelieferten Version zu entsprechen – eine Abweichung hier ist genau der Grund, warum das nächste Release versehentlich eine Build-Nummer wiederverwendet.

Niemals eine vorbereitete Version parken

Eine Version, die auf „Für Einreichung vorbereiten“ in App Store Connect sitzt, hält den einzigen verfügbaren Version-Slot – es kann keine neue Version darunter erstellt werden. Also: Entscheiden Sie das Schicksal einer vorbereiteten Version in derselben Sitzung, in der sie vorbereitet wird. Reichen Sie sie entweder ein oder erstellen Sie die Zeile noch nicht.

Wenn ein neuerer Build bereit ist, während eine ältere vorbereitete Version noch geparkt ist, löschen Sie die geparkte Zeile nicht und reichen Sie den veralteten Build nicht nur ein, um den Slot freizumachen. Während eine Version auf „Für Einreichung vorbereiten“ sitzt, ist ihre Versionszeichenfolge noch ein bearbeitbares Feld – rollen Sie sie an Ort und Stelle vor: Ändern Sie die Versionszeichenfolge auf die neue, hängen Sie den neuen Build an, ersetzen Sie „Neuerungen“. Screenshots, Überprüfungsnotizen und Datenschutzantworten werden übernommen, daher ist nichts Vorbereitetes verschwendet.

Ein Tester-Build (TestFlight) und eine öffentliche Einreichung sind unabhängige Entscheidungen – TestFlights interner Testtrack benötigt insbesondere keine Überprüfung und keine Versionszeile, daher ist „Tester brauchen heute einen Build“ nie ein Grund, warum eine öffentliche Einreichung warten muss, und eine ausstehende öffentliche Einreichung ist nie ein Grund, warum Tester warten müssen.

6. Konten, Übertragungen, Paketnamen

• Ein persönliches Google Play-Entwicklerkonto, das nach dem Richtlinien-Stichtag erstellt wurde (derzeit 13. November 2023 – überprüfen Sie die aktuellen Richtlinien), muss einen geschlossenen Test mit mindestens ...