2026: Faltbares iPhone Ultra – App-Store-Screenshots?

Kurzurteil: Behalten, vorbereiten, später exportieren

Symptom: Sie planen für Herbst 2026 eine neue iOS-Version und wissen nicht, ob ein mögliches faltbares iPhone Ultra eine komplette neue Screenshot-Serie erzwingt.

Schnellste Lösung: Erstellen Sie jetzt keine Bildserie nach unbestätigten Abmessungen. Apple akzeptiert aktuell zwischen 1 und 10 Screenshots pro Ziel; die offizielle Spezifikationsseite führt bestehende iPhone-Displayklassen auf, aber kein faltbares iPhone. Prüfen Sie deshalb Ihre Bildpipeline, markieren Sie breite Kandidaten und warten Sie mit dem finalen Export, bis Apple Gerät und App-Store-Connect-Regeln bestätigt hat. Apple: Screenshot-Spezifikationen

Dieser Beitrag richtet sich an Sie, wenn Sie im Herbst 2026 eine neue App-Version einreichen, mehrere Sprachversionen oder benutzerdefinierte Produktseiten pflegen oder kurzfristige Design- und Testarbeit vermeiden müssen. Er ist auch für iOS-Entwickler und QA-Verantwortliche gedacht, die ein veränderliches Layout prüfen, aber noch kein offizielles Gerät und keine offiziellen Store-Vorgaben haben.

Stand: 08.08.2026. Die Aussagen zu einem „iPhone Ultra“, einer möglichen faltbaren Bauweise, einer Herbstvorstellung und einer eventuellen getrennten Markteinführung sind weiterhin Berichte oder Lieferketteninformationen. Apple hat dafür bislang keine offizielle Produkt- oder Screenshot-Spezifikation veröffentlicht. Die aktuellen Store-Regeln und iOS-27-Fähigkeiten wurden in der offiziellen Apple-Dokumentation gegengeprüft.

Die wichtigste Trennung: Gerät, App-Layout und Store-Material

In vielen Teams werden drei verschiedene Fragen vermischt:

1. Welche Hardware Apple möglicherweise vorstellt.
2. Wie sich die App bei einer anderen nutzbaren Breite verhält.
3. Welche Bilddateien App Store Connect tatsächlich verlangt.

Diese Ebenen sind nicht gleich.

Für ein faltbares iPhone kann eine breitere App-Oberfläche sinnvoll sein. Daraus folgt aber nicht automatisch, dass Apple eine neue Screenshot-Größe einführt. Ebenso bedeutet eine neue Displayklasse nicht zwingend, dass Sie jede bestehende Aufnahme ersetzen müssen. App Store Connect kann vorhandene hochauflösende Bilder je nach Ziel skalieren. Apple beschreibt ausdrücklich, dass Sie bei gleicher Benutzeroberfläche für mehrere Gerätegrößen und Lokalisierungen nur die höchste erforderliche Auflösung bereitstellen können; kleinere Ziele werden daraus skaliert. Apple: Upload von App-Vorschauen und Screenshots

Die aktuelle Spezifikationsseite nennt beispielsweise für ein 6,9-Zoll-iPhone mehrere akzeptierte Hoch- und Querformatgrößen. Für 6,5 Zoll, 6,3 Zoll und weitere Klassen gelten eigene Pixelmaße. Ein faltbares Ziel ist dort am 08.08.2026 nicht aufgeführt. Genau deshalb wäre es riskant, eine in Medien genannte Breite oder Auflösung direkt in Ihre Produktionsvorlage zu übernehmen. Apple: aktuelle iPhone-Screenshotgrößen

Achtung: Eine Medienmeldung kann den richtigen Veröffentlichungszeitraum nahelegen und trotzdem keine Aussage darüber treffen, welche Assets Apple später in App Store Connect verlangt. Verwenden Sie Gerüchte zur Terminplanung, nicht zur Festlegung von Pixelmaßen.

Was Sie unverändert weiterverwenden können

Ihre bestehende Screenshot-Serie bleibt die richtige Ausgangsbasis, wenn sie drei Bedingungen erfüllt:

• Sie zeigt die aktuell ausgelieferte App.
• Sie entspricht den gegenwärtig akzeptierten Größen oder kann von App Store Connect skaliert werden.
• Die dargestellten Funktionen und Texte sind weiterhin korrekt.

Apple erlaubt aktuell mindestens einen und höchstens zehn Screenshots in den unterstützten Formaten JPEG, JPG und PNG. Transparenz beziehungsweise Alphakanäle sind bei den offiziellen Screenshot-Spezifikationen nicht vorgesehen. Diese Regeln betreffen die gegenwärtig dokumentierten Ziele; sie bestätigen keine zukünftige faltbare Gerätekategorie. Apple: Screenshot-Spezifikationen und Dateivorgaben

Besonders gut wiederverwendbar sind Aufnahmen, deren Aussage nicht an eine bestimmte Geräteform gebunden ist:

• ein klarer Startbildschirm mit dem zentralen Nutzen,
• eine Such- oder Filterfunktion,
• ein Ergebnisbildschirm mit gut lesbarer Information,
• ein Zahlungs-, Export- oder Freigabeprozess,
• eine Funktion, die in Hoch- und Querformat ähnlich verständlich bleibt.

Weniger stabil sind Bilder, die bewusst einen engen Bildschirmrand, eine bestimmte Aussparung oder eine exakt positionierte Geräteumrandung zeigen. Diese müssen nicht sofort neu gebaut werden. Sie sollten aber als „später prüfen“ markiert werden.

Für Produktverantwortliche ist der Unterschied wichtig: Eine komplette Serie vor der offiziellen Spezifikation neu zu produzieren kostet nicht nur neue Aufnahmen. Sie zieht Übersetzungen, Rechtschreibprüfung, Lokalisierungsfreigaben, Produktseitenvarianten und interne Review-Schleifen nach sich. Ohne bestätigten neuen Slot entsteht dabei leicht Arbeit, die später erneut verworfen wird.

Wann breite Kandidatenbilder sinnvoll sind

Nicht jede App profitiert von einer breiteren Darstellung. Wählen Sie Kandidaten nach echtem Funktionsgewinn aus, nicht nach der bloßen Existenz eines möglichen Faltgeräts.

Eine Vorprüfung lohnt sich besonders bei:

• Tabellen- und Dashboard-Apps,
• Karten- und Routenansichten,
• Dokumenten- und PDF-Lesern,
• Musik- oder Videoeditoren,
• Datenanalyse- und Monitoring-Tools,
• Apps mit Liste-und-Detail-Aufteilung,
• Werkzeugen, bei denen zusätzliche horizontale Fläche die Bedienung vereinfacht.

Bei einer einfachen Taschenrechner-, Kamera- oder Login-App ist ein breiteres Bild möglicherweise kein besseres Store-Motiv. Der zusätzliche Raum kann leer wirken. Das wäre kein überzeugender Vorteil für Nutzer und kein guter Grund, eine neue Screenshot-Serie zu bauen.

Die Prüfung sollte deshalb nicht lauten: „Wie sieht die App auf dem faltbaren iPhone aus?“ Diese Frage setzt ein unbekanntes Gerät voraus. Besser ist:

• Bleiben zentrale Texte bei veränderlicher Breite lesbar?
• Werden Karten, Tabellen und Diagramme sinnvoll neu angeordnet?
• Entsteht eine echte Zwei-Spalten- oder Liste-Detail-Darstellung?
• Bleiben Schaltflächen erreichbar, wenn sich die Breite ändert?
• Ist der Vorteil in einem einzelnen Store-Bild sofort erkennbar?

Apple beschreibt für aktuelle Plattformen und Werkzeuge Möglichkeiten, Apps auf veränderliche Größen und Layoutbedingungen zu prüfen. Für die Vorbereitung können Sie deshalb mit den verfügbaren iOS-27- und Xcode-27-Testumgebungen arbeiten, ohne daraus eine bestätigte Aussage über ein faltbares iPhone abzuleiten. Hinweise zu den aktuellen Werkzeugständen finden Sie in den Xcode-27-Release-Notes von Apple und in den aktuellen Plattform-Updates.

Eine breite Kandidatenaufnahme darf nur echte App-Funktion zeigen. Verwenden Sie keine erfundene Geräteumrandung, kein angebliches Systemfenster und keine nicht bestätigte Darstellung des Faltmechanismus. Apple verlangt, dass Screenshots die Nutzung der App zeigen und nicht nur Titelgrafiken, Splashscreens oder irreführende Produktbilder. Apple: App-Review-Richtlinien, Abschnitt 2.3

Wo Ihre Screenshot-Automatisierung zuerst nachgeben kann

Der größte kurzfristige Risikofaktor ist oft nicht das Design, sondern ein hart codiertes Skript.

Prüfen Sie Ihre Pipeline in dieser Reihenfolge:

1. Aufnahme: Wird ein Simulator oder ein Gerät anhand eines festen Namens ausgewählt?
2. Abmessungen: Sind Breite und Höhe in Shell-Skripten, YAML-Dateien oder Exportprofilen fest eingetragen?
3. Ausrichtung: Erzwingt die Pipeline ausschließlich Hochformat oder Querformat?
4. Geräterahmen: Wird aus dem Dateinamen automatisch ein bestimmter Rahmen geladen?
5. Textposition: Hängen Überschrift, Untertitel oder CTA an festen Pixelkoordinaten?
6. Export: Werden Zielgröße, Dateityp und Kompression in einem untrennbaren Schritt erzeugt?

Diese Trennung entscheidet darüber, ob eine spätere Apple-Anpassung eine kleine Konfigurationsänderung oder eine komplette Produktionsaktion auslöst.

Eine belastbare Struktur besteht aus vier austauschbaren Stufen:

• App-Zustand herstellen und Aufnahme erfassen,
• Rohbild ohne Marketingrahmen speichern,
• Text, Markierungen und Gerätevisualisierung anwenden,
• finale Datei nach bestätigter Store-Spezifikation exportieren.

Bereiten Sie jetzt variable Arbeitsflächen, sichere Beschnittbereiche und neutrale Rohaufnahmen vor. Schreiben Sie aber keine vermutete Foldable-Auflösung in CI/CD, xcrun simctl, Bildverarbeitungsprofile oder Dateinamen. Die offizielle Apple-API für App-Screenshots arbeitet ebenfalls mit Screenshot-Sets und Displayzielen; die tatsächlichen Anforderungen werden bei der Einreichung geprüft. Apple: App-Screenshots über die App Store Connect API

Wenn Ihre Pipeline heute nur „iPhone 6.9“ oder „iPhone 6.5“ als feste Zeichenkette kennt, sollte diese Information aus einer Konfigurationsdatei kommen. Das erleichtert später die Umstellung, beweist aber nicht, dass ein neues Gerät denselben Prozess verwenden darf.

Für die Verwaltung getrennter Testläufe können Sie außerdem eine zentrale Arbeitsumgebung verwenden, in der Build-Artefakte, Simulatorzustände und Freigabeschritte nachvollziehbar bleiben. Einen neutralen Überblick über mögliche Mac-Entwicklungsumgebungen und die dazugehörigen Abläufe finden Sie auf der MacHTML-Übersichtsseite. Entscheidend bleibt unabhängig vom Werkzeug: Rohaufnahme und finaler Store-Export dürfen nicht an dasselbe feste Geräteziel gekoppelt sein.

Mehr Sprachen und Produktseiten vervielfachen die Rückarbeit

Die Kosten einer kurzfristigen Änderung steigen mit jeder zusätzlichen Variante.

Relevant sind nicht nur die Anzahl der Sprachen, sondern auch:

• unterschiedliche Textlängen pro Lokalisierung,
• eigene Screenshots je Produktseite,
• A/B-Varianten für bestimmte Zielgruppen,
• unterschiedliche Bildreihenfolgen,
• regionale Rechts- und Datenschutzanforderungen,
• getrennte Freigaben durch Marketing, Produkt und Übersetzung.

Apple erlaubt bis zu drei App-Vorschauen pro unterstützter Gerätegröße und Sprache. App-Vorschauen sind optional, stehen vor den Screenshots und können bei der Verarbeitung bis zu 24 Stunden benötigen. Diese Grenze und die Bearbeitungszeit betreffen die aktuelle Dokumentation; sie sind keine Prognose für ein zukünftiges faltbares Ziel. Apple: App-Vorschauen und Uploadprozess

Für mehrsprachige Teams lohnt sich deshalb eine Inhaltsmatrix. Definieren Sie für jede Aufnahme:

• den einen Hauptnutzen,
• die maximal zulässige Textmenge,
• den unveränderlichen Bildbereich,
• den austauschbaren UI-Bereich,
• die Lokalisierung,
• die gewünschte Ausrichtung,
• den Status „freigegeben“, „Kandidat“ oder „nach Ankündigung“.

So muss nach einer offiziellen Änderung nicht jede Sprache neu konzipiert werden. Sie ersetzen nur Rohaufnahme, Rahmen oder Exportziel, sofern Apple tatsächlich ein zusätzliches Ziel verlangt.

Kleine Apps mit wenigen Screenshots und nur einer Sprache können dagegen warten. Für sie ist die Vorarbeit an einem flexiblen Template oft größer als der spätere einmalige Austausch. Entscheidend ist nicht die vermutete Hardware, sondern die Anzahl der tatsächlich zu pflegenden Varianten.

FAQ: Was bis zur offiziellen Ankündigung gilt

Gibt es eine neue Screenshot-Größe für das faltbare iPhone?

Am 08.08.2026 ist keine solche Größe offiziell dokumentiert. Die Apple-Seite führt bestehende iPhone-Displayklassen mit konkreten Pixelmaßen auf. Weder der Name „iPhone Ultra“ noch ein faltbares Modell oder ein eigener Upload-Slot ist von Apple bestätigt. Erstellen Sie daher keinen produktiven Export auf Basis von Mediengrafiken oder Lieferkettenberichten.

Sollten aktuelle iPhone-Screenshots jetzt neu erstellt werden?

Nur wenn Ihre bestehenden Bilder unabhängig vom Falt-Thema veraltet, unlesbar oder nicht mehr regelkonform sind. Für die mögliche neue Hardware sollten Sie keine komplette Serie vorziehen. Prüfen Sie stattdessen die erste Bildreihe, wählen Sie breite Funktionskandidaten aus und lösen Sie feste Gerätewerte aus der Pipeline.

Müssen gefalteter und aufgeklappter Zustand getrennt hochgeladen werden?

Das ist offen. Die gegenwärtigen App-Store-Connect-Dokumente unterscheiden nach Plattform, Displayziel, Sprache und Asset-Typ. Eine öffentliche Regel für getrennte Faltzustände ist nicht dokumentiert. Erst ein neuer offizieller Slot oder eine konkrete Apple-Anweisung würde diese Arbeit rechtfertigen.

Was ist ohne echtes Faltgerät möglich?

Sie können mit iOS-27-Testumgebungen die Reaktion Ihrer App auf unterschiedliche Fensterbreiten prüfen. Validieren Sie Lesbarkeit, Navigation, Tabellen, Karten und Zustandswechsel. Für Store-Material dürfen Sie aber nur echte App-Oberflächen zeigen. Eine erfundene Hardwareansicht wäre keine belastbare Vorbereitung.

Muss eine neue App-Version eingereicht werden?

Nach der aktuellen Apple-Anleitung müssen Sie nach einer genehmigten Einreichung eine neue Version erstellen, um Screenshots zu aktualisieren. Planen Sie diese Änderung nicht automatisch für den Tag einer möglichen Gerätevorstellung ein. Veröffentlichung, Verkaufsstart, neue Store-Slots und Review-Freigabe können getrennte Termine haben.

Die fünf Schritte für eine belastbare Vorbereitung

1. Aktuelle Store-Basis dokumentieren.
   Exportieren Sie eine Liste der derzeit verwendeten iPhone-Ziele, Bildgrößen, Sprachen, Produktseiten und Versionen. Vermerken Sie, welche Bilder manuell und welche automatisiert erzeugt werden.

2. Geräteannahmen aus der Produktion entfernen.
   Verschieben Sie Pixelmaße, Orientierung, Rahmenname und Exportprofil in eine austauschbare Konfiguration. Löschen Sie keine funktionierende aktuelle Konfiguration, sondern versionieren Sie sie.

3. Breite Kandidaten nach Nutzwert bewerten.
   Markieren Sie nur Ansichten, bei denen zusätzliche Fläche eine konkrete Funktion verbessert. Ein Dashboard mit mehr gleichzeitig sichtbaren Informationen ist ein Kandidat. Ein unveränderter Loginbildschirm ist es meistens nicht.

4. Mit iOS 27 und Xcode 27 prüfen.
   Testen Sie veränderliche Breiten, Textumbruch, Fokusreihenfolge, Touch-Ziele und Zustandswiederherstellung. Dokumentieren Sie das Ergebnis als Layout- oder Produktprüfung, nicht als Beweis für die spätere Hardware.

5. Finale Ausgabe blockieren, nicht vorbereiten.
   Lassen Sie Rohaufnahmen, Texte und Layoutvorlagen bereitliegen. Sperren Sie jedoch den finalen Foldable-Export, bis Apple das Gerät, die Displayklasse, die akzeptierten Maße und die Uploadlogik veröffentlicht.

6. Ein Einreichungsfenster reservieren.
   Trennen Sie Veröffentlichungstermin, SDK-Abnahme, Screenshotproduktion, Designfreigabe und Versionseinreichung. So bleibt Ihre Planung handlungsfähig, falls die Hardware angekündigt, aber später verfügbar wird.

Für die operative Zusammenarbeit sollten Sie Ihre Test- und Freigabeschritte in einer zentralen Dokumentation festhalten. Wenn mehrere Personen auf dieselbe Entwicklungsumgebung zugreifen, muss die Verantwortlichkeit für Simulator, Rohdaten, Export und App Store Connect klar getrennt sein. Eine gemeinsame Checkliste verhindert, dass ein nicht freigegebenes Bild versehentlich in eine Lokalisierung oder Produktseitenvariante gelangt. Bei Fragen zu Zugriffsrechten, Sitzungsübergabe und der sicheren Ablage von Testartefakten sollte Ihre Dokumentation die jeweiligen Rollen und Löschfristen eindeutig festlegen. Ergänzende Hinweise zu Zugriffsverwaltung und Arbeitsabläufen finden Sie in der MacHTML-Hilfe.

Entscheidungscheckliste für den 08.08.2026

• [ ] Die aktuelle App-Store-Connect-Spezifikation wurde am 08.08.2026 geprüft.
• [ ] Es gibt keine produktive Pipeline, die eine unbestätigte Foldable-Auflösung verwendet.
• [ ] Bestehende Screenshots zeigen die tatsächlich veröffentlichte App.
• [ ] Die erste bis dritte Aufnahme erklärt den Hauptnutzen ohne Gerätegerücht.
• [ ] Breite Kandidatenbilder wurden nach echtem Funktionswert ausgewählt.
• [ ] Rohaufnahme, Gestaltung, Rahmen und Export sind getrennte Schritte.
• [ ] Textpositionen können sich an sicheren Flächen statt an festen Pixeln orientieren.
• [ ] Lokalisierte Varianten und benutzerdefinierte Produktseiten sind inventarisiert.
• [ ] Testdaten enthalten keine echten personenbezogenen Daten.
• [ ] Keine erfundene Apple-Geräteumrandung erscheint in einer Aufnahme.
• [ ] Der Prozess kann neue Displayziele aufnehmen, ohne Rohmaterial neu zu konzipieren.
• [ ] Die finale Veröffentlichung wartet auf offizielle Apple-Maße und Uploadregeln.
• [ ] Die mögliche neue Version ist im Herbstplan getrennt von der Geräteankündigung eingeplant.
• [ ] Nach der offiziellen Mitteilung werden Apple Developer, App Store Connect Help und die Apple-Aktivitätsseite erneut geprüft.

Wann „warten“ und wann „vorbereiten“ die bessere Entscheidung ist

Weiterverwenden ist richtig, wenn Ihre App keine breite Darstellung benötigt, die aktuellen Bilder korrekt sind und Ihre Pipeline bereits flexible Exporte unterstützt. Der Vorteil: kein unnötiger Design- und Lokalisierungsaufwand.

Vorbereiten ist richtig, wenn Ihre App stark von Tabellen, Karten, Leseflächen oder Mehrspaltenansichten profitiert. Erstellen Sie Kandidatenbilder und testen Sie die Benutzeroberfläche, aber veröffentlichen Sie keine Behauptung über ein noch nicht bestätigtes Gerät.

Nach der Ankündigung neu erstellen ist richtig, wenn Apple ein eigenes Displayziel, neue Größen, eine andere Ausrichtung oder eine getrennte Materiallogik einführt. Erst dann lohnt sich die konkrete Aufnahme auf dem passenden Simulator oder Gerät.

Apple weist außerdem darauf hin, dass Produktseitenmaterialien die tatsächliche App-Erfahrung korrekt und aktuell darstellen müssen. Ein Bild, das eine Funktion oder einen Zustand suggeriert, den die ausgelieferte App nicht bietet, kann daher nicht als harmlose Marketingvorlage betrachtet werden. Apple: Richtlinien für genaue Metadaten

Die aktuelle Lösung gegenüber einer Mac-Testumgebung

Wenn Sie die Prüfung auf einem privaten Rechner oder einer allgemeinen Cloud-Umgebung durchführen, entstehen drei typische Nachteile: Die benötigte Xcode-Version ist nicht dauerhaft verfügbar, Simulator- und Artefaktstände sind schwer reproduzierbar, und mehrere Teammitglieder greifen nicht zuverlässig auf dieselbe Umgebung zu. Bei automatisierten Screenshots kommen zusätzlich Berechtigungen, Displayauflösung und instabile Sitzungen hinzu.

Für kurzfristige iOS-27-Tests, die Vorbereitung einer Screenshot-Pipeline oder eine unabhängige Abnahme kann eine gemietete Mac-Umgebung deshalb praktischer sein als ein vorschneller Hardwarekauf. Für dauerhaft hohe Last, eigene physische Geräteanschlüsse oder langfristig planbare Produktionssysteme bleibt ein eigener Mac die bessere Wahl. Speichern Sie in jedem Fall nur synthetische Testdaten und prüfen Sie Ihre DSGVO-Vorgaben, bevor Sie App-Artefakte oder Kundendaten auf eine entfernte Umgebung übertragen.

Ihre nächste konkrete Aktion ist die Checkliste oben: aktuelle Assets einfrieren, flexible Vorlagen vorbereiten und die offizielle Apple-Spezifikation nach der Geräteankündigung erneut abgleichen. So sind Sie schnell genug für eine bestätigte Änderung, ohne heute eine komplette Screenshot-Serie für ein unbestätigtes Gerät zu produzieren.