iPad-Skalierbarkeit in iOS 27: Der Workaround hat seinen Preis

Die Release Notes zu iOS 27 nennen für iPad-Apps, die nicht kontinuierlich skalierbar sind, einen Workaround in einem einzigen Satz: Deklarieren Sie in Ihrer Info.plist die Unterstützung für alle vier Interface-Ausrichtungen.¹ Was der Hinweis verschweigt: Das System bildet die Schnittmenge aus dieser appweiten Deklaration und den unterstützten Ausrichtungen jedes einzelnen View Controllers.² Weiten Sie die appweite Menge, weiten Sie sie überall – das iPhone eingeschlossen –, sofern nicht jeder eingeschränkte View Controller supportedInterfaceOrientations überschreibt.

Update, 24. August: Die Sperre ist aufgehoben. Die aktuellen Release Notes führen Issue 166422120 als Fixed – es ist zwischen der Ausgabe zu Beta 4 und der zu Beta 6 aus den Known Issues verschwunden, und die Ausgabe zu Beta 7 bestätigt es: Deklarierte Ausrichtungen bedingen die kontinuierliche Skalierbarkeit nicht mehr, ganz so, wie es die unten zitierte Absichtserklärung vorsah.¹ Wer den Workaround mit allen vier Ausrichtungen ausgeliefert hat, braucht ihn auf den aktuellen Betas nicht mehr. Prüfen Sie allerdings vor dem Entfernen noch einmal jene View Controller, bei denen Sie begleitend supportedInterfaceOrientations überschrieben haben: Diese Overrides tragen weiterhin für sich allein (am in diesem Beitrag beschriebenen Schnittmengenverhalten hat sich nichts geändert). Auch die Resize-Known-Issues rund um UIRequiresFullScreen aus der Beta-4-Zeit stehen inzwischen unter Resolved Issues als Fixed. Die folgende Analyse bleibt unverändert erhalten und ist weiterhin an Beta 4 verankert, denn die Nebenwirkungen des Workarounds greifen überall dort, wo er in ausgelieferten Builds noch steckt. Das größere Bild, in das sich diese Änderung einfügt, zeichnet Die Ära des skalierbaren iPhones.

Auch die verkürzte Lesart dieser Änderung beschreibt den aktuellen Stand falsch. Apples Absicht ist, dass deklarierte Ausrichtungen die kontinuierliche Skalierbarkeit nicht länger bedingen. Der Eintrag in den Release Notes, der diese Absicht festhält, steht unter Known Issues – weil sie in Beta 4 eben doch noch bedingen.¹

Beide Hälften zählen. Das Verhalten ist ein Bug auf dem Weg zu einer bewussten Änderung, und der Workaround für diesen Bug hat eine Nebenwirkung, die niemand an derselben Stelle dokumentiert.

TL;DR

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 kontinuierlich skalierbar. Apple führt das als Known Issue und stellt zugleich fest, Ausrichtungen sollten „keine Bedingung für kontinuierliche Skalierbarkeit mehr sein”.¹ Der dokumentierte Workaround lautet: alle vier deklarieren. Damit weitet sich die Ausrichtungsmenge appweit, und das System entscheidet über Rotation, indem es appweite Ausrichtungen mit denen jedes View Controllers vergleicht.² Vier weitere Known Issues betreffen UIRequiresFullScreen, das kontinuierliche Resize-Updates liefert, wo diskrete UIScreen-Wechsel vorgesehen sind.¹ Weder UIRequiresFullScreen noch UISupportedInterfaceOrientations ist als veraltet markiert.³⁴

Was in den Release Notes tatsächlich steht

Im UIKit-Abschnitt der Notes zu iOS und iPadOS 27 Beta 4 betreffen sechs Einträge dieses Thema, fünf davon sind offen.¹

Die Sperre selbst, geführt unter Known Issues:

„Wenn Ihre iPad-App auf dem iPad mit dem iOS 27 SDK gebaut wurde und ihre UISupportedInterfaceOrientations nicht alle vier Interface-Ausrichtungen enthält, wird die App als nicht kontinuierlich skalierbar behandelt. Ab iOS 27 sollten unterstützte Interface-Ausrichtungen keine Bedingung für kontinuierliche Skalierbarkeit mehr sein.”

Achten Sie im zweiten Satz auf die Zeitform. „Sollten keine Bedingung mehr sein” beschreibt beabsichtigtes Verhalten. Der Eintrag existiert als Known Issue, weil das ausgelieferte Verhalten dieser Absicht noch nicht entspricht.

Dieser Unterschied ändert, was zu tun ist. Hätten Ausrichtungen die Skalierbarkeit tatsächlich schon freigegeben, wäre der Rat, Workarounds zu entfernen. Da sie sie weiterhin bedingen, lautet der Rat, einen anzuwenden – und damit zu rechnen, dass der Grund dafür verschwindet.

Vier Known Issues rund um UIRequiresFullScreen:

Eine iPad-App, die mit dem iOS 27 SDK gebaut wurde und UIRequiresFullScreen setzt, erhält kontinuierliche Resize-Updates, obwohl „jede Größenänderung stattdessen als diskreter Wechsel zu einem neuen UIScreen mit aktualisierten Bounds ausgeliefert werden sollte”. Dasselbe gilt für eine reine iPhone-App auf dem iPad und ebenso innerhalb von iPhone-Spiegelung.¹

Ein vierter Eintrag betrifft die Behandlung von Ausrichtungen bei der iPhone-Spiegelung: Eine mit dem iOS 27 SDK gebaute App erhält eine Scene, die alle Ausrichtungen unterstützt, „unabhängig von den in UISupportedInterfaceOrientations deklarierten oder von UIViewController.supportedInterfaceOrientations zurückgegebenen Ausrichtungen” – obwohl diese „berücksichtigt werden sollten, bis der Benutzer beginnt, die Fenstergröße zu ändern”.¹

Einer ist erledigt: Ein früheres Problem, bei dem sich unter UIRequiresFullScreen die Bounds von UIScreen.main beim Skalieren änderten, steht inzwischen unter Resolved Issues.¹ In einer früheren Beta war es ein aktives Known Issue. Wer mit Notizen von vor ein paar Wochen arbeitet, sollte diesen Punkt prüfen, bevor er ihn wiederholt.

Was kontinuierliche Skalierbarkeit bringt

Bevor der Preis abgewogen wird, lohnt sich Genauigkeit bei dem, was hier überhaupt gesperrt ist – denn „kontinuierlich skalierbar” leistet konkrete Arbeit.

Ein iPad-Fenster kann seine Größe auf zwei Arten ändern. Es kann zwischen diskreten Zuständen springen; das bekommt eine App im Kompatibilitätsmodus: Das System, so Apple, „hält eine konsistente Scene-Größe für Ihre App aufrecht, stellt die Scene Ihrer App aber nicht im Vollbild dar”.³ Oder es kann dem Ziehen folgen und einen Strom von Zwischengrößen empfangen, während der Benutzer das Resize-Element bewegt.

Der Unterschied zeigt sich in der Hand des Benutzers. Eine kontinuierlich skalierbare App reflowt, während das Fenster in Bewegung ist. Eine nicht kontinuierlich skalierbare hält ihr Layout und schnappt am Ende ein – was neben System-Apps, die das nicht tun, träge wirkt.

Apple verengt den Kompatibilitätspfad seit Jahren. UIRequiresFullScreen kam in iOS 9, um sich vollständig aus iPad-Multitasking und dynamischer Größenänderung 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 inzwischen darüber, was er vorenthält, statt darüber, was er gewährt.

Die Frage, die der Workaround beantwortet, lautet also: Nimmt Ihre iPad-App am modernen Windowing teil, oder sitzt sie in einem Modus, den Apple weiter 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 des Workarounds

Apples Workaround 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:²

„Um zu bestimmen, ob rotiert werden soll, vergleicht das System die unterstützten Ausrichtungen des View Controllers mit den unterstützten Ausrichtungen der App – wie sie durch die Info.plist-Datei oder die [Methode] des App-Delegates festgelegt sind – und mit den unterstützten Ausrichtungen des Geräts.”

Drei Mengen, geschnitten. Die Deklaration in der Info.plist ist eine Obergrenze, keine Anweisung. Eine App, die durch genau einen Eintrag in der Info.plist im Hochformat geblieben ist und auf View-Controller-Ebene nie etwas überschrieben hat, verliert ihre Einschränkung in dem Moment, in dem sie den Workaround 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: Zur kopfstehenden Ausrichtung heißt es, „es ist Best Practice, sie für das iPad-Idiom zu aktivieren. iOS-Geräte ohne Home-Button, etwa das iPhone 12, unterstützen diese Ausrichtung nicht. Für das iPhone-Idiom sollten Sie sie vollständig deaktivieren.”² Die Dokumentation zur Info.plist sagt dasselbe von der anderen Seite und hält fest, dass das System Upside-Down „auf Geräten ohne Home-Button” ignoriert.⁴

Die ehrliche Anweisung besteht also aus zwei Schritten, nicht aus einem:

<!-- 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 ein Windowing-Verhalten auf dem iPad zu bekommen. Der Fehler ist kein Crash und kein Build-Fehler. Er ist eine Kameraansicht, die kippt, während jemand sie benutzt.

Beachten Sie außerdem: Die Standardwerte von supportedInterfaceOrientations unterscheiden sich je nach Idiom, und das System zieht die Eigenschaft nur heran, wenn shouldAutorotate true zurückgibt.² Wer Letzteres überschrieben hat, sollte dieses Zusammenspiel noch einmal nachlesen, bevor er seine Einschränkung für gesichert hält.

Herausfinden, ob Sie betroffen sind

Nichts davon erzeugt einen Build-Fehler, das Audit bleibt also Handarbeit. Drei Prüfungen, absteigend danach, 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 Wert ungleich null, wenn ein Schlüssel fehlt – was bei UIRequiresFullScreen bereits die Antwort ist: kein Schlüssel, nie im Kompatibilitätsmodus gewesen.

Finden Sie die Controller, die Ausrichtung im Code einschränken. Genau sie funktionieren nach der Info.plist-Änderung weiter, und ihr Fehlen macht diese Änderung gefährlich.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

Ein leeres Ergebnis in Kombination mit einer engen Info.plist-Deklaration ist genau das Profil, das bricht: Die App ist einzig kraft der Property List im Hochformat, und das Weiten entfernt die einzige Einschränkung, die es gab.

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

Medienaufnahme, Dokumentenscans, Unterschriftsfelder, Spiele und alles mit einer Canvas fester Seitenverhältnisse sind die Stellen, an denen eine unerwartete Rotation am teuersten ist – und zugleich die, an denen Overrides pro Controller am offensichtlichsten hingehören.

UIRequiresFullScreen wird ausgehöhlt, nicht abgekündigt

Vier der fünf offenen Issues betreffen UIRequiresFullScreen.¹ Der Schlüssel, der eine App aus dem iPad-Multitasking herausnimmt, ist inzwischen die Bedingung, unter der die Resize-Auslieferung falsch arbeitet.

Er ist nicht als veraltet markiert. Die Dokumentation zu UIRequiresFullScreen weist Verfügbarkeit ab iOS 9.0 und iPadOS 9.0 aus, ohne Deprecation-, Unavailability- oder Beta-Flag.³ Für UISupportedInterfaceOrientations gilt dasselbe, verfügbar seit iOS 3.2.⁴

Diese Kombination verdient einen Namen. Eine App, die 2026 UIRequiresFullScreen setzt, kompiliert ohne Warnung, geht ohne Migrationshinweis in den Versand und landet in einem Kompatibilitätsmodus, den Apple weiter verengt. Was dieser Modus auf modernen Systemen bedeutet, steht längst in der Dokumentation: Unter iPadOS 26 und neuer auf iPads mit Windowed-Apps-Modus sowie unter iPadOS 16 und neuer auf iPads mit Stage Manager „hält das System eine konsistente Scene-Größe für Ihre App aufrecht, stellt die Scene Ihrer App aber nicht im Vollbild dar”.³

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

Das Muster: Die SDK-Bindung entscheidet

Jeder Eintrag oben teilt eine Bedingung, und es ist nicht die OS-Version. Jeder gilt für Apps, die „mit dem iOS 27 SDK gebaut” wurden.¹

Gleiche Quelle, anderes Binary, anderes Verhalten. Das kam in diesem Release wiederholt vor: Bilder in Menüeinträgen hängen davon ab, gegen welches SDK Sie gelinkt haben, mit drei verschiedenen Verhaltensweisen über zwei SDK-Generationen. Und die teamübergreifende Container-Verweigerung in macOS 27 scheint der umgekehrte Fall zu sein: eine Richtlinie auf OS-Ebene ohne SDK-Qualifier – genau deshalb lohnt es sich, diesen Unterschied zu prüfen statt anzunehmen.

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

Was jetzt zu tun ist

Entscheiden Sie, ob Sie kontinuierliche Skalierbarkeit überhaupt brauchen. Deklariert Ihre iPad-App bereits alle vier Ausrichtungen, trifft nichts davon zu. Der Workaround ist nur relevant, wenn Sie Ausrichtungen bewusst eingeschränkt haben.

Wenden Sie den Workaround an, koppeln Sie ihn mit Overrides pro Controller. Die Info.plist-Änderung ist eine Obergrenze; die Einschränkung muss in supportedInterfaceOrientations auf den Controllern landen, die sie brauchen, abhängig vom Idiom.

Prüfen Sie UIRequiresFullScreen gesondert. Vier offene Issues betreffen ihn, und Ihr Build weist nicht darauf hin. Greppen Sie Ihre Info.plist-Dateien, auch die Targets, die Sie nicht für iPad-Apps halten – eines der Issues betrifft reine iPhone-Apps auf dem iPad.

Rechnen Sie damit, dass die Sperre verschwindet. Apple erklärt, Ausrichtungen sollten kontinuierliche Skalierbarkeit nicht länger bedingen. Sobald das greift, entfällt der Grund, alle vier zu deklarieren – die geweitete Ausrichtungsmenge aber bleibt in Ihrer Info.plist, bis jemand sie entfernt. Hinterlassen Sie einen Kommentar, der erklärt, warum sie 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 Beta 4 mit Stand vom 2. August 2026 wieder.

Die wichtigsten Punkte

Für iPad-Entwickler: - Deklarierte Ausrichtungen bedingen die kontinuierliche Skalierbarkeit in Beta 4 weiterhin, obwohl Apple das Gegenteil festhält. Behandeln Sie es als Bug mit Workaround, nicht als das neue Verhalten. - Der Workaround weitet die appweite Ausrichtungsobergrenze. Ergänzen Sie supportedInterfaceOrientations-Overrides pro Controller, sonst fängt Ihr iPhone-Build an zu rotieren. - Vier offene Issues betreffen UIRequiresFullScreen, das kontinuierliche statt diskreter Resize-Updates liefert.

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 Issue hier hängt am Bauen mit dem iOS 27 SDK, nicht am Betriebssystem des Benutzers.

FAQ

Bedingen deklarierte Ausrichtungen die kontinuierliche Skalierbarkeit nicht mehr?

In Beta 4 doch. Apple erklärt, „ab iOS 27 sollten unterstützte Interface-Ausrichtungen keine Bedingung für kontinuierliche Skalierbarkeit mehr sein”, und führt diese Aussage unter Known Issues, weil das aktuelle Verhalten weiterhin an ihnen hängt.¹

Wie lautet der tatsächliche Workaround?

Deklarieren Sie alle vier Interface-Ausrichtungen in UISupportedInterfaceOrientations.¹ Koppeln Sie das mit supportedInterfaceOrientations-Overrides auf den View Controllern, die eingeschränkt bleiben müssen, denn das System schneidet die appweite Menge mit der jedes Controllers.²

Wirkt sich das auf meinen iPhone-Build aus?

Wenn Sie eine Universal App ausliefern und sich zur Einschränkung der Ausrichtung allein auf die Info.plist verlassen: ja. Apple empfiehlt, Upside-Down für das iPhone-Idiom vollständig zu deaktivieren, und hält fest, 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-Flag aus.³ Vier der offenen Issues hier betreffen ihn – das Fehlen einer Deprecation-Markierung sollte deshalb nicht als Empfehlung gelesen werden.

Sollte ich den Workaround entfernen, sobald Apple die Sperre behebt?

Entfernen Sie den Teil, den Sie nicht mehr brauchen, und behalten Sie den, der Sie schützt. Sobald deklarierte Ausrichtungen die kontinuierliche Skalierbarkeit nicht mehr bedingen, entfällt der Grund, alle vier aufzulisten, und Sie können UISupportedInterfaceOrientations wieder auf das eingrenzen, was Ihre App tatsächlich unterstützt. Die supportedInterfaceOrientations-Overrides pro Controller sollten in jedem Fall bleiben: Ausrichtungseinschränkungen dort auszudrücken, wo die Einschränkung hingehört, ist haltbarer, als sich auf eine appweite 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 Overrides einen Aufnahme-Screen aufrecht gehalten haben.

Woran erkenne ich, ob meine App derzeit kontinuierlich skalierbar ist?

Ändern Sie die Fenstergröße auf einem iPad und beobachten Sie, ob das Layout dem Ziehen folgt oder am Ende einschnappt. Folgt es, ist die App kontinuierlich skalierbar. Schnappt es ein, prüfen Sie zweierlei: ob UIRequiresFullScreen gesetzt ist, was dynamische Größenänderung vollständig abwählt, und ob UISupportedInterfaceOrientations alle vier Ausrichtungen auflistet – das ist die Bedingung, die dieses Known Issue beschreibt.¹³

Umgehe ich das alles, wenn ich gegen ein älteres SDK baue?

Jeder Eintrag hängt am Bauen mit dem iOS 27 SDK.¹ Ein älteres SDK vermeidet diese konkreten Issues und verschiebt die kommende Änderung, statt sie zu verhindern.

Quellen