Die Ära des skalierbaren iPhones: Machen Sie Ihre App bis September bereit

Wie bereiten Sie eine iPhone-App auf skalierbare Bildschirme vor? Die Grenze zieht Apple beim SDK, gegen das Sie linken: Die Release Notes zu Xcode 27 bezeichnen den Resize-Modus im Device Hub für Apps, die gegen ein SDK von iOS 26 oder früher gelinkt sind, ausdrücklich als nicht unterstützt, und jeder Eintrag zur Größenveränderbarkeit in den Release Notes zu iOS 27 steht unter der Bedingung „built with the iOS 27 SDK“.¹² Danach gilt: Spüren Sie jede Annahme über feste Größen auf (Zugriffe auf UIScreen.main.bounds, fest codierte Frames, an der Ausrichtung hängende Layouts), stützen Sie sich auf Size Classes und layoutadaptive SwiftUI-Container und testen Sie fortlaufend in den Resizable-Canvas-Vorschauen und im Resize-Modus des Device Hub von Xcode 27.² Die Ausrichtungsbedingung, die der kontinuierlichen Skalierbarkeit lange im Weg stand, ist in den aktuellen Release Notes als Fixed markiert – der Weg ist also frei.¹

Den ganzen Sommer über liefen Apples Herbst-Betas für iPhone-Entwickler auf eine einzige Botschaft zu: Hören Sie auf, ein festes Rechteck vorauszusetzen. Die Belege stecken nicht in den Keynotes, sondern im Werkzeug und in den Release Notes – die Größenveränderbarkeit kommt mit der Verlinkung gegen das iOS 27 SDK, die Vorschau-Canvas lässt sich frei skalieren, und im Lauf des Beta-Zyklus räumten die Release Notes das letzte strukturelle Hindernis beiseite. Welche Hardware in diesem Herbst auch erscheint: Der Vertrag auf Softwareseite hat sich bereits geändert.

Kurzfassung: iOS 27 bringt kontinuierliche Skalierbarkeit für Apps, die mit dem neuen SDK gebaut wurden; Xcode 27 liefert die passenden Testflächen dafür (Resizable-Canvas-Vorschauen, Resize-Modus im Device Hub); und die aktuellen Release Notes – die Ausgabe zu Beta 7, veröffentlicht am 24. August – führen die Ausrichtungshürde als Fixed: Zwischen den Ausgaben zu Beta 4 und Beta 6 wanderte sie aus den Known Issues heraus, und deklarierte Ausrichtungen entscheiden nicht länger darüber, ob Ihre App skaliert.¹ Die Arbeit besteht überwiegend aus Subtraktion: Finden Sie die Stellen, an denen Ihr Layout an eine einzige Bildschirmgröße glaubt, und nehmen Sie ihm diesen Glauben. Es folgt die Checkliste, in der Reihenfolge, in der ich sie abarbeiten würde.

Warum jetzt

Drei datierte Fakten stellen die Uhr:

1. Beta 7 erschien am 24. August, mitten in der Stabilisierungsphase des Zyklus – Apples späte Betas reparieren eher, als dass sie ergänzen, und die finalen Releases kamen bisher jedes Jahr im September.¹
2. Die Grenze der Größenveränderbarkeit ist der SDK-Link. Die Release Notes zu Xcode 27 beschreiben den Wechsel in den Resize-Modus des Device Hub „with an app linked against an iOS 26 or earlier SDK“ als „unsupported“.² Dasselbe Muster zieht sich durch die iOS-Notes: Jeder Eintrag zur Größenveränderbarkeit ist an „built with the iOS 27 SDK“ gebunden. Bauen Sie neu, stehen Sie auf der skalierbaren Seite dieser Linie; bleiben Sie beim alten SDK, steigen Sie aus der Richtung aus, in die sich die Plattform bewegt.
3. Die letzte strukturelle Hürde ist gefallen. Zur Zeit von Beta 4 galt eine iPad-App, deren UISupportedInterfaceOrientations eine der vier Ausrichtungen ausließ, als nicht kontinuierlich skalierbar – ein bekanntes Problem, dessen dokumentierter Workaround einen undokumentierten Preis hatte, den ich im Beitrag zum Resizability-Workaround beschrieben habe. Zwischen den Ausgaben zu Beta 4 und Beta 6 verschwand der Eintrag aus den Known Issues, und die aktuelle Ausgabe führt ihn als Fixed: „Beginning with iOS 27, supported interface orientations should no longer be a condition for continuous resizability.“ Die Liste der Known Issues von UIKit ist in den Notes zu Beta 7 leer.¹

Zusammengenommen erwartet die Plattform nun, dass Ihr Layout eine Funktion seines Containers ist und nicht eines Datenblatts. Das iPad hat diese Lektion mit Multitasking zuerst erteilt; iOS 27 dehnt denselben Vertrag auf das iPhone aus.

Die Checkliste

1. Mit dem iOS 27 SDK neu bauen – und dann wirklich hinsehen

Das Opt-in ist der Neubau. Bevor Sie eine einzige Zeile Layoutcode ändern, bauen Sie mit Xcode 27, öffnen den Resize-Modus im Device Hub und ziehen daran. Die meisten sauber strukturierten SwiftUI-Apps überstehen diesen Erstkontakt besser, als ihre Autoren erwarten; was bricht, ist lehrreich, und es bricht jedes Mal an derselben Handvoll Stellen – genau davon handelt der Rest dieser Checkliste.

2. Die Annahmen über feste Größen aufspüren

Die üblichen Verdächtigen, in der Reihenfolge, in der sie meist zubeißen:

• UIScreen.main.bounds als „die Bildschirmgröße“. In einer skalierbaren Welt gibt es die Bildschirmgröße nicht, und UIScreen.main gilt seit iOS 26 offiziell als veraltet. Leiten Sie Größen aus Ihrer Window Scene ab oder, in SwiftUI, aus dem Container – mit sparsam eingesetztem GeometryReader oder bewusst gesetztem containerRelativeFrame(_:).
• Fest codierte Frames und magische Zahlen, kalibriert auf bestimmte Geräte („390 Punkte Breite heißt iPhone“). Jede Geräteerkennung nach dem Muster if width == <Zahl> wird Sie irgendwann anlügen.
• Layout, das an der Ausrichtung statt an der Größe hängt. Ausrichtungsabfragen waren immer nur ein Stellvertreter; nachdem iOS 27 Ausrichtungen von der Skalierbarkeit entkoppelt hat, ist dieser Stellvertreter offiziell Ballast. Verzweigen Sie über horizontale und vertikale Size Classes – wofür sie gedacht waren.
• Zwischenspeichern von Maßen beim Start. Alles, was einmal beim Start gemessen und abgelegt wird, ist nach der ersten Größenänderung veraltet.

3. Lassen Sie die adaptiven Container ihre Arbeit tun

Genau dafür wurde SwiftUIs modernes Layoutwerkzeug gebaut: ViewThatFits, um zwischen Anordnungen zu wählen, containerRelativeFrame, um gegen den Container statt gegen den Bildschirm zu dimensionieren, dazu Grids und flexible Frames für alles dazwischen. Stammt Ihre App aus der Ära des festen Rechtecks, ist das wirkungsvollste Refactoring meist, ein tragendes Layout aus GeometryReader plus Arithmetik durch diese Primitive zu ersetzen. UIKit-Apps kommen mit Size Classes und den umgebungsgesteuerten Sections von UICollectionViewCompositionalLayout zum selben Ergebnis.

Die Toolbar- und Layoutänderungen in iOS 27 weisen in dieselbe Richtung – das Framework gibt Ihnen jetzt an den Punkten explizite Kontrolle, an denen der Platz ausgeht, und der Platz geht nun dynamisch aus.

4. Dort testen, wo die Größenänderung wirklich passiert

Xcode 27 bietet zwei eigens dafür gebaute Flächen, beide früh im Beta-Zyklus ausgereift:

• Resizable-Canvas-Modus in den Vorschauen – nicht mehr auf bestimmte Seitenverhältnisse beschränkt (die Einschränkung fiel in Beta 2), sodass Sie das gesamte Formenspektrum durchziehen können, in dem Ihre App landen kann.²
• Resize-Modus im Device Hub für laufende Apps, mit seit Beta 3 reparierten Notausgängen (das Verlassen des Resize-Modus durch Absturz oder Wechsel in den Hintergrund blockiert den Gerätebildschirm nicht mehr bis zum Neustart).²

Gehen Sie in beiden je einmal durch sämtliche Hauptbildschirme. Die Fehler, die Sie finden, häufen sich in den Bildschirmen, die zwischengespeichert, angenommen oder abgeleitet haben.

5. Prüfen Sie die Flags, die Sie vor Jahren gesetzt haben

UIRequiresFullScreen und eng gefasste Deklarationen von UISupportedInterfaceOrientations waren historisch der Weg, sich den Anforderungen des iPad-Multitaskings zu entziehen. Veraltet ist keiner der beiden Schlüssel, doch beide tragen jetzt auf neue Weise: Der Beta-Zyklus brauchte mehrere Ausgaben, um ihr Zusammenspiel mit der kontinuierlichen Skalierbarkeit zu klären, und die zur Zeit von Beta 4 bekannten Probleme rund um das Resize-Verhalten von UIRequiresFullScreen sind inzwischen unter Resolved Issues als Fixed markiert.¹ Stehen diese Schlüssel wegen einer Entscheidung aus dem Jahr 2019 in Ihrer Info.plist, ist dieser Monat der richtige, um die Entscheidung bewusst neu zu treffen. Die Analyse der Workaround-Kosten behandelt die Nebenwirkungen des Ausrichtungssatzes, die Sie prüfen sollten, bevor Sie irgendetwas weiter öffnen.

6. Planen Sie die Folgewirkungen ein

Skalierbar heißt: Ihr Text bricht anders um, Ihre Bilder werden anders beschnitten, Ihr NavigationSplitView klappt nach fremder Laune zusammen und wieder auf, und Ihre sorgfältig abgestimmten Empty States erscheinen in Seitenverhältnissen, die Sie nie in der Vorschau hatten. Nichts davon ist für sich genommen schwierig. All das zusammen ist der Grund, warum die Checkliste jetzt beginnt und nicht erst in der Woche, in der die Hardware erscheint.

Was ich mir sparen würde

Sparen Sie sich Spekulationen über konkrete Geräte. Der Vertrag zur Größenveränderbarkeit steckt in einem SDK, das Sie heute laden können, dokumentiert in Release Notes, die Sie heute lesen können, testbar in Werkzeugen, die schon mit der ersten Beta von Xcode 27 ausgeliefert wurden. Erscheint in diesem Herbst ein faltbares iPhone, sind Apps bereit, die obige Liste abgearbeitet haben; kommt es erst im Frühjahr, zahlt sich dieselbe Arbeit sofort beim iPad-Multitasking aus – und bei allem anderen, was die Plattform als Nächstes skaliert. Sich auf den Mechanismus vorzubereiten schlägt die Vorbereitung auf das Gerücht.

Die wichtigsten Erkenntnisse

• Die Opt-in-Linie ist der SDK-Link. Bauen Sie mit dem iOS 27 SDK neu, wird Skalierbarkeit zum Problem und zur Chance Ihrer App; Apps mit älterem SDK behandelt das Device Hub im Resize-Modus als nicht unterstützt.²
• Die Ausrichtungshürde ist gefallen. Deklarierte Ausrichtungen entscheiden nicht mehr über Skalierbarkeit – der Eintrag ist in den aktuellen Notes als Fixed markiert, und die Liste der Known Issues von UIKit ist leer.¹
• Die Arbeit besteht darin, Annahmen zu löschen, nicht Funktionen zu ergänzen. Abfragen der Bildschirmgröße, Layouts aus magischen Zahlen, Ausrichtung als Stellvertreter, Caches beim Start: finden, durch containerabgeleitetes Layout ersetzen, fertig.
• Testen Sie auf den echten Flächen. Resizable-Canvas-Vorschauen und der Resize-Modus im Device Hub existieren genau dafür; ein Durchgang pro Bildschirm in beiden findet das meiste, was später zubeißt.

FAQ

Wird meine App automatisch skalierbar?

Die Grenze zieht Apple beim SDK-Link – die Release Notes zu Xcode 27 nennen den Resize-Modus mit Apps auf SDK-Stand iOS 26 oder älter nicht unterstützt, und die iOS-Notes binden jedes Verhalten zur Größenveränderbarkeit an einen Build mit dem iOS 27 SDK.¹² Was danach geschieht, hängt an Ihrem Layout: containergetriebenes SwiftUI passt sich meist an; Annahmen über feste Größen treten als Fehler zutage.

Muss ich weiterhin alle vier Ausrichtungen deklarieren, um kontinuierlich skalierbar zu sein?

Nein – die aktuellen Release Notes markieren die Ausrichtungsbedingung als Fixed (geklärt zwischen den Ausgaben zu Beta 4 und Beta 6) und halten fest: „supported interface orientations should no longer be a condition for continuous resizability“.¹ Frühere Betas verlangten den Workaround mit allen vier Ausrichtungen, der appweite Nebenwirkungen hat, die man kennen sollte, falls Sie ihn ausgeliefert haben.

Ist UIRequiresFullScreen jetzt veraltet?

Nein. Der Schlüssel wird weiterhin unterstützt, und die im Beta-Zyklus bekannten Probleme rund um sein Resize-Verhalten sind in den aktuellen Notes unter Resolved Issues als Fixed markiert.¹ Aber er ist genau die Art jahrealtes Opt-out, das man auf einer skalierbar gedachten Plattform bewusst neu entscheiden sollte.

Ab wann wird das dringend?

Die finalen Releases von iOS 27 werden im September erwartet, und Apples herbstlicher Zyklus der SDK-Anforderungen bedeutet, dass neue Einreichungen danach nach dem üblichen Zeitplan auf das iOS 27 SDK wechseln. Die obige Checkliste ist für die meisten Apps eine konzentrierte Arbeitswoche – wer jetzt beginnt, ist vor der Launch-Saison bequem fertig.

Quellen