Was du ohne neue App-Version ändern kannst: Apple vs. Google
Bevor du einen Store-Eintrag anfasst, lohnt sich eine Frage: Kostet mich diese Änderung eine komplette Einreichung, oder kann sie leise rausgehen? Liegst du falsch, sitzt du entweder in einer Review-Warteschlange, die du nicht eingeplant hattest, oder du denkst, eine Änderung sei live, während sie noch auf Freigabe wartet. Die beiden Stores beantworten diese Frage genau entgegengesetzt — und dieser Unterschied ist der ganze Grund, warum es so nervig ist, Listings auf beiden Plattformen synchron zu halten.
Hier kommt die ehrliche Feld-für-Feld-Version — angefangen bei der Matrix, dann die Logik hinter den Regeln jedes Stores, damit du auch die Fälle vorhersehen kannst, die diese Tabelle nicht abdeckt.
Die Matrix
Jedes gängige Listing-Feld und was jeder Store bei einer Änderung verlangt. „Neue Version / neues Release“ heißt: Der Store behandelt die Änderung als Teil einer Einreichung, die du absenden musst; „geprüft“ heißt: Ein Mensch oder ein automatischer Check läuft, bevor es live geht.
| App-Icon | Das Haupt-Icon steckt im Binary — eine Änderung braucht einen neuen Build. Wird mit diesem Build geprüft. | Das Store-Icon ist ein Listing-Asset. Kein neues Release nötig. Wird geprüft. |
Zwei Dinge fallen sofort auf. Apple leitet fast alles über einen Versionseintrag. Google lässt den kompletten Listing-Eintrag sich unabhängig bewegen. Keiner der beiden Stores überspringt die Prüfung bei Assets, die zählen — das Wort „geprüft“ taucht in fast jeder Zelle auf. Die eigentliche Frage lautet also selten „wird das geprüft“, sondern „zieht diese Änderung eine Einreichung mit sich“.
Apple: Ein neuer Versionseintrag ist nicht dasselbe wie ein neuer Build
Das ist die Unterscheidung, über die die meisten stolpern. Im App Store erzeugt das Bearbeiten von Screenshots, Name, Untertitel, Keyword-Feld oder Beschreibung eine neue Version deines Listings. Das klingt, als müsstest du zurück zu Xcode. Ist es aber nicht. Apple übernimmt deine aktuellen Metadaten automatisch in die neue Version, und eine reine Metadaten-Änderung braucht keinen neuen App-Code — du hängst einen Build an (App Store Connect verlangt trotzdem einen an der Version) und änderst nichts daran, was die App tatsächlich tut. Du bearbeitest die anstehenden Felder, reichst ein, und ein Review-Zyklus deckt alles ab.
„Kein neuer Code, aber trotzdem geprüft“ ist also die korrekte Merkregel. Kein Kompilierschritt, keine neuen Funktionen — aber die Änderung landet trotzdem in der App Review und wartet, bis sie an der Reihe ist, bevor sie öffentlich wird. Bündle deine Änderungen: Weil ein einzelner Versionseintrag neue Screenshots, eine überarbeitete Beschreibung, einen neuen Untertitel und aktualisierte Keywords gleichzeitig enthalten kann, gibt es keinen Grund, für jedes davon einen eigenen Review-Zyklus zu verbrauchen.
Das App-Icon ist die Ausnahme, die einen Build braucht. Dein primäres Icon steckt fest im Binary und wird daraus gezeichnet — ein wirklich neues Icon bedeutet also einen neuen Build. Dasselbe gilt für alternative Icons: Sie müssen in der App gebündelt sein, um nutzbar zu sein, deshalb ist das Hinzufügen eines neuen Icons ein Build, keine Listing-Änderung.
Die zwei Apple-Hintertüren
Werbetext. Das ist das einzige Feld, das du ohne Version und ohne Prüfung ändern kannst. Er umfasst 170 Zeichen, steht über der Beschreibung und aktualisiert sich, wann immer du willst — praktisch für eine Aktion, eine Launch-Notiz oder zeitkritische Texte. Er beeinflusst das Suchranking nicht und ist Teil keiner Einreichung — genau deshalb ist er das schnellste Feld im Store, das man ändern kann. Wenn heute noch etwas live sein muss, ist das dein Feld.
Product Page Optimization. Mit PPO testest du bis zu drei Varianten deiner Screenshots, App Previews und deines Icons gegen deine aktuelle Produktseite — ohne eine neue App-Version auszuliefern. Das kommt dem am nächsten, was Apple außerhalb einer normalen Einreichung an visuellen Änderungen zulässt. Zwei Einschränkungen halten das ehrlich: Die Testvarianten-Metadaten müssen trotzdem freigegeben werden, bevor der Test läuft (also geprüft, nicht sofort), und jedes Icon, das du testen willst, muss bereits Teil des aktuellen App-Binarys sein. PPO ändert, was Besucher sehen — es überspringt keine Prüfung.
Google Play: Listing veröffentlichen ohne Release
Bei Play läuft es andersrum. Dein Store-Eintrag — Titel, Kurzbeschreibung, ausführliche Beschreibung, Screenshots, Feature-Grafik, Icon, Promo-Video — lässt sich eigenständig bearbeiten und veröffentlichen, ganz ohne neuen App-Release. Du nimmst die Änderungen vor, und sie erscheinen in der Publishing-Übersicht als „bereit zur Prüfung einreichen“. Du reichst sie ein, sie durchlaufen Googles Prüfung und gehen live — unabhängig von jedem Build.
Ein paar Dinge sollte man präzise halten, um das nicht zu überzeichnen. Die Änderungen werden trotzdem geprüft — Plays Review läuft auch bei Listing-Änderungen, und Elemente wie App-Name und Icon werden geprüft, es ist also kein stiller Sofort-Austausch. Und der Listing-Eintrag kann nicht losgelöst von einer veröffentlichten App existieren: Play verlangt, dass die App schon mindestens ein Release hatte, bevor es einen öffentlichen Eintrag zum Bearbeiten gibt. Du kannst keine eigenständige Store-Seite für etwas veröffentlichen, das nie veröffentlicht wurde. Managed Publishing bringt noch eine Feinheit ins Spiel — ist es aktiviert, warten freigegebene Änderungen, bis du sie aktiv veröffentlichst, was eine Funktion ist, keine Verzögerung, sobald du damit rechnest.
Die Asymmetrie — und warum sie dich Zeit kostet
Stellt man die beiden Modelle nebeneinander, ist der Bruch klar. Apple bindet fast jede Text- und Bildänderung an einen Versionseintrag und eine Prüfung, mit Werbetext und PPO als einzigen Umwegen. Google entkoppelt den Listing-Eintrag komplett vom Release, prüft die Änderungen und liefert sie nach eigenem Zeitplan aus, solange die App bereits existiert.
Diese Asymmetrie kostet leise Zeit, wenn du beide Stores bespielst. Dieselbe Screenshot-Auffrischung ist auf dem einen Store eine Versions-Einreichung und auf dem anderen ein eigenständiges Listing-Update. Eine neu geschriebene Beschreibung ist bei Apple eine geprüfte Version und bei Google eine geprüfte Listing-Änderung. Der Inhalt ist derselbe, die Mechanik nicht — aus einer einzigen Aktion bei Play wird bei Apple eine andere Aktion. Und leicht liefert man das eine aus und vergisst das andere, oder man denkt, etwas sei bei Apple schon live, während es noch in der Prüfung steckt.
Wo Mokbi ins Spiel kommt
Diese Asymmetrie zwischen den Stores ist der ganze Grund, warum sich ein Publishing-Tool lohnt. Mokbi hat als Screenshot-Editor angefangen, aber ein Listing ist Text und Bilder zusammen — also gestaltet es das Screenshot-Set und entwirft den Listing-Text für beide Stores an einem Ort: App-Store-Name, Untertitel, Keyword-Feld und Beschreibung; Play-Titel, Kurzbeschreibung und ausführliche Beschreibung. Du bekommst genau die Felder, die jeder Store tatsächlich indexiert, passend für diesen Store — statt eines einzigen Textblocks, den du zweimal einfügst.
Anschließend übersetzt es den kompletten Listing-Eintrag — Screenshots und Text — in 50 Sprachen, sodass eine Änderung, die du einmal machst, im richtigen Feld in jedem Markt landet, statt in einem sonst überall lokalisierten Listing auf Englisch stehen zu bleiben. Und es veröffentlicht: Mokbi spielt den fertigen Listing-Eintrag direkt über die Play Developer API zu Google Play und stellt ihn in App Store Connect zum Einreichen bereit — Apple verlangt auf seiner Seite weiterhin den finalen Submit- und Review-Schritt, das ist eine Apple-Regel und genau die Asymmetrie zwischen den Stores, um die es in diesem ganzen Beitrag geht. Genau bei dieser letzten Prüfung beginnen auch die Uhren aus diesem Beitrag zu ticken.