Design für das iPhone Duo: Was sich bewegt, was sich teilt und was bleibt

Was verlangt das Design für das iPhone Duo? Zwei Layouts, nicht ein Layout je Pose: „Ein Layout in compact width für das Außendisplay und ein Layout in regular width für das Innendisplay geben Ihnen die Grundlage für jede Pose”, und Apples eigener Rat lautet, „gestalten Sie Ihre App so, dass sie sich frei in der Größe ändern lässt”. (4:32)12 Auf dieser Grundlage sitzen vier Muster, die der Leitfaden und seine drei begleitenden Tech Talks beschreiben: Bedienelemente wandern an die Seite des Displays und behalten ihre Reihenfolge von oben nach unten; Inhalte werden von diesen Bedienelementen abgesetzt, sofern sie nicht bewusst randlos sind; interaktive Elemente verschieben sich von der Falte weg, scrollende Inhalte dagegen nicht; und ein neuer Container, das Arrangement, teilt oder überlagert zwei Views nach Regeln. Die Talks beschreiben die APIs hinter den letzten beiden Punkten, und Arrangements kommen mit iOS 27.1.3

Apple hat Designing for iPhone Duo am Nachmittag der Keynote in den Human Interface Guidelines veröffentlicht, zusammen mit drei Tech Talks für Designerinnen und Designer: „Design for iPhone Duo”, „Strike a pose with adaptive layouts on iPhone Duo” und „Raise the bar with iPhone Duo”.1234 Der Beitrag aus Entwicklersicht auf dieser Seite rechnet die Punktwerte durch und behandelt die SDK-Regeln. In diesem Text geht es um die Designentscheidungen, die der Leitfaden verlangt, zitiert aus Apples eigenen Worten samt Zeitmarke im jeweiligen Talk, und darum, was ich in meinen eigenen Apps damit vorhabe.

TL;DR: Gestalten Sie für zwei Größenklassen und überlassen Sie dem System die Posen. Leisten werden auf dem Außendisplay und auf dem Innendisplay im Querformat vertikal; einzig das Innendisplay im Hochformat behält horizontale Leisten.4 Elemente mit Symbol wandern in die Vertikale, reine Textelemente bleiben horizontal, und ganz oben in der vertikalen Leiste stehen Back oder Close, gefolgt von einer hervorgehobenen Aktion wie Done.4 Inhalte werden über die horizontale Safe Area von der Leiste abgesetzt, sofern sie nicht immersiv sind und nicht scrollen.2 An der Falte gilt: In der Buchpose „wandern Elemente wie Warnhinweise auf die Trailing-Seite” (4:09), und auf dem Tisch rücken interaktive Bedienelemente in die untere Hälfte, während „durchgehend scrollende Inhalte wie Artikel, Feeds, Dokumente und Listen sich nicht verschieben” (3:46).3 Arrangements sind der neue Layout-Container, entweder Split oder Overlay, und Apples Auswahlregel ist genau die, die Sie ohnehin schon anwenden: Aus einem horizontalen oder vertikalen Stack wird ein Split, aus einem ZStack ein Overlay.3

Watch on Apple Developer ↗

Eine Regel vor allen Mustern

Zwei der Talks und der Leitfaden wiederholen denselben Satz, und von diesem Satz aus sollte man gestalten. Vince aus Apples Designteam: „Menschen werden das iPhone Duo in vielen verschiedenen Posen benutzen, und Sie möchten, dass Ihre App in all diesen Posen großartig aussieht. Das heißt aber nicht, für jede Pose ein eigenes Layout zu entwerfen. Konzentrieren Sie sich stattdessen auf zwei Größenklassen: compact width auf dem Außendisplay und regular width auf dem Innendisplay. Vermeiden Sie feste Breiten, Breakpoints oder irgendwelche Maße, die an einen bestimmten Bildschirm gebunden sind” (3:50).2 Der Leitfaden sagt dasselbe in seinem Abschnitt zu den Posen.1 Vince ergänzt ein optionales Layout, für das Gerät, das wie ein Laptop auf einem Tisch steht: Dort „können Medien oben sitzen, während antippbare Bedienelemente unten auf einer stabilen Basis liegen” (4:48), vorausgesetzt, es „hat dieselben Bedienelemente und dieselbe grundsätzliche Hierarchie wie die anderen Posen” (4:57).2

The foldable iPhone standing half-open on a desk like a small tent, its screen showing a large 9:41 clock

Standbild aus Apples Event-Übertragung vom 9. September 2026, 11:05 Uhr PT: die stehende Pose. Die Aufzählung des Leitfadens lautet „teilweise gefaltet wie ein Buch, auf einer Fläche abgelegt oder auf den Kanten stehend”.

Alles Weitere setzt diese Grundlage voraus – dieselbe Grundlage, die die Checkliste zum größenveränderlichen iPhone prüft und der Beitrag zur iPad-Größenänderung erklärt. Wenn ein Layout aus Größenklassen, Layout-Rändern und Safe-Area-Insets aufgebaut ist, lautet Vinces Versprechen: „Ihre App sollte sich bereits an das iPhone Duo anpassen” (4:27).2

Die Seite: Was dorthin wandert und was bleibt

Auf dem Außendisplay „wandern” Bedienelemente, die bisher oben und unten saßen, „an die rechte Seite des Displays, um den vertikalen Platz zu maximieren und sie mit dem rechten Daumen leichter erreichbar zu machen” (1:18).2 Die Seite trägt die Tab-Leiste, die Symbolleisten, Navigationselemente wie Back, die Statusleiste und die Dynamic Island, „die sich vertikal ausdehnt, sobald Live Activities eintreffen” (1:48).2 Auf dem Innendisplay bleiben die Leisten im Querformat vertikal und kehren im Hochformat zur Horizontalen zurück – „die einzige Pose, in der wir horizontale Leisten beibehalten haben” (5:27), denn „es gibt reichlich vertikalen Platz für App-Inhalte” (5:32).2 In Split View gilt: „Wenn eine App auf der linken Seite liegt, wandern die Bedienelemente ebenfalls an den linken Displayrand” (3:11).2 Und die Leiste richtet sich an der Hardware aus, sie „bleibt deshalb in Sprachen mit Leserichtung von rechts nach links auf derselben Geräteseite” (4:21).4

The foldable iPhone held mid-fold in two hands, its inner display showing a large 41 over a desert photo, with the side-mounted camera and controls at the right edge

Standbild aus Apples Event-Übertragung vom 9. September 2026, 10:59 Uhr PT: das halb gefaltete Gerät mit dem Innendisplay nach vorn und den seitlich angebrachten Bedienelementen an seiner rechten Kante.

Zwei Dinge entscheiden darüber, ob ein bestimmtes Bedienelement vertikal wird. Das erste ist sein Container. Anna aus dem Team UI Frameworks: „Stellen Sie sicher, dass Sie die Leisten verwenden, die Navigationscontainer wie TabView oder NavigationStack bereitstellen” (2:19), denn Inhalte aus eigenen Instanzen von UIToolbar, UINavigationBar oder UITabBar „werden nicht berücksichtigt” (2:58).4 In Split Views „nimmt nur die Detailspalte teil” (3:43), und Inspektoren „erhalten keine eigene” Leiste (3:53).4 Das zweite ist der Inhalt des Elements. Vertikale Leisten haben „eine flexible Elementhöhe und eine feste Breite” (6:10), was „vertikale Leisten besser für Darstellungen geeignet macht, die nur aus Symbolen bestehen” (6:13).4 Deshalb „ändern Elemente mit Symbol, etwa die Buttons Back und Share, ihre Achse in die Vertikale. Und reine Textelemente, etwa der Edit-Button, bleiben weiterhin auf der horizontalen Achse” (7:06).4 Vinces Fassung ist die für das Design: „Symbolleistenelemente, die für den Platz auf der rechten Seite zu breit sind, etwa ein Textbutton oder ein Segmented Control, sollten auf dem iPhone Duo in der Navigationsleiste bleiben” (6:22).2

Die Regel für die Reihenfolge ist kurz. „Reservieren Sie den oberen Bereich für primäre Navigationselemente wie Back oder Close, gefolgt von hervorgehobenen Aktionen wie Done” (4:47).4 In SwiftUI nutzt ein eigenes Back oder Close die Platzierung cancellationAction (5:02) und eine hervorgehobene Aktion topBarPinnedTrailing (5:24); in UIKit ein führendes Element mit leftItemSupplementsBackButton im Standardwert false (5:06) und pinnedTrailingGroup für die hervorgehobene Aktion (5:27).4 Alles Übrige behält seine ursprüngliche Gruppierung, wobei „ein vertikaler Spacer die oberen und unteren Platzierungen visuell trennt” (5:34).4

Die Regeln des Leisten-Talks für einzelne Elemente, jeweils mit ihrem Stichwort:4

  • Der Test für ein eigenes Element: „Verstärkt es lediglich das Symbol, oder trägt es eigenständige Information?” (9:36)
  • Eine Anzahl gehört in ein Badge. Damit wird aus einem Element mit Text und Symbol eines, das nur aus einem Symbol besteht und sich „in einer vertikalen Leiste zu Hause fühlt” (9:23); „ein Warenkorb-Button, der einen Geldbetrag anzeigt”, bleibt horizontal (9:52).
  • Ein Element, das zwischen Symbol und Text wechselt, etwa Edit, bleibt horizontal; der systemeigene Edit-Button tut das bereits, und ein eigenes Element bekommt das rein horizontale AxisBehavior (8:11, 8:32).
  • Eine eigene oder komplexe View bleibt standardmäßig horizontal (8:40); wenn sie „eine vertikale Darstellung unterstützt” (8:48), lässt das auf die Vertikale ausgerichtete Axis Behavior sie in die Leiste (8:54).
  • Geben Sie jedem Element einen Titel, auch wenn es ein Symbol zeigt, denn „das System verwendet ihn, sobald ein Element in ein Overflow-Menü oder eine erweiterte Form wandert” (7:44).
  • Leisten für Tastaturzubehör „sollten an der Tastatur bleiben, statt auf die vertikale Achse zu wechseln” (10:00).
  • Eigene Views lesen die Umgebungseigenschaft toolbarVerticalEdge, in UIKit das entsprechende Trait, um zu erfahren, ob eine vertikale Leiste vorhanden ist (10:35).

Im Overflow zeigen sich die Designprioritäten, und der Talk nennt dazu fünf Regeln:4

  • „Standardmäßig laufen Elemente von unten nach oben in den Overflow” (13:23); jedes Element kann eine hohe, niedrige oder eigene Sichtbarkeitspriorität tragen, zunächst „nach Gruppen” vergeben (13:36), danach innerhalb einer Gruppe. Die APIs für Priorität und Overflow gehören zu den Symbolleisten-Neuerungen der WWDC26, die der Beitrag zu SwiftUI in iOS 27 auf dieser Seite behandelt; bei 13:49 verweist der Talk auf Apples WWDC26-Session zu den Neuerungen in SwiftUI.
  • Entscheiden Sie, was zuerst komprimiert wird: In navigationslastigen Views „wird zuerst die Symbolleiste komprimiert, damit die primären Ziele erreichbar bleiben” (12:07) – das ist der Standard; in aufgabenorientierten Views „wird zuerst die Tab-Leiste komprimiert, um häufig genutzte Aktionen zu erhalten” (12:18), festgelegt über toolbarCompressionBehavior (12:22).
  • Führen Sie das eigene Overflow-Menü der App mit dem des Systems zusammen, in SwiftUI über ToolbarOverflowMenu, in UIKit über additionalOverflowItems (12:36, 12:43), und behalten Sie die Auslassungspunkte allein dem Overflow vor (12:53).
  • „Häufig genutzte Aktionen wie Compose in Mail oder New Note in Notes sollten zu den Letzten gehören, die in den Overflow wandern” (13:59).
  • Elemente mit Badge „sollten länger sichtbar bleiben, damit sie auf einen Blick erfassbar bleiben” (14:11).

Vertikale Leisten sind nicht verpflichtend. Ein einseitiges, unten schwerpunktlastiges Layout wie Calculator oder ein Sheet mit einem einzigen Symbolleistenelement wie Close kann die Leiste über toolbarVerticalBehavior oder preferredVerticalBarBehavior abschalten (14:28, 14:37, 14:47).4

Zentriert oder abgesetzt

Mit der Leiste an einer Seite „sind nun viele Ebenen asymmetrisch” (6:33).2 Vince nennt drei Positionen. Die meisten Inhalte werden abgesetzt, damit sie nicht hinter den Bedienelementen verschwinden, und „wenn Ihre App sich an den horizontalen Safe-Area-Insets ausrichtet, geschieht dieses Absetzen automatisch” (6:58).2 Manche Oberflächen zentrieren weiterhin auf dem gesamten Display, ohne Versatz; das „funktioniert gut bei immersiven, stark visuellen Interfaces, die nicht scrollen, solange Sie sicher sind, dass interaktive Elemente nicht von den Bedienelementen rechts verdeckt werden” (7:10).2 Und beides lässt sich mischen: „ein Hintergrundbild oder ein Header über die volle Breite mit scrollbarem Vordergrundinhalt, der eingerückt ist” (7:22), solange „jedes interaktive Element innerhalb dieses scrollbaren Bereichs liegt, damit nichts verdeckt wird” (7:28).2 Die Anmerkung des Leitfadens zur Safe Area ergänzt den Fall Split View: An der gegenüberliegenden Kante können die Bedienelemente der anderen App liegen, deshalb zählt die Safe Area an beiden Kanten.1

Die Falte: Verschiebung

Macro shot from the keynote of the foldable's display layers fanned out in a stack

Standbild aus Apples Event-Übertragung vom 9. September 2026, 11:08 Uhr PT: die Schichten des Displays. Im teilweise gefalteten Zustand ist die Wölbung durch die Mitte die „folding region” des Leitfadens.

Maria, Human Interface Designer in Apples Designsystem-Team, beginnt mit dem Prinzip: „Großartiges Design für das iPhone Duo hängt daran zu wissen, wann man anpassen muss” (2:25).3 Viele Interfaces „können ganz natürlich um Reserved Regions herumfließen” (2:30), der Rest nutzt Displacement, also Verschiebung, „die den Rahmen bestehender Elemente anhand des verfügbaren Platzes anpasst und wichtige Inhalte sichtbar, erreichbar und unverdeckt hält, selbst wenn das Gerät teilweise gefaltet ist” (2:39).3 Das Muster hat eine Reichweite, „von einem Button bis zu einem ganzen Container oder größeren Teilen eines Layouts” (3:03), und zwei Regeln: „Wenn ein Element sich eigenständig anpassen kann, bewegen Sie es allein. Und wenn Elemente zusammenwirken, bewegen Sie sie gemeinsam, um ihre Beziehung zu erhalten” (3:17), sowie „achten Sie auf übermäßige Bewegung” (3:26), denn „ein Element weit von seinem Ursprung wegzubewegen, schwächt ihre visuelle Beziehung” (3:29).3 Ihr Beispiel ist ein Kontextmenü zu einem ausgewählten Foto: Statt das Menü im Trailing-Bereich zu zentrieren, „bewegen sich beide Elemente gemeinsam und richten sich an der Falte aus” (3:39).3

Die Ausnahme ist die, auf die sich Gestalterinnen und Gestalter am häufigsten stützen werden: „Durchgehend scrollende Inhalte wie Artikel, Feeds, Dokumente und Listen verschieben sich nicht. Diese Erlebnisse passen sich bereits über das Scrollen an, sie zwischen den verfügbaren Bereichen zu bewegen kann die Kontinuität also unterbrechen” (3:46).3 Vince sagt es von der anderen Seite: Das System schiebt interaktive Elemente aus der Wölbung heraus, weil „Buttons schwer zu treffen sind, wenn sie direkt in der Falte landen” (9:28); das Verhalten steckt in „Sheets, Warnhinweisen, Menüs, Symbolleisten-Buttons und mehr” (9:40), und „scrollbarer Inhalt muss diesen Bereich nicht meiden” (9:57).2

Die Ausrichtung der Falte legt die Bereiche fest: In der Buchpose verläuft sie vertikal, die Bereiche sind links und rechts; auf dem Tisch oder im Hochformat verläuft sie horizontal, die Bereiche sind oben und unten.23 Wohin ein verschobenes Element wandert, hängt von der Pose ab, und Marias Begründungen sind der nützliche Teil. In der Buchpose „wandern Elemente wie Warnhinweise auf die Trailing-Seite. Das hält sie näher an der Stelle, an der sie erscheinen werden, wenn das Gerät sich schließt und das Erlebnis auf dem Außendisplay weitergeht” (4:09).3 Auf einem Tisch aufgestellt gilt: „Der obere Bereich eignet sich gut für Inhalte, die von Sichtbarkeit auf Distanz profitieren” (4:29), und „der untere Bereich eignet sich gut für interaktive Bedienelemente” (4:39), wo „antippbare Elemente wie Mediensteuerungen hinwandern können und so eine stabilere Fläche für die Berührung bieten” (4:43).3 Der Talk zu den Prinzipien stimmt zu: Im Hochformat und teilweise gefaltet „wandern interaktive Elemente in die untere Hälfte des Displays; das macht sie leichter erreichbar und hält das Gerät zugleich stabil auf der Fläche” (2:33).2 Wenn mehrere Bereiche infrage kämen, bleiben Sie kontextbezogen: Ein Suchfeld „nutzt den zusätzlichen Platz” (5:00), wenn das Gerät geöffnet ist, und während es sich faltet, passen sich „Breite und Position so an, dass es über der durchsuchten View bleibt” (5:04).3

Das meiste davon erledigt das System. „Action Sheets, Warnhinweise, Menüs und Popover sind allesamt leichtgewichtige kontextbezogene Erlebnisse, die über einer Reserved Region erscheinen können” (5:23), und es „positioniert Komponenten rund um die Reserved Region automatisch neu” (5:34).3 Eine Split View „hält beide Spalten sichtbar, indem sie deren Breite anpasst und sie in einer gleichmäßigen 50/50-Teilung anordnet” (5:40).3 Ein Raster ist der Fall, den Sie selbst verantworten: In Marias Fitness-Entwurf „kann ich die äußeren Ränder beibehalten und zugleich den Abstand rund um das Scharnier vergrößern, sodass jeder Container in seinem Bereich bleibt” (5:56).3 Ihre Zusammenfassung aller Beispiele ist zugleich das Briefing: „Wir bewegen, skalieren oder reorganisieren das, was ohnehin schon da ist. Halten Sie Inhalte, Funktionen und Layouts verfügbar, damit Menschen auf das vollständige Erlebnis zugreifen können, unabhängig davon, wie sie das iPhone Duo gerade nutzen” (6:04).3

Reserved Regions, die Mechanik hinter der Verschiebung

Maria führt den Begriff im Talk zu adaptiven Layouts ein: „Auch neue Hardwaremerkmale prägen den verfügbaren Platz mit. Dazu zählen das Scharnier und die zwei Kameras auf Außen- und Innendisplay. Wir nennen das Reserved Regions” (0:37), und rät, sie „genau wie alle anderen Bereiche zu behandeln, an die sich Ihr Layout ohnehin schon anpasst” (0:53) – ihr Beispiel sind die Fenstersteuerungen unter iPadOS.3 Es gibt drei davon: die äußere Kamera, die innere Kamera, solange sie aktiv ist, und die Falte (1:00, 1:18, 1:32).3 Der Beitrag aus Entwicklersicht enthält die Definitionen des Leitfadens zu jeder einzelnen und hält meine Prüfung fest, dass der Leitfaden für die APIs keine Dokumentation verlinkt; dieser Abschnitt bleibt deshalb bei der Mechanik.1 Harry, Engineer im Team UI Frameworks, beschreibt die API: „In SwiftUI fragen Sie Reserved Regions über eine GeometryProxy aus einem GeometryReader oder dem Modifier onGeometryChange ab. Verwenden Sie die neue Methode reservedRegion auf der Geometry Proxy, um die in Ihrer View verfügbaren Bereiche zu erhalten.” (6:38) In UIKit „verwenden Sie die Methode reservedRegion, die auf UIView verfügbar ist” (7:03), und „Sie können die Eigenschaft frame einer Reserved Region abfragen, um sie in Ihr eigenes Layout einzubeziehen” (7:07).3

Es gibt zwei Arten. Die Falte „wird von einer Division Reserved Region getragen, weil sie eine größere Fläche in mehrere kleinere Flächen unterteilt” (6:55), und sie „ist nur aktiv, wenn jemand das Gerät gefaltet hat. Flach ausgeklappt ist sie inaktiv und hat eine Breite von null” (7:26).3 Die Kamera ist eine Occlusion Region: Diese „unterteilen keine Flächen, sondern verdecken sie” (7:54), und der Bereich „ist aktiv, wenn die Kamera aktiv ist, und inaktiv, wenn die Kamera inaktiv ist” (8:12).3 Inaktive Bereiche lassen sich mit der Option includeInactive abfragen, und Harrys Grund, sie überhaupt zu betrachten, ist eine Designentscheidung: „In rasterartigen Layouts könnten Sie eine gerade Spaltenzahl bevorzugen, sobald eine Division Region vorhanden ist – unabhängig von ihrem Aktivitätszustand” (7:41).3 Der Leitfaden wiederholt das als Regel.1 Am Tag der Keynote verlinkte der Leitfaden um 16:15 Uhr PT für diese APIs keine Dokumentationsseite, und Apples Entwicklerseite datiert die Beta von Xcode 27.1 auf „später in diesem Monat”.15

Arrangements: Split oder Overlay

Keynote slide: 80% larger display than iPhone 18 Pro

Standbild aus Apples Event-Übertragung vom 9. September 2026, 11:00 Uhr PT: das Innendisplay, das Apple 80 Prozent größer nennt – die Fläche, für die Arrangements gedacht sind.

Harrys Definition: „Zwischen diesen Navigations- und Content-Containern sitzt ein Layout-Container. Diese Layout-Container ordnen zwei Views nach einer Reihe von Regeln an. Sie heißen Arrangements” (9:20).3 Die Regeln nehmen Eingaben entgegen, „die horizontale und vertikale Größenklasse der View, das Seitenverhältnis aus Breite zu Höhe der View und die Frage, ob aktive Division Regions vorliegen” (10:37), und erzeugen Ausgaben: „ob ich die View überhaupt anzeigen sollte” (10:52) und, falls ja, „wie ihr Rahmen aussieht” (10:54).3 Dann das Datum: „In iOS 27.1 können Sie systemseitig bereitgestellte Arrangements in Ihren eigenen Apps verwenden” (11:02).3

In SwiftUI nimmt eine ArrangementView eine primäre und eine sekundäre View entgegen (11:25), der Stil wird über arrangementViewStyle gesetzt (11:57); in UIKit nimmt ein UIArrangementViewController primäre und sekundäre View Controller entgegen (11:39).3 Der Split-Stil, der Standard, „teilt horizontal, wenn die View breiter als hoch ist” (12:13), und vertikal, wenn sie höher ist; er lässt sich auf eine Achse beschränken, und wenn er auf seiner primären Achse nicht teilen kann, „entscheidet er sich, nur eine einzige View zu zeigen” (12:49).3 Der Overlay-Stil „positioniert Inhalte bevorzugt über- oder untereinander” (13:31), und wenn das Gerät sich faltet, „positioniert er primäre und sekundäre View bevorzugt nebeneinander” (13:51), was eine View über die Umgebungseigenschaft overlayArrangementZIndex erkennen kann, um zwischen eingeklappter und ausgeklappter Form zu wechseln (14:01).3

Die Wahl zwischen beiden ist der klarste Rat des Talks, und der Leitfaden übernimmt ihn: „Wenn Sie in Teilen Ihrer App bereits ein splitartiges Layout mit Komponenten wie einem HStack oder VStack umsetzen, ziehen Sie das Split-Arrangement in Betracht. Wenn Sie in Teilen Ihrer App bereits ein overlayartiges Layout mit Komponenten wie einem ZStack umsetzen, ziehen Sie das Overlay-Arrangement in Betracht” (14:44).3 Ohne bestehendes Muster nehmen Sie ein Overlay, „wenn zwischen Ihren Views eine klare Vordergrund-Hintergrund-Beziehung besteht” (15:10), etwa Bedienelemente über lesbarem Inhalt im Accessibility Reader, und einen Split, „wenn es eher eine Beziehung von Haupt- und Detailansicht ist” (15:32), etwa ein Podcast und sein Transkript, wo „es wichtig ist, dass keines von beiden je verdeckt wird” (15:43).3 Die beiden Grenzen – Navigationscontainer um ein Arrangement herum statt darin, und kein Arrangement innerhalb einer List oder ScrollView – stehen bei 16:15 und 16:26 im Talk; der Leitfaden nennt nur die erste, in dem Satz, den der Beitrag aus Entwicklersicht zitiert.13

Das Innendisplay: drei ehrliche Layouts

„Sie wollen nicht einfach eine auseinandergezogene iPhone-App” (7:39).2 Vince bietet drei Formen an. Eine Split View, die „mehrere Ebenen Ihrer App-Hierarchie gleichzeitig” zeigt (7:46), unter der Bedingung, dass die Hierarchie „sich zwischen Außen- und Innendisplay nicht ändert” (7:51), denn Menschen „öffnen und schließen das Gerät womöglich häufig, während sie Ihre App nutzen; sie muss innen wie außen vorhersehbar und konsistent sein” (7:59).2 Ein Reflow nach dem Vorbild von Music, bei dem „ein vertikal gestapeltes Layout” (8:15) zu „einem zweispaltigen Layout wird, sobald mehr horizontaler Platz da ist” (8:18).2 Oder eine Tab-Leiste, die „auf dem Innendisplay als Seitenleiste” erscheint (8:26), was „am besten für informationsdichte Apps funktioniert, wie in diesem Beispiel aus Health” (8:33).2 Das Mail-Beispiel des Leitfadens ist der Fall Split View: geschlossen eine Liste oder eine Nachricht, geöffnet beides nebeneinander.1

Sheets haben eigene Regeln. Auf dem Außendisplay „wandern auch die Bedienelemente eines Sheets an die Seite” (8:46), was Sie für ein Sheet mit einem einzigen Symbolleisten-Button abschalten können; dann „enden Sheets knapp vor der Frontkamera, und die Statusleiste positioniert sich selbst neu” (9:04).2 Auf dem Innendisplay nutzen Sheets standardmäßig „normale horizontale Leisten” (9:13), und wenn das Gerät teilweise gefaltet ist, „rutschen sie zur Seite, um nicht in der Falte zu liegen” (9:20).2 Der Leisten-Talk ergänzt die Ausnahme zur Platzierung: Sheets auf dem Innendisplay sind „standardmäßig zentriert, und die Elemente bleiben horizontal” (4:03), aber mit der API preferredPlacement gilt: „Sheets, die links platziert sind, bleiben ohne vertikale Leiste, während Sheets rechts eine erhalten” (4:11).4

Die Prüfliste

Der Leisten-Talk und der Talk zu adaptiven Layouts enden jeweils mit einer Prüfliste, hier sind sie als eine. Die Abschlussliste des Leisten-Talks (15:10): mit den aktuellen SDKs bauen, denn die vertikalen Leisten sind per SDK ein Opt-in (2:06); die Leisten und ihre Reihenfolge prüfen (4:41) und eigene Elemente so aktualisieren, dass sie sich vertikal anordnen lassen; und Sichtbarkeitsprioritäten vergeben, „damit das System sich anpassen kann” (15:26).4 Dann, aus dem Talk zu adaptiven Layouts (16:40): „Beginnen Sie damit, die zentrierten Layouts Ihrer App zu prüfen. Überlegen Sie, ob Sie daraus ein zweispaltiges Layout machen können oder welches Verschiebungsmuster in diesem Anwendungsfall sinnvoll ist”; Standardcontainer und Standardpräsentationen nutzen, um das Verhalten geschenkt zu bekommen (16:49); für eigene Split- oder Overlay-Layouts zu ArrangementView greifen; und „die manuell angeordneten Bedienelemente mit der höchsten Priorität in Ihren Views identifizieren und in Betracht ziehen, die ReservedRegions-API zu übernehmen, um dort, wo nötig, eine eigene Verschiebung umzusetzen” (17:06).3

Was ich damit vorhabe

Drei meiner Apps sind iPhone-Apps, und der Leitfaden sortiert sie sauber. Die Einordnung ist meine Lesart, nicht Apples.

  • Get Bananas ist eine Liste. Listen verschieben sich nicht, Tab-Leiste und Symbolleiste wandern von selbst an die Seite, solange ich die Systemcontainer weiter nutze, und die eine Designentscheidung ist die Sichtbarkeitspriorität: Die Aktion zum Hinzufügen eines Eintrags ist mein Compose, sie sollte also als Letztes in den Overflow wandern.
  • Reps protokolliert jeden Satz als Zeile aus Gewicht, Wiederholungen und einer Aktion zum Eintragen, während des Trainings in einem Raster – genau Marias Fitness-Beispiel. Die Entscheidung: In der Buchpose legt eine dreispaltige Zeile die mittlere Spalte auf das Scharnier, das Raster wird deshalb zu zwei paarweisen Spalten. In der Tischpose sitzt die Aktion zum Eintragen in der unteren Hälfte. Der Kompromiss ist ein zusätzlicher Fingertipp pro Satz gegen ein Ziel, das nie in der Falte landet, wo laut Vince „Buttons schwer zu treffen sind” (9:28).2 Der Pausentimer bleibt oben, in dem Bereich, der laut Maria gut für „Inhalte, die von Sichtbarkeit auf Distanz profitieren” (4:29), funktioniert.3
  • Return zeichnet Gesundheitsdiagramme, und das sind scrollende Inhalte. Wo heute ein Diagramm und sein Zeitraum-Picker in einem vertikalen Stack sitzen, bildet Harrys Regel diesen Stack auf ein Split-Arrangement ab, das beide sichtbar hält, während das Gerät sich faltet; das Diagramm selbst sollte sich nie verschieben.

Die wichtigsten Erkenntnisse

Für Designerinnen und Designer: - Zwei Größenklassen, keine Posen: compact width außen, regular width innen.1 Die einzige optionale Ergänzung, die Apples Designteam vorschlägt, ist ein Tischlayout, das dieselben Bedienelemente behält.2 - Symbole werden vertikal, Text bleibt horizontal; oben in der seitlichen Leiste stehen Back oder Close, dann Done; häufige Aktionen und Elemente mit Badge wandern zuletzt in den Overflow.4 - Scrollende Inhalte verschieben sich nie; Warnhinweise, Menüs, Sheets und Bedienelemente schon, und das Ziel folgt dem Zweck: Warnhinweise in der Buchpose auf die Trailing-Seite und auf dem Tisch in den oberen Bereich, Bedienelemente für die Berührung in die untere Hälfte.23

Für Design Engineers: - Die Falte ist eine Division Region, die nur im gefalteten Zustand aktiv ist und flach eine Breite von null hat; die innere Kamera ist eine Occlusion Region, die nur aktiv ist, solange die Kamera es ist; beide lassen sich über eine GeometryProxy oder eine UIView abfragen.3 - Arrangements kommen mit iOS 27.1: Aus einem Stack wird ein Split, aus einem ZStack ein Overlay, und Navigationscontainer bleiben außerhalb.3 - Nutzen Sie die Systemleisten aus Navigationscontainern, sonst kommt das vertikale Layout nie zustande.4

Häufige Fragen

Brauche ich für jede Pose ein eigenes Layout?

Nein. Apple rät, für zwei Größenklassen zu gestalten – compact width auf dem Außendisplay und regular width auf dem Innendisplay – und feste Breiten, Breakpoints oder an einen Bildschirm gebundene Maße zu vermeiden.12 Die einzige optionale Ergänzung, aus dem Design-Talk, ist ein Layout für die Tischpose mit denselben Bedienelementen und derselben Hierarchie.2

Welche Bedienelemente bleiben auf dem iPhone Duo horizontal?

Reine Textelemente, für die seitliche Leiste zu breite Elemente wie Segmented Controls, Elemente, die zwischen Symbol und Text wechseln, etwa Edit, Leisten für Tastaturzubehör und, wenn Sie es so wählen, die gesamte Leiste in einer einseitigen App mit Schwerpunkt unten oder in einem Sheet mit einem einzigen Symbolleistenelement.24

Was ist Verschiebung?

Apples Muster, bestehende Elemente zu bewegen, in der Größe zu ändern oder neu zu organisieren, damit sie sichtbar und erreichbar bleiben, wenn das Gerät teilweise gefaltet ist. Warnhinweise, Menüs, Popover, Sheets und Symbolleisten-Buttons bekommen es vom System; scrollende Inhalte sind ausgenommen.23

Wann erscheinen Arrangement Views und die APIs für Reserved Regions?

Der Talk zu adaptiven Layouts nennt iOS 27.1 als Version, ab der sich systemseitig bereitgestellte Arrangements in eigenen Apps nutzen lassen, und Apples Entwicklerseite datiert die Beta von Xcode 27.1 auf den späteren September. Der Designleitfaden verlinkt für keine der beiden APIs bislang eine Dokumentation.135

Muss scrollender Inhalt die Falte meiden?

Nein. Sowohl der Design-Talk als auch der Talk zu adaptiven Layouts nehmen scrollende Inhalte aus; sie passen sich bereits über das Scrollen an.23

Quellen


  1. Apple Human Interface Guidelines, Designing for iPhone Duo, Eintrag im Änderungsprotokoll vom 9. September 2026 („New page”), abgerufen am 9. September 2026 um 16:15 Uhr PT. Zitiert: der Satz zu den Größenklassen und die Liste der Posen. Sinngemäß wiedergegeben: die drei Reserved Regions, die Regel zur geraden Spaltenzahl, das Mail-Beispiel und die Anmerkung zur Safe Area bei Split View. ↩↩↩↩↩↩↩↩↩↩↩↩

  2. Apple Developer Tech Talk, Design for iPhone Duo, Marcos und Vince, Apple Designteam. Die Zitate stammen aus der englischen Untertitelspur des Talks an den in Klammern angegebenen Zeitmarken. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩

  3. Apple Developer Tech Talk, Strike a pose with adaptive layouts on iPhone Duo, Maria, Human Interface Designer, und Harry, Engineer im Team UI Frameworks. Die Zitate stammen aus der englischen Untertitelspur des Talks an den in Klammern angegebenen Zeitmarken; die API-Namen sind so wiedergegeben, wie sie im Talk gesprochen werden. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩

  4. Apple Developer Tech Talk, Raise the bar with iPhone Duo, Anna, Engineer im Team UI Frameworks, und Maria, Human Interface Designer. Die Zitate stammen aus der englischen Untertitelspur des Talks an den in Klammern angegebenen Zeitmarken; die API-Namen sind so wiedergegeben, wie sie im Talk gesprochen werden. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩

  5. Apple Developer, Get Ready for iPhone Duo, abgerufen am 9. September 2026 um 16:10 Uhr PT: „Xcode 27.1 beta … Coming later this month”; anstelle des früheren „Coming soon” ist nun der Designleitfaden verlinkt. ↩↩

Verwandte Beiträge

Typografie-Skalen: Warum ich 13 Stufen gewählt habe und weshalb das Verhältnis entscheidend ist

Meine Typskala hat 13 Stufen von 12px bis 80px: wie ich das Verhältnis wählte, warum Systemschriften besser sind und was…

9 Min. Lesezeit

Schönheit und Brutalismus: Wie ich blakecrosley.com an der Schnittstelle gestaltet habe

Ich habe meine Website an der Schnittstelle von Schönheit und Brutalismus gebaut: strukturelle Ehrlichkeit mit präziser …

10 Min. Lesezeit

16 Design-Fallstudien: Die vier Muster, die ich in meine eigene Arbeit übernommen habe

Nach der Analyse von 16 Produkten: vier übergreifende Muster, die meine Herangehensweise an Interface-Design verändert h…

9 Min. Lesezeit