App Store Connect vs. Google Play Console: der Veröffentlichungsablauf
Wenn du nur auf einem Store veröffentlichst, lernst du eine Konsole und machst weiter. Auf beiden zu veröffentlichen bedeutet, zwei mentale Modelle im Kopf zu haben, die dieselben Wörter für unterschiedliche Dinge verwenden. „Release", „Review" und „Rollout" bedeuten in App Store Connect jeweils etwas anderes als in der Google Play Console. Dieser Beitrag stellt die beiden Abläufe Stufe für Stufe nebeneinander, damit du einen Launch planen kannst, der ohne Überraschungen auf beiden Stores landet.
Der Ablauf im direkten Vergleich
Fang hier an. Jede Zeile ist eine Stufe auf dem Weg zum Live-Update; die beiden Spalten zeigen, was in jeder Konsole tatsächlich passiert.
| Reine Metadaten-Änderung | Die meisten Listing-Änderungen laufen über eine neue Version durch die Prüfung; nur wenige Felder lassen sich live bearbeiten. | Eine Store-Listing-Änderung, eingereicht und geprüft, ohne einen neuen Build auszuliefern. |
Wie Apple eine Version freigibt
In App Store Connect ist die Arbeitseinheit eine Version. Du hängst einen Build an, füllst Metadaten und Screenshots aus und reichst das Ganze bei der App Review ein. Apple betrachtet das als ein Paket – deshalb bedeutet ein Screenshot-Austausch oder eine Beschreibungsänderung für sich genommen meist eine neue Version und einen weiteren Gang durch die Prüfung.
Sobald die App Review zustimmt, entscheidet deine Release-Option, was passiert. Wähle automatisch, und sie geht sofort live. Wähle manuell, und sie wartet unter „Ausstehende Entwicklerfreigabe" – Apple hat zugestimmt, aber nichts ist öffentlich, bis du selbst auf den Knopf drückst (danach bis zu 24 Stunden einplanen). Wähle geplant, und sie erscheint automatisch zu einem von dir festgelegten Datum und einer Uhrzeit. Du triffst diese Wahl pro Version, jedes Update ist also eine neue Entscheidung.
Für einen schrittweisen Launch aktivierst du Phased Release. Es gilt für automatische Updates bei bestehenden Nutzern und verteilt sie über 7 Tage in steigenden Prozentschritten; du kannst pausieren, wenn in den Zahlen etwas nicht stimmt. Es blockiert keine brandneue App und gilt nicht für manuelle Freigaben – das ist das App-Store-Gegenstück zu Googles gestaffeltem Rollout, kein Halt der gesamten Freigabe.
Wie Google für einen Track freigibt
Google verteilt dieselbe Aufgabe auf Tracks. Ein Build startet auf einem Test-Track – intern, geschlossen oder offen – und wird zur Produktion befördert, sobald du bereit bist. Interner Test ist für eine kleine, vertraute Gruppe (bis zu 100). Geschlossener Test erweitert sich auf eingeladene Listen (bis zu 2.000 pro Liste). Offener Test ist öffentlich mit Opt-in, ohne Obergrenze. Produktion erreicht alle in deinen gewählten Ländern.
Wenn du eine Freigabe auslöst, entspricht Managed Publishing Apples manuellem Halt. Ist es aktiv, sammeln sich geprüfte Änderungen in der Publishing-Übersicht unter „Bereit zum Senden" und gehen erst live, wenn du veröffentlichst – praktisch, um eine Freigabe mit einem Marketingtermin abzustimmen. Ist es deaktiviert, werden geprüfte Änderungen sofort nach Freigabe veröffentlicht.
Für einen schrittweisen Launch nutzt du ein gestaffeltes Rollout: Du gibst die Freigabe an einen Prozentsatz der Nutzer frei und erhöhst diesen selbst über die Zeit, mit der Möglichkeit zu stoppen, wenn Absturzraten steigen. Wie Apples Phased Release gilt es für Updates, nicht für Erstveröffentlichungen – eine brandneue Produktions-Freigabe erreicht alle auf einmal.
Der Unterschied, über den viele stolpern
Das ist der Punkt, den man sich merken sollte: Apple koppelt Metadaten an die Version; Google hält das Store-Listing von der Freigabe getrennt.
Bei Apple sind deine Screenshots, Beschreibung und Keywords Teil der Version, die geprüft wird. Willst du die Screenshots zwischen Builds austauschen? Bei den meisten Feldern bedeutet das eine neue Version und einen weiteren Prüfdurchlauf. Bei Google ist das Store-Listing ein eigenes Objekt – du kannst Text und Grafiken aktualisieren und genau das zur Prüfung einreichen, während das ausgelieferte App-Bundle unverändert bleibt. Zwei Stores, zwei sehr unterschiedliche Antworten auf die Frage: „Kann ich das ohne komplette Freigabe ändern?"
Das fällt besonders ins Gewicht, wenn ein Launch viele bewegliche Teile hat: ein Build, ein Screenshot-Set, lokalisierter Text für Dutzende Märkte. Bei Apple bündelst du das meist alles in eine Version, damit es zusammen geprüft wird. Bei Google kannst du Listing und Freigabe unabhängig voneinander staffeln und in der Reihenfolge veröffentlichen, die zum Plan passt.
Prüfzeiten und die Falle für neue Konten
Apples App Review dauert 2026 für ein übliches Update etwa 24–48 Stunden, länger bei einer Ersteinreichung eines neuen Entwicklers oder bei allem, das eine genauere Prüfung auslöst. Googles Prüfung ist oft schneller – Stunden bis wenige Tage bei einem etablierten Konto –, aber für Neulinge gibt es eine Hürde.
Ein persönliches Google-Play-Entwicklerkonto, das nach Mitte November 2023 erstellt wurde, muss vor dem Antrag auf Produktionszugriff einen geschlossenen Test mit mindestens 12 zugestimmten Testern über 14 zusammenhängende Tage durchlaufen. Fällt die Zahl unter 12, kann die Serie zurückgesetzt werden. Organisationskonten und ältere persönliche Konten überspringen das. Apple hat kein direktes Gegenstück – wenn du also die erste App auf beiden Stores launchst, plane Googles Testfenster von vornherein ein; meistens ist es der längere Weg.
Wo Mokbi ansetzt
Beide Konsolen wollen dieselben fertigen Assets: gerahmte Screenshots und sauberen, lokalisierten Text in jeder erforderlichen Größe. Mokbi baut diese Seite einmal auf. Du gestaltest die Screenshots und entwirfst den Store-Text in einem Projekt, übersetzt beides dann in 50 Sprachen und exportierst einen Satz, der in einem Durchgang zu den Maßen von App Store Connect und Google Play Console passt – so speist dieselbe Arbeit zwei Listings statt zweier getrennter Kraftakte.
Mokbi veröffentlicht sie auch. Es überträgt Listing und Assets direkt über die Play Developer API an Google Play und bereitet die Version in App Store Connect vor, bereit zur Einreichung durch dich. Apple verlangt den finalen Submit- und Prüfschritt persönlich von dir – das ist eine Apple-Regel, keine Einschränkung von Mokbi. So oder so steuerst du die Listing-Updates beider Konsolen von einem Ort aus, mit einem Abo: Der Editor ist kostenlos mit Wasserzeichen, und Solo (€29.99/Monat) oder Studio (€49.99/Monat) schalten unbegrenzten Export und Publishing frei, solange dein Abo läuft.