iPad-Größenanpassung unter iOS 27: Die Umgehungslösung hat ihren Preis

Apples Release Notes zu iOS 27 nennen eine einzeilige Umgehungslösung für iPad-Apps, die sich nicht stufenlos in der Größe anpassen lassen: Deklarieren Sie in Ihrer Info.plist alle vier Interface-Ausrichtungen.¹ Verschwiegen wird dabei, dass das System diese app-weite Deklaration mit den unterstützten Ausrichtungen jedes einzelnen View Controllers schneidet.² Wer den app-weiten Satz erweitert, erweitert ihn überall — das iPhone eingeschlossen —, sofern nicht jeder eingeschränkte View Controller supportedInterfaceOrientations überschreibt.

Auch die verkürzte Fassung dieser Änderung trifft den aktuellen Stand nicht. Apples Absicht ist, dass deklarierte Ausrichtungen die stufenlose Größenanpassung nicht länger bedingen. Der Release-Note-Eintrag, der diese Absicht festhält, steht unter „Known Issues“ — denn in Beta 4 hängt die stufenlose Größenanpassung weiterhin an ihnen.¹

Beide Hälften zählen. Das Verhalten ist ein Fehler auf dem Weg zu einer bewussten Änderung, und die Umgehungslösung für diesen Fehler hat einen Nebeneffekt, den an derselben Stelle niemand dokumentiert.

Kurzfassung

In iOS und iPadOS 27 Beta 4 gilt eine iPad-App, die mit dem iOS 27 SDK gebaut wurde und in deren UISupportedInterfaceOrientations eine der vier Ausrichtungen fehlt, als nicht stufenlos größenveränderbar. Apple führt das als bekanntes Problem auf — zusammen mit der Aussage, unterstützte Ausrichtungen sollten „no longer be a condition for continuous resizability“, also keine Bedingung für die stufenlose Größenanpassung mehr sein.¹ Die dokumentierte Umgehungslösung besteht darin, alle vier zu deklarieren. Damit erweitern Sie den Ausrichtungssatz Ihrer App app-weit, und das System entscheidet über Rotation, indem es die app-weiten Ausrichtungen mit denen jedes View Controllers vergleicht.² Vier weitere bekannte Probleme betreffen UIRequiresFullScreen: Dort werden stufenlose Größenaktualisierungen geliefert, wo diskrete UIScreen-Wechsel vorgesehen sind.¹ Weder UIRequiresFullScreen noch UISupportedInterfaceOrientations ist als veraltet markiert.³⁴

Was in den Release Notes tatsächlich steht

Sechs Einträge im UIKit-Abschnitt der Notes zu iOS und iPadOS 27 Beta 4 berühren dieses Thema, fünf davon sind offen.¹

Die Begrenzung selbst, geführt unter „Known Issues“:

„On iPad, if your iPad app is built with the iOS 27 SDK and its UISupportedInterfaceOrientations doesn’t include all four interface orientations, the app is treated as non-continuously resizable. Beginning with iOS 27, supported interface orientations should no longer be a condition for continuous resizability.“

Sinngemäß: Enthält die UISupportedInterfaceOrientations einer mit dem iOS 27 SDK gebauten iPad-App nicht alle vier Interface-Ausrichtungen, behandelt das System die App als nicht stufenlos größenveränderbar — und ab iOS 27 sollten unterstützte Interface-Ausrichtungen keine Bedingung für die stufenlose Größenanpassung mehr sein.

Achten Sie im zweiten Satz auf die Zeitform. „Should no longer be a condition“ beschreibt beabsichtigtes Verhalten, nicht den Ist-Zustand. Der Eintrag steht als bekanntes Problem da, weil das ausgelieferte Verhalten der Absicht noch nicht entspricht.

Dieser Unterschied ändert Ihr Vorgehen. Würden Ausrichtungen die Größenanpassung tatsächlich nicht mehr bedingen, wäre der Rat, Umgehungslösungen zu entfernen. Da die Begrenzung noch besteht, lautet der Rat, eine anzuwenden — und damit zu rechnen, dass ihr Anlass verschwindet.

Vier bekannte Probleme rund um UIRequiresFullScreen:

Eine iPad-App, die mit dem iOS 27 SDK gebaut wurde und UIRequiresFullScreen setzt, erhält stufenlose Größenaktualisierungen — obwohl jede Größenänderung stattdessen als diskreter Wechsel zu einem neuen UIScreen mit aktualisierten Bounds ausgeliefert werden sollte („each resize should instead be delivered as a discrete change to a new UIScreen with an updated bounds“). Dasselbe gilt für eine reine iPhone-App auf dem iPad und ebenso innerhalb von iPhone Mirroring.¹

Ein viertes Problem betrifft die Behandlung von Ausrichtungen in iPhone Mirroring: Eine mit dem iOS 27 SDK gebaute App erhält eine Szene, die alle Ausrichtungen unterstützt — unabhängig davon, welche Ausrichtungen deklariert oder zurückgegeben werden („regardless of the orientations declared in UISupportedInterfaceOrientations or returned by UIViewController.supportedInterfaceOrientations“). Dabei sollten diese eigentlich beachtet werden, bis der Benutzer beginnt, die Fenstergröße zu ändern („should be honored until the user begins resizing the window“).¹

Eines ist gelöst: Ein früheres Problem, bei dem sich die Bounds von UIScreen.main unter UIRequiresFullScreen beim Ändern der Größe änderten, steht inzwischen unter „Resolved Issues“.¹ In einer vorherigen Beta war es ein offenes bekanntes Problem. Wenn Sie mit Notizen von vor einigen Wochen arbeiten, prüfen Sie diesen Punkt, bevor Sie ihn weitertragen.

Was Ihnen stufenlose Größenanpassung bringt

Bevor der Preis abgewogen wird, lohnt Genauigkeit darüber, was hier eigentlich begrenzt wird — denn „stufenlos größenveränderbar“ leistet eine sehr konkrete Arbeit.

Ein iPad-Fenster kann seine Größe auf zwei Arten ändern. Es kann zwischen diskreten Zuständen springen, und genau das bekommt eine App im Kompatibilitätsmodus: Das System behält, in Apples Worten, „eine gleichbleibende Szenengröße für Ihre App bei, zeigt die Szene Ihrer App aber nicht im Vollbild“ („maintains a consistent scene size for your app, but doesn’t present your app’s scene full screen“).³ Oder die Größe folgt der Ziehbewegung, und die App empfängt einen Strom von Zwischengrößen, während der Benutzer das Größenelement bewegt.

Der Unterschied ist direkt spürbar, während man zieht. Eine stufenlos größenveränderbare App baut ihr Layout laufend neu auf, während sich das Fenster bewegt. Eine nicht stufenlos größenveränderbare hält ihr Layout fest und springt erst am Ende ein — was neben System-Apps, die das nicht tun, träge wirkt.

Apple verengt den Kompatibilitätspfad seit Jahren. UIRequiresFullScreen kam mit iOS 9, um sich vollständig aus dem iPad-Multitasking und der dynamischen Größenanpassung auszuklinken.³ Stage Manager in iPadOS 16 und der Windowed-Apps-Modus in iPadOS 26 haben jeweils erweitert, was ein Fenster kann, und die Dokumentation beschreibt den Kompatibilitätsmodus mittlerweile über das, was er vorenthält, statt über das, was er gewährt.

Die Frage, die die Umgehungslösung beantwortet, lautet also: Nimmt Ihre iPad-App am modernen Windowing teil, oder sitzt sie in einem Modus, den Apple beständig schrumpfen lässt? Das ist eine Änderung an der Info.plist wert. Eine ungesicherte Änderung ist es nicht — worum es im nächsten Abschnitt geht.

Der Preis der Umgehungslösung

Apples Umgehungslösung steht in einem einzigen Satz: alle vier Interface-Ausrichtungen in der Info.plist deklarieren.¹ Die Konsequenz steht auf einer anderen Seite.

UIViewController.supportedInterfaceOrientations dokumentiert, wie über Rotation entschieden wird:²

„To determine whether to rotate, the system compares the view controller’s supported orientations with the app’s supported orientations — as determined by the Info.plist file or the app delegate’s [method] — and the device’s supported orientations.“

Sinngemäß: Um zu entscheiden, ob rotiert wird, vergleicht das System die unterstützten Ausrichtungen des View Controllers mit denen der App — bestimmt durch die Info.plist oder die entsprechende Methode des App Delegates — und mit denen des Geräts.

Drei Mengen, geschnitten. Die Deklaration in der Info.plist ist eine Obergrenze, keine Anweisung. Eine App, die nur deshalb im Hochformat geblieben ist, weil sie in der Info.plist eine einzige Ausrichtung listet und auf View-Controller-Ebene nie etwas überschreibt, verliert ihre Einschränkung in dem Moment, in dem sie die Umgehungslösung anwendet.

Bei einer Universal-App landet das auf dem iPhone genauso wie auf dem iPad. Und Apples eigene Empfehlung spricht dort gegen die breite Deklaration: Zum kopfstehenden Hochformat heißt es, es empfehle sich, diese Ausrichtung für das iPad-Idiom zu aktivieren; iOS-Geräte ohne Home-Button wie das iPhone 12 unterstützen sie nicht, und für das iPhone-Idiom solle man sie vollständig deaktivieren („It’s best practice to enable it for the iPad idiom. iOS devices without a Home button, such as iPhone 12, don’t support this orientation. You should disable it entirely for the iPhone idiom.“).² Die Dokumentation zur Info.plist sagt dasselbe von der anderen Seite und hält fest, dass das System das kopfstehende Hochformat auf Geräten ohne Home-Button ignoriert („on devices without a Home button“).⁴

Die ehrliche Anleitung umfasst also zwei Schritte, nicht einen:

<!-- Info.plist: the ceiling. Required for continuous resizability on iPad. -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationPortraitUpsideDown</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// And the floor, on every controller that must stay constrained.
final class CaptureViewController: UIViewController {
    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        UIDevice.current.userInterfaceIdiom == .pad ? .all : .portrait
    }
}

Lassen Sie den zweiten Schritt weg, haben Sie einer Universal-App gesagt, sie solle auf dem iPhone kopfüber rotieren, um auf dem iPad ein Windowing-Verhalten zu erhalten. Der Fehler ist kein Absturz und kein Build-Fehler. Er ist eine Kameraansicht, die umklappt, während jemand sie benutzt.

Beachten Sie außerdem, dass sich die Standardwerte von supportedInterfaceOrientations je nach Idiom unterscheiden und das System die Eigenschaft nur heranzieht, wenn shouldAutorotate true zurückgibt.² Falls Sie das überschrieben haben, lohnt es sich, dieses Zusammenspiel nachzulesen, bevor Sie annehmen, Ihre Einschränkung greife noch.

Herausfinden, ob Sie betroffen sind

Nichts davon erzeugt einen Build-Fehler, die Prüfung ist also Handarbeit. Drei Kontrollen, absteigend danach sortiert, wie viel Zeit sie sparen.

Prüfen Sie pro Target, was Ihre Info.plist tatsächlich deklariert. Die Ausrichtungsschlüssel werden häufig einmal beim Anlegen des Projekts gesetzt und nie wieder angefasst, und eine Universal-App kann über UISupportedInterfaceOrientations~ipad unterschiedliche Deklarationen für iPhone und iPad mitführen. Lesen Sie beide.

# Every orientation and fullscreen declaration across the project
rg -l 'UISupportedInterfaceOrientations|UIRequiresFullScreen' --glob '*.plist'

# And what each one says
/usr/libexec/PlistBuddy -c "Print :UISupportedInterfaceOrientations" Info.plist
/usr/libexec/PlistBuddy -c "Print :UIRequiresFullScreen" Info.plist

PlistBuddy beendet sich mit einem Exit-Code ungleich null, wenn ein Schlüssel fehlt — und genau das ist für UIRequiresFullScreen bereits die Antwort: kein Schlüssel heißt, Sie waren nie im Kompatibilitätsmodus.

Finden Sie die Controller, die Ausrichtungen im Code einschränken. Diese funktionieren nach der Änderung an der Info.plist weiterhin, und ihr Fehlen ist es, was die Änderung gefährlich macht.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

Ein leeres Ergebnis in Kombination mit einer engen Deklaration in der Info.plist ist genau das Profil, das bricht: Die App ist ausschließlich kraft der Property List auf Hochformat festgelegt, das Erweitern entfernt also die einzige vorhandene Einschränkung.

Sehen Sie sich die App danach auf beiden Idiomen an. Der Fehler ist visuell, und das automatisierte Signal ist schwach. Ein UI-Test, der einen Bildschirm bedient und dessen Inhalte prüft, besteht in jeder Ausrichtung. Wonach Sie suchen, ist eine Ansicht, die rotiert, obwohl sie das vorher nicht konnte — was bedeutet: den iPhone-Build starten und das Gerät oder den Simulator nach der Info.plist-Änderung tatsächlich drehen.

Medienaufnahme, Dokumentenscans, Unterschriftenfelder, Spiele und alles mit fest vorgegebenem Seitenverhältnis sind die Stellen, an denen eine unerwartete Rotation am teuersten ist — und zugleich die, an denen Überschreibungen pro Controller am offensichtlichsten hingehören.

UIRequiresFullScreen wird ausgehöhlt, nicht abgekündigt

Vier der fünf offenen Probleme betreffen UIRequiresFullScreen.¹ Der Schlüssel, mit dem sich eine App aus dem iPad-Multitasking ausklinkt, ist inzwischen die Bedingung, unter der die Auslieferung von Größenänderungen fehlerhaft arbeitet.

Abgekündigt ist er nicht. Die Dokumentation zu UIRequiresFullScreen weist Verfügbarkeit ab iOS 9.0 und iPadOS 9.0 aus, ohne Deprecation-, Unavailability- oder Beta-Kennzeichnung.³ UISupportedInterfaceOrientations, verfügbar seit iOS 3.2, ebenso wenig.⁴

Diese Kombination sollte man beim Namen nennen. Eine App, die 2026 UIRequiresFullScreen setzt, kompiliert ohne Warnung, wird ohne Migrationshinweis ausgeliefert und landet in einem Kompatibilitätsmodus, den Apple weiter verengt. Die Dokumentation beschreibt bereits, was dieser Modus auf modernen Systemen bedeutet: Ab iPadOS 26 auf iPads mit Windowed-Apps-Modus und ab iPadOS 16 auf iPads mit Stage Manager behält das System „eine gleichbleibende Szenengröße für Ihre App bei, zeigt die Szene Ihrer App aber nicht im Vollbild“.³

Der Schlüssel tut nicht mehr das, was sein Name sagt. Ausgemustert wurde er nicht, und nichts in Ihrem Build wird Ihnen das mitteilen.

Das Muster: Die SDK-Bindung entscheidet

Alle obigen Einträge teilen eine Bedingung, und es ist nicht die OS-Version. Jeder gilt für Apps, die mit dem iOS 27 SDK gebaut wurden („built with the iOS 27 SDK“).¹

Gleiche Quelle, anderes Binary, anderes Verhalten. Das ist in diesem Release wiederholt aufgetaucht: Bilder in Menüeinträgen hängen davon ab, gegen welches SDK Sie gelinkt haben, mit drei unterschiedlichen Verhaltensweisen über zwei SDK-Generationen hinweg. Und die teamübergreifende Container-Verweigerung in macOS 27 scheint der umgekehrte Fall zu sein: eine Richtlinie auf OS-Ebene ohne SDK-Einschränkung — genau deshalb lohnt es, die Unterscheidung zu prüfen statt sie vorauszusetzen.

Die praktische Folge fürs Testen: Ein Build gegen das iOS 26 SDK und ein Build gegen das iOS 27 SDK sind verschiedene Prüfobjekte. Enthält Ihre CI-Matrix nur eine Xcode-Version, testet sie nur eines davon.

Was jetzt zu tun ist

Klären Sie, ob Sie stufenlose Größenanpassung überhaupt brauchen. Deklariert Ihre iPad-App bereits alle vier Ausrichtungen, betrifft Sie nichts davon. Die Umgehungslösung ist nur relevant, wenn Sie Ausrichtungen bewusst eingeschränkt haben.

Wenn Sie die Umgehungslösung anwenden, koppeln Sie sie an Überschreibungen pro Controller. Die Änderung an der Info.plist ist eine Obergrenze; die Einschränkung muss in supportedInterfaceOrientations auf den Controllern landen, die sie brauchen — abhängig vom Idiom.

Prüfen Sie UIRequiresFullScreen separat. Vier offene Probleme betreffen den Schlüssel, und Ihr Build markiert ihn nicht. Durchsuchen Sie Ihre Info.plist-Dateien, einschließlich jedes Targets, das Sie nicht als iPad-App im Kopf haben, denn eines der Probleme betrifft reine iPhone-Apps auf dem iPad.

Rechnen Sie damit, dass die Begrenzung verschwindet. Apple erklärt, Ausrichtungen sollten die stufenlose Größenanpassung nicht länger bedingen. Sobald das greift, entfällt der Grund, alle vier zu deklarieren — der erweiterte Ausrichtungssatz bleibt aber in Ihrer Info.plist, bis ihn jemand entfernt. Hinterlassen Sie einen Kommentar, der erklärt, warum er dort steht.

Prüfen Sie die Notes erneut, bevor Sie handeln. Einer dieser sechs Einträge ist bereits von „Known Issues“ zu „Resolved“ gewandert. Dieser Beitrag gibt den Stand von Beta 4 am 2. August 2026 wieder.

Das Wichtigste in Kürze

Für iPad-Entwickler: - Deklarierte Ausrichtungen begrenzen in Beta 4 weiterhin die stufenlose Größenanpassung, obwohl Apple erklärt, sie sollten es nicht. Behandeln Sie das als Fehler mit Umgehungslösung, nicht als das neue Verhalten. - Die Umgehungslösung erweitert Ihre app-weite Ausrichtungs-Obergrenze. Ergänzen Sie Überschreibungen von supportedInterfaceOrientations pro Controller, sonst beginnt Ihr iPhone-Build zu rotieren. - Vier offene Probleme betreffen UIRequiresFullScreen: Der Schlüssel liefert stufenlose statt diskreter Größenaktualisierungen.

Für alle, die eine ältere App pflegen: - UIRequiresFullScreen ist nicht abgekündigt und erzeugt keine Warnung, während das angeforderte Verhalten immer enger wird. Prüfen Sie gezielt darauf. - Jedes Problem hier hängt daran, dass gegen das iOS 27 SDK gebaut wird — nicht daran, welches OS der Benutzer ausführt.

FAQ

Begrenzen deklarierte Ausrichtungen die stufenlose Größenanpassung weiterhin?

In Beta 4: ja. Apple erklärt zwar, „beginning with iOS 27, supported interface orientations should no longer be a condition for continuous resizability“ — ab iOS 27 sollten unterstützte Interface-Ausrichtungen also keine Bedingung für die stufenlose Größenanpassung mehr sein. Diese Aussage steht jedoch unter „Known Issues“, weil das aktuelle Verhalten sie nach wie vor als Bedingung behandelt.¹

Wie lautet die tatsächliche Umgehungslösung?

Deklarieren Sie alle vier Interface-Ausrichtungen in UISupportedInterfaceOrientations.¹ Koppeln Sie das an Überschreibungen von supportedInterfaceOrientations auf den View Controllern, die eingeschränkt bleiben müssen, denn das System schneidet den app-weiten Satz mit dem jedes Controllers.²

Wirkt sich das auf meinen iPhone-Build aus?

Wenn Sie eine Universal-App ausliefern und die Ausrichtung allein über die Info.plist einschränken: ja. Apple empfiehlt, das kopfstehende Hochformat für das iPhone-Idiom vollständig zu deaktivieren, und weist darauf hin, dass das System es auf Geräten ohne Home-Button ignoriert.²⁴

Ist UIRequiresFullScreen abgekündigt?

Nein. Die Dokumentation weist Verfügbarkeit ab iOS und iPadOS 9.0 ohne Deprecation-Kennzeichnung aus.³ Vier der hier offenen Probleme betreffen den Schlüssel — das Fehlen einer Abkündigungsmarkierung sollte also nicht als Empfehlung gelesen werden.

Sollte ich die Umgehungslösung entfernen, sobald Apple die Begrenzung behebt?

Entfernen Sie den Teil, den Sie nicht mehr brauchen, und behalten Sie den, der Sie schützt. Sobald deklarierte Ausrichtungen die stufenlose Größenanpassung nicht mehr bedingen, entfällt der Grund, alle vier zu listen, und Sie können UISupportedInterfaceOrientations wieder auf das eingrenzen, was Ihre App tatsächlich unterstützt. Die Überschreibungen von supportedInterfaceOrientations pro Controller sollten in jedem Fall bleiben, denn Ausrichtungseinschränkungen dort auszudrücken, wo die Einschränkung hingehört, ist haltbarer, als sich auf eine app-weite Obergrenze zu verlassen.

Der Fehlerfall, den es zu vermeiden gilt, ist der umgekehrte: die Info.plist wieder einzuengen und dabei zu vergessen, dass allein die Überschreibungen einen Aufnahmebildschirm aufrecht gehalten haben.

Woran erkenne ich, ob meine App derzeit stufenlos größenveränderbar ist?

Ändern Sie die Fenstergröße auf einem iPad und achten Sie darauf, ob das Layout der Ziehbewegung folgt oder erst am Ende einspringt. Folgt es, ist die App stufenlos größenveränderbar. Springt es, prüfen Sie zwei Dinge: ob UIRequiresFullScreen gesetzt ist, womit die dynamische Größenanpassung vollständig abgeschaltet wird, und ob UISupportedInterfaceOrientations alle vier Ausrichtungen listet — das ist die Bedingung, die dieses bekannte Problem beschreibt.¹³

Umgeht ein Build gegen ein älteres SDK das alles?

Jeder Eintrag ist daran gebunden, dass mit dem iOS 27 SDK gebaut wird.¹ Ein älteres SDK vermeidet diese konkreten Probleme und verzögert die kommende Änderung — verhindern kann es sie nicht.

Quellen