iOS 27 casse les notifications push sans UISceneDelegate : voici le correctif

Si vous compilez votre application avec le SDK iOS 27 sans adopter le cycle de vie UIScene, elle ne se lance plus. Et une application qui ne se lance pas ne s’enregistre jamais pour le push : vos notifications s’éteignent sans aucun rapport de plantage pointant le push comme cause. Le symptôme ressemble à un problème de livraison. C’est en réalité un problème de lancement.

Ce cas piège les équipes précisément parce que les deux sujets semblent sans rapport : le push et le démarrage de l’application vivent dans des coins différents de votre code, et de votre esprit. iOS 27 les relie. Ce guide couvre ce qui casse, la chaîne exacte qui coupe vos notifications, qui se trouve dans la zone d’impact, et la checklist de migration pour corriger le problème. Pushwoosh est une plateforme d’engagement client, et son SDK iOS gère déjà cette transition, mais le correctif ci-dessous s’applique que vous soyez client ou non.

Ce qui casse réellement

Apple a annoncé à la WWDC25 que la version suivant iOS 26 exigerait le cycle de vie UIScene pour toute application UIKit compilée avec le SDK le plus récent. iOS 27 est cette version. L’exigence est désormais appliquée.

Le déclencheur compte, et la plupart des fils de discussion paniqués se trompent : l’application se déclenche quand vous compilez avec le SDK iOS 27 dans Xcode 27, pas simplement quand un utilisateur lance votre application existante sur un iPhone iOS 27. Votre build actuellement publié continue de fonctionner sur les téléphones mis à jour. La rupture arrive avec votre prochaine version compilée avec le nouveau SDK. Cette distinction vous achète du temps, mais seulement jusqu’à votre prochaine soumission.

Voici ce qui ne change pas, et c’est justement là que les articles alarmistes en font trop : le flux APNs lui-même reste intact. Vous demandez toujours l’autorisation, appelez toujours registerForRemoteNotifications(), et recevez toujours le device token dans didRegisterForRemoteNotificationsWithDeviceToken. Ce callback reste dans votre AppDelegate, et il n’existe actuellement aucun équivalent basé sur les scenes vers lequel le déplacer sur iOS 27. La mécanique du push va bien. C’est le démarrage qu’Apple a modifié.

La chaîne qui réduit votre push au silence

Quand une application sans manifeste de scene est compilée avec le SDK iOS 27, la défaillance se déroule dans cet ordre :

1. UIKit exige l’adoption des scenes au lancement et ne trouve aucun UIApplicationSceneManifest dans votre Info.plist.
2. L’application se termine avant qu’aucune méthode de l’AppDelegate ne s’exécute.
3. Comme application(_:didFinishLaunchingWithOptions:) ne s’exécute jamais, registerForRemoteNotifications() ne se déclenche jamais non plus.
4. Sans enregistrement, didRegisterForRemoteNotificationsWithDeviceToken n’est jamais appelé, donc l’application ne reçoit jamais de token APNs.
5. Pas de token, pas de livraison. Et comme l’application a planté au démarrage, vos logs incriminent le lancement, pas le pipeline de notifications.

Ce qui fait perdre autant de temps de débogage, c’est que le symptôme et la cause sont très éloignés l’un de l’autre. Vous constatez des livraisons manquantes et commencez par auditer votre fournisseur de push, vos payloads, vos certificats. La véritable faute se situe trois couches plus haut, dans un fichier manifeste qui n’a rien à voir avec les notifications.

Qui se trouve dans la zone d’impact

L’exigence touche les applications UIKit, mais la façon dont elle vous atteint dépend de votre stack.

Pour les équipes cross-platform, le point sensible n’est pas le framework, mais les SDK empilés dessus. Tout SDK de push ou d’analytics qui s’installe en enveloppant votre AppDelegate peut bloquer la migration vers les scenes jusqu’à ce que ce fournisseur publie son propre support. Si une dépendance possède votre point d’entrée @main, vous attendez sa sortie, pas seulement la vôtre. Nous avons déjà vu une migration bloquée 2 semaines à cause exactement de cela, sur une seule dépendance peu coopérative, alors que tout ce que l’équipe contrôlait réellement était déjà prêt. Vérifiez la compatibilité scene de votre SDK de notifications avant de supposer que la migration se fait en une journée. Si vous utilisez notre plugin Flutter, la page des problèmes de migration connus est la première chose à lire.

La checklist de migration

Le correctif n’a pas changé depuis l’introduction des scenes en 2019. Ce qui a changé, c’est qu’il n’est plus optionnel.

• Ajoutez un manifeste de scene. Placez un UIApplicationSceneManifest dans votre Info.plist, ou configurez les scenes via le code avec les méthodes UIApplicationDelegate et UISceneDelegate.
• Créez un SceneDelegate. Si vous n’en avez pas, ajoutez-en un et assurez-vous qu’il compile réellement dans votre target. Un SceneDelegate présent dans le projet mais jamais ajouté aux sources de build est un piège fréquent.
• Déplacez la création de la fenêtre. La propriété de la fenêtre quitte l’AppDelegate. Remplacez UIWindow(frame:) par UIWindow(windowScene:) et hébergez votre vue racine depuis le scene.
• Déplacez la gestion du cycle de vie UI. Les transitions foreground, background et active/inactive passent à UISceneDelegate. Après la migration, UIKit cesse d’appeler les méthodes d’état UI sur votre AppDelegate, donc tout ce qui y reste meurt silencieusement.
• Laissez l’enregistrement du push où il est. L’enregistrement du token et ses callbacks restent dans l’AppDelegate. Ne les déplacez pas par souci de symétrie.
• Migrez la gestion des URL et des liens profonds. Les URL entrantes arrivent désormais via les méthodes de scene. Si vos push ouvrent des écrans précis, c’est cette étape qui maintient vos liens profonds fonctionnels.
• Recompilez et vérifiez l’émission du token. Compilez avec le SDK iOS 27, lancez l’application et confirmez qu’elle reçoit un token APNs. Si ce n’est pas le cas, le guide de dépannage des erreurs iOS est le point de départ. Vérifiez sur un build réel avant la publication, pas après.

Conservez l’AppDelegate. C’est le point que les équipes ratent quand elles lisent «l’AppDelegate va disparaître». Il ne disparaît pas. Son rôle se restreint aux événements de processus et de niveau application, tandis que le cycle de vie UI migre vers le scene. L’enregistrement du push est un sujet de niveau application, et c’est exactement pour cette raison qu’il reste en place.

Pourquoi miser uniquement sur le push est fragile

Prenons un peu de recul. Une seule clé de manifeste, dans un fichier que la plupart de l’équipe n’ouvre jamais, peut mettre tout votre canal push hors service à la prochaine version. C’est beaucoup de fragilité reposant sur un seul canal de diffusion.

Et cela s’ajoute à un plafond que le push avait déjà : l’opt-in. Même avec une stratégie de demande d’autorisation bien pensée, une part importante de vos utilisateurs n’accorde jamais l’autorisation push dès le départ, si bien que le push n’atteint qu’une fraction de votre base un bon jour. Des ruptures de plateforme comme celle-ci ne font qu’élargir l’écart entre qui vous pouvez atteindre et qui vous atteignez réellement.

Les équipes qui absorbent ce genre de changement sont celles qui ne dépendent pas d’un canal unique. Quand le push est une méthode de diffusion parmi l’e-mail, le SMS et l’in-app, une régression au lancement sur une seule plateforme réduit votre portée sans l’annuler. Vous vous achetez ainsi la marge nécessaire pour exactement ce genre de surprise qu’Apple vient de livrer.

Faites vérifier votre configuration push iOS 27 avec Pushwoosh

Le SDK Pushwoosh prend déjà en charge le cycle de vie scene d’iOS 27, et sa configuration multicanale fait qu’une rupture sur une seule plateforme n’entraîne jamais toute votre stratégie de notifications avec elle. Si votre migration est en cours et qu’un enregistrement échoue, la FAQ du SDK iOS couvre les problèmes les plus courants. Et si vous souhaitez un second avis sur la survie de votre enregistrement push après la migration, nous pouvons passer en revue votre intégration avec vous.

FAQ