Migration UIScene d’iOS 27 : réparer l’échec de lancement d’une app en 2026 ?

Ce guide est destiné aux mainteneurs d’anciennes apps UIKit dont AppDelegate crée encore directement le UIWindow, ou dont le manifeste de scènes n’est pas configuré. Il convient aussi aux projets Storyboard, aux interfaces entièrement codées et aux architectures mixtes qui doivent répartir correctement les responsabilités entre AppDelegate et SceneDelegate.

Il est particulièrement utile si votre équipe ne possède qu’une seule machine de production et souhaite tester Xcode 27 à distance sans interrompre les publications existantes.

Point de contrôle : au 14 septembre 2026, Apple indique que l’exigence est déclenchée par une construction avec le SDK iOS 27.0. Elle ne dépend donc pas uniquement de la version d’iOS installée sur l’appareil. L’échéance future imposant ce SDK pour chaque soumission n’est pas publiée ; ne remplacez pas cette information par une date supposée.

La documentation Apple sur la transition vers le cycle de vie UIKit fondé sur les scènes décrit la séparation entre le cycle de vie du processus et celui d’une scène. La note technique TN3187 complète cette migration pour les applications existantes.

Le premier diagnostic ne consiste pas à ajouter un fichier SceneDelegate.swift. Il consiste à inspecter le produit final. Une compilation réussie ne prouve pas que l’application pourra créer sa première fenêtre après installation.

Vérifiez, dans l’archive destinée à la validation, les éléments suivants :

• le SDK utilisé par la construction finale ;
• la présence de UIApplicationSceneManifest dans l’Info.plist ;
• la validité de la configuration de scène déclarée ;
• l’implémentation de application(_:configurationForConnecting:options:) si votre architecture en dépend ;
• le chemin de création de la fenêtre ;
• les journaux du premier lancement après installation.

Apple confirme que l’utilisation du SDK iOS 27.0 rend obligatoire le cycle de vie fondé sur UIScene pour une app UIKit concernée. La discussion d’un membre de l’équipe Apple sur la frontière déclenchée par le SDK précise que la construction avec un ancien SDK ne déclenche pas encore cette contrainte. Il s’agit d’un mécanisme de compatibilité, pas d’une solution durable.

Trois décisions avant de modifier le code

Utilisez cette branche de décision avant de supprimer une ancienne méthode ou de changer la machine de construction :

• Si l’archive finale utilise le SDK iOS 27.0 et que l’application n’a pas de scène valide, choisissez la migration immédiate. Ne vous contentez pas de corriger un écran vide après installation.
• Si l’archive actuelle utilise un ancien SDK, mais que Xcode 27 est déjà prévu dans votre calendrier, choisissez une migration à deux voies. Conservez l’ancien outil validé et construisez une copie isolée avec le nouveau SDK.
• Si le produit ne doit pas encore être construit avec le SDK iOS 27.0, utilisez temporairement l’outil déjà validé, documentez la raison et planifiez la migration. Ne supprimez aucune ancienne entrée de cycle de vie avant d’avoir une procédure de retour.

Cette décision répond à la question du contournement par une ancienne version de Xcode : oui, elle peut temporairement éviter le comportement déclenché par le nouveau SDK, mais elle ne corrige pas le projet. La date du 9 septembre 2026 correspond à l’ouverture de Xcode 27 RC dans les informations de version Apple ; consultez la page officielle des versions Xcode plutôt que des calendriers non confirmés.

Projet Storyboard

Dans une application Storyboard, le manifeste doit associer la scène à la configuration attendue et au Storyboard principal. La documentation Apple sur la déclaration des scènes prises en charge doit servir de référence pour le nom de la configuration et la relation avec le Storyboard.

Le piège courant est de conserver deux propriétaires de la fenêtre. AppDelegate instancie un UIWindow, puis SceneDelegate en crée un second lorsque la scène se connecte. Le résultat peut être une interface vide, un contrôleur racine qui n’apparaît pas ou une restauration incohérente.

Répartissez les responsabilités :

• AppDelegate : initialisation globale du processus, services partagés et événements qui ne dépendent d’aucune scène ;
• SceneDelegate : connexion de la scène, fenêtre de cette scène, contrôleur racine et transitions entre arrière-plan et premier plan ;
• Storyboard : création déclarative des contrôleurs prévus par la configuration ;
• code métier : navigation et état applicatif, sans référence implicite à une unique fenêtre globale.

Après la modification, installez l’archive sur un appareil ou un simulateur propre. Testez un lancement froid, un passage en arrière-plan, une réactivation et une restauration d’état. Une compilation sans erreur ne constitue pas une preuve d’acceptation.

Interface UIKit entièrement codée

Pour une interface créée en code, scene(_:willConnectTo:options:) doit relier la fenêtre à l’objet UIWindowScene, affecter le contrôleur racine, puis rendre la fenêtre visible. La relation essentielle est donc :

1. récupérer la scène fournie par le système ;
2. créer ou convertir la UIWindow avec ce contexte ;
3. construire le contrôleur racine ;
4. affecter rootViewController ;
5. rendre la fenêtre visible ;
6. conserver uniquement les références nécessaires à cette scène.

La référence Apple de UIScene rappelle que la scène représente une session d’interface, pas le processus entier. Recherchez ensuite les anciennes hypothèses dans le projet :

• AppDelegate.window utilisé comme source universelle de navigation ;
• keyWindow recherché globalement ;
• contrôleur présenté depuis une fenêtre qui n’est plus active ;
• initialisation d’un conteneur à chaque reconnexion ;
• logique de restauration attachée au lancement du processus uniquement.

Remplacez ces accès par un contexte de scène explicite. Si une fonction reçoit une URL ou une commande utilisateur, faites-lui recevoir la scène ou le contrôleur concerné plutôt que de retrouver une fenêtre par effet de bord.

Architecture mixte

Les projets qui combinent Storyboard, injection de dépendances et construction de certains écrans sont les plus exposés aux doubles initialisations. Cartographiez d’abord qui crée chaque objet. Ne déplacez pas automatiquement toute l’initialisation d’AppDelegate dans SceneDelegate.

Un service réseau, une base locale ou une configuration d’analyse peut appartenir au processus. Une session d’édition, un contrôleur racine ou un état de navigation appartient à une scène. Cette distinction devient importante sur iPad, avec Stage Manager, sur Mac Catalyst ou lors de l’utilisation d’un écran externe.

L’adoption de UIScene ne vous oblige pas à ouvrir immédiatement plusieurs fenêtres. Elle vous oblige à ne plus supposer qu’il n’existe qu’une seule interface. Pour un projet documentaire, vérifiez la restauration de chaque session et la libération des ressources lors de la déconnexion.

Le lancement depuis l’icône ne représente qu’un chemin. Les liens profonds, les liens universels, les notifications et les retours de connexion peuvent arriver lorsque le processus est arrêté, lorsqu’une scène est en arrière-plan ou lorsqu’une scène est déjà active.

Dans un projet UIKit moderne, lisez les options de connexion au moment où la scène est créée. La documentation Apple de connectionOptions décrit les informations disponibles lors de cette connexion. Ensuite, gérez les événements qui arrivent sur une scène déjà active dans les méthodes de cycle de vie appropriées.

Voici la séparation à appliquer :

• processus : préparation des services globaux et de la configuration commune ;
• connexion de scène : URL initiale, activité utilisateur ou notification présente au démarrage ;
• scène déjà active : nouvelles URL, nouvelles activités ou actions reçues sans recréation du processus ;
• restauration : récupération de l’état propre à la session, sans réinitialiser l’application entière.

Les SDK de connexion, d’analyse et de notifications constituent un risque particulier lorsqu’ils supposent que tout passe encore par AppDelegate. Vérifiez leur documentation et leurs points d’intégration avant de retirer les anciens appels. Ne publiez pas un projet avec des identifiants réels dans vos journaux de migration.

Créez des tests avec des liens et des charges de notification désensibilisés. Couvrez au minimum :

• application arrêtée, puis ouverture par lien ;
• application en arrière-plan, puis réveil par notification ;
• application déjà active, puis réception d’un nouveau lien ;
• retour depuis un flux de connexion ;
• restauration après fermeture forcée.

Le test doit prouver que le bon contrôleur reçoit l’événement et qu’il n’est pas traité deux fois.

La validation doit être indépendante de la machine qui produit actuellement les archives. Une seule installation de Xcode peut masquer un problème de sélection de SDK, de cache, de certificat ou de script de construction.

Le document Apple consacré aux notes de version de Xcode 27 doit être rapproché des notes App Store Connect applicables au moment de votre envoi. L’archive finale est votre unité de contrôle, pas le résultat d’un simple bouton « Build ».

Suivez cette procédure :

1. Gelez la référence. Notez la révision, la sélection Xcode, le SDK, les réglages de signature et le résultat de la dernière archive. Retirez les noms de projet, identifiants, URL internes et chemins sensibles des rapports partagés.
2. Dupliquez l’environnement. Utilisez une machine séparée, locale ou distante, sans remplacer immédiatement l’outil de production. Installez la version Xcode 27 prévue et vérifiez le SDK réellement sélectionné.
3. Analysez le projet. Inspectez Info.plist, UIApplicationSceneManifest, les delegates, les références à window et les points d’entrée des URL et notifications.
4. Migrez selon l’architecture. Configurez le Storyboard ou reconstruisez la chaîne UIWindowScene dans scene(_:willConnectTo:options:). Ne mélangez pas deux propriétaires de la fenêtre.
5. Construisez et testez. Exécutez Build et Test, puis installez l’application. Ajoutez les scénarios de lancement froid, reconnexion, arrière-plan, restauration et notification.
6. Archivez séparément. Conservez le fichier d’archive, les journaux, l’Info.plist final et le résultat d’installation. Comparez le comportement avec la référence, pas seulement les avertissements de compilation.
7. Testez l’exploitation distante. Fermez puis rouvrez la session distante, redémarrez l’hôte et relancez une construction sans intervention manuelle. Un serveur de compilation qui fonctionne uniquement après une reconnexion graphique n’est pas prêt pour l’automatisation.
8. Définissez le retour. Tant que l’installation, les liens profonds ou l’archive échouent, repassez sur l’outil validé. Ne supprimez pas la chaîne précédente avant d’avoir enregistré la cause et la correction.

Si votre production dépend d’un seul Mac, une infrastructure Mac distante pour les essais de construction peut isoler cette expérimentation. Consultez également les options et conditions de location de Mac avant de choisir une durée adaptée à une migration ponctuelle ou à une période de double validation.

Cochez chaque ligne seulement avec une preuve conservée :

• [ ] L’archive de test utilise bien le SDK prévu.
• [ ] UIApplicationSceneManifest est présent et cohérent.
• [ ] La configuration de scène correspond au Storyboard ou au code utilisé.
• [ ] Une seule couche crée et possède la fenêtre de chaque scène.
• [ ] Le lancement froid affiche l’interface attendue.
• [ ] La réactivation ne crée pas un contrôleur ou un service en double.
• [ ] La restauration d’état ne réinitialise pas une autre scène.
• [ ] Un lien entrant fonctionne après arrêt, en arrière-plan et à l’état actif.
• [ ] Une notification est traitée dans chacun de ces trois états.
• [ ] Les anciens appels AppDelegate ont été examinés avant suppression.
• [ ] L’archive est installée et lancée, au lieu d’être seulement compilée.
• [ ] Une construction reproductible fonctionne après reconnexion et redémarrage de l’hôte.
• [ ] L’ancien environnement reste disponible avec une condition de retour écrite.
• [ ] Les journaux et paramètres sensibles sont désensibilisés.

Votre rapport doit distinguer quatre résultats : compilation, installation, premier lancement et fonctionnement après événement externe. Les regrouper sous le seul mot « succès » rend le diagnostic inutile.

Pour les projets audio, vidéo ou de design qui combinent import de fichiers, aperçu plein écran et reprise d’une session de travail, ajoutez des tests de restauration de contenu. Une scène recréée peut afficher correctement l’écran d’accueil tout en perdant le document, la file d’export ou le contrôleur de prévisualisation. Cette vérification révèle souvent les dépendances cachées à une fenêtre globale.

En pratique, la migration UIScene d’iOS 27 doit être traitée comme une modification du contrat de démarrage, pas comme l’ajout mécanique d’un delegate. Une ancienne machine de production concentre plusieurs risques : elle mélange l’outil stable et le nouvel outil, elle rend le retour arrière plus stressant et elle peut empêcher les tests de redémarrage ou de session distante. Une machine Mac isolée offre un environnement reproductible pour comparer les archives et les lancements avant de toucher au flux de publication principal.

Si vous ne souhaitez pas acheter un Mac uniquement pour cette phase, CALMVPS permet de louer un Mac distant avec accès à un environnement macOS complet. Cette approche est surtout pertinente pour une migration limitée, une validation Xcode 27 ou une période de double construction ; pour une charge permanente et lourde ou pour l’usage d’interfaces physiques, un Mac dédié reste plus approprié. Vous pouvez examiner une solution de Mac distant pour votre validation, puis ne basculer la production qu’après les preuves listées ci-dessus.