So änderst du App-Store-Screenshots ohne neue App-Version
Du willst die Screenshots einer bereits veröffentlichten App heute austauschen, öffnest App Store Connect, und die Screenshot-Felder der aktuellen Version sind schreibgeschützt. Das ist Absicht, kein Bug. Screenshots sind Teil der Metadaten einer Version, und sobald eine Version genehmigt und veröffentlicht ist, sind ihre Metadaten eingefroren. Hier sind die Wege, die wirklich ändern, was Nutzer sehen, und was jeder davon an Build-Uploads und Review-Zeit kostet.
Warum die Felder gesperrt sind
App Store Connect speichert Screenshots pro App-Version. Ist deine App live, befindet sich diese Version im Status "released", und Screenshots, Beschreibung und Keywords sind gesperrt. Um irgendetwas davon zu bearbeiten, arbeitest du an einem separaten, bearbeitbaren Versionsdatensatz im Status "Prepare for Submission". Der Live-Eintrag zeigt weiterhin die alten Screenshots, bis eine neue Version genehmigt und darüber veröffentlicht wird.
Apples eigene Dokumentation sagt es unumwunden: Ist deine App eingereicht und genehmigt, musst du eine neue Version anlegen, um die Screenshots zu aktualisieren. Die Frage lautet also nicht "Kann ich die Live-Version bearbeiten" (nein), sondern "Welcher Mechanismus bringt die kleinste, schnellste Änderung".
Weg 1: ein neuer Versionsdatensatz (der Standard)
Das ist der Weg, den die meisten Entwickler bereits kennen. In App Store Connect legst du eine neue Version an, öffnest den bearbeitbaren "Prepare for Submission"-Datensatz, ersetzt die Screenshots und reichst sie zur Prüfung ein. Wichtiges Detail: Du musst kein neues Feature oder Bugfix ausliefern, aber es muss ein Build an die Version angehängt sein.
App Store Connect bietet dir im Build-Picker der neuen Version nicht den Build an, der gerade live ist. In der Praxis machst du also eines von zwei Dingen: einen anderen bereits hochgeladenen Build wählen (ein Überbleibsel aus einem früheren TestFlight-Upload funktioniert) oder ein frisches Binary mit demselben Quellcode und einer erhöhten Build-Nummer hochladen. Keins von beidem bringt neue Funktionen. Aber ein Build muss vorhanden sein, und die ganze Version, Screenshots inklusive, durchläuft die App Review. Die neuen Screenshots erscheinen erst, nachdem diese Version genehmigt und veröffentlicht ist.
Nutze diesen Weg, wenn du ohnehin mehr als Screenshots änderst, etwa eine neue Beschreibung und Keyword-Set zusätzlich zu den Bildern, da alles in derselben Einreichung mitlaufen kann.
Weg 2: Product Page Optimization (keine neue Version, kein neuer Build)
Product Page Optimization (PPO) ist Apples eingebautes A/B-Testing-Feature und zugleich der einzige Weg, Screenshots und Vorschau-Videos ganz ohne neue Version und ohne neuen Build zu ändern. Du erstellst einen Test, fügst eine Variante mit deinen neuen Screenshots hinzu und reichst diese Variante ein. Apple sagt ausdrücklich, dass diese Metadaten ohne Einreichung einer neuen App-Version übermittelt werden können.
Der Haken, der das Ganze ehrlich hält: Die neuen Inhalte durchlaufen trotzdem die App Review, bevor der Test starten kann. Die einzige Ausnahme ist das Neuanordnen bereits genehmigter, im Store befindlicher Screenshots, das braucht keine neue Prüfung. Alles wirklich Neue wird zuerst begutachtet.
PPO ist als Experiment angelegt, deshalb kommen die Ergebnisse als geschätzte Conversion-Steigerung zurück, ein Prozentwert gegenüber deiner aktuellen Seite mit einer Konfidenzangabe zu den Daten. Willst du die neuen Screenshots einfach für alle live schalten statt einen gemessenen Test zu fahren, kannst du den Test erstellen, laufen lassen und dann die Gewinner-Variante auf deine Standard-Produktseite anwenden. Das Anwenden einer Variante beendet den Test und bringt diese Inhalte zu jedem Nutzer, weiterhin ganz ohne Binary-Upload.
Eine Grenze, die man klar benennen sollte: Screenshots und Vorschau-Videos sind über PPO build-frei, alternative App-Icons dagegen nicht. Ein Icon muss in das Binary kompiliert werden, das bereits im Store liegt, ein wirklich neues Icon braucht also weiterhin einen Build. Halte Icons aus einem build-freien Screenshot-Tausch heraus.
Weg 3: Custom Product Pages für gezielte Varianten
Willst du für eine bestimmte Zielgruppe oder Ad-Kampagne ein anderes Screenshot-Set statt einer Änderung an deinem Haupteintrag, erlauben dir Custom Product Pages, alternative Versionen unter eigenen URLs zu veröffentlichen. Jede Variante wird separat geprüft und über einen Link erreicht, dein Standard-Eintrag bleibt unangetastet. Das ist eher ein Targeting-Werkzeug als ein "Live-Eintrag ändern"-Werkzeug, gehört aber auf die Landkarte, wenn du entscheidest, wie du Screenshots ohne komplette App-Veröffentlichung bewegst.
Das eine Feld, das du jederzeit ändern kannst: Werbetext
Der Werbetext ist das einzige App-Store-Feld, das du ohne neue Version und ohne App Review bearbeiten kannst. Er ist ein 170-Zeichen-Block oben in deiner Beschreibung, Änderungen werden von selbst innerhalb weniger Stunden ausgerollt (Apple räumt dafür bis zu 48 Stunden ein). Er wird nicht für das Keyword-Ranking indexiert, verschiebt also deine Suchposition nicht, ist aber der richtige Ort für eine zeitkritische Zeile, während eine Screenshot-Änderung noch in der Prüfung steckt.
Weg für Weg: Build und Review auf einen Blick
Welchen Weg du wählen solltest
- Nur Screenshots austauschen, schnellster Weg. Product Page Optimization. Kein Build, eine Prüfung der neuen Inhalte, dann die Variante anwenden und sie ist für alle live.
- Screenshots plus Text oder Keywords ändern. Neuer Versionsdatensatz, damit das ganze Update in einer Einreichung läuft.
- Andere Bilder für eine Kampagne, nicht die Hauptseite. Custom Product Page.
- Eine Zeile, die in der nächsten Stunde live sein muss. Werbetext, während die eigentliche Screenshot-Änderung geprüft wird.
Wo Mokbi ins Spiel kommt
Mokbi erledigt die gesamte Screenshot-Auffrischung von Anfang bis Ende. Es gestaltet die neuen Screenshots und die Google-Play-Feature-Grafik, schreibt dann den kompletten Eintrag, Titel, Untertitel, Beschreibung und Werbetext, und übersetzt alles in einem Durchgang in 50 Sprachen. Genau das bremst normalerweise eine Screenshot-Auffrischung, und Mokbi erledigt es in einem einzigen Ablauf.
Danach veröffentlicht es. Mokbi bringt den Eintrag und die fertigen Assets direkt über die Play Developer API zu Google Play, wo sie sofort live gehen, und stellt alles in App Store Connect bereit, fertig zum Einreichen. Apple verlangt, dass der finale Submit-Schritt und die App Review über dein eigenes Konto laufen, dieser eine Klick bleibt also bei dir, aber die Inhalte und die Texte liegen bereits fertig da, in jeder Sprache, in einer neuen Version oder einem Product-Page-Optimization-Test, sobald du die Konsole öffnest.