Ihre App für das iPhone Duo vorbereiten: ein durchgespieltes Beispiel

Wie bereiten Sie eine App auf das iPhone Duo vor? Bauen Sie sie mit dem iOS-27.1-SDK, schicken Sie sie im Simulator durch jede Pose, beheben Sie, was dieser Rundgang zeigt, und planen Sie die Einreichung um zwei Termine herum, die Apple noch nicht genannt hat. Das iPhone Duo kommt am 23. Oktober mit iOS 27.1 in den Handel.¹ Was eine App darauf bekommt, entscheidet die SDK-Version, die in ihr Binary gestempelt ist: Ein und dieselbe Quelldatei, gelinkt als 26.0, 27.0 und 27.1, erschien als telefongroßer Kasten, als Fenster neben der Statusleiste am Rand und als ganzer Bildschirm mit den Leisten an der Seite und gemeldetem Falz.¹² Stand 2. Oktober stempeln nur Apples Betas 27.1 oder neuer (Xcode 27.1 beta, das den Duo-Simulator enthält, und Xcode 27.2 beta), und App Store Connect nimmt ihre Builds für TestFlight an, nicht für den Store.⁸ Dieser Beitrag erledigt die ganze Arbeit an Kiradex, einer Sammler-App für Sammelkarten, die wir in TestFlight haben: was ohne eigenes Zutun funktionierte, was der Rundgang fand und das Lesen des Codes nicht, die Screenshots für beide Displays und ein Briefing, das Sie einem Coding-Agenten übergeben können.

Das Wichtigste in Kürze

• Der SDK-Stempel ist der Schalter. iOS liest die SDK-Version im LC_BUILD_VERSION des Binarys. Mit Stempel 27.1 bekam die Probe-App den ganzen Bildschirm, geschlossen 466 mal 678 Punkte und offen 951 mal 669, mit senkrechten Leisten und reservierten Regionen. Mit Stempel 27.0 endete sie 80 Punkte vor dem Rand, an dem die Statusleiste sitzt, behielt waagerechte Leisten und erfuhr nichts über den Falz. Mit Stempel 26.0 war sie ein 375 mal 667 großes Telefon in einem Kasten. Prüfen Sie Ihr Binary mit otool -l.¹²
• Der Kalender hat zwei offene Termine. TestFlight nimmt seit dem 18. September Builds mit dem 27.1-SDK an und seit dem 16. September Builds der 27.2-Beta; der App Store nimmt nur Builds mit dem 27.0-SDK an; die Screenshot-Größen für das Duo sind veröffentlicht, und ihr Upload „will be available later this year“ (wird im Laufe des Jahres möglich).⁸⁹ Ein Schlüssel für den Startbildschirm ist beim Upload inzwischen Pflicht.¹⁰
• Den Großteil erledigten die Systemcontainer. Ein TabView, ein NavigationStack in vier seiner fünf Tabs und Toolbar-Elemente mit Titel und Symbol brachten die Leisten von Kiradex ohne jeden Duo-Code an die Seite. Ein einziges ArrangementView teilte das geöffnete Display und verschob seine Trennlinie in der Pose Book auf den Falz. Ein einziges onHingeChange spielt die Eröffnung der App erneut ab, wenn sich das Telefon aufklappt.¹³
• Der Rundgang fand, was das Lesen nicht fand. Ein Sheet, dessen einziger Button ein Text-„Done“ ist, reserviert die seitliche Leiste und lässt sie leer. Die Vollbildkarte läuft unter die äußere Kamera. Ins Hochformat gedreht, stapelt sich die Teilung. Eine Karte, die beim Aufklappen offen bleibt, landet im kompakten Layout und wird gestreckt. Das für das innere Display geschriebene Layout für reguläre Breite bricht auf einem 6,9-Zoll-iPhone im Querformat.¹³
• Bis der Store 27.1 annimmt, braucht ein Quellbaum zwei Xcodes. #available hilft nicht; das 27.0-SDK hat kein ArrangementView, gegen das kompiliert werden könnte. Eine Compilation Condition oder #if canImport(SwiftUI, _version: 8.0.85) grenzt die neuen Aufrufe ein.¹⁴
• Die Screenshots entstehen im selben Durchlauf. Die Aufnahmen des Simulators haben genau die Größen von App Store Connect, und genau so groß sind die Öffnungen in Apples Duo-Rahmen. Apples Regeln verlangen weiterhin frontal, unverändert und keine 3D-Renderings des Geräts.⁹¹¹

Der Stand am 2. Oktober

Drei dieser Zeilen warten auf Apple, und keine davon blockiert die Arbeit. Aus der Tabelle folgt diese Reihenfolge: die App auf das 27.1-SDK und in den Simulator bringen, sie durch jede Pose schicken, beheben, was der Rundgang zeigt, diesen Build in TestFlight stellen und die Store-Einreichung samt Duo-Screenshots für den Tag bereithalten, an dem sich das jeweilige Tor öffnet.

Apples eigener Ausgangspunkt ist der erste seiner sechs Tech Talks, zehn Minuten lang, und alles Folgende setzt ihn voraus:

Schritt eins: Der SDK-Stempel entscheidet, was das Telefon Ihnen gibt

Der Talk beginnt mit einem Kompatibilitätsversprechen in drei Stufen. Eine App, die nicht mit dem iOS-27-SDK gebaut wurde, läuft trotzdem: „When the device is closed, your app will use the screen space to the left of the status bar and camera. When the device is open, your app will be a familiar size and aspect ratio.“ (Geschlossen nutzt die App den Platz links von Statusleiste und Kamera, geöffnet hat sie eine vertraute Größe und ein vertrautes Seitenverhältnis.) (0:36) Eine App, die das iOS-27-SDK übernommen hat, „will extend to the left of the status bar area on the inner display.“ (reicht auf dem inneren Display bis links an den Bereich der Statusleiste.) (0:58) Und dann: „When you build your app with the iOS 27.1 SDK, your app extends to the edge of the screen. Standard navigation and toolbar buttons now lay out vertically under the status bar.“ (Mit dem iOS-27.1-SDK reicht die App bis an den Bildschirmrand, und die Standardbuttons für Navigation und Toolbar ordnen sich senkrecht unter der Statusleiste an.) (1:05)³

Diese Stufen sind keine Eigenschaft Ihres Codes. Sie sind eine Eigenschaft einer einzigen Zahl in Ihrem Binary, der SDK-Version, die der Linker im Load Command LC_BUILD_VERSION festhält, und iOS liest sie beim Start. Um zu sehen, wie viel davon abhängt, habe ich eine kleine Probe-App gebaut, ein TabView mit einem NavigationStack samt fünf Toolbar-Elementen und einem ArrangementView, und zwar dreimal aus derselben Quelldatei. Der einzige Unterschied zwischen den drei Binarys ist diese Zahl: 26.0, 27.0, 27.1. Dann habe ich alle drei im iPhone-Duo-Simulator in jeder Pose laufen lassen.¹²

Eine Quelldatei, drei SDK-Stempel, geöffnet und aufrecht. Von links nach rechts: 26.0, 27.0, 27.1.

Fenstergrößen in Punkten, wie das Fenster des jeweiligen Builds sie selbst meldete.¹²

Lesen Sie die mittlere Spalte zweimal, denn mit ihr werden die meisten Apps demnächst ausgeliefert. Ein Build aus Xcode 27 bekommt auf dem inneren Display reguläre Breite und den Großteil des Bildschirms, eine echte Verbesserung gegenüber dem Telefon im Kasten aus der ersten Spalte. Er endet aber 80 Punkte vor der hinteren Kante, wo die Statusleiste liegt, er bekommt keine senkrechten Leisten, und das System verrät ihm nichts über den Falz oder die Kameras: Jede Abfrage reservierter Regionen kam leer zurück, in jeder Pose, ganz gleich, wie oft die Probe-App fragte.¹² Um sicherzugehen, dass der Stempel ein fairer Stellvertreter ist, habe ich außerdem eine schlichte Version der Probe-App mit Xcode 27.0 selbst kompiliert, gegen dessen eigenes iOS-27.0-SDK. Sie bekam dieselben Fenster: 386 mal 678 geschlossen, 871 mal 669 offen.¹²

Apples schriftlicher Leitfaden ist an dieser Stelle weniger genau als der Talk, und sein Wortlaut hat sich verschoben. Am 17. September lautete die Übersicht „Build your app with Xcode 27.1 or later to use all of the available screen space on iPhone Duo. In earlier versions, your app doesn’t extend under the status bar and camera.“ (Bauen Sie Ihre App mit Xcode 27.1 oder neuer, um den gesamten Platz auf dem iPhone Duo zu nutzen; in früheren Versionen reicht die App nicht unter Statusleiste und Kamera.) Am 19. September lautete sie, wie auch am 2. Oktober, „Build your app with the latest version of Xcode to use all of the available screen space on iPhone Duo. When you build with Xcode 26 and earlier, your app doesn’t extend under the status bar and camera.“ (Bauen Sie mit der neuesten Xcode-Version, um den gesamten Platz zu nutzen; mit Xcode 26 und früher reicht die App nicht unter Statusleiste und Kamera.)² Der neue Satz nennt nur Xcode 26 und früher als unzureichend, und „latest version“ sagt nicht, ob eine Beta zählt; ein Leser könnte also annehmen, dass ein Build aus Xcode 27.0 den ganzen Bildschirm bekommt. Im Simulator dieser Beta tut er das nicht. Er bekommt die mittlere Stufe des Talks, und der frühere Wortlaut entsprach dem, was ich gemessen habe. Solange keine Hardware etwas anderes zeigt, planen Sie nach der Tabelle.

Prüfen Sie deshalb vor allem anderen den Stempel des Builds, den Sie testen:

otool -l Build/Products/Debug-iphonesimulator/YourApp.app/YourApp | grep -A4 LC_BUILD_VERSION

Ein Debug-Build aus Xcode legt seinen Code in YourApp.debug.dylib neben einen kleinen Launcher, und beide tragen den Load Command. Sie suchen nach sdk 27.1 oder höher; die mit 27.2 gestempelte Probe-App, also mit dem Wert, den das SDK der Xcode-27.2-Beta schreiben würde, wurde genauso behandelt wie 27.1.¹² Bei Kiradex steht dort minos 27.0 und sdk 27.1: Die App installiert sich unter iOS 27.0 und bekommt auf einem Duo das Verhalten von 27.1.¹³

Ich bestehe so darauf, weil ich mich hier öffentlich geirrt habe. Mein erster Bericht aus diesem Simulator vom 21. September sagte, die Toolbar werde nie senkrecht und die reservierten Regionen seien in jeder Pose leer. Die Beta war in Ordnung. Ich hatte die Probe-App damals mit einem direkten Aufruf von swiftc -sdk kompiliert, der Link-Schritt nahm das macOS-SDK aus demselben Xcode als Wurzel, und das Binary ging mit dem Stempel 27.0 hinaus: Alles, was ich an jenem Tag gemessen habe, war die mittlere Spalte. Jener Beitrag trägt inzwischen die Korrektur.¹² Wenn Ihr Duo-Layout im Simulator nur halb übernommen aussieht, mit Leisten oben quer und einem toten schwarzen Streifen an der Seite, prüfen Sie den Stempel, bevor Sie Ihren Code prüfen.

Die App auf dem Prüfstand

Kiradex ist eine Sammler-App für Sammelkarten, die wir in TestFlight haben: jede Serie, die Karten, die Sie besitzen, und die, die Sie suchen, ihr Wert im Zeitverlauf und jede Karte als 3D-Objekt, das Sie umdrehen können. Sie ist kostenlos, nur fürs iPhone, läuft ab iOS 27.0 und speichert die Listen eines Sammlers in dessen eigener iCloud, ohne einen Server von uns dazwischen.¹³ Fertig ist sie nicht. Der Scanner hat noch nie eine echte Kamera gesehen, und bis zu dieser Woche hatte niemand die App auf einem geöffneten Duo betrachtet: Neben dem Layout für das innere Display stand in ihrer Roadmap die Zeile „Seen on the open Duo’s inner display only by the column maths; the simulator was folded shut.“ (Auf dem inneren Display des geöffneten Duo nur über die Spaltenrechnung gesehen; der Simulator war zugeklappt.)¹³ Das macht sie zu einem fairen Testfall. Die Duo-Arbeit darin wurde nach Apples Dokumentation geschrieben und nie an einem Bildschirm überprüft.

Was sie für das Duo tut, ist überschaubar, und es lohnt sich, es aufzuzählen, weil so wenig davon Duo-Code ist:

• Die Navigation gehört dem System. Ein TabView mit fünf Tabs, einer davon mit der Suchrolle, und ein NavigationStack in vier davon; der Scanner ist eine Kameraansicht ohne eigene Leiste. Toolbar-Elemente sind Labels mit Titel und Symbol, angehängt per .toolbar. Nirgends gibt es eine selbst gebaute Leiste.
• Das Layout folgt der Size Class. Kompakte Breite bekommt eine dreispaltige Albumseite und schiebt den Inspektor einer Karte auf den Stack. Reguläre Breite, was bei einer reinen iPhone-App meist das innere Display des Duo bedeutet, bekommt eine Kartenwand mit gerader Spaltenzahl; wählt man eine Karte aus, teilt sich der Bildschirm zwischen Seite und Inspektor.
• Zwei Aufrufe aus dem 27.1-SDK. Die Teilung ist ein ArrangementView im Stil .split, mit einem HStack als Rückfallebene unter iOS 27.1. Und onHingeChange spielt die Eröffnungsanimation der App erneut ab, ein rotes Gerät, das aufschwingt, wenn das Telefon von geschlossen in irgendeinen anderen Zustand wechselt.
• Keine Ausrichtungssperre, dafür ein Startbildschirm. Info.plist führt Hochformat und beide Querformate auf und deklariert UILaunchScreen.¹³

Das ist die ganze Liste: zwei Verfügbarkeitsprüfungen in zwei Dateien. Alles andere, was das Telefon mit der App macht, macht es mit jeder App, die so gebaut ist.

Die Bilder in diesem Beitrag zeigen die App, wie sie läuft, mit Kartenbildern aus dem öffentlichen Katalog, den sie liest. Kiradex ist ein unabhängiges Werkzeug für Sammler, nicht verbunden mit oder unterstützt von Nintendo, Creatures Inc., GAME FREAK inc. oder The Pokémon Company, und die Kartenbilder gehören ihren Rechteinhabern.

Schritt zwei: jede Pose durchgehen

Apples Leitfaden fasst den Rundgang in vier Prüfungen:²

• „Confirm your views resize well in each supported orientation and pose.“ (Vergewissern Sie sich, dass Ihre Views in jeder unterstützten Ausrichtung und Pose sauber ihre Größe anpassen.)
• „Inspect how the system presents your app’s navigation bars, toolbars, and tab bars vertically on the side of the display.“ (Prüfen Sie, wie das System Navigationsleisten, Toolbars und Tab-Leisten Ihrer App senkrecht an der Displayseite darstellt.)
• „Identify any views, sheets, or popovers that position awkwardly when you fold or open iPhone Duo.“ (Finden Sie Views, Sheets oder Popover, die beim Zu- oder Aufklappen des iPhone Duo ungünstig sitzen.)
• „Identify elements or controls in your views that appear in the fold, and are difficult to see or interact with.“ (Finden Sie Elemente oder Bedienelemente, die im Falz liegen und schwer zu sehen oder zu bedienen sind.)

Seine Gestaltungsrichtlinien sagen, wie viele Layouts das erfordern sollte: „A compact width layout for the outer display and a regular width layout for the inner display give you the fundamentals for every pose.“ (Ein Layout für kompakte Breite auf dem äußeren Display und eines für reguläre Breite auf dem inneren liefern die Grundlagen für jede Pose.)⁷

Die Posen sind Buttons in Device Hub: Closed, Book, Open und Rotate Right, und jede Kombination ergibt einen anderen Bildschirm. Der Leitfaden von SwiftLee ergänzt eine feinere Steuerung, die ich nicht brauchte: „Holding Option ⌥ reveals a slider that you can use to control the hinge angle of the device with precision“ (Mit gedrückter Wahltaste ⌥ erscheint ein Schieberegler, mit dem sich der Scharnierwinkel präzise steuern lässt).¹⁷ Bevor wir die App ansehen, hilft es zu wissen, was das System in jeder Pose an jede App übergibt. Das sind die Messwerte der Probe-App mit dem Stempel 27.1:¹²

Drei Dinge in dieser Tabelle prägten alles Weitere.

Das Fenster ändert sich nicht, wenn das Telefon faltet. Book und Open melden dieselbe Größe. Der einzige Unterschied, den die App sehen kann, ist, dass die Division des Falzes von inaktiv zu aktiv wechselt und das Scharnier teilweise geöffnet bei 127 Grad meldet, wo es zuvor vollständig geöffnet bei 180 Grad gemeldet hatte. Eine App, die nur ihre Größe liest, erfährt nie, dass das Telefon gefaltet wurde.

Der Falz ist immer da, und er ist schmal. Er wird geöffnet wie gefaltet gemeldet, genau in der Mitte, und der Rahmen, den die API zurückgibt, ist in beiden Zuständen 40 Punkte breit, mit 20 Punkten Rand auf jeder Seite. Apples Talk sagt über die Region des Falzes: „When flat, it’s inactive and has a width of zero.“ (Flach ist sie inaktiv und hat die Breite null.) (7:32) Der Simulator gibt keinen Rahmen der Breite null zurück. Artem Novichkovs Praxisnotizen beschreiben denselben Messwert als „40 pt wide, with 20 pt margins on each side of a zero-width fold line,“ (40 pt breit, mit 20 pt Rand auf beiden Seiten einer Faltlinie der Breite null)¹⁷ und ich lese die Null des Talks genauso, als die Linie zwischen den Rändern; das ist eine Lesart, nichts, was Apples Text sagt. Auch den praktischen Punkt macht der Talk: „By default, only active ones will be returned, but you can query for inactive ones“ (Standardmäßig werden nur aktive zurückgegeben, aber Sie können auch inaktive abfragen) und „in grid-like layouts, you could prefer even numbers of columns when a division region is present regardless of its active state.“ (In rasterartigen Layouts können Sie gerade Spaltenzahlen bevorzugen, sobald eine Division vorhanden ist, ob aktiv oder nicht.) (7:16, 7:41)⁵

Die Regionen kommen spät. Bei jedem Start lasen die ersten paar Auswertungen der Probe-App überhaupt keine Regionen, und jede Auswertung danach las den vollständigen Satz. Eine View, die einmal fragt, in ihrem ersten Layout-Durchlauf, speichert ein leeres Array. Lesen Sie sie im Body der View, bei jeder Auswertung; die Probe-App wertete per Timer einmal pro Sekunde neu aus, und Artem Novichkovs Notizen formulieren die Regel direkt: „Read them in the GeometryReader body so the view updates when they arrive. Don’t cache them.“ (Lesen Sie sie im Body des GeometryReader, damit sich die View aktualisiert, sobald sie eintreffen. Speichern Sie sie nicht zwischen.)¹²¹⁷

Ein praktischer Hinweis vor der App. Die iOS-27.1-Simulator-Runtime in dieser Beta unterstützt genau einen Gerätetyp, das iPhone Duo; fordert man von ihr ein iPhone 18 Pro Max an, scheitert das mit „Incompatible device“. Der Vergleich weiter unten, derselbe Build auf einem gewöhnlichen iPhone, lief deshalb auf der iOS-27.0-Runtime, was zugleich ein schneller Weg ist, um zu bestätigen, dass die #available-Rückfallebenen funktionieren.¹²

Ein Build von Kiradex auf einem 6,9-Zoll-iPhone, dem geschlossenen Duo und dem geöffneten Duo. Nichts im Code der App setzt die Leisten an die Seite.

Was der Rundgang fand

Ein UI-Test schickte Build 5 durch acht Arten von Bildschirm in jeder von sechs Posen (sieben geschlossen und gedreht, wo der Einstellungen-Button ins Überlaufmenü gewandert war), während ein Skript an jeder Station beide Displays aufnahm: außen 1398 mal 2034 Pixel, innen 2853 mal 2007, die Größen, die App Store Connect aufführt.¹³ Gemessen an Apples vier Prüfungen bestand die App mehr, als ich erwartet hatte, und scheiterte an Stellen, die kein Lesen des Codes markiert hatte.

Was ohne Zutun funktionierte

Die Leisten. Geschlossen stehen die Toolbar und alle fünf Tabs in der Leiste unter der Uhr; offen ebenso; offen und gedreht wandern sie zurück nach oben und unten. Nichts in der App verlangt danach. Der zweite Talk nennt den Grund, warum selbst gebaute Leisten zurückbleiben: „When used to build custom bars, content from sub-components like UIToolbar, UINavigationBar, or UITabBar won’t be considered.“ (Werden eigene Leisten aus Unterkomponenten wie UIToolbar, UINavigationBar oder UITabBar gebaut, wird deren Inhalt nicht berücksichtigt.) (2:52)⁴ Und weil jedes Toolbar-Element auf den Hauptbildschirmen ein Label ist, hat jedes ein Symbol für die Leiste und einen Titel für das Überlaufmenü, und das ist die andere Bedingung des Leitfadens: „If your item has a title and doesn’t have an icon, the system doesn’t present it vertically.“ (Hat ein Element einen Titel, aber kein Symbol, stellt das System es nicht senkrecht dar.)²

Der Falz. Offen hängen die Karten einer Serie zu sechst nebeneinander, eine gerade Zahl, sodass keine Karte in der Bildschirmmitte sitzt. Wählt man eine aus, teilt sich der Bildschirm zwischen der Seite und dem Inspektor der Karte, und zwar in der Mitte des Inhaltsbereichs der App, bei x 433. Das liegt 42 Punkte links vom Falz, weil die Leiste rechts 84 Punkte wegnimmt, und solange das Telefon flach liegt, spielt das keine Rolle. In der Pose Book verschiebt die Arrangement-View die Trennlinie auf den Falz und lässt das 40-Punkte-Band frei: Der Inspektor, der bei x 433 begann, beginnt jetzt bei 495. Für die Pose Book hat die App überhaupt keinen Code; das ist ArrangementView, das tut, was der Talk beschreibt: „moving, resizing, or reorganizing what’s already there.“ (Vorhandenes verschieben, in der Größe ändern oder neu anordnen.) (6:04)⁵¹³

Offen und flach, dann in der Pose Book. Die Lücke im zweiten Bild ist der Falz, und nicht die App hat sie dort hingesetzt.

Sheets, wenn das Telefon offen ist. Auf dem inneren Display erscheint ein Sheet zentriert, und sein Done-Button bleibt waagerecht; in der Pose Book wanderte das Sheet der Probe-App von selbst auf die führende Seite des Falzes.¹²

Das Scharnier als Ereignis. Klappen Sie das Telefon auf, während die App läuft, spielt ihre Eröffnung auf dem inneren Display erneut: das rote Gerät, erst geschlossen, dann aufschwingend in die App hinein. Das ist ein einziger onHingeChange-Handler, der auslöst, wenn der Status closed verlässt, und es ist genau die Arbeitsteilung, die der vierte Talk verlangt: „Hinge data is observed live, and is ideal for driving interactions or effects. For layout, use the arrangement and region APIs.“ (Scharnierdaten werden live beobachtet und eignen sich ideal für Interaktionen oder Effekte; für das Layout nutzen Sie die Arrangement- und Region-APIs.) (2:34)⁶

Aufklappen bei laufender App: Die Eröffnung ist das eigene Gerät der App, von der App gezeichnet, vom Scharnier erneut abgespielt.

Was ihr entging

Ein Sheet mit einem einzigen Text-Button reserviert die Leiste und lässt sie leer. Geschlossen gibt das Einstellungen-Sheet an seiner hinteren Kante einen Streifen für eine senkrechte Leiste ab und legt dann nichts hinein: Das einzige Toolbar-Element ist ein „Done“ mit Titel und ohne Symbol, und ein reines Text-Element bleibt waagerecht. Das Formular wird in den Rest gequetscht. Die Probe-App hat die Kosten gemessen: 374 Punkte Inhaltsbreite mit reservierter Leiste, 450 mit abgeschalteter senkrechter Leiste.¹² Apples Talk benennt genau diesen Fall: „if a sheet is control-heavy with only one item, like the close button here, consider disabling a vertical bar so it doesn’t reduce available space.“ (Ist ein Sheet voller Bedienelemente und hat nur ein Element in der Leiste, etwa diesen Schließen-Button, erwägen Sie, die senkrechte Leiste abzuschalten, damit sie keinen Platz kostet.) (14:37)⁴ Es gibt zwei Reparaturen, und die Probe-App hat beide durchgespielt. Geben Sie dem Button ein Symbol, Button("Done", systemImage: "checkmark"), und er wandert als hervorgehobenes Häkchen in die Leiste; oder setzen Sie .toolbarVerticalBehavior(.disabled) auf den Inhalt des Sheets, und die Leiste verschwindet, um den Preis eines kürzeren Sheets.

Von links nach rechts: das Sheet der App, dann die Probe-App mit reinem Text-Done, mit Symbol und mit abgeschalteter senkrechter Leiste.

Die Vollbildkarte läuft unter die Kamera. Das Paradestück der App ist eine Karte auf schwarzer Bühne mit ausgeblendeten Leisten, und ihre Bühne ignoriert die Safe Area an jeder Kante. Auf dem äußeren Display schickt das die obere Ecke der Karte unter die Kamera. Das System meldet diese Kamera jeder View, die fragt, als aktive Okklusion von 37 Punkten im Quadrat, und ihre Position stimmt bis auf anderthalb Punkte mit der Aussparung in Apples eigenem Rahmenbild überein.¹¹¹² Apples Gestaltungsrichtlinien erlauben die Behandlung in voller Breite, „as long as nothing conflicts with the Dynamic Island or the status bar.“ (solange nichts mit der Dynamic Island oder der Statusleiste kollidiert.)⁷ Die Reparatur: Den randlosen Anschnitt für den schwarzen Grund behalten und die Karte selbst hereinholen, entweder indem die Bühne auf diesem Display die hintere und obere Safe Area respektiert, oder indem sie reservedRegions(kind: .occlusion) liest und die Karte frei von dem rahmt, was zurückkommt.

Die Aufnahme des Betrachters in Apples Rahmen für das äußere Display. Der Screenshot des Simulators hat kein Loch, das Telefon schon.

Gedreht stapeln sich die beiden Bereiche. Offen und ins Hochformat gedreht ist das Display 669 Punkte breit und immer noch reguläre Breite, also teilt die App weiterhin. Eine Arrangement-View, die einen Raum füllt, der höher als breit ist, teilt jedoch oben und unten, laut Apples Leitfaden: „it places the primary view on top and the secondary view below it when the containing view is taller than it is wide.“ (Ist die umgebende View höher als breit, setzt sie die primäre View oben und die sekundäre darunter.)² Heraus kommt ein Streifen, der eine Kartenreihe und den oberen Rand einer zweiten zeigt, über einem Inspektor. Der Kommentar der App an genau dieser Zeile hält über das Paar fest: „is only useful side by side,“ (sei nur nebeneinander nützlich), und nichts hat das erzwungen. Den Stil mit .split.axes(.horizontal) einzuschränken ist die dokumentierte Steuerung,¹⁶ mit einem Haken, den der Talk ausbuchstabiert: „If the split arrangement cannot split among an axis, and it’s the primary axis, the arrangement view chooses to only show a single view.“ (Kann das geteilte Arrangement entlang einer Achse nicht teilen, und ist es die primäre Achse, zeigt die Arrangement-View nur eine einzige View.) (12:44)⁵ Die Probe-App bestätigt beide Hälften: Über das gedrehte Display gespannt, stapelte sich eine schlichte Teilung, und die rein horizontale Teilung zeigte den primären Bereich und sonst nichts.¹² Für diese App würde das den Inspektor verstecken, also ist die ehrliche Lösung eine Entscheidung und kein Modifier: Ist der Raum höher als breit, schieben Sie den Inspektor auf den Stack, wie es das kompakte Layout tut.

Gedreht: waagerechte Leisten, wie Apples Richtlinien es vorsehen, und eine Teilung, die für dieses Paar von Views in die falsche Richtung ging.

Eine Karte, die über das Aufklappen hinweg offen bleibt, landet in keinem der beiden Layouts. Geschlossen schiebt die Auswahl einer Karte deren Inspektor auf den Navigationsstack. Klappen Sie auf, während dieser Inspektor zu sehen ist, und die Karte ist noch da, also genau der Teil, den man leicht falsch macht. Es bleibt aber ein gepushter Bildschirm, jetzt 951 Punkte breit: links die Bühne, die Details in einem weißen Kasten, der verloren auf Schwarz treibt, ein Zurück-Button in der Leiste. Das Design der App für dieses Display ist die Wand mit der Karte daneben, und der einzige Weg dorthin führt zurück und über eine erneute Auswahl der Karte. Eine Auswahl steuert beide Layouts; ein Navigationspfad tut es nicht. Die Reparatur: den Wechsel von kompakter zu regulärer Breite bei ausgewählter Karte bemerken und den gepushten Bildschirm entfernen, damit die Teilung übernimmt.

Dieselbe Karte vor und nach dem Aufklappen. Der Zustand hat überlebt; das Layout ist das kompakte, gestreckt.

Reguläre Breite ist nicht „das Duo“. Die App behandelt reguläre Breite als inneres Display: Wand, gerade Spaltenzahl, Teilung. Ein 6,9-Zoll-iPhone auf der Seite ist ebenfalls reguläre Breite, mit kompakter Höhe, und die App sperrt die Ausrichtung nicht. Läuft sie dort, erzeugt derselbe Zweig eine vom linken Rand eingerückte Seite, einen Inspektor, dessen Detailspalte für den Kartennamen zu schmal ist, und Aktionsbuttons, die an der Unterkante des Bildschirms abgeschnitten werden. Nichts davon ist neu in iOS 27, und in keiner Duo-Pose, die ich durchgespielt habe, trat es auf; die Duo-Arbeit hat es gefunden, weil zum ersten Mal jemand das Layout für reguläre Breite auf jedem Bildschirm durchging, der eine solche meldet. Unterscheiden lassen sich beide Fälle über die andere Size Class: Das innere Display ist in beiden Richtungen regular, und Apples Talk gibt das äußere Display auf der Seite liegend als compact in beiden an.³ Ein Layout, das in zwei Richtungen Platz braucht, sollte nach beiden fragen.

Das Layout für reguläre Breite auf einem Telefon, das kein Duo ist: ein 6,9-Zoll-iPhone auf der Seite, iOS 27.0.

Die Tastatur verdeckt die Leiste. Ist die Tastatur auf dem äußeren Display eingeblendet, liegen die Tabs unten in der Leiste dahinter. Das ist das Layout des Systems, kein Fehler; der Talk sagt, die Leiste müsse womöglich überlaufen, „as other competing UI appears, like the keyboard“ (wenn andere konkurrierende UI erscheint, etwa die Tastatur) (11:50).⁴ Sie steht auf dieser Liste, weil sie das Werkzeug kaputt gemacht hat: Mein erster Rundgang tippte bei eingeblendeter Suchtastatur auf „Collection“, und der Tipp landete auf dem Buchstaben P. UI-Tests, die davon ausgehen, dass eine Tab-Leiste immer erreichbar ist, scheitern hier zuerst.

Zwei kleinere Dinge. Die App wählt gerade Spaltenzahlen anhand der Size Class der Breite, während der Talk vorschlägt, sich an der eigenen Region des Falzes zu orientieren, ob vorhanden oder nicht. Und eines, das mit dem Falten nichts zu tun hat: Viermal hintereinander auf dem 6,9-Zoll-Simulator geöffnet, zeigte der Vollbildbetrachter beim ersten Mal die Karte und bei den nächsten drei einen leeren schwarzen Bildschirm. Keines von beiden hält einen TestFlight-Build auf. Beide blieben unsichtbar, bis die App auf einem Bildschirm lief und etwas ihre Buttons der Reihe nach drückte.

Was der Simulator nicht zeigen konnte

Den Scanner. Er öffnet die rückseitige Weitwinkelkamera und nutzt bereits einen Rotation Coordinator, wie es der Kamera-Talk verlangt: „On iPhone Duo, the rotation coordinator will update when your app moves displays.“ (Auf dem iPhone Duo aktualisiert sich der Rotation Coordinator, wenn Ihre App das Display wechselt.) (8:19)⁶ Ob die Session den Wechsel von einem Display zum anderen übersteht, ist eine Frage für die Hardware; der Simulator hat überhaupt keine Kamera. Apples Release Notes zählen außerdem StandBy und die meisten App-Extensions zu dem, was diese Runtime nicht ausführen kann, und die Notes zu Xcode 27.2 beta 2 ergänzen einen Punkt für alle, die Aufnahmen automatisieren: „Screenshots and recordings in iPhone Duo may be black for up to a few minutes after booting the device.“ (Screenshots und Aufnahmen im iPhone Duo können nach dem Hochfahren des Geräts bis zu einige Minuten lang schwarz sein.)²⁰

Ein Quellbaum, zwei Xcodes

Der Kalender schafft ein Problem. Der Build, den der Store annimmt, stammt aus Xcode 27 mit dem 27.0-SDK; der Build, der sich auf dem iPhone Duo richtig verhält, stammt aus dem 27.1-SDK. Bis Apple den Store für Letzteren öffnet, muss eine App, die ein Update ausliefern und zugleich an ihrem Duo-Layout weiterarbeiten will, unter beiden kompilieren.

if #available(iOS 27.1, *) bringt Sie nicht ans Ziel. Verfügbarkeit ist eine Frage der Laufzeit; der Compiler muss das Symbol trotzdem finden. Kiradex umschließt seine beiden Duo-Aufrufe genau auf diese Weise, und sein Deployment Target ist 27.0, damit sich der Build auf einem Telefon installiert, das noch nicht aktualisiert wurde. Unter dem 27.1-SDK kompiliert das. Unter Xcode 27.0 bricht eine Datei, die dasselbe tut, mit error: cannot find 'ArrangementView' in scope ab, weil das 27.0-SDK keinen solchen Typ hat.¹⁴ Kiradex ist noch nicht im Store und kann deshalb einfach bei der Beta-Toolchain bleiben; eine App mit Kunden kann das nicht.

Auch die dokumentierten Bedingungen von Swift unterscheiden die beiden SDKs nicht. #if compiler(>=6.4) ist unter beiden wahr: Xcode 27.0, Xcode 27.1 beta und Xcode 27.2 beta geben alle dasselbe Apple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1) aus.¹⁴ Bleiben zwei Zäune, und ich habe beide ausprobiert.

Eine selbst gesetzte Compilation Condition. Das ist der dokumentierte Weg. Definieren Sie ein Flag nur in der Konfiguration, die Sie mit der Beta bauen (in Xcode SWIFT_ACTIVE_COMPILATION_CONDITIONS = DUO_SDK, auf der Kommandozeile -D DUO_SDK), und zäunen Sie den Code, der nur unter 27.1 existiert, damit ein:

struct Pair<Primary: View, Secondary: View>: View {
    @ViewBuilder var primary: Primary
    @ViewBuilder var secondary: Secondary

    var body: some View {
        #if DUO_SDK
        if #available(iOS 27.1, *) {
            ArrangementView { primary } secondary: { secondary }
                .arrangementViewStyle(.split)
        } else {
            HStack(spacing: 0) { primary; secondary }
        }
        #else
        HStack(spacing: 0) { primary; secondary }
        #endif
    }
}

Ohne das Flag besteht diese Datei die Typprüfung unter Xcode 27.0 und unter der 27.1-Beta. Mit dem Flag besteht sie sie unter der Beta und scheitert unter 27.0 mit demselben Fehler wegen des fehlenden Symbols: Die falsche Kombination lässt sich nicht bauen.¹⁴

Die eigene Version des SDKs, vom Compiler gelesen. canImport nimmt ein zweites Argument mit Unterstrich, das mit der Version eines Moduls verglichen wird, und die Modulversion von SwiftUI unterscheidet sich zwischen den SDKs: 8.0.84.1.104 im 27.0-SDK, 8.0.85.27 im 27.1-SDK, 8.1.6.1.101 im SDK der 27.2-Beta.¹⁴ Das hier braucht also keine Build-Einstellung:

#if canImport(SwiftUI, _version: 8.0.85)
// ArrangementView, reservedRegions, onHingeChange, toolbarVerticalBehavior
#else
// what the app did before
#endif

Ich habe in jeden Zweig ein #warning gesetzt und das Ganze mit allen drei Xcodes kompiliert: 27.0 nahm den zweiten Zweig, die 27.1-Beta und die 27.2-Beta nahmen den ersten.¹⁴ Die Vorsicht steckt im Unterstrich. Die Grammatik des Swift-Buchs für diese Bedingung lautet canImport(import-path) und nicht mehr, _version: ist also eine Compilerfunktion ohne dokumentierten Vertrag, und die Zahl 8.0.85 habe ich aus zwei SDKs herausgelesen, Apple hat sie nicht veröffentlicht.¹⁴ Nutzen Sie sie, solange der Store für 27.1 geschlossen ist, falls eine Build-Einstellung in Ihrem Setup umständlich ist; nehmen Sie das Flag, wenn Sie etwas wollen, das Sie verteidigen können.

So oder so ist der Zaun vorübergehend. An dem Tag, an dem App Store Connect Builds aus einem Xcode mit dem 27.1-SDK annimmt, löschen Sie ihn und behalten die #available-Prüfungen, denn sie schützen ein Telefon, das noch unter iOS 27.0 läuft.

Einreichen: was App Store Connect heute annimmt

TestFlight nimmt den 27.1-Build. Die Release Notes von App Store Connect vom 18. September: „You can now submit apps built with Xcode 27.1 beta using the SDK for iOS 27.1 beta or iPadOS 27.1 beta for internal and external testing.“ (Apps, die mit Xcode 27.1 beta und dem SDK für iOS 27.1 beta oder iPadOS 27.1 beta gebaut sind, lassen sich jetzt für internes und externes Testen einreichen.) Die Einträge vom 16. und 28. September sagen dasselbe für Xcode 27.2 beta und beta 2.⁸ Kiradex geht diesen Weg; sein fünfter Build, der, den dieser Beitrag testet, wurde am 2. Oktober hochgeladen, und App Store Connect führt ihn als gültig.¹³

Der App Store nimmt ihn noch nicht. Der jüngste Eintrag, der den Store öffnet, stammt vom 14. September: „You can now upload apps built with Xcode 27 using the SDK for iOS 27.0, iPadOS 27.0, macOS 27.0, tvOS 27.0, visionOS 27.0, and watchOS 27.0 for the App Store, and for internal and external testing through TestFlight.“ (Apps, die mit Xcode 27 und den 27.0-SDKs gebaut sind, lassen sich jetzt für den App Store sowie für internes und externes Testen über TestFlight hochladen.)⁸ Nichts danach erwähnt 27.1 und den Store im selben Satz, und Apples Releases-Feed, dessen neueste Einträge auf den 28. September datiert sind, führt einen einzigen Build von Xcode 27.1, die Beta vom 18. September.⁸ Apple hat nicht gesagt, wann sich das ändert. Das Gerät kommt am 23. Oktober in den Handel.¹

Öffnet Apple den Store nicht vor dem 23. Oktober für das 27.1-SDK, ist der Store-Build, den Ihre Kunden am Verkaufsstart haben, bestenfalls ein Build mit dem 27.0-SDK, und der Vergleich oben sagt, was er im Simulator bekommt, wobei Apples Talk dieselbe mittlere Stufe beschreibt: den Bildschirm neben der Statusleiste, waagerechte Leisten, keinen Falz. Das ist eine brauchbare App, wenn sie sich sauber in der Größe anpasst, und genau das spricht dafür, die Arbeit an der Größenanpassung jetzt mit Xcode 27 auszuliefern.

Ein Startbildschirm ist jetzt Pflicht. Keine Duo-Regel, aber sie kommt mit demselben SDK, und sie scheitert beim Upload, nicht bei der Prüfung. Apples Technote: „Starting in iOS 27 and iPadOS 27, App Store Connect requires your app to include a launch screen configuration in its Info.plist,“ (Ab iOS 27 und iPadOS 27 verlangt App Store Connect eine Startbildschirm-Konfiguration in der Info.plist), und ohne einen der Schlüssel UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen oder UILaunchScreens wird der Upload mit „ITMS-90870: Missing launch screen.“ abgelehnt.¹⁰ Kiradex deklariert UILaunchScreen mit einer Farbe, dem Rot seines Covers, sodass der Start direkt in die Eröffnungsanimation übergeht.¹³

Die Screenshot-Plätze gibt es auf dem Papier. Die Screenshot-Spezifikationen von App Store Connect führen das iPhone Duo seit dem 9. September, in zwei Paaren: 1398 mal 2034 oder 2034 mal 1398 Pixel für das äußere Display und 2007 mal 2853 oder 2853 mal 2007 für das innere, mit dem Hinweis „Support for uploading assets for this device in App Store Connect will be available later this year.“ (Der Upload von Assets für dieses Gerät in App Store Connect wird im Laufe des Jahres unterstützt.)⁹ Die üblichen Regeln gelten: „You can upload one to 10 screenshots in .jpeg, .jpg, and .png formats,“ (Sie können ein bis 10 Screenshots in den Formaten .jpeg, .jpg und .png hochladen) und „Images can’t include alpha channels or transparencies.“ (Bilder dürfen keine Alphakanäle oder Transparenzen enthalten.)⁹

Ein Satz auf der Upload-Seite entscheidet, wie Sie darum herum planen: „Once your app is submitted for review and approved, you must create a new version to update the screenshots.“ (Ist Ihre App eingereicht und freigegeben, müssen Sie eine neue Version anlegen, um die Screenshots zu ändern.)⁹ Duo-Screenshots lassen sich später nicht einzeln nachschieben; wenn die Plätze aufgehen, fahren sie auf einer Version mit.

Zusammengenommen die Reihenfolge, die ich ansetzen würde und für Kiradex gerade ansetze:

1. Der 27.1-Build jetzt in TestFlight, mit den Befunden des Rundgangs, behoben, sobald sie auftauchen.
2. Für eine App, die schon im Store ist: ein mit Xcode 27 gebautes Update, das jede Korrektur enthält, die das 27.1-SDK nicht braucht. Size Classes statt Prüfungen auf Idiom und Ausrichtung, Safe Areas pro Kante, Leisten im Besitz von Systemcontainern, Titel und Symbol auf jedem Toolbar-Element.
3. Screenshots jetzt in den Duo-Größen aus dem Simulator aufnehmen und aufheben.
4. Eine Version bereithalten für den Tag, an dem zwei Dinge zutreffen: Ein Xcode mit dem 27.1-SDK wird für den Store akzeptiert, und die Duo-Plätze nehmen Uploads an. Apple hat bisher jede Änderung dieser Art in den Release Notes von App Store Connect bekannt gegeben, darunter den Eintrag vom 14. September, der den Store für das Release von Xcode 27 öffnete, und den vom 9. September, der die Duo-Screenshot-Spezifikationen hinzufügte; das ist also die Seite, die Sie beobachten sollten, und daneben die Seite mit den Entwicklernachrichten.⁸

Eine weitere Anforderung liegt weiter in der Zukunft. Ab April 2027 gilt „iOS and iPadOS apps must be built with the iOS 27 & iPadOS 27 SDK or later“ (iOS- und iPadOS-Apps müssen mit dem SDK für iOS 27 und iPadOS 27 oder neuer gebaut sein), damit sie sich überhaupt hochladen lassen.¹⁸ Eine App, die noch mit einem iOS-26-SDK gebaut wird, bekommt auf einem Duo das kleinste der drei Bilder oben, und ab April 2027 kann sie kein Update hochladen, bis sie auf das iOS-27-SDK wechselt.

Screenshots für zwei Displays

Das Rohmaterial hat der Rundgang bereits geliefert: Jede Station wurde mit 1398 mal 2034 und 2853 mal 2007 Pixeln aufgenommen und gedreht mit 2034 mal 1398 und 2007 mal 2853, alle vier Größen aus der iPhone-Duo-Zeile von App Store Connect.⁹¹³ Bleibt zu entscheiden, was um sie herum steht, und genau hier lädt ein faltbares Telefon zu einem Fehler ein.

Das Bild, das alle wollen, ist das halb geöffnete Telefon schräg im Raum, die App fließt über den Falz. Apples Marketingrichtlinien schließen es Zeile für Zeile aus. Für Apples eigene Gerätebilder: „Use Apple product images ‘as is’ and without modification. Modifications include adding reflections, shadows, highlights, or graphic elements that appear to enter or come out of the product screen; cropping, tilting, or obstructing any part of the images; animating, flipping, or spinning the images“ (Apple-Produktbilder unverändert verwenden; als Veränderung gelten Spiegelungen, Schatten, Glanzlichter oder Grafiken, die in den Bildschirm hinein- oder aus ihm herauszuragen scheinen, Beschneiden, Kippen oder Verdecken sowie Animieren, Spiegeln oder Drehen). Für Bildmaterial, das Sie selbst erstellen: „Straight-on product shots are preferred. Don’t use extreme angles or alter an Apple product in any way.“ (Frontale Produktaufnahmen werden bevorzugt; keine extremen Winkel und keinerlei Veränderung an einem Apple-Produkt.) Und unter „Unauthorized Uses“ (unzulässige Verwendungen) steht ganz oben: „Rendering in 3D or creating any simulation of an Apple product“ (ein Apple-Produkt in 3D rendern oder auf irgendeine Weise simulieren).¹¹ Mein Beitrag über Screenshots geht durch, wie die Preisträger mit diesen Regeln umgehen und wie ein Satz aussieht, der sie einhält; ein Scharnier ändert daran nichts.

Was Apple Ihnen stattdessen gibt, ist ein Rahmenpaket für dieses Telefon, in zwei Ausführungen und fünf Ansichten: das geschlossene Telefon im Hoch- und Querformat, das geöffnete innere Display im Quer- und Hochformat und das geöffnete Telefon von hinten mit dem äußeren Display neben den Kameras. Die Öffnungen in diesen Dateien haben exakt die Screenshot-Größen, eine Simulator-Aufnahme passt also ohne Skalierung hinein.¹¹ Eine halb gefaltete Ansicht gibt es nicht, eine schräge auch nicht.

Die Rahmen unten bestehen deshalb aus drei Teilen: einem Grund in den eigenen Farben der App, einer kurzen Textzeile und der Aufnahme in Apples Rahmen, ganz und aufrecht, mit nichts darüber. Abwechslung entsteht durch den Grund, die Größe des Geräts und einen Rahmen pro Satz, der gar kein Gerät zeigt: die Vollbildkarte der App auf Schwarz, also das eigene 3D der App und niemandes Hardware.

Drei Sätze, per Skript aus den Aufnahmen des Rundgangs komponiert, mit 1320 mal 2868, 1398 mal 2034 und 2853 mal 2007 Pixeln. Sie zeigen die Methode, nicht den Store-Eintrag: Diese Aufnahmen tragen Katalogkarten, und was der Store-Satz zeigt, ist die offene Frage im dritten Hinweis unten.

Drei praktische Hinweise aus der Arbeit daran.

Per Skript komponieren. Die Sätze oben stammen aus einer einzigen Python-Datei, die eine Aufnahme, eine Überschrift und einen Grund entgegennimmt und ein PNG in exakter Größe ohne Alphakanal schreibt. Ändert sich die App, und diese änderte sich an dem Tag, an dem ich sie aufnahm, zweimal, läuft der Rundgang erneut, und die Rahmen bauen sich neu.

Zeigen Sie, was das Telefon hinzufügt. Apples Upload-Seite sagt, ein 6,9-Zoll-Satz genüge, wenn die Oberfläche auf allen Größen gleich ist: „provide only the highest resolution screenshots required. They automatically scale down to smaller device sizes.“ (Liefern Sie nur die Screenshots mit der höchsten erforderlichen Auflösung; sie werden automatisch auf kleinere Geräte verkleinert.)⁹ Auf diesem Telefon ist sie nicht gleich: Die Kartenwand und der geteilte Inspektor existieren nur auf dem inneren Display. Mit diesen beiden Rahmen beginnt der innere Satz.

Achten Sie darauf, was auf dem Bildschirm ist. Dieselben Richtlinien sagen: „You are responsible for securing the rights to all materials used in screen content within your app.“ (Sie sind dafür verantwortlich, die Rechte an allen Materialien zu sichern, die im Bildschirminhalt Ihrer App verwendet werden.)¹¹ Eine Sammler-App zeigt ihrem Wesen nach die Kunstwerke anderer Leute, und ein Store-Eintrag ist Werbung, also etwas anderes als das, was die App im Gebrauch anzeigt. Diese Entscheidung haben wir für Kiradex noch nicht getroffen, und die Rahmen oben werden so, wie sie sind, nicht eingereicht. Aus diesem Grund hat der Rundgang einen zweiten Modus, der mit sechs erfundenen Karten läuft; sie haben noch keine Illustrationen, ein eingereichter Satz bedeutet also, Platzhalter zu gestalten oder die Rechtefrage zu klären.

Kiradex hat noch keinen Store-Eintrag. Sobald es einen gibt, beginnt er mit einem 6,9-Zoll-Satz, und die Duo-Sätze warten mit einer eigenen Version auf den Tag, an dem App Store Connect sie annimmt.

Die Arbeit an einen Coding-Agenten übergeben

Das meiste an dieser Arbeit ist von der Art, die ein Agent gut erledigt, sofern er die App sehen kann. Zwei Hälften, und eine davon liefert Apple mit.

Die statische Hälfte gehört Apple. Der erste Tech Talk endet mit ihr: „During the talk, Modernize Your UIKit App, we introduced a new app modernization skill. With Xcode 27.1, this skill has a new name: App Resizability. It now supports SwiftUI and iPhone Duo.“ (Im Talk „Modernize Your UIKit App“ haben wir einen neuen Skill zur App-Modernisierung vorgestellt; mit Xcode 27.1 heißt er App Resizability und unterstützt nun SwiftUI und das iPhone Duo.) (9:19)³ Der Skill ist ein Satz einfacher Textdateien innerhalb der Beta: in Xcode 27.1 beta Contents/PlugIns/IDEIntelligenceChat.framework/Versions/A/Resources/app-resizability.idechatprompttemplate und fünf Referenzdateien daneben.¹⁵ Seine Anweisungen sagen, wie weit das Netz auszuwerfen ist: „Treat a request about the foldable iPhone Duo as a request for every task in the Task Registry, because a screen that changes size exposes all of them at once.“ (Behandeln Sie eine Anfrage zum faltbaren iPhone Duo als Anfrage nach jeder Aufgabe im Task Registry, denn ein Bildschirm, der seine Größe ändert, legt alle auf einmal offen.)¹⁵

Es lohnt sich, ihn zu lesen, auch wenn Sie ihn nie ausführen, denn er ist Apples Prüfliste in Schriftform. Er prüft drei Projekteinstellungen und ändert keine davon (einen Schlüssel für den Startbildschirm, die Deklaration der iPad-Ausrichtungen, UIRequiresFullScreen), und dann sucht er fünf Muster: UIScreen.main, Layout nach Oberflächenausrichtung, Layout nach userInterfaceIdiom, App-Lebenszyklus, wo der Szenen-Lebenszyklus hingehört, und Safe-Area-Code, der annimmt, dass beide Seiten gleich sind. Die Safe-Area-Datei enthält den Satz, der die Hälfte dessen erklärt, was auf diesem Telefon schiefgeht: „Asymmetric horizontal insets are the normal case. Where a vertical bar is present, one horizontal edge usually carries the whole inset and the other carries zero.“ (Asymmetrische horizontale Insets sind der Normalfall; wo eine senkrechte Leiste vorhanden ist, trägt meist eine Kante den ganzen Inset und die andere null.)¹⁵

Kiradex ist eine SwiftUI-App aus diesem Jahr, und diese fünf Suchen finden darin nichts.¹³ Jeder Befund oben stammt aus dem Ausführen. Das ist die Grenze der statischen Hälfte: Sie liest Quellcode, und der Falz, die Leiste und die Tastatur sind nur auf einem Bildschirm sichtbar.

Die andere Hälfte ist ein Rundgang, den der Agent ausführen und anschauen kann. Möglich wurde das Audit oben durch drei kleine Bausteine, und keiner davon ist an diese App gebunden:

1. Ein UI-Test, der jede Art von Bildschirm besucht und an jedem anhält. Keine Assertions, sondern eine Tour. Unsere öffnet den Dex, eine Serie, eine Karte, ein Sheet, die Sammlungsliste, eine Karte aus der Sammlung, den Vollbildbetrachter und die Suche mit eingeblendeter Tastatur: acht Stationen.¹³
2. Eine Aufnahme, die auf dem Mac stattfindet, nicht im Test. Der eigene Screenshot eines UI-Tests zeigt ein Display. simctl erreicht beide:

xcrun simctl io "$UDID" screenshot --type=png --display=primary   outer.png
xcrun simctl io "$UDID" screenshot --type=png --display=primary-1 inner.png

Der Test schreibt eine leere Datei, benannt nach der Station; eine Shell-Schleife auf dem Mac bemerkt sie, nimmt beide Displays auf und antwortet mit einer zweiten Datei; der Test wartet darauf und geht weiter. Die äußere Aufnahme hat bei geschlossenem Telefon 1398 mal 2034 Pixel und die innere bei geöffnetem 2853 mal 2007, die Bilder des Audits und die Screenshots für den Store entstehen also im selben Durchlauf.⁹¹³ 3. Eine Möglichkeit, die Pose ohne Hand an der Maus zu wechseln. simctl hat keinen Pose-Befehl, und die UI-Test-Frameworks in dieser Beta haben keinen Scharnier-Aufruf, den ich hätte finden können, also drückt das Skript die Buttons Closed, Book, Open und Rotate Right in Device Hub über die Bedienungshilfen-API, was auch mit Device Hub im Hintergrund funktioniert.¹³

Damit hört die Prüfung der App in jeder Pose auf, eine Bitte um die Meinung des Agenten zu sein, und wird zu einem Ordner mit Bildern pro Pose, den er und Sie lesen können. Das Briefing unten ist das, was ich übergeben würde. Es ist zum Einfügen geschrieben.

Goal: make this app correct on iPhone Duo in every pose, without device checks.

0. Toolchain. Build with Xcode 27.1 beta. Confirm the binary is stamped with the 27.1 SDK:
   otool -l <App>.app/<App> | grep -A4 LC_BUILD_VERSION      (debug builds: <App>.debug.dylib)
   If "sdk" is lower than 27.1, stop: nothing below will reproduce.

1. Static pass. Report every use, with file and line, of:
   UIScreen.main / UIScreen.mainScreen; userInterfaceIdiom; interface orientation used for layout;
   a UIApplicationDelegate doing scene work; one safe-area inset applied to both sides;
   a bare ignoresSafeArea() on anything a person reads or taps; fixed widths tied to a phone size;
   toolbars or tab bars built by hand instead of owned by NavigationStack, NavigationSplitView or TabView;
   toolbar items with a title and no symbol, or a symbol and no title.
   Confirm Info.plist has a launch screen key and no orientation lock the design does not need.

2. Walk. Run the screenshot tour in each pose and capture BOTH displays at every stop:
   closed; closed and turned; open; open and turned; partly folded; partly folded and turned.
   If no tour exists, write a UI test that stops at each kind of screen and signals a host script, and have
   the script capture with:  xcrun simctl io <udid> screenshot --display=primary     (outer)
                             xcrun simctl io <udid> screenshot --display=primary-1   (inner)
   Poses are buttons in Device Hub (Closed, Book, Open, Rotate Right); simctl has no pose command.

3. Read every capture and answer, per pose:
   - Are the bars where the system puts them (down the side closed and in open landscape, across the top
     and bottom in open portrait)? Is any toolbar item missing from the bar and from the overflow menu?
   - Does any sheet reserve the side rail and leave it empty?
   - With the keyboard up, what is covered? Can every tab still be reached once it is dismissed?
   - Does anything sit under the outer camera corner or the status column?
   - Open: does a grid have an even number of columns? Does any control or line of text cross the middle?
   - Partly folded: does content move off the fold? Do sheets and alerts land on one side?
   - Turned: did a two-pane layout stack when it should have stayed side by side, or the reverse?
   - Is the same selection, scroll position and navigation path still there after the pose changed?

4. Fix with, in this order: a system container that already adapts; size classes; ArrangementView for a
   custom two-pane layout; reservedRegions for hand-placed content. Never branch on the device model,
   the idiom, the orientation, or the raw hinge angle to decide layout.

5. Guard everything from the 27.1 SDK with `if #available(iOS 27.1, *)` and a fallback that keeps both
   panes reachable. If the same source must also build with Xcode 27.0, fence it at compile time.

6. Report what could not be checked in the simulator: cameras, StandBy, extensions, haptics, real reach.

Apples Material, in der Reihenfolge, in der ich es nutzen würde

Alles, was Apple für dieses Gerät veröffentlicht hat, hängt an einer Seite, Get ready for iPhone Duo.¹⁹ In Arbeitsreihenfolge:

Die Zusammenfassung der Fragen und Antworten aus den Group Labs und die Forum-Threads habe ich nicht gelesen: Apples Forumsseiten beantworten einen automatisierten Abruf mit einer Seite zur menschlichen Verifizierung, und ich habe sie nicht umgangen.

Die wichtigsten Erkenntnisse

• Wenn Sie heute eine App ausliefern: Bringen Sie die Arbeit an der Größenanpassung jetzt heraus, gebaut mit Xcode 27. Das ist es, was Ihre Kunden am 23. Oktober auf einem Duo haben, falls der Store an diesem Tag noch für das 27.1-SDK geschlossen ist, und nichts davon braucht die Beta.
• Wenn Sie die Duo-APIs übernehmen: Bauen Sie mit Xcode 27.1 beta, bestätigen Sie sdk 27.1 oder höher mit otool, halten Sie den Build in TestFlight und zäunen Sie die Aufrufe ein, die es nur unter 27.1 gibt, falls derselbe Quellcode weiterhin für den Store bauen muss.
• Wenn Sie testen: Lesen Sie nicht den Code, spielen Sie die Posen durch. Geschlossen, offen, teilweise gefaltet, jeweils auch gedreht, ein Sheet, die Tastatur, eine Vollbildansicht und ein Bildschirm, der über das Aufklappen hinweg offen bleibt. Nehmen Sie jedes Mal beide Displays auf.
• Wenn Sie den Store-Eintrag gestalten: Nehmen Sie jetzt in den Duo-Größen auf, komponieren Sie per Skript, verwenden Sie Apples Rahmen frontal und halten Sie eine Version bereit für den Tag, an dem die Plätze aufgehen.
• Wenn Sie das einem Agenten übergeben: Geben Sie ihm den Rundgang, nicht nur die Dateien. Apples Skill App Resizability deckt ab, was sich durch Lesen finden lässt; alles in den Befunden oben wurde durch Hinsehen gefunden.

Häufige Fragen

Läuft meine bestehende App unverändert auf dem iPhone Duo?

Ja. Apples Talk verspricht es für jedes SDK, und der Simulator bestätigt es: Ein mit dem iOS-26-SDK gestempelter Build lief als Fenster von 375 mal 667 Punkten, und einer mit dem Stempel 27.0 füllte den Bildschirm neben der Statusleiste, mit waagerechten Leisten. Keiner von beiden bekommt senkrechte Leisten oder reservierte Regionen.³¹²

Welches Xcode brauche ich für das volle iPhone-Duo-Layout?

Xcode 27.1 beta (27A9269), das das iOS-27.1-SDK und den einzigen iPhone-Duo-Simulator enthält. Seine 27.1-Simulator-Runtime unterstützt nur den Gerätetyp iPhone Duo, andere iPhones werden also auf der 27.0-Runtime getestet. Das SDK der Xcode-27.2-Beta hat dieselben APIs, und eine mit 27.2 gestempelte Probe-App verhielt sich im Simulator wie 27.1, aber dieses Xcode hat kein Duo, auf dem sie laufen könnte.⁸¹²¹⁴

Kann ich heute einen iPhone-Duo-Build im App Store einreichen?

Keinen, der mit dem 27.1-SDK gebaut ist, Stand 2. Oktober 2026. App Store Connect nimmt Builds aus den Betas von Xcode 27.1 und 27.2 für internes und externes Testen in TestFlight an und Builds aus Xcode 27 für den Store. Apple hat kein Datum für die Änderung genannt.⁸

Welche Screenshot-Größen verlangt App Store Connect für das iPhone Duo?

1398 mal 2034 oder 2034 mal 1398 Pixel für das äußere Display und 2007 mal 2853 oder 2853 mal 2007 für das innere Display, ein bis zehn Bilder ohne Alphakanal. Der Upload ist als „later this year“ (im Laufe des Jahres) angekündigt.⁹

Wie nehme ich beide Displays des iPhone-Duo-Simulators auf?

xcrun simctl io <udid> screenshot --display=primary für das äußere Display und --display=primary-1 für das innere. Der eigene Screenshot eines UI-Tests erfasst ein Display.¹³

Warum sind die Leisten meiner App im iPhone-Duo-Simulator noch waagerecht?

Drei Ursachen, in der Reihenfolge, in der Sie sie prüfen sollten. Das Binary ist nicht mit dem 27.1-SDK gestempelt. Die Leisten sind selbst gebaut, statt einem TabView, NavigationStack oder NavigationSplitView zu gehören. Oder das innere Display steht im Hochformat, wo Apple die Leisten absichtlich waagerecht hält.²⁷¹²

Brauche ich für jede Pose ein eigenes Layout?

Nein. Apples Richtlinien sehen zwei Layouts vor, kompakte und reguläre Breite, dazu eine Reaktion auf den Falz, wo Inhalt ihn kreuzen würde. Kiradex hat diese beiden und eine Arrangement-View; die Pose Book brauchte keinen Code.⁷¹³

Verwandtes auf dieser Website: Der Simulator-Beitrag enthält die Installationsschritte, das Geräteprofil und die korrigierten Messungen pro Pose; Gestalten für das iPhone Duo liest Apples Gestaltungsrichtlinien als Regeln; der Duo-Beitrag für Entwickler hat die Hardwarezahlen und die datierte Chronik; der Beitrag über Screenshots begründet, was ein Satz sagen sollte; die Checkliste für das größenveränderliche iPhone ist die Xcode-27-Arbeit, die Sie laut diesem Beitrag zuerst ausliefern sollten; und der Xcode-27-Hub verfolgt die Toolchain.

Quellen