Symptom: Auf dem iPhone Duo bleiben Flächen leer, Inhalte werden abgeschnitten oder Leisten liegen ungünstig über der Oberfläche. Schnellster Weg: Apple zufolge passen sich Apps mit dem iOS 27 SDK dynamisch an Displaygrößen an; um die vollständigere Displayfläche zu nutzen, prüfen Sie Ihre App mit dem iOS 27.1 SDK und reproduzieren Sie die betroffenen Zustände in Xcode 27.1. (Apple: Vorbereitung auf das iPhone Duo)
Dieser Runbook richtet sich an Sie, wenn Ihre App noch mit einem älteren SDK gebaut wurde und Sie vor einer Anpassung erst das tatsächliche Verhalten prüfen möchten. Er eignet sich außerdem, wenn Sie in SwiftUI oder UIKit feste Größen, eine feste Ausrichtung oder eine selbst gestaltete Navigationsleiste verwenden. Verantworten Sie Builds und Veröffentlichung in einem kleinen Team, können Sie damit Simulator-Abnahme und Freigabe sauber voneinander trennen.
Zuletzt geprüft am 23.10.2026 anhand der Apple-Designrichtlinien und der Xcode-27.1-Release-Notes. (Designrichtlinien, Xcode-27.1-Release-Notes)
Zuerst den Fehlerzustand eingrenzen, statt die Oberfläche neu zu bauen
Behandeln Sie eine verschobene Oberfläche zunächst als reproduzierbaren Layoutfehler, nicht als Beweis dafür, dass die gesamte App neu geschrieben werden muss. Notieren Sie, in welchem Zustand der Fehler auftritt: auf dem Außendisplay, nach dem Wechsel zum Innendisplay, nach einer Größenänderung, bei geänderter Ausrichtung oder erst nach einer Interaktion. Ohne diese Zuordnung können Sie leicht einen funktionierenden Zustand korrigieren und den fehlerhaften übersehen.
Halten Sie für jeden Fund eine kurze Reproduktionsnotiz fest: Startansicht, ausgelöste Aktion, sichtbarer Fehler und erwartetes Ergebnis. Ergänzen Sie nach Möglichkeit Simulatoraufnahmen vor und nach der Änderung. Diese Dokumentation ist keine bloße Ablage: Sie zeigt, ob sich die Abweichung durch eine Größenänderung, durch eine überlagerte Systemleiste oder durch einen Fehler in der eigenen Zustandslogik erklären lässt.
Prüfen Sie danach, ob der Fehler die Darstellung, die Bedienbarkeit oder beides betrifft. Ein abgeschnittener Titel ist zunächst ein visueller Befund. Liegt dagegen eine Schaltfläche außerhalb des erreichbaren Bereichs, fehlt zusätzlich eine verlässliche Interaktionsmöglichkeit. Trennen Sie diese Befunde in Ihrem Ticket; andernfalls kann eine optische Korrektur als erledigt gelten, obwohl die Hauptaktion weiterhin nicht erreichbar ist.
Warum zeigt eine App auf dem iPhone Duo Inhalte nur teilweise oder mit Leerraum? Häufig ist die Oberfläche an eine feste Breite oder Höhe gebunden, oder der Code leitet den verfügbaren Platz aus einem bestimmten Gerätemodell ab. Ein leerer Bereich kann aber auch entstehen, wenn der Inhalt korrekt kleiner bleibt, statt sich an den verfügbaren Platz anzupassen. Vergleichen Sie daher den tatsächlichen Inhaltsrahmen mit dem sichtbaren Bereich, bevor Sie Abstände oder Schriftgrößen ändern.
Prüfen Sie besonders Code, der feste Frame-Maße, konstante Insets oder eine angenommene Bildschirmbreite enthält. Suchen Sie außerdem nach Verzweigungen, die anhand einer Gerätebezeichnung statt anhand der verfügbaren Größe entscheiden. Solche Annahmen können auf einem einzelnen Simulatorzustand passend wirken und beim Wechsel der Displayfläche unzutreffend werden. Die Apple-Designrichtlinien zum iPhone Duo bieten den maßgeblichen Rahmen für die Anpassung an dessen Display- und Layoutbedingungen. (Apple-Designrichtlinien für das iPhone Duo)
Displaywechsel als eigenen Szenario-Test abnehmen
Außen- und Innendisplay sind keine zwei voneinander unabhängigen Screens, die Sie lediglich mit statischen Screenshots vergleichen sollten. Prüfen Sie, ob Ihre Oberfläche auf veränderte verfügbare Größe reagiert, während der bestehende Navigations- und Anwendungszustand erhalten bleibt. Apple beschreibt für Apps, die mit dem iOS 27 SDK gebaut wurden, eine dynamische Anpassung an Displaygrößen. Das bedeutet jedoch nicht automatisch, dass ein älterer Layoutansatz die zusätzliche Fläche sinnvoll nutzt oder dass jeder individuelle Container korrekt reagiert. (Apple-Vorbereitungsleitfaden)
| Ausgangslage | Was Sie im Simulator prüfen | Entscheidung |
|---|---|---|
| Build mit älterem SDK | App auf beiden Displayflächen starten und wichtige Ansichten öffnen | Läuft die Oberfläche stabil und bleibt bedienbar, ist eine sofortige Neukonstruktion nicht begründet; dokumentieren Sie dennoch nicht genutzte Fläche und Abweichungen. |
| Build mit iOS 27 SDK | Größenwechsel während einer geöffneten Ansicht beobachten | Prüfen Sie, ob Komponenten auf die Änderung reagieren und ob Navigation, Inhalt und Eingaben erhalten bleiben. |
| Build mit iOS 27.1 SDK oder neuer | Vollständigere Flächennutzung sowie Position von Werkzeug- und Tableisten kontrollieren | Vergleichen Sie Darstellung und Bedienbarkeit mit den für Ihre App erwarteten Zuständen; passen Sie nur die nachweislich fehlerhaften Annahmen an. |
Wie passen Sie das Layout beim Wechsel zwischen Außen- und Innendisplay an? Reproduzieren Sie den Wechsel zunächst mit einer Ansicht, die sichtbar fehlschlägt. Prüfen Sie anschließend, ob deren Größe aus dem tatsächlich verfügbaren Layoutbereich folgt oder aus einem festen Wert stammt. Nehmen Sie die Änderung erst dann ab, wenn die Ansicht nach dem Wechsel sowohl ihre wichtigen Inhalte als auch den erwarteten Interaktionszustand behält.
Erfassen Sie bei der Reproduktion dieselbe Ansicht unmittelbar vor und nach dem Größenwechsel. Achten Sie auf verschobene Ränder, unerwartete freie Flächen, angeschnittene Inhalte und Komponenten, die an der alten Position verbleiben. Wird der Fehler nur nach einer bestimmten Aktion sichtbar, etwa nach Öffnen eines Menüs, gehört diese Aktion in die Reproduktionsnotiz. Ein Vergleich bloßer Startansichten würde den Zustandsfehler dann nicht zeigen.
Bei der Implementierung ist die verfügbare Größe aussagekräftiger als eine Vermutung über das Gerätemodell. In SwiftUI helfen Größenklassen dabei, die verfügbare Layoutumgebung zu beurteilen; in UIKit stellen Trait-Informationen den Kontext für Anpassungen bereit. Verwenden Sie diese Mechanismen nicht schematisch: Entscheidend ist, ob die konkrete Ansicht damit auf den beobachteten Wechsel korrekt reagiert. (SwiftUI-Dokumentation zu Größenklassen, UIKit-Dokumentation zu Trait Collections)
Werkzeugleisten und benutzerdefinierte Ansichten separat prüfen
Mit einem Build auf Basis des iOS 27.1 SDK können sich Annahmen über die Platzierung von Werkzeug- und Tableisten bemerkbar machen. Kontrollieren Sie daher nicht nur, ob ein Element noch auf dem Bildschirm liegt, sondern auch, ob der Inhalt ausreichend Abstand hält und zentrale Aktionen erreichbar bleiben. Apple weist in seinen Hinweisen zur Vorbereitung und in den Designrichtlinien auf die zu berücksichtigenden Layoutänderungen hin. Behandeln Sie diese Punkte als Prüfanlass, nicht als Behauptung, dass jede App dieselbe Verschiebung zeigt.
| Prüffall | Beobachtbarer Befund | Nächster Schritt |
|---|---|---|
| Werkzeug- oder Tableiste | Schaltflächen wirken versetzt, sind verdeckt oder liegen an einer unerwarteten Stelle | Tatsächliche Leistenkonfiguration und verwendeten Layoutcontainer prüfen; System- und eigene Leiste unterscheiden. |
| Inhalt nahe einer Kante | Text, Eingabefeld oder Aktion gerät in einen unsicheren beziehungsweise überlagerten Bereich | Abstände gegen die Safe Area prüfen, statt nur einen globalen Randwert zu erhöhen. |
| Wechsel bei offener Ansicht | Inhalt springt, wird abgeschnitten oder verliert seinen Zustand | Größenänderung und Zustandsverwaltung getrennt reproduzieren; klären, ob Layout oder Logik die Ursache ist. |
| Benutzerdefinierte Navigation | Hauptaktion bleibt sichtbar, ist aber schwer oder nicht zuverlässig bedienbar | Sichtbarkeit und Interaktionsbereich getrennt kontrollieren; anschließend die konkrete Aktion testen. |
safeAreaLayoutGuide, wenn die betroffenen Constraints an die sichere Inhaltsfläche gebunden sein müssen. Das ist keine pauschale Reparatur für jeden Versatz: Bei einer eigenen Leiste kann die Ursache beispielsweise in einer doppelten Einrückung oder in einem Container liegen, der den verfügbaren Platz falsch weitergibt. Prüfen Sie deshalb die Constraints an der Stelle, an der der Fehler auftritt. ([Apple-Dokumentation zu safeAreaLayoutGuide](https://developer.apple.com/documentation/uikit/uiview/safearealayoutguide))
**Beeinflusst die Leistenposition unter iOS 27.1 auch ältere Apps?** Das lässt sich nicht allein aus dem SDK-Namen ableiten. Apple beschreibt die vollständigere Nutzung der Displayfläche für Apps, die mit dem iOS 27.1 SDK oder neuer gebaut sind, und empfiehlt, Werkzeug- und Tableisten im betreffenden Layoutkontext zu prüfen. Bei einem älteren Build sollten Sie deshalb zuerst dessen tatsächliches Verhalten festhalten und anschließend entscheiden, ob ein neuer Build nötig ist.**Achtung:** Eine Leiste, die im Screenshot sichtbar ist, ist nicht automatisch korrekt abgenommen. Prüfen Sie für jede zentrale Aktion, ob sie weiterhin erreichbar ist und ob der Inhalt nicht durch dieselbe Leiste verdeckt wird.
Teilweise Faltung, Ausrichtung und Eigenbau-UI gezielt durchspielen
Bei selbst gezeichneten Controls, festgelegter Ausrichtung oder komplex verschachtelten Containern reicht ein Test der Startansicht nicht aus. Wechseln Sie in dem reproduzierbaren Simulatorablauf jeweils nur den Zustand, der zur Abweichung führt, und prüfen Sie danach drei Dinge: Wird der Inhalt verdeckt? Bleibt die Interaktionsfläche erreichbar? Ist der Zustand der Ansicht nach dem Wechsel noch fachlich korrekt? So unterscheiden Sie einen Layoutfehler von einem Logikfehler, bei dem beispielsweise ein Menü offen bleibt, obwohl sich seine Bezugskante geändert hat.
Bei einer teilweise gefalteten Darstellung sollten Sie prüfen, ob ein Element über einen nicht nutzbaren oder visuell getrennten Bereich hinweg gespannt wird. Nutzen Sie keine Annahme, dass eine Ansicht immer in einem einzigen rechteckigen, unveränderlichen Bereich erscheint. Orientieren Sie sich an den Apple-Designrichtlinien und an der konkreten Ansicht, nicht an einer vermeintlich universellen Anpassungsregel.
Ein sinnvoller Prüflauf beginnt mit einer Ansicht, die den Fehler zuverlässig zeigt, und führt anschließend dieselbe Navigation nach dem Größen- oder Ausrichtungswechsel erneut aus. Notieren Sie, ob der Inhalt neu angeordnet, lediglich beschnitten oder gar nicht aktualisiert wird. Diese Unterscheidung weist auf unterschiedliche Fehlerpfade: Constraints und Layoutcontainer betreffen die Geometrie; gespeicherte Auswahl, Fokus oder Navigationszustand betreffen dagegen die Anwendungslogik.
Wie prüfen Sie das mit dem iPhone-Duo-Simulator in Xcode 27.1? Wählen Sie in Xcode 27.1 eine passende iPhone-Duo-Simulator-Konfiguration, starten Sie den Build und reproduzieren Sie den Wechsel, der den Fehler auslöst. Vergleichen Sie die Ansicht vor und nach dem Wechsel, kontrollieren Sie Leisten und Interaktionsbereiche und wiederholen Sie den Ablauf nach der Korrektur. Die Xcode-Release-Notes sind die Referenz für Änderungen und Hinweise zu dieser Xcode-Version; prüfen Sie außerdem die offiziellen Systemanforderungen, bevor Sie eine Entwicklungsumgebung aktualisieren. (Xcode 27.1 Release Notes, Xcode-Systemanforderungen)
SwiftUI und UIKit nach der betroffenen Annahme reparieren
Wählen Sie den Reparaturpfad anhand des konkreten Layoutbefunds, nicht anhand eines pauschalen Rezeptes für eine UI-Technologie. Ziel ist eine Oberfläche, die auf unterschiedliche verfügbare Größen reagieren kann, ohne für jede Haltung eine vollständig getrennte Kopie derselben Ansicht zu benötigen. Das heißt nicht, dass jede Ansicht identisch aussehen muss: Ein breiterer Bereich kann eine andere Anordnung rechtfertigen, sofern Navigation und Bedienlogik nachvollziehbar bleiben.
| Projektbereich | Zuerst untersuchen | Sinnvolle Richtung | Abnahmekriterium |
|---|---|---|---|
| SwiftUI-Ansicht | Feste Frames, verwendete Größenklassen und Abhängigkeit von der verfügbaren Layoutumgebung | Prüfen, ob die Ansicht aus ihrer tatsächlichen Umgebung abgeleitet werden kann; Größenklassen nur dort einsetzen, wo sie die Entscheidung tragen. | Inhalt passt nach dem Wechsel, ohne dass zentrale Bedienelemente verschwinden oder der Zustand verloren geht. |
| UIKit-Ansicht | Constraints, Trait Collections und Bindung an die Safe Area | Betroffene Constraints und Container an der reproduzierten Stelle überprüfen; Traits als Kontext statt als Geräte-Whitelist verwenden. | Inhalt bleibt innerhalb des vorgesehenen Bereichs und Aktionen sind erreichbar. |
| Eigene Navigation oder Controls | Feste Positionen, eigene Hit-Tests und Abhängigkeit von der Bildschirmkante | Zeichnung, Layout und Interaktionsbereich getrennt prüfen und die Ursache gezielt korrigieren. | Sichtbare Position und tatsächliche Bedienfläche stimmen im relevanten Zustand überein. |
Bei UIKit kontrollieren Sie, ob die betroffene View an sinnvolle Constraints gebunden ist und ob sie die für ihre Darstellung benötigten Trait-Informationen berücksichtigt. Prüfen Sie außerdem, ob Abstände zur Safe Area gehören oder ob ein eigener Container diese bereits berücksichtigt. Eine zusätzliche Einrückung kann eine Überlagerung scheinbar beheben, zugleich aber auf einem anderen Display unnötigen Leerraum erzeugen.
Arbeiten Sie in kleinen, überprüfbaren Änderungen: erst den fehlerhaften Frame oder Constraint korrigieren, dann denselben Reproduktionsablauf wiederholen. Ändern Sie nicht gleichzeitig Navigation, Abstände und Zustandsverwaltung, wenn Sie danach nicht mehr erkennen können, welche Änderung den Fehler beseitigt hat. Halten Sie fest, welche Ansicht und welcher Zustand geprüft wurden; so kann ein Teammitglied den Befund später nachvollziehen, ohne sich auf eine mündliche Beschreibung verlassen zu müssen.
Simulator-Abnahme dokumentieren und den Veröffentlichungsentscheid treffen
Behandeln Sie die Simulatorprüfung als Layout- und Funktionskontrolle für die dort reproduzierten Szenarien, nicht als Ersatz für die Abnahme auf einem physischen Gerät. Der Simulator hilft Ihnen, Displaywechsel, Werkzeugleisten und wiederholbare Ansichtsabläufe zu untersuchen. Er bestätigt weder automatisch jedes Verhalten auf realer Hardware noch ein Ergebnis der App-Prüfung oder Veröffentlichung. Trennen Sie diese Aussagen in Ihrer Freigabe, damit ein bestandener Simulatorlauf nicht als weitergehende Garantie ausgelegt wird.
Für eine belastbare Abnahme sollten Sie folgende Punkte dokumentieren:
- Build-Grundlage festhalten: Notieren Sie, mit welchem SDK und welcher Xcode-Version der geprüfte Build erstellt wurde. Vergleichen Sie diese Angaben mit den offiziellen Apple-Hinweisen zu SDK-Verhalten und mit den Xcode-Release-Notes.
- Fehler reproduzieren: Öffnen Sie die betroffene Ansicht und führen Sie genau den dokumentierten Wechsel aus. Wenn sich der Befund nicht reproduzieren lässt, ändern Sie den Code nicht auf Verdacht; prüfen Sie zunächst, ob Build, Ausgangszustand und Bedienfolge übereinstimmen.
- Layoutflächen vergleichen: Erfassen Sie die Ansicht vor und nach dem Wechsel und markieren Sie Leerraum, Beschnitt oder Versatz. Ergänzen Sie, ob die Abweichung nur visuell ist oder auch eine Interaktion verhindert.
- Gezielt korrigieren: Ändern Sie die nachgewiesene feste Größenannahme, den betroffenen Constraint oder die Leistenbehandlung. Vermeiden Sie eine separate vollständige Oberfläche für jede Haltung, solange ein adaptives Layout den Befund beheben kann.
- Regression wiederholen: Führen Sie dieselbe Navigation nach der Korrektur erneut aus und prüfen Sie zusätzlich die angrenzenden Aktionen, die dieselbe Leiste oder denselben Container verwenden.
- Freigabe klar begrenzen: Halten Sie fest, welche Simulatorzustände bestanden wurden und welche Prüfungen noch auf einem Gerät oder in einem Veröffentlichungsprozess erfolgen müssen.
Sie können sich in der MACGPU-Übersicht zu Remote-Mac-Umgebungen über die verfügbaren Zugangswege informieren. Wenn Ihre Layoutprüfung abgeschlossen ist und Sie stattdessen dauerhaft lokale Hardware benötigen, finden Sie auch eine Übersicht zum Bestellen eines M4-Mac. Wählen Sie die Mietlösung nur dann, wenn der temporäre Zugriff zu Ihrem Test- und Buildbedarf passt; für einen einzelnen Simulatorbefund bleibt der reproduzierbare Testablauf wichtiger als ein Wechsel der Infrastruktur.