Ihre Release-Checkliste deckt Build und Signierung ab, aber niemand weiß, welche Produktseiten-Screenshots für iPhone Duo fehlen.

Schnellste Lösung: Erfassen Sie jetzt Ihre Apps, Sprachen und Screenshot-Verantwortlichen, und nehmen Sie die Prüfung in Ihre Einreichungsfreigabe auf. Die Anforderung gilt ab April 2027; allein deshalb müssen Sie weder Ihre CI-Plattform noch Ihren Mac-Knoten wechseln. Apple nennt April 2027 als Starttermin für die neue Screenshot-Anforderung.

Dieser Leitfaden ist für Sie gedacht, wenn Sie iOS-Veröffentlichungen und App-Store-Connect-Materialien verantworten.
Als CI-Verantwortliche oder CI-Verantwortlicher erfahren Sie, welche Screenshot-Prüfungen sich automatisieren lassen.
Wenn Sie mehrere Apps betreuen, erhalten Sie einen Ablauf, mit dem Zuständigkeiten und Nachweise sichtbar bleiben.

Zuletzt aktualisiert am 13.10.2026. Geprüft anhand der App-Store-Connect-Veröffentlichungshinweise und der offiziellen Screenshot-Spezifikationen.

Zeitplan: angekündigte Vorgabe statt sofortiger Einreichungssperre

Die Ankündigung ist Anlass für eine geplante Prozessänderung, nicht für einen ungeprüften Umbau Ihrer Build-Infrastruktur. Apple gibt an, dass die Anforderung ab April 2027 für eingereichte Apps oder Spiele gilt. Behandeln Sie den Termin daher als Release-Meilenstein und halten Sie ihn getrennt von heute bereits geltenden Prüfbedingungen fest. Die Apple-Ankündigung ist die maßgebliche Stelle für den Status.

Wichtig ist die Abgrenzung: Ein Screenshot für eine Produktseite ist ein Einreichungsasset. Er ersetzt keinen Nachweis, dass Ihre App auf einem Gerät korrekt funktioniert. Umgekehrt belegt ein erfolgreicher Geräte- oder Simulatorlauf nicht, dass das benötigte Seitenmaterial vollständig ist. Wenn Sie beides in einem einzigen Statusfeld führen, können Teams einen grünen Kompatibilitätstest fälschlich als abgeschlossene Asset-Prüfung interpretieren.

Zeitpunkt oder Prüfpunkt Was Sie festhalten Was daraus nicht folgt
Jetzt, vor der Umstellung Apps, Sprachen, Produktseiten und vorhandene Screenshots erfassen Dass die neue Vorgabe bereits gilt
Vor der Asset-Produktion Aktuelle offizielle Spezifikationen für iPhone Duo prüfen Dass eine ältere Screenshotdatei automatisch genügt
Ab April 2027 Die angekündigte Anforderung bei betroffenen Einreichungen berücksichtigen Dass Ihre CI-Plattform ausgetauscht werden muss
Vor einer breiteren Einführung Einen vollständigen Veröffentlichungsablauf pilotieren und dokumentieren Dass ein grüner CI-Check die Annahme durch App Store Connect garantiert

Die Tabelle ist ein Planungsrahmen, kein Ersatz für Apples aktuelle Vorgaben. Prüfen Sie die offiziellen Seiten erneut, wenn Apple den Anwendungsbereich, die Frist oder die Spezifikationen ändert. Notieren Sie in Ihrem internen Release-Kalender außerdem, ob ein Datum aus einer offiziellen Quelle stammt oder lediglich Ihr eigener Vorlauf für Produktion und Review ist.

Achtung: Setzen Sie April 2027 nicht als pauschale Aussage „ab sofort erforderlich“ in interne Tickets oder Release-Vorlagen. Halten Sie die angekündigte Gültigkeit und den Zeitpunkt Ihrer internen Vorbereitung als getrennte Felder fest.

Vor dem ersten Export: Welche Anwendungen und Sprachen sind betroffen?

Bevor Sie Dateien produzieren, sollten Sie wissen, für welche Produkte und Produktseiten sie gebraucht werden. In Teams mit mehreren Apps steckt der Aufwand oft nicht im ersten Screenshot, sondern in der fehlenden Übersicht: Eine Sprache hat aktuelle Assets, eine andere wurde seit mehreren Releases nicht geprüft, und niemand kann erkennen, ob die Datei zum vorgesehenen App-Stand gehört.

Legen Sie dafür ein Inventar an, das mindestens diese Zuordnung ermöglicht:

Inventarfeld Eintrag, den Sie pflegen Warum die Zuordnung zählt
Anwendung und Produktseite App-Kennung beziehungsweise interne Release-Bezeichnung Verhindert, dass Material einer anderen App zugeordnet wird
Sprache und Markt Geplante Sprachversion der Seite Macht Lücken zwischen lokalisierten Seiten sichtbar
Plattformanforderung iPhone Duo als eigener Prüfpunkt Trennt diese Anforderung von anderen Gerätegrößen
Asset-Stand Vorhanden, zu erneuern oder noch zu erstellen Zeigt den tatsächlichen Arbeitsvorrat
Zuständigkeit Produkt, Design, QA oder Release-Team Vermeidet ungeklärte Übergaben
Freigabe und Version Quelle, App-Version und Prüfstatus Erleichtert Rückfragen und spätere Nachweise

Verwechseln Sie den offiziellen Geltungsbereich nicht mit Ihrer internen Planung. Apple beschreibt die neue Anforderung für eingereichte Apps oder Spiele; welche Ihrer Anwendungen tatsächlich betroffen sind und wann Sie die zugehörige Produktseite vorbereiten, sollten Sie anhand Ihrer Veröffentlichungspipeline prüfen. Ein Unternehmen kann freiwillig früher testen, sollte diesen Vorlauf aber als interne Maßnahme kennzeichnen – nicht als von Apple bereits durchgesetzte Sperre.

Für die Priorisierung genügt zunächst eine Liste der betroffenen Anwendungen und Sprachen mit einer verantwortlichen Person je Lücke. Erstellen Sie nicht sofort für jeden denkbaren Fall einen komplexen Workflow. Entscheidend ist, dass Sie zwischen „Asset fehlt“, „Asset vorhanden, aber ungeprüft“ und „für den aktuellen Release freigegeben“ unterscheiden können.

Vor der Produktion: App-Store-Connect-Spezifikationen mit dem Motiv abgleichen

Bei den App-Store-Connect-Screenshot-Spezifikationen zählt nicht allein, ob eine Bilddatei technisch lesbar ist. Prüfen Sie die Anforderungen, die Apple für iPhone Duo aktuell aufführt, unmittelbar vor dem Export. Dazu gehören die angezeigten Abmessungen und weitere Dateivorgaben; übernehmen Sie diese nicht aus einem älteren Team-Wiki, wenn die offizielle Spezifikationsseite inzwischen einen aktualisierten Stand zeigt.

Auch das Motiv selbst verdient eine getrennte Prüfung. Ein Produktseiten-Screenshot soll die tatsächliche App-Erfahrung verständlich darstellen. Ein nachträglich gestaltetes Marketingbild mit eingebauten Gerätegrafiken ist nicht automatisch dasselbe wie ein Screenshot der App. Apple beschreibt die Erwartungen an Screenshots in den Richtlinien zur Darstellung von App-Inhalten; die Designhinweise für iPhone Duo bieten zusätzlichen Kontext für die Darstellung auf dem Gerät.

Was prüfen Sie bei den Screenshot-Spezifikationen?

Rufen Sie vor der Asset-Produktion die Spezifikationen für die passende Gerätekategorie auf und vergleichen Sie die dort genannten Dateieigenschaften mit Ihrem Export. Notieren Sie, welche Seite geprüft wurde und an welchem Tag. So kann ein späterer Fehler eingeordnet werden, ohne zu raten, ob Ihr Pipeline-Skript eine alte Vorgabe verwendet hat.

Prüfen Sie außerdem, ob Format und Ausrichtung zur jeweiligen Einreichung passen und ob das Bild im vorgesehenen Bereich korrekt angezeigt werden kann. Apple kann Spezifikationen oder Upload-Abläufe ändern; deshalb sollte Ihre interne Anleitung auf die offizielle Seite verweisen und nicht nur starre Werte aus einer einmaligen Recherche enthalten.

Ein erfolgreicher technischer Check beantwortet nicht die Frage, ob das Bild den tatsächlichen Funktionsumfang korrekt zeigt. Lassen Sie Produkt oder QA daher beurteilen, ob die dargestellte Ansicht repräsentativ ist und keine veralteten Oberflächen, Testdaten oder nicht verfügbare Funktionen zeigt. Für die Regeln zur Screenshot-Darstellung ist die offizielle Richtlinienreferenz zu Screenshots die passendere Grundlage als eine reine Dateiprüfung.

Erfahrung aus der Prozessplanung: Wenn ein Team „Screenshot“ sowohl für unveränderte App-Aufnahmen als auch für gestaltete Werbemotive verwendet, wird die Abnahme schnell uneindeutig. Benennen Sie Asset-Typ und Freigabeverantwortung ausdrücklich, statt beides unter einem Sammelbegriff abzuhaken.

Bei der Produktion: Herkunft, Version und Freigabe nachvollziehbar speichern

Legen Sie fest, wer das Ausgangsmaterial liefert. Je nach Organisation kann die Aufnahme aus dem Produktteam, der Qualitätssicherung oder einem Release-Schritt kommen. Entscheidend ist nicht, dass jede Firma dieselbe Zuständigkeitsverteilung übernimmt, sondern dass für jede App und Sprache eine konkrete Übergabe existiert.

Speichern Sie neben der exportierten Datei auch die Informationen, die eine spätere Prüfung ermöglichen: App-Version, Sprache, Quelle der Aufnahme, Erstellungsstand und Freigabe. Ein Screenshot ohne Versionsbezug kann nach einem UI-Update noch technisch gültig wirken, obwohl er einen überholten Produktzustand zeigt. Legen Sie fest, wo die freigegebene Datei liegt und wer eine neue Version erzeugen darf.

Wenn Sie Skripte, Simulatoren oder Xcode-Werkzeuge in diesem Ablauf einsetzen möchten, behandeln Sie diese zunächst als einzelne Hilfsmittel. Gehen Sie nicht davon aus, dass eine bestimmte Xcode-Version automatisch sämtliche Screenshot-Erstellung, Lokalisierung und redaktionelle Abnahme erledigt. Die Apple-Veröffentlichungshinweise zu Xcode 27.1 sollten Sie prüfen, wenn diese Version Bestandteil Ihrer bestehenden Umgebung ist. Die Versionsnummer allein ist jedoch kein Nachweis, dass Ihre konkrete Screenshot-Kette reproduzierbar funktioniert.

Wann müssen Sie Ihre iOS-Veröffentlichung ändern?

Die neue Anforderung wirkt sich auf Ihre iOS-Veröffentlichung aus, sobald Sie die dafür nötigen Assets und ihre Freigabe in den Release-Ablauf aufnehmen müssen. Daraus folgt nicht automatisch ein Wechsel der CI-Plattform. Beginnen Sie mit den Prozessschritten, die tatsächlich betroffen sind: Inventar, Dateiprüfung, Bericht und Upload-Vorbereitung.

Apple erläutert den Upload von App-Vorschauen und Screenshots. Verwenden Sie diese Anleitung für den konkreten Uploadweg und testen Sie die Schritte in Ihrem eigenen Account. Eine Datei, die Ihr Skript als formal passend meldet, ist damit noch nicht bestätigt oder von App Store Connect akzeptiert. Der Upload und die anschließende Vorschau bleiben ein eigener Prüfschritt.

In der CI: Vollständigkeit prüfen, fachliche Freigabe nicht vortäuschen

Automatisieren Sie zuerst Prüfungen, die eindeutige Ergebnisse liefern. Ein CI-Schritt kann beispielsweise feststellen, ob für die im Release definierte Kombination aus Anwendung und Sprache ein erwartetes Asset vorhanden ist, ob die Datei geöffnet werden kann und ob sie die aktuell hinterlegten technischen Kriterien erfüllt. Speichern Sie den Prüfbericht zusammen mit der Build- oder Release-Kennung, damit später klar ist, zu welchem Einreichungsstand er gehört.

Die Automatisierung sollte keine Aussage treffen, die sie nicht belegen kann. Ein Skript kann eine Datei finden und deren Eigenschaften prüfen; es beurteilt nicht zuverlässig, ob die abgebildete Oberfläche zur freigegebenen Produktversion passt oder ob der Bildinhalt die Erwartungen an ein App-Store-Screenshot erfüllt. Diese Punkte benötigen eine menschliche Sichtprüfung oder einen ausdrücklich dafür vorgesehenen redaktionellen Freigabeschritt.

Nutzen Sie für die Einführung diese Entscheidungsbedingungen:

  • Wenn pro App und Sprache eine eindeutige Asset-Zuordnung existiert und die technischen Prüfkriterien aus Apples aktueller Spezifikation abgeleitet sind, dann nehmen Sie Vollständigkeits- und Dateiprüfungen in die CI auf.
  • Wenn Quelldateien, Versionsbezug oder Zuständigkeit noch fehlen, dann beginnen Sie mit einer manuell gepflegten Inventarliste und beheben zuerst diese Lücken.
  • Wenn die Prüfung nur das Vorhandensein und die Lesbarkeit einer Datei bestätigt, dann kennzeichnen Sie sie als technische Vorprüfung und verlangen weiterhin eine fachliche Freigabe.
  • Wenn der automatisierte Upload noch nicht in einer kontrollierten Probe validiert wurde, dann behandeln Sie Upload und App-Store-Connect-Vorschau weiterhin als manuelle Release-Schritte.
  • Wenn Ihr aktueller Mac-Knoten Builds zuverlässig ausführt und Ihr Engpass allein in fehlenden Assets oder Zuständigkeiten liegt, dann behalten Sie ihn zunächst bei. Wechseln Sie die Umgebung erst, wenn ein konkret gemessener technischer Bedarf dies rechtfertigt.

Diese Regeln verhindern zwei häufige Fehlschlüsse: „CI grün“ bedeutet nicht „Apple hat die Assets angenommen“, und „neue Screenshot-Anforderung“ bedeutet nicht „neue Mac-Hardware erforderlich“. Trennen Sie im Statusbericht mindestens technische Dateiprüfung, fachliche Freigabe und Upload-Ergebnis.

Vor der Ausweitung: Einen vollständigen Veröffentlichungsdurchlauf abnehmen

Bevor Sie die neue Prüfung auf alle Anwendungen übertragen, führen Sie einen vollständigen Probeablauf mit einer geeigneten App durch. Wählen Sie einen Fall, der die tatsächliche Übergabe zwischen Materialerstellung, Prüfung und Upload abbildet. Halten Sie pro Schritt fest, wer zuständig war, welches Ergebnis vorlag und wie ein Fehlschlag behandelt wurde.

  1. Bestand wählen: Nehmen Sie eine App mit klarer Produktverantwortung und einer überschaubaren Zahl offener Assets.
  2. Material zuordnen: Dokumentieren Sie Quelle, Sprache, App-Version und Freigabestatus der vorgesehenen Screenshot-Dateien.
  3. Technisch prüfen: Lassen Sie die geplante lokale oder CI-Prüfung die Vollständigkeit und die aus Apples aktueller Spezifikation abgeleiteten Dateikriterien kontrollieren.
  4. Inhaltlich abnehmen: Lassen Sie eine verantwortliche Person bestätigen, dass Motiv und dargestellte App-Erfahrung zum vorgesehenen Release passen.
  5. Upload und Vorschau prüfen: Verwenden Sie Apples Anleitung zum Hochladen von Screenshots und protokollieren Sie, was App Store Connect tatsächlich anzeigt.
  6. Rückfall dokumentieren: Legen Sie fest, wer bei fehlender Datei, technischer Ablehnung oder notwendiger Motivkorrektur die Arbeit übernimmt und wie die Einreichung bis zur Klärung weiterläuft.

Fragen Sie bei der Abnahme nicht nur, ob der Ablauf erfolgreich war. Prüfen Sie auch, ob die Zuständigkeiten ohne Zuruf verständlich waren, ob der Bericht zur richtigen App-Version gehört und ob der manuelle Review-Schritt klar vom CI-Ergebnis getrennt ist. Wenn ein Fehler auftritt, ergänzen Sie die Checkliste um den konkreten Fehlertyp, statt pauschal weitere Pflichtprüfungen für alle Teams einzuführen.

Erst wenn dieser Durchlauf reproduzierbar ist, sollten Sie den Prozess auf weitere Apps ausdehnen. Bei jeder Erweiterung kontrollieren Sie, ob sich Sprachen, Produktseiten oder interne Verantwortlichkeiten unterscheiden. Ein gemeinsamer Mechanismus ist hilfreich, wenn er diese Unterschiede sichtbar macht; ein einheitliches Häkchen ohne App- und Sprachbezug verschleiert dagegen genau die Lücken, die Sie finden möchten.

Die praktische Konsequenz für Ihre CI ist damit begrenzt und klar: Planen Sie die Anforderung in den Veröffentlichungsprozess ein, automatisieren Sie prüfbare Dateikriterien und behalten Sie die inhaltliche Freigabe sowie den App-Store-Connect-Upload als separate Nachweise. Für diese Arbeit ist der erste Engpass meist die Asset-Verwaltung, nicht die Rechenleistung des Mac-Knotens.

Wenn Sie für einen zeitlich begrenzten Pilotlauf, eine zusätzliche Validierungsumgebung oder einen getrennten iOS-Veröffentlichungsarbeitsplatz einen Mac benötigen, vergleichen Sie zunächst die vorhandene Infrastruktur mit den tatsächlichen Anforderungen. Ein selbst betriebener Mac bindet Anschaffungsbudget und Wartungszeit; ein vorhandener geteilter Knoten kann bei parallelen Aufgaben zum Engpass werden. Bleiben Sie bei Ihrer bestehenden Umgebung, wenn sie den Bedarf zuverlässig abdeckt oder Sie dauerhaft eine feste Hardwarekonfiguration benötigen. Für einen befristeten Bedarf können Sie VMSPIN und die verfügbaren Remote-Mac-Optionen prüfen und die Preise von VMSPIN mit Ihrem geplanten Zeitraum abgleichen. Die Miete ist eine mögliche Ergänzung für Tests oder Übergangsphasen, kein Grund, allein wegen der Screenshot-Anforderung Ihre CI umzubauen.