Das iPhone Duo verlangt nicht für jede Gerätestellung ein eigenes Interface. Entscheidend ist, ob eine App ihre verfügbare Fläche korrekt liest, Standardsysteme nutzt und auf Größenänderungen reagieren kann. Genau dort zeigen sich bei bestehenden SwiftUI- und UIKit-Apps die meisten Probleme.

Apple weist darauf hin, dass bestehende Apps grundsätzlich auch ohne neue Kompilierung auf dem iPhone Duo laufen. Das bedeutet aber noch nicht, dass sie das Außen- und Innendisplay sinnvoll nutzen. Mit dem iOS 27.1 SDK kommen die vollständige Darstellung bis an die Bildschirmränder, vertikale Bedienelemente und neue APIs für reservierte Bereiche hinzu.

Die wichtigste Regel: Nicht für jede Position ein eigenes Layout bauen

Ein faltbares Gerät kennt viele Zustände. Es kann geschlossen, geöffnet, gedreht oder teilweise gefaltet sein. Dazu kommen Split View, Bild-in-Bild und unterschiedliche Fenstergrößen. Eine Sammlung hart codierter Sonderfälle wird deshalb schnell unwartbar.

Apple empfiehlt, die Oberfläche entlang der verfügbaren Fläche zu gestalten. Compact und Regular Size Classes, Seitenverhältnis, Safe Areas und aktive reservierte Bereiche liefern dafür die relevanten Informationen. Die App soll sich wie ein zusammenhängendes Produkt anfühlen, nicht wie mehrere getrennte Varianten.

1. Mit Xcode 27.1 und dem iPhone Duo Simulator beginnen

Der erste Test sollte nicht mit Vermutungen beginnen. Im iPhone Duo Simulator lässt sich die App öffnen, schließen, drehen und in unterschiedliche Faltpositionen bringen. So wird sichtbar, welche Probleme bereits vorhanden sind und welche Funktionen durch Standardkomponenten automatisch funktionieren.

Für eine erste Prüfung reichen fünf Abläufe: App auf dem Außendisplay starten, auf das Innendisplay wechseln, während einer Detailansicht falten, die Fensterbreite in Split View verändern und die App in beiden Ausrichtungen testen. Navigation, Auswahl und eingegebene Daten sollten dabei erhalten bleiben.

2. Size Classes statt Geräteausrichtung verwenden

Auf dem Außendisplay verhält sich das iPhone Duo ähnlich wie andere iPhones. Das Innendisplay bietet in beiden Dimensionen eine Regular Size Class und damit Platz für Sidebars oder zweispaltige Ansichten. Entscheidungen allein anhand von Hoch- oder Querformat greifen deshalb zu kurz.

// SwiftUI
@Environment(\.horizontalSizeClass) private var horizontalSizeClass
var body: some View {
    if horizontalSizeClass == .regular {
        DetailWithSidebar()
    } else {
        CompactDetail()
    }
}

In UIKit kommt dieselbe Information aus der Trait Collection. Wichtig ist nicht das verwendete Framework, sondern dass die Layoutentscheidung auf der tatsächlich verfügbaren Fläche basiert.

3. Starre Bildschirmannahmen entfernen

Code, der von einer festen iPhone-Breite, symmetrischen Rändern oder einem einzigen Hauptbildschirm ausgeht, ist ein Warnsignal. Auf einem Gerät mit zwei Displays ist UIScreen.main keine verlässliche Grundlage für Layoutentscheidungen. Apple empfiehlt, den Bildschirm aus der jeweiligen Window Scene zu beziehen oder direkt mit Environment, Trait Collection und View Bounds zu arbeiten.

Keine festen Breiten für zentrale Inhaltsbereiche verwenden.
Keine Layoutlogik an ein bestimmtes iPhone-Modell koppeln.
Inhalte nicht anhand der Bildschirmmitte positionieren.
Rotation und Größenänderung nicht als vollständigen Neustart der Ansicht behandeln.

4. Safe Areas auf jeder Seite getrennt behandeln

Safe Areas und Layout Margins können auf dem iPhone Duo asymmetrisch sein. Wer den linken Abstand liest und einfach für rechts übernimmt, riskiert Kollisionen mit Kamera, Statusbereich oder seitlichen Bedienelementen.

Interaktive Inhalte gehören in die Safe Area. Hintergründe und rein dekorative Flächen dürfen darüber hinausreichen. Diese Trennung ist besonders wichtig bei eigenen Toolbars, Vollbildmedien und Interfaces, die bisher mit festen Insets arbeiten.

5. Navigation und Systemkomponenten arbeiten lassen

NavigationSplitView, UISplitViewController, TabView und UITabBarController passen sich laut Apple an die verschiedenen Zustände des iPhone Duo an. Spalten können auf dem Außendisplay reduziert und auf dem Innendisplay nebeneinander dargestellt werden. Auch Sheets, Popovers, Menüs und Alerts berücksichtigen die verfügbare Fläche.

Eigene Navigation ist nicht automatisch falsch. Sie verursacht aber mehr Prüfaufwand. Besonders vertikale Bars, Überlaufzustände und die Erreichbarkeit wichtiger Aktionen sollten dann gezielt getestet werden.

6. Falte und Reserved Regions richtig behandeln

Die Falte ist nicht einfach ein schwarzer Streifen, den jede Ansicht pauschal aussparen muss. iOS beschreibt Scharnier und Kamerabereiche als Reserved Regions. Eine aktive Division Region teilt den nutzbaren Bereich, wenn das Gerät teilweise gefaltet ist. Ist das Gerät flach, kann dieselbe Region inaktiv sein.

Systemcontainer berücksichtigen diese Bereiche häufig automatisch. Bei manuell platzierten Bedienelementen, Karten, Kameravorschauen oder eigenen Overlays muss die App die Regionen selbst abfragen. Fortlaufend scrollende Inhalte wie Artikel oder Feeds sollten normalerweise nicht künstlich verschoben werden. Wichtige Buttons und zusammengehörige Steuerelemente dürfen hingegen nicht auf der Falte landen.

7. Das Innendisplay sinnvoll nutzen

Nur mehr Leerraum ist selten die beste Antwort auf ein größeres Display. Haupt- und Detailansicht, Inhalt und Inspektor oder Medienansicht und Steuerung können auf dem Innendisplay gleichzeitig sichtbar werden. Entscheidend ist, dass die zusätzliche Information einen echten Nutzen hat und die Hierarchie der App erhalten bleibt.

iOS 27.1 stellt dafür Arrangement Views in SwiftUI und UIKit bereit. Eine Split-Anordnung eignet sich für gleichwertige Haupt- und Detailbereiche. Eine Overlay-Anordnung passt, wenn eine Ebene klar im Vordergrund liegt. Wer bereits mit HStack oder VStack arbeitet, findet häufig in der Split-Anordnung die natürlichere Entsprechung.

8. Split View als regulären Zustand testen

Split View ist kein seltener Sonderfall. Die App kann neben einer zweiten App laufen und dabei Breiten annehmen, die auf keinem klassischen iPhone vorkommen. Jede zentrale Ansicht sollte deshalb nicht nur auf Außen- und Innendisplay, sondern auch in mehreren Zwischenbreiten geprüft werden.

Prüfpunkt	Worauf es ankommt
Navigation	Auswahl und Hierarchie bleiben beim Größenwechsel erhalten.
Formulare	Fokus, Tastatur und Eingaben gehen nicht verloren.
Listen und Grids	Spaltenzahl und Abstände reagieren ohne Sprünge.
Sheets und Menüs	Inhalt bleibt sichtbar und erreichbar.
Medien und Kamera	Vorschau, Controls und Seitenverhältnis funktionieren in jeder relevanten Größe.

Was bestehende SwiftUI- und UIKit-Apps meistens brauchen

Eine sauber aufgebaute App braucht oft keinen kompletten Umbau. Bei SwiftUI liegen die häufigsten Aufgaben in flexibleren View-Kompositionen, NavigationSplitView, Size Classes und der Prüfung eigener Overlays. Bei UIKit geht es meist um Auto Layout, Trait Collections, Split View Controller, Scene-basierte Bildschirmwerte und selbst gezeichnete Komponenten.

Aufwendiger wird es bei stark manuellen Layouts, fest verdrahteter Navigation, komplexen Kameraabläufen oder mehreren gleichzeitig aktiven Scenes. Hier lohnt sich zuerst eine Bestandsaufnahme. Sie zeigt, ob wenige gezielte Änderungen genügen oder ein eigener Umsetzungssprint sinnvoll ist.

Kompakte Readiness-Checkliste

Mit dem aktuellen SDK bauen und alle relevanten Gerätestellungen simulieren.
Size Classes und verfügbare Fläche statt Orientation verwenden.
Feste Bildschirmgrößen und Zugriffe auf UIScreen.main prüfen.
Linke, rechte, obere und untere Safe Area separat respektieren.
Standardnavigation vor eigenen Sonderlösungen bevorzugen.
Interaktive Elemente von aktiven Reserved Regions fernhalten.
Split View in mehreren Breiten testen.
App-Zustand beim Öffnen, Schließen und Drehen erhalten.
Kamera, Video und mehrere Scenes gesondert prüfen.
Vor dem Release zusätzlich auf echter Hardware testen.

Wann aus dem Test ein eigenes Projekt wird

Wenn eine App auf Standardkomponenten und flexiblen Layouts basiert, kann die Anpassung überschaubar bleiben. Häufen sich starre Frames, eigene Navigationssysteme und geräteabhängige Annahmen, sollte die Arbeit priorisiert werden. Nicht jeder Befund muss vor dem ersten Tag behoben sein. Kritisch sind blockierte Bedienung, verlorener Zustand, abgeschnittene Inhalte und Funktionen, die nur in einer einzigen Größe nutzbar bleiben.

Für bestehende Apps bietet Keyvity einen iPhone Duo Readiness Check mit SwiftUI und UIKit an. Dabei werden die relevanten Zustände geprüft, Risiken priorisiert und nur die Anpassungen empfohlen, die für die App tatsächlich sinnvoll sind.

Offizielle Apple-Ressourcen

Stand: 15. September 2026. Der Leitfaden basiert auf den aktuell veröffentlichten Apple Developer Tech Talks und wird ergänzt, wenn Apple weitere finale Dokumentation und Werkzeuge bereitstellt.

iPhone Duo Apps: Adaptive Layouts richtig umsetzen