Mit dem iPhone Duo bringt Apple am 23. Oktober 2026 sein erstes faltbares iPhone auf den Markt. Für Website-Betreiber bedeutet das nicht einfach nur eine weitere Bildschirmgröße, die berücksichtigt werden muss. Interessanter ist der Wechsel zwischen zwei deutlich unterschiedlichen Nutzungssituationen: geschlossen mit einem 5,4 Zoll großen Außendisplay und geöffnet mit einem 7,6 Zoll großen Innendisplay. Je nach Ausrichtung verändert sich dabei nicht nur die Breite, sondern auch die verfügbare Höhe erheblich.
Gutes Responsive Design sollte mit solchen Veränderungen grundsätzlich umgehen können. Ein faltbares Smartphone macht Schwachstellen aber besonders schnell sichtbar: sehr hohe Hero-Bereiche, feststehende Header, Cookie-Banner, umfangreiche Navigationen oder Formulare können auf einem breiten, aber vergleichsweise niedrigen Display plötzlich deutlich weniger komfortabel funktionieren.
Ihre Website direkt online testen
Mit unserem Online-Test-Tool können Sie Ihre Website direkt in diesem Beitrag in unterschiedlichen Testansichten prüfen. Wechseln Sie zwischen den vorbereiteten Größen und beobachten Sie vor allem, wie sich Navigation, Inhalte, Formulare und wichtige Schaltflächen verhalten.
Die Vorschau ist dabei bewusst als erster Layout-Check gedacht. Einen Test auf einem echten iPhone Duo kann sie nicht ersetzen. Safari selbst, ein- und ausgeblendete Browserleisten, die Bildschirmtastatur und das tatsächliche Verhalten beim Wechsel zwischen den Displays lassen sich durch eine veränderte Fenstergröße allein nicht vollständig simulieren.
Drei Testansichten für die Vorbereitung
Für einen ersten Check bieten sich derzeit die folgenden Größen an. Wichtig: Es handelt sich um vorläufige Testwerte in CSS-Pixeln, nicht um von Apple bestätigte Safari-Viewport-Maße.
| Testansicht | Breite × Höhe | Worauf Sie achten sollten |
|---|---|---|
| Außenbildschirm | 466 × 678 px | Bleibt trotz Header, Browseroberfläche und festen Elementen genügend Platz für den eigentlichen Inhalt? |
| Innenbildschirm im Querformat | 890 × 626 px | Funktioniert ein breiteres Layout auch bei vergleichsweise geringer Höhe? |
| Innenbildschirm im Hochformat | 626 × 890 px | Wird der zusätzliche Platz sinnvoll genutzt, ohne Inhalte unnötig auseinanderzuziehen? |
Apple gibt für die beiden Displays Auflösungen von 1.398 × 2.034 beziehungsweise 1.878 × 2.670 Pixeln an. Unter der Annahme eines Device Pixel Ratio von 3 ergeben sich daraus rechnerisch die genannten CSS-Größen. Ein DPR von 3 ist für das iPhone Duo derzeit jedoch keine von Apple veröffentlichte Web-Spezifikation. Die Werte sind deshalb bewusst als Arbeitshypothese zu verstehen. Das tatsächliche Safari-Viewport kann unter anderem durch Skalierung, Browseroberfläche und Anzeigeeinstellungen abweichen. Apple: technische Daten
Beschränken Sie den Test außerdem nicht auf genau diese drei Größen. Entscheidend ist, ob das Layout auch in den Übergängen dazwischen stabil bleibt. Gerade dort zeigen sich häufig Probleme mit Breakpoints, Navigationen oder Spaltenlayouts.
Auch deutlich schmalere Ansichten bleiben relevant. Die WCAG-Anforderung „Reflow“ sieht für gewöhnliche, vertikal scrollende Inhalte eine Darstellung bei einer Breite von umgerechnet 320 CSS-Pixeln vor, ohne dass Informationen oder Funktionen verloren gehen oder in zwei Richtungen gescrollt werden muss. Die 320 Pixel sind dabei kein spezieller Smartphone-Breakpoint, sondern ein Maßstab für barrierefreies Reflow-Verhalten, unter anderem bei starker Vergrößerung. Für Inhalte wie große Tabellen oder Karten gelten Ausnahmen. W3C: Reflow
Die Breite allein ist kein ausreichendes Kriterium
Gerade der geöffnete Innenbildschirm zeigt, warum Responsive Design nicht ausschließlich über die Breite gedacht werden sollte. Bei rund 890 CSS-Pixeln kann eine Website bereits eine umfangreichere Navigation, größere Bilder oder mehrere Spalten anzeigen. Gleichzeitig stehen im Querformat rechnerisch nur etwa 626 Pixel Höhe zur Verfügung.
Ein Layout kann dadurch auf den ersten Blick fast wie eine kleine Desktop-Ansicht wirken und trotzdem deutlich weniger vertikalen Raum bieten als erwartet. Ein großer Header und ein Hero-Bereich mit voller Bildschirmhöhe können dann bereits fast den gesamten sichtbaren Bereich belegen.
Prüfen Sie deshalb insbesondere, was Besucher unmittelbar nach dem Seitenaufruf sehen: Sind Überschrift und wichtigste Aussage erkennbar? Ist eine relevante Schaltfläche erreichbar? Was passiert, wenn zusätzlich ein Cookie-Dialog eingeblendet wird? Lassen sich längere Dialoge vollständig bedienen und gegebenenfalls innerhalb des verfügbaren Bereichs scrollen?
Für Bereiche, die sich bewusst an der Browserhöhe orientieren sollen, stehen heute unter anderem die CSS-Einheiten svh und dvh zur Verfügung. svh orientiert sich an der kleinsten verfügbaren Viewport-Höhe, beispielsweise bei eingeblendeten Browserleisten. dvh reagiert dagegen dynamisch auf Veränderungen der Browserfläche. Welche Variante sinnvoll ist, hängt vom jeweiligen Element ab. WebKit: Viewport-Einheiten
Ein pauschaler Austausch von vh durch dvh löst allerdings nicht automatisch alle Probleme. Abstände, Inhaltsmenge, Overlays und fest positionierte Elemente müssen weiterhin sinnvoll zusammenspielen.
Besonders wichtig ist das bei Formularen. In Safari auf dem iPhone verändert die eingeblendete Bildschirmtastatur in erster Linie den sichtbaren Visual Viewport. Elemente mit position: fixed oder viewportbezogenen Höhen können dadurch weiterhin von der Tastatur verdeckt werden. Formulare sollten deshalb zusätzlich mit tatsächlich eingeblendeter Tastatur getestet werden. Chrome Developers: Verhalten von Viewports und Bildschirmtastatur
Zusätzlichen Platz dort nutzen, wo er wirklich hilft
Das größere Innendisplay eröffnet Möglichkeiten, die auf klassischen Smartphones nur eingeschränkt sinnvoll sind. Entscheidend ist aber nicht, möglichst viele Inhalte nebeneinanderzustellen, sondern zusammengehörige Informationen näher zusammenzubringen.
Auf einer Leistungsseite könnten beispielsweise Beschreibung und passende Referenz nebeneinander stehen. In einem Onlineshop lassen sich Produktbild und Auswahlmöglichkeiten gleichzeitig darstellen. Bei umfangreicheren Formularen kann eine Zusammenfassung oder zusätzliche Hilfestellung neben den Eingabefeldern stehen.
Ein längerer Fließtext profitiert dagegen selten davon, plötzlich in zwei Spalten aufgeteilt zu werden. Hier sind eine angenehme Zeilenlänge, ausreichend Weißraum und gut abgestimmte Abstände meist wichtiger. Auch eine Navigation muss nicht zwangsläufig zur vollständigen Desktop-Navigation werden, nur weil theoretisch mehr Breite vorhanden ist.
Bei solchen Layoutänderungen sollte außerdem die Bedienreihenfolge berücksichtigt werden. Werden Elemente optisch anders angeordnet als im HTML-Dokument, muss die Navigation per Tastatur weiterhin nachvollziehbar bleiben. Der Fokus sollte nicht scheinbar willkürlich zwischen verschiedenen Bereichen der Seite springen. W3C: Fokusreihenfolge
Nicht für das iPhone Duo, sondern für den verfügbaren Platz entwickeln
Es wäre verlockend, jetzt spezielle Breakpoints für 626 oder 890 Pixel anzulegen und diese als „iPhone-Duo-Ansicht“ zu behandeln. Genau das sollte jedoch nicht das Ziel sein.
Ein Breakpoint ist dann sinnvoll, wenn ein Layout oder eine Komponente den vorhandenen Platz nicht mehr sinnvoll nutzen kann – nicht, weil ein bestimmtes Gerät eine bestimmte Auflösung besitzt. Eine Navigation sollte also dort kompakter werden, wo die Links tatsächlich zu eng werden. Zwei Spalten sollten dort zu einer Spalte wechseln, wo der Inhalt ansonsten gequetscht wirkt.
Das macht die Anpassungen gleichzeitig robuster. Davon profitieren nicht nur Nutzer eines iPhone Duo, sondern beispielsweise auch Tablets im Split-Screen, kleinere Browserfenster auf dem Desktop oder zukünftige Geräte mit bislang unbekannten Formaten.
Welche Technik heute sinnvoll ist
Für wiederverwendbare Komponenten sind Container Queries besonders interessant. Während klassische Media Queries meist auf die Größe des gesamten Browserfensters reagieren, kann sich eine Komponente mit Container Queries an dem Platz orientieren, der ihr tatsächlich zur Verfügung steht.
Eine Referenzkarte kann dadurch beispielsweise unabhängig davon reagieren, ob sie gerade in einer schmalen Seitenleiste, in einem zweispaltigen Layout oder über die gesamte Seitenbreite angezeigt wird. Gerade bei flexiblen und faltbaren Displays ist das häufig sinnvoller, als sämtliche Entscheidungen ausschließlich von der Fensterbreite abhängig zu machen. MDN: Container Queries
Daneben entstehen Webstandards, mit denen sich speziell auf faltbare Geräte reagieren lässt. Zwei Ansätze sind dabei besonders interessant.
device-posture kann unterscheiden, ob sich ein unterstütztes Gerät in einem flachen Zustand (continuous) oder in einer gefalteten Stellung (folded) befindet. Damit wären beispielsweise Layoutanpassungen für eine Nutzung in Buch- oder Laptop-Position denkbar. Die Schnittstelle liefert allerdings weder einen exakten Faltwinkel noch Informationen darüber, um welches Gerät es sich handelt. Auch ein gewöhnlicher Bildschirm gilt als continuous. MDN: Device Posture API
Die Viewport Segments API geht einen anderen Weg. Sie ist für Situationen gedacht, in denen ein Browser den verfügbaren Viewport in mehrere logisch getrennte Bereiche aufteilt – etwa durch einen Falz oder ein physisches Scharnier. CSS und JavaScript können dann Informationen über Größe und Position dieser Segmente erhalten und Inhalte entsprechend verteilen. Dabei sollte allerdings nicht davon ausgegangen werden, dass jedes faltbare Display automatisch zwei solche Segmente bereitstellt. Entscheidend ist, welche Informationen Browser und Betriebssystem tatsächlich zur Verfügung stellen. MDN: Viewport Segments API
Stand 14. September 2026 sind diese speziellen Schnittstellen für eine iPhone-Duo-Optimierung noch keine verlässliche Grundlage. device-posture wird laut den aktuellen MDN-Browser-Kompatibilitätsdaten von Safari nicht unterstützt; die Viewport Segments API wird weiterhin als experimentell und nur eingeschränkt verfügbar geführt. Eine Website sollte deshalb nicht davon abhängig sein, dass Safari einen Faltzustand oder einzelne Displaysegmente bereitstellt. Solche Funktionen eignen sich derzeit vor allem als Progressive Enhancement: Wo der Browser sie unterstützt, kann das Erlebnis verbessert werden – die grundlegende Bedienbarkeit muss aber auch ohne sie erhalten bleiben. MDN: Browser-Kompatibilitätsdaten
Anpassungen nach ihrem tatsächlichen Nutzen priorisieren
Für eine bestehende Website würden wir deshalb nicht mit speziellen Funktionen für faltbare Geräte beginnen. Der sinnvollste erste Schritt ist ein Test der Funktionen, die Besucher tatsächlich benötigen: Funktioniert die Navigation in allen relevanten Größen? Bleiben wichtige Schaltflächen erreichbar? Lassen sich Formulare auch mit eingeblendeter Tastatur vollständig ausfüllen? Verdecken Cookie-Banner, Pop-ups oder feststehende Elemente wichtige Inhalte? Funktionieren gegebenenfalls Produktauswahl, Warenkorb oder andere zentrale Funktionen weiterhin ohne Einschränkungen?
Werden dabei konkrete Probleme sichtbar, sollten diese zuerst behoben werden. Im nächsten Schritt kann geprüft werden, ob sich der zusätzliche Platz auf dem geöffneten Display sinnvoll nutzen lässt – beispielsweise durch bessere Spaltenaufteilungen, kürzere Wege zwischen zusammengehörigen Informationen oder optimierte Abstände.
Erst danach stellt sich die Frage nach speziellen Funktionen für Faltzustände. Solange die Browserunterstützung dafür nicht zuverlässig vorhanden ist, sollten sie eine gut funktionierende responsive Website ergänzen und nicht deren Voraussetzung sein.
Ein neues Smartphone allein ist also kein Grund für einen vollständigen Relaunch. Das iPhone Duo ist vielmehr ein guter Stresstest für Responsive Design: Eine Website, die flexibel mit unterschiedlichen Breiten, Höhen und Nutzungssituationen umgehen kann, ist in der Regel auch für kommende Geräte deutlich besser vorbereitet.
Sie möchten wissen, wie gut Ihre Website auf unterschiedliche Displaygrößen vorbereitet ist? Wir unterstützen Sie bei der Analyse und bei der Umsetzung sinnvoller Anpassungen – vom Screendesign bis zur individuellen WordPress-Programmierung. Projektanfrage stellen.
