UIKits Scene-Pflicht: Was unter iOS 27 nicht mehr startet

Apples Migrationsdokumentation formuliert die härteste Anforderung des iOS-27-Zyklus in einem einzigen Satz: „Ab iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27 und visionOS 27 müssen Apps, die mit dem neuesten SDK gebaut werden, den szenenbasierten Lebenszyklus übernehmen, sonst starten sie nicht.”¹ Nicht veraltet, nicht mit Warnung versehen, nicht langsamer: Sie starten nicht. Session 278 sagt es ebenso unverblümt: „Der UIScene-Lebenszyklus ist jetzt erforderlich, wenn Sie mit den neuesten SDKs bauen. Ohne ihn wird Ihre Anwendung nicht mehr starten.”² Jede UIKit-App, die noch auf dem alten App-Delegate-Lebenszyklus läuft, hat bis zu dem Moment Zeit zu migrieren, in dem sie gegen das iOS-27-SDK gebaut wird – und die Warnphase reicht bereits Jahre zurück.

Die Anforderung, formuliert bei 2:36 in Session 278.

Kurzfassung

• Apps, die mit dem iOS-27-SDK gebaut werden, müssen den szenenbasierten UIKit-Lebenszyklus verwenden, sonst starten sie nicht – über iOS, iPadOS, Mac Catalyst, tvOS und visionOS 27 hinweg.¹ Bestehende Binärdateien, die mit älteren SDKs gebaut wurden, funktionieren weiterhin; die Hürde ist das SDK, gegen das Sie bauen.
• Die Eskalation erfolgte schrittweise: UIKit begann bereits in iOS 18.4, eine Migrationsmeldung zu protokollieren, und die Meldung änderte sich in iOS 26. In iOS 27 wird aus dem Protokolleintrag ein Startfehler.¹
• Sie müssen migrieren, wenn eine der beiden Bedingungen zutrifft: Ihre Info.plist enthält keinen UIApplicationSceneManifest-Schlüssel mit einer Konfiguration, oder Ihr App-Delegate implementiert die Methode zur Szenenkonfiguration nicht.¹
• Die minimale Migration ist klein: ein Scene-Manifest-Eintrag in der Property-List oder die Delegate-Methode für dynamische Konfigurationen. Die Unterstützung mehrerer Szenen bleibt optional.¹
• Xcode 27 liefert eine Agent-Skill zur App-Modernisierung mit, die Apps auf den Scene-Lebenszyklus umstellt, Prüfungen auf den Hauptbildschirm und die Ausrichtung umschreibt, bei komplexen Aufgaben Rückfragen stellt und Kommentare für Arbeit hinterlässt, die sie in einer Sitzung nicht abschließen kann.²

Eine Pflicht, keine Abkündigung

Der 27er-Zyklus zeigt ein Muster, APIs eine Version nach der Reifung ihres Ersatzes zurückzustutzen: ImageCreator stellt unter iOS 27 die Arbeit ein, und MXMetricManager trägt eine 27.0-Abkündigung in derselben Woche, in der sein Ersatz erschien. Die Scene-Anforderung ist der folgenreichste Eintrag in diesem Muster, weil sie die gesamte App betrifft, nicht nur eine Funktion. Eine App, die Image Playground nie berührt, verliert in diesem Herbst nichts. Eine App, die den Scene-Lebenszyklus ignoriert, startet ab dem Tag nicht mehr, an dem sie mit dem neuen SDK gebaut wird.

Der Zeitplan zeigt, wie viel Vorlauf Apple verbrauchte, bevor es zur Durchsetzung kam. Ab iOS 18.4, iPadOS 18.4, Mac Catalyst 18.4, tvOS 18.4 und visionOS 2.4 protokollierte UIKit eine Meldung für Apps, die noch nicht migriert hatten, und in den 26er-Releases änderte sich die Meldung.¹ Zwei Releases voller Warnungen, dann fällt der Boden weg. Die konzeptionelle Grundlage ist noch älter: Die Session greift bis zur WWDC 2014 zurück, auf Bruce Nilos Formulierung, dass „eine Geräterotation nur eine animierte Größenänderung der Bounds ist”, und merkt an, dass mit den in der Größe veränderbaren iPad-Fenstern und den größenveränderbaren iPhone-Apps „diese Erkenntnis heute relevanter ist denn je”.²

Eine Abgrenzung lohnt eine präzise Formulierung: Die Anforderung bindet Apps, die „mit dem neuesten SDK gebaut werden”.¹ Bereits ausgelieferte Binärdateien, die gegen iOS 26 oder frühere SDKs gebaut wurden, starten weiterhin. In dem Moment, in dem Sie mit den SDKs von Xcode 27 neu bauen, um irgendetwas Neues aufzunehmen, kommt der Scene-Lebenszyklus mit.

Müssen Sie tatsächlich migrieren?

Die Dokumentation nennt einen Test mit zwei Bedingungen. Migrieren Sie, wenn der UIApplicationSceneManifest-Schlüssel in Ihrer Information-Property-List fehlt (oder keine angegebenen Konfigurationen hat), oder wenn Ihr App-Delegate die Methode zur Szenenkonfiguration nicht implementiert.¹ Die meisten Apps, die nach 2019 begonnen wurden, bestehen den Test bereits; Xcodes Vorlagen erzeugen seitdem szenenbasierte Projekte. Die von der Pflicht erfassten Apps sind die langlebigen, deren AppDelegate immer noch das Fenster besitzt.

Die minimale Lösung führt über einen von zwei Wegen. Der statische Weg fügt der Property-List einen UIApplicationSceneManifest-Schlüssel mit einer Scene-Konfiguration hinzu, erreichbar über die allgemeinen Einstellungen des Targets unter „Scene manifest” in den Deployment-Infos.¹ Der dynamische Weg implementiert stattdessen die Delegate-Methode zur Szenenkonfiguration – für Apps, die Szenen auf Basis von Benutzeraktivitäten anpassen oder verschiedene Szenenrollen behandeln; das Beispiel der Dokumentation nutzt die Rolleneigenschaft der Session, um zu bestimmen, welche Szene erstellt werden soll.¹ Apps, die den Root-View-Controller aus einem Storyboard laden, geben den Storyboard-Namen im Scene-Manifest an, und das System konfiguriert die Window-Szene und den Root-View-Controller automatisch.¹

Was die Pflicht nicht verlangt, sind mehrere Szenen. Die Dokumentation stellt ausdrücklich klar, dass die Unterstützung mehrerer Szenen optional bleibt und eine Umstrukturierung Ihres Datenmodells in szenenspezifischer Form erfordern kann; sie rät Ihnen abzuwägen, ob die Benutzererfahrung davon profitiert, bevor Sie sie aktivieren.¹ Migrieren bedeutet, Lebenszyklus-Ereignisse von der App-Ebene auf die Scene-Ebene zu verschieben, wobei UIApplicationDelegate die prozessbezogenen Ereignisse behält und der Scene-Delegate die UI-spezifischen übernimmt.¹ Ein Detail, das bei der Konfiguration zu Stolpern führt: Geben Sie UIWindowScene-Objekte an statt einfacher UIScene-Objekte, und CarPlay-Szenen verwenden ihren eigenen Szenentyp für Template-Anwendungen.¹

Warum jetzt: alles wird größenveränderbar

Die Pflicht landet im selben Release, das die Größenveränderbarkeit universell macht, und Session 278 stellt beides als eine zusammenhängende Geschichte dar. In iOS und macOS 27 lassen sich iPhone-Mirroring-Fenster auf dem Mac frei in der Größe verändern, und eine reine iPhone-App, die auf dem iPad läuft, wird „vollständig größenveränderbar wie jede andere iPad-App”.² Der Scene-Lebenszyklus ist, in den Worten der Session, „die Grundlage für jede adaptive App”: die Voraussetzung für alles andere, was die Session zu beheben verlangt.²

Die Liste der zu behebenden Punkte ist eine Säuberung bildschirmzentrierter Annahmen. Verweise auf den Hauptbildschirm liefern falsche Informationen, sobald Ihre Szene auf einem anderen Display lebt, weshalb die Session rät, den Bildschirm dynamisch über die Window-Szene des Fensters anzusprechen oder, besser noch, Bildschirmverweise vollständig zu entfernen: Der Bildschirmmaßstab wird zum displayScale der Trait-Collection, und die Bildschirm-Bounds werden zur effektiven Geometrie der Window-Szene oder schlicht zur Größe der umgebenden View.² Die automatische Trait-Verfolgung mildert die Migration: Das System verfolgt, welche Trait-Eigenschaften innerhalb von Layout- und Zeichenmethoden wie layoutSubviews gelesen werden, und ruft sie erneut auf, wenn sich ein verfolgtes Trait ändert.²

Zwei seit Langem etablierte Signale verlieren ihre Layout-Bedeutung gänzlich. Das Benutzeroberflächen-Idiom „ist für keinerlei Layout-Entscheidung mehr aussagekräftig”, weil eine iPhone-App auf dem iPad vollständig größenveränderbar läuft, während sie weiterhin das Phone-Idiom meldet; und die unterstützte Schnittstellenausrichtung wird zu einer Präferenz, die das System in größenveränderbaren Umgebungen ignoriert, wobei iPhone Mirroring unabhängig vom Seitenverhältnis des Fensters stets Hochformat meldet.² Der Ersatz für beides sind Size-Classes. Spiele erhalten ein Zugeständnis statt einer Ausnahme: UIRequiresFullscreen wird ab iOS 27 auf dem iPhone in größenveränderbaren Umgebungen berücksichtigt, doch sein Verhalten ändert sich zu diskreter Größenänderung, indem die Szene bei jeder Größenänderung in eine passende Bildschirmkonfiguration überführt wird, sodass das Spiel im verfügbaren Raum in voller Qualität rendert.²

Das Testen der gesamten Matrix wurde im selben Zyklus günstiger: Device Hub und Xcode Previews erhalten einen „Resize-Modus”, der die Geräteränder frei zieht, wobei die Session anschließend Prüfungen auf echten Geräten via iPhone Mirroring und iPad empfiehlt.²

Für die Migration gibt es eine Agent-Skill

Die Session schließt damit, das Ausmaß der Aufgabe anzuerkennen und auf Xcode 27s Antwort zu verweisen: eine neue Skill zur App-Modernisierung mit „einem tiefen Verständnis der Adaptivitätsaufgaben”, die die Session umreißt.² Wird der Agent gebeten, eine App anpassungsfähiger zu machen, wandelt er Aufrufe des Hauptbildschirms in Prüfungen der Trait-Collection oder der Scene-Bounds um – mit Invalidierungslogik, wo nötig –, ersetzt Prüfungen der Schnittstellenausrichtung durch Size-Classes und „stellt Ihre App sogar auf den Scene-Lebenszyklus um”.² Bei komplexen Aufgaben stellt er Rückfragen, und bei Arbeit, die für eine Sitzung zu groß ist, hinterlässt er Kommentare, die markieren, was noch aussteht.²

Die Verteilungsgeschichte passt zum Rest von Apples Skills-Vorstoß auf dieser WWDC: xcrun agent skills export erzeugt Markdown-Dateien, die Sie in andere Tools importieren können – derselbe Mechanismus, der in Xcode 27s Agent-Skills-Export behandelt wird.² Eine vom SDK erzwungene Migration, gepaart mit einer Skill, die die Migration durchführt, ist der bislang klarste Ausdruck dafür, wie Apple erwartet, dass Breaking Changes im Agenten-Zeitalter aufgefangen werden: Die Plattform hebt den Boden an, und das Tooling trägt Sie darüber hinweg.

FAQ

Wird meine bestehende App unter iOS 27 nicht mehr funktionieren?

Allein wegen dieser Anforderung nicht. Die Pflicht gilt für Apps, die „mit dem neuesten SDK gebaut werden”.¹ Binärdateien, die bereits mit älteren SDKs ausgeliefert wurden, starten unter iOS 27 weiterhin. Der Fehler tritt auf, wenn Sie gegen das iOS-27-SDK neu bauen, ohne den szenenbasierten Lebenszyklus vorbereitet zu haben.

Woran erkenne ich, ob meine App betroffen ist?

Prüfen Sie zwei Dinge.¹ Wenn Ihrer Info.plist ein UIApplicationSceneManifest-Schlüssel mit einer Konfiguration fehlt und Ihr App-Delegate die Methode zur Szenenkonfiguration nicht implementiert, befinden Sie sich auf dem App-Delegate-Lebenszyklus, und die App startet nicht, wenn sie mit dem iOS-27-SDK gebaut wird. UIKit protokolliert seit iOS 18.4 eine Migrationsmeldung für betroffene Apps.¹

Zwingt mich das, mehrere Fenster zu unterstützen?

Nein. Die Unterstützung mehrerer Szenen bleibt optional, und Apples Dokumentation rät abzuwägen, ob Ihre Benutzererfahrung davon profitiert, bevor Sie sie aktivieren, da dies erfordern kann, Ihr Datenmodell szenenspezifisch zu gestalten.¹ Die Pflicht verlangt nur den szenenbasierten Lebenszyklus selbst: Lebenszyklus-Ereignisse, die pro Szene statt global behandelt werden.

Kann ein Agent die Migration durchführen?

Xcode 27 liefert eine Skill zur App-Modernisierung mit, die laut Session eine App auf den Scene-Lebenszyklus umstellen, Verweise auf den Hauptbildschirm umschreiben und Prüfungen der Ausrichtung durch Size-Classes ersetzen kann, dabei Rückfragen stellt, wo die Änderung mehrdeutig ist, und Kommentare für unvollendete Arbeit hinterlässt.² Sie exportiert über xcrun agent skills export in andere Tools.² Behandeln Sie ihre Ausgabe wie jede von einem Agenten geschriebene Migration: Prüfen Sie das Diff, besonders rund um die Zustandswiederherstellung und das Fenster-Setup.

Die Pflicht vollendet ein Thema dieses Zyklus: Apple erzwingt Migrationen an der 27er-Grenze, statt sie nur vorzuschlagen, nachdem die Einstellung von ImageCreator dieselbe schrittweise Eskalation auf einer kleineren Fläche gezeigt hat. Die Antwort über eine Agent-Skill verbindet sich mit dem breiteren Skills-Bogen in Xcode 27 liefert Agent-Skills, die Sie überallhin exportieren können. Der vollständige Serien-Hub ist die Apple-Ecosystem-Serie.

Quellen