Was ist das Problem?
Das Außendisplay des iPhone Duo misst 382 x 578 CSS-Pixel bei einer Pixeldichte von 3. Uns fiel beim ersten Gerätecheck auf: Die Website füllte das Display nicht. Rechts lief ein Streifen neben dem Inhalt, in dem die Seitenfarbe stand, links blieb ein dunkler Rand. Das Display ist klein, jeder Rand ist verschenkte Fläche.
Die Ursache ist kein Fehler im eigenen CSS. Safari behandelt die rechte Anzeigezone des Duos, in der die Kamera sitzt, als Sperrbereich. Bei einem Layout in Gerätebreite, also 382 Pixel, darf die Seite dort nicht malen. Der Streifen rechts ist genau dieser Sperrbereich. Wir haben das Verhalten bei anderen Seiten nachgesehen und es dort ebenfalls gefunden. Es ist Safari-Verhalten, kein Seitenfehler.
Zusätzlich färbte sich die Adressleiste teilweise in der Vorhangfarbe unserer Seite. Auch das ist Safari 26: Der Browser sampelt Farben von der Seite und legt sie auf die Leisten. Beides zusammen nahm dem kleinen Display weiteren Platz.
Warum der Viewport-Trick nötig ist
Der Weg zur Vollfläche führt über einen bewussten Verstoß gegen die übliche Regel. Statt des Meta-Tags mit Gerätebreite setzen wir eine feste Layout-Breite von 460 Pixeln:
<meta name="viewport" content="width=460, initial-scale=1, viewport-fit=cover">
Safari rendert die Seite daraufhin in 460 Pixeln Breite und skaliert sie auf das 382 Pixel schmale Sichtfeld herunter. Die Skalierung gehört dabei zum Konzept: Weil das Layout breiter ist als das Sichtfeld, malt die Seite auch unter dem Sperrbereich an der rechten Kante. Das Display ist komplett gefüllt.
Zoom erzwingen lässt sich dieser Zustand nicht über JavaScript. Das visualViewport-Objekt ist eine Lese-Schnittstelle, Skalierungen stehen dort nur zum Auslesen bereit. Wer zoomen will, muss es über das Meta-Tag deklarieren.
Wie der Fix aussieht
Das feste Viewport-Meta allein reicht nicht. Es erzeugt eine zweite Folge, mit der der Rest des Umbaus umgeht: Layout-Breite 460 und Sichtfeld 382 differenzieren um 78 Pixel. Diese 78 Pixel sind ein Pan-Raum. Ohne Gegenmaßnahmen lässt sich die Seite mit dem Finger seitlich verschieben, und alles, was dort liegt, ist nicht anklickbar. Vier Baustellen haben wir dafür dokumentiert:
- Vollflächenbänder: Bänder, die mit Viewport-Einheiten arbeiten, müssen an der Layout-Breite ausgerichtet werden. Am Duo löst Safari diese Einheiten anders auf als der umgebende Container. Wir setzen die Layout-Breite deshalb per JavaScript in eine CSS-Variable und rechnen alle Bänder darauf um. Gemessen am Gerät: Vor der Umstellung lief ein Vorhangband auf 382 Pixel, während die Sektion 460 breit layerte. Nach der Umstellung folgt es dem Layout.
- Adressleiste: Safari 26 sampelt Farben fixierter Vollflächenelemente und legt sie auf die Leisten. Solange ein opakes Element an der Kante klebt, bleibt der Balken stehen, egal welche Farbe er hat. Zwei solcher Elemente hatten wir: ein Struktur-Overlay und einen Effekt-Canvas. Beide sind jetzt sektionsgebunden statt fixiert. Danach kollabierte die Leiste wieder.
- Dialoge und Menüs: Alle Dialoge, Menüs und Lightboxen bemessen ihre Breite jetzt am Sichtfeld, nicht an der Layout-Breite, und lassen sich am Sichtfeld ausrichten. Vorher reichte der halbe Dialog in den Pan-Raum, dort landen keine Touch-Ereignisse. Menüpunkte und Lightbox-Schalter waren nicht bedienbar, ohne dass irgendein Test das meldete.
- Seitlicher Versatz: Ebenen, die in den Pan-Raum malen, erzeugen das Gefühl der verschiebbaren Seite. Der Effekt-Canvas des Goldregens läuft sektionsgebunden und auf Sichtfeldbreite geklemmt.
Eine Besonderheit von Safari haben wir dabei bewusst in Kauf genommen: Die nativen Dialog-Fokussierschritte scrollen den Seitenanfang beim Öffnen in den Pan-Raum. Dialoge deshalb nicht mehr mit der Modal-Methode zu öffnen, sondern als normale Ebene mit eigenem Scroll-Lock, gehört mit zum Fix.
Warum das keine Kleinigkeit ist
Wir haben fünf Tage an diesem Display gesessen. Nicht weil der Fix langwierig ist, sondern weil die Fallstricke versteckt sind. Headless-Browser-Tests laufen grün, weil Chromium die Viewport-Einheiten gegen die Layout-Breite auflöst und den Pannraum nicht kennt. Fehler, die nur am Gerät auftreten, sieht man dort nicht. Wir haben jeden Fix erst am echten Duo geprüft.
Und es gibt einen echten Anreiz, sich mit dem Außendisplay zu beschäftigen: Wir nutzen ein Duo selbst und lassen es im Alltag überwiegend geschlossen. Das Außendisplay ist damit für viele der erste Kontakt mit einer Website. Wer dort Ränder zeigt, verschenkt den ersten Eindruck.
Welche Fehlerbilder es gibt
Im Einzelnen haben wir diese Fehlerbilder dokumentiert und behoben:
- Balken rechts: Safari sperrt die rechte Anzeigezone für Seiteninhalte. Fix: Viewport-Meta mit fester Layout-Breite 460, die Seite malt beim Skalieren unter den Sperrbereich.
- Seite seitlich verschiebbar: Layout-Breite größer als Sichtfeld erzeugt Pannraum. Fix: Kein Inhalt im toten Streifen, Dialoge und Effekte auf Sichtfeldbreite klemmen.
- Menü nicht anklickbar: Der Dialog zentriert auf dem Layout-Viewport und ragt in den Pannraum. Dort landen keine Touch-Ereignisse. Fix: Dialoge auf Sichtfeld klemmen.
- Adressleiste färbt sich um: Safari 26 sampelt Farben fixierter Vollflächenelemente an den Kanten. Fix: keine opaken fixierten Vollflächenelemente an den Kanten.
Häufige Fragen zum Duo-Außendisplay
Welche CSS-Pixel misst das Außendisplay des iPhone Duo?
382 x 578 CSS-Pixel bei einer Pixeldichte von 3, im geschlossenen Zustand des Geräts. Aufgeklappt nutzt die Website den Desktop-Build ab 761 Pixeln Breite.
Muss ich meine Website für 382 Pixel umbauen?
Die mobile Ansicht bleibt bestehen, sie wird ergänzt. Das feste Viewport-Meta sorgt für die Skalierung, die vier Baustellen aus dem Artikel fangen die Folgen ab. Wer keine fixierten Vollflächenelemente und keine viewport-basierten Bänder hat, hat weniger Arbeit. Aufgeklappt nutzt das Duo den Desktop-Build ab 761 Pixeln Breite.
Warum zeigen meine Tests den Fehler nicht?
Chromium-basierte Tests lösen Viewport-Einheiten gegen die Layout-Breite auf und kennen den Pannraum nicht. Der Fehler existiert nur am Gerät. Wer ein Duo besitzt, testet dort. Wer keins besitzt, kann die Skalierung mit einem Browser-Override simulieren, muss dann aber die Auflösung der Einheiten prüfen.
Was kostet die Anpassung einer bestehenden Website?
Das hängt vom Aufbau ab. Websites mit wenigen Vollflächenelementen und zentrierten Dialogen sind in einem Tag angepasst. Websites mit fixierten Effekt-Layern, eigenem Dialogsystem und viewport-basierten Bändern brauchen zwei bis drei Tage, inklusive Gerätetest. Unsere eigene Website gehört zur zweiten Kategorie und hat fünf Tage gebraucht, weil wir das Display-Verhalten von Null auf dokumentieren mussten. Diese Recherche liegt jetzt, einer Anpassung steht nichts im Weg.
Was möchten Sie umsetzen?
Schreiben Sie uns. Wir melden uns werktags in der Regel am selben Tag.
QLTY IS ALL GmbH · Barbarossaplatz 7 · 50674 Köln







iPhone Duo: Warum 9:16 allein nicht mehr reicht
KI im Marketing: die aktuellen Zahlen