Wenn Sie Ihre App gegen das iOS-27-SDK kompilieren, ohne den UIScene-Lifecycle zu adoptieren, startet sie nicht mehr. Und eine App, die nicht startet, registriert sich nie für Push — Ihre Benachrichtigungen verstummen, ohne dass ein Absturzbericht auf Push als Ursache hindeutet. Das Symptom sieht aus wie ein Zustellungsproblem. Tatsächlich ist es ein Startproblem.
Das ist ein Punkt, der genau deshalb überrascht, weil Push und App-Start technisch in völlig getrennten Bereichen liegen — im Code und im Kopf des Teams. iOS 27 verknüpft beides. Dieser Leitfaden erklärt, was kaputtgeht, die exakte Kette, die Ihre Benachrichtigungen verstummen lässt, wer betroffen ist, und die Migrations-Checkliste, um es zu beheben. Pushwoosh ist eine Customer-Engagement-Plattform, und ihr iOS SDK deckt diesen Übergang bereits ab — der folgende Fix gilt aber unabhängig davon, ob Sie unser SDK einsetzen.
Vorab zur Einordnung: Der APNs-Zustellweg selbst bleibt unverändert und damit auch DSGVO-konform, so wie es Pushwoosh-Infrastruktur insgesamt ist — SOC 2 Type I und ISO 27001:2022 zertifiziert, Rechenzentren in der EU und den USA. Diese Migration betrifft ausschließlich den App-Start, nicht die Datenverarbeitung im Push-Flow.
Teil unseres Leitfadens zum iOS-27-Release. Während die SDK-Arbeit läuft, lohnt sich auch ein Blick auf Ihre tatsächliche Gerätereichweite.
Was tatsächlich kaputtgeht
Apple kündigte auf der WWDC25 an, dass die auf iOS 26 folgende Version den UIScene-Lifecycle für jede mit dem neuesten SDK gebaute UIKit-App verpflichtend macht. iOS 27 ist diese Version. Die Anforderung wird jetzt durchgesetzt.
Der Auslöser ist entscheidend, und die meisten panischen Diskussionen verstehen ihn falsch: Die Durchsetzung greift, wenn Sie gegen das iOS-27-SDK in Xcode 27 kompilieren — nicht schon dann, wenn ein Nutzer Ihre bestehende App auf iOS 27 startet. Ihr aktuell veröffentlichter Build läuft auf aktualisierten Geräten weiter. Der Bruch kommt mit Ihrem nächsten Release, kompiliert mit dem neuen SDK. Diese Unterscheidung verschafft Ihnen Zeit — aber nur bis zur nächsten Einreichung.
Was sich nicht ändert, und genau hier übertreiben viele Alarm-Artikel: Der APNs-Flow selbst bleibt unangetastet. Sie fordern weiterhin die Berechtigung an, rufen weiterhin registerForRemoteNotifications() auf und erhalten den Device Token weiterhin in didRegisterForRemoteNotificationsWithDeviceToken. Dieser Callback bleibt in Ihrem AppDelegate — auf iOS 27 gibt es aktuell kein scene-basiertes Äquivalent, in das er verschoben werden müsste. Die Push-Mechanik funktioniert einwandfrei. Was Apple geändert hat, ist der Start.
Die Kette, die Ihren Push verstummen lässt
Wird eine App ohne Scene-Manifest gegen das iOS-27-SDK kompiliert, läuft der Fehler in dieser Reihenfolge ab:
- UIKit verlangt beim Start die Scene-Adoption und findet kein
UIApplicationSceneManifestin Ihrer Info.plist. - Die App wird beendet, bevor irgendeine AppDelegate-Methode ausgeführt wird.
- Da
application(_:didFinishLaunchingWithOptions:)nie ausgeführt wird, wirdregisterForRemoteNotifications()nie ausgelöst. - Ohne Registrierung wird
didRegisterForRemoteNotificationsWithDeviceTokennie aufgerufen — die App erhält also nie einen APNs-Token. - Kein Token, keine Zustellung. Und weil die App beim Start abgestürzt ist, weisen Ihre Logs auf den Start, nicht auf die Notification-Pipeline.
Der Grund, warum das so viel Debugging-Zeit kostet: Symptom und Ursache liegen weit auseinander. Sie sehen fehlende Zustellungen und beginnen, Ihren Push-Anbieter, Ihre Payloads, Ihre Zertifikate zu prüfen. Der tatsächliche Fehler liegt drei Ebenen höher, in einer Manifest-Datei, die mit Benachrichtigungen nichts zu tun hat.
Wer betroffen ist
Die Anforderung trifft UIKit-Apps — wie stark, hängt von Ihrem Stack ab.
| Stack | Exposition |
|---|---|
| Natives UIKit | Direkt. Wer den AppDelegate-Lifecycle besitzt, besitzt auch die Migration. |
| SwiftUI | Geringeres Risiko bei Verwendung des App-Protokolls und WindowGroup, die bereits scene-basiert sind. Apps, die noch auf einen UIApplicationDelegateAdaptor mit eigener Fensterlogik setzen, benötigen eine Prüfung. |
| Flutter | Das Framework migriert Apps mit unverändertem AppDelegate in aktuellen Versionen automatisch, eigene native Logik muss aber manuell migriert werden. |
| React Native | Abhängig von Ihren nativen Modulen und Drittanbieter-SDK-Wrappern, die den AppDelegate einhängen. |
App-Protokolls und WindowGroup, die bereits scene-basiert sind. Apps, die noch auf einen UIApplicationDelegateAdaptor mit eigener Fensterlogik setzen, benötigen eine Prüfung.Der kritische Punkt für Cross-Platform-Teams ist nicht das Framework, sondern die darüber liegenden SDKs. Jedes Push- oder Analytics-SDK, das sich durch Umschließen Ihres AppDelegate installiert, kann die Scene-Migration blockieren, bis der jeweilige Anbieter Scene-Support liefert. Gehört Ihr @main-Einstiegspunkt einer Abhängigkeit, warten Sie auf deren Release — nicht nur auf Ihr eigenes. Wir haben eine Migration erlebt, die 2 Wochen genau daran hing: eine einzige unkooperative Abhängigkeit, während alles, was das Team selbst kontrollierte, längst fertig war. Prüfen Sie die Scene-Kompatibilität Ihres Notification-SDKs, bevor Sie annehmen, die Migration sei an einem Tag erledigt. Wenn Sie unser Flutter-Plugin nutzen, ist die Seite zu bekannten Migrationsproblemen die erste Pflichtlektüre.
Die Migrations-Checkliste
Der Fix hat sich seit der Einführung der Scenes 2019 nicht geändert. Geändert hat sich, dass er nicht mehr optional ist.
- Scene-Manifest hinzufügen. Fügen Sie ein
UIApplicationSceneManifestin Ihre Info.plist ein, oder konfigurieren Sie Scenes im Code über die Methoden von UIApplicationDelegate und UISceneDelegate. - SceneDelegate erstellen. Falls noch nicht vorhanden: hinzufügen und sicherstellen, dass es tatsächlich in Ihr Target kompiliert wird. Ein SceneDelegate, das im Projekt existiert, aber nie zu den Build-Sources hinzugefügt wurde, ist eine häufige Falle.
- Fenstererstellung verschieben. Die Fensterhoheit wandert aus dem AppDelegate. Ersetzen Sie
UIWindow(frame:)durchUIWindow(windowScene:)und hosten Sie Ihre Root-View aus der Scene heraus. - UI-Lifecycle-Handling verschieben. Foreground-, Background- und Active/Inactive-Übergänge wandern zu UISceneDelegate. Nach der Migration ruft UIKit die UI-Zustandsmethoden am AppDelegate nicht mehr auf — alles, was dort verbleibt, stirbt still.
- Push-Registrierung an ihrem Platz lassen. Token-Registrierung und die Token-Callbacks bleiben im AppDelegate. Verschieben Sie sie nicht aus Symmetriegründen.
- URL- und Deep-Link-Handling migrieren. Eingehende URLs kommen jetzt über Scene-Methoden an. Wenn Ihre Push-Benachrichtigungen bestimmte Screens öffnen, hält dieser Schritt Ihre Deep Links funktionsfähig.
- Neu bauen und Token-Ausgabe verifizieren. Bauen Sie mit dem iOS-27-SDK, starten Sie die App und bestätigen Sie den Erhalt eines APNs-Tokens. Falls nicht: Die Anleitung zur Fehlerbehebung für iOS ist der richtige Ausgangspunkt. Verifizieren Sie das an einem echten Build vor der Veröffentlichung, nicht danach.
Behalten Sie den AppDelegate. Das ist der Punkt, den Teams übersehen, wenn sie lesen, „der AppDelegate verschwindet”. Er verschwindet nicht. Seine Rolle verengt sich auf Prozess- und App-Ebene-Ereignisse, während der UI-Lifecycle zur Scene wandert. Push-Registrierung ist ein Thema auf App-Ebene — genau deshalb bleibt sie dort.
Warum ein alleiniger Push-Kanal fragil ist
Ein Schritt zurück: Ein einziger Manifest-Schlüssel, in einer Datei, die kaum jemand im Team je öffnet, kann Ihren gesamten Push-Kanal beim nächsten Release lahmlegen. Das ist viel Fragilität, die auf einem einzigen Zustellweg lastet.
Und das kommt zu einer Grenze hinzu, die Push ohnehin schon hat: das Opt-in. Selbst bei einer durchdachten Permission-Strategie erteilt ein großer Teil Ihrer Nutzer nie die Push-Berechtigung — Push erreicht an einem guten Tag also nur einen Bruchteil Ihrer Basis. Plattform-Brüche wie dieser vergrößern nur die Lücke zwischen wen Sie erreichen könnten und wen Sie tatsächlich erreichen.
Teams, die solche Änderungen unbeschadet überstehen, sind die, die nicht von einem einzigen Kanal abhängen. Ist Push nur ein Zustellweg neben E-Mail, SMS und In-App, dellt eine Startzeit-Regression auf einer Plattform Ihre Reichweite nur, statt sie auszulöschen. So kaufen Sie sich genau den Puffer, den Sie für eine Überraschung wie diese von Apple brauchen.
Solange die SDK-Arbeit ohnehin offen ist: Nutzen Sie den Moment, um zu prüfen, was eine Benachrichtigung überhaupt sendenswert macht.
Lassen Sie Ihr iOS-27-Push-Setup mit Pushwoosh prüfen
Das Pushwoosh SDK unterstützt den iOS-27-Scene-Lifecycle bereits, und dank Multichannel-Setup reißt ein Bruch auf einer einzelnen Plattform nie Ihre gesamte Notification-Strategie mit sich. Wenn Ihre Migration läuft und etwas sich nicht registriert, deckt die iOS-SDK-FAQ die häufigsten Stolperstellen ab. Und wenn Sie eine zweite Meinung dazu wollen, ob Ihre Push-Registrierung die Migration übersteht: Wir prüfen Ihre Integration gemeinsam mit Ihnen — auf Infrastruktur, die SOC 2 Type I und ISO 27001:2022 zertifiziert sowie DSGVO-konform ist.
FAQ
didRegisterForRemoteNotificationsWithDeviceToken-Callback bleiben in Ihrem AppDelegate. Auf iOS 27 gibt es kein scene-basiertes Äquivalent, in das Sie sie verschieben könnten — der Versuch wäre ein Fehler. Nur der UI-Lifecycle wandert zur Scene.
Verwandte Artikel
Alle anzeigen