La règle de l'écran de lancement d'iOS 27 : quatre clés ou refus

Les notes de version d’iOS 27 transforment une phrase de documentation en barrière de soumission : « Les apps iOS et iPadOS compilées avec le SDK 27.0 ou une version ultérieure doivent inclure un écran de lancement. Le fichier Info.plist de votre app doit contenir l’une des clés suivantes : UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen ou UILaunchScreens. Les apps qui n’incluent pas d’écran de lancement sont refusées dès que l’App Store commence à accepter les apps compilées avec le SDK 27.0. »¹

L’exigence, elle, ne date pas d’hier. Le guide Xcode d’Apple s’ouvre sur : « Chaque app iOS doit fournir un écran de lancement. »² Ce qui arrive avec iOS 27, c’est la sanction en cas d’oubli.

En bref

• Les apps compilées avec le SDK iOS 27.0 ou une version ultérieure doivent déclarer un écran de lancement via l’une des quatre clés Info.plist, et l’App Store refuse les builds qui ne le font pas.¹
• La barrière se situe à la soumission, pas à l’exécution. Apple écrit « refusées dès que l’App Store commence à accepter les apps compilées avec le SDK 27.0 » : l’échec se produit donc dans App Store Connect, et non sur l’appareil d’un utilisateur.¹
• La règle nomme iOS et iPadOS, puis s’arrête là. Apple ne l’étend ni à tvOS, ni à visionOS, ni à Mac Catalyst dans cette même note.¹ L’obligation d’adopter le cycle de vie par scènes, qui arrive dans le même cycle, se lit autrement : son guide de migration cite nommément iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27 et visionOS 27.³
• Deux clés couvrent un écran de lancement unique (UILaunchScreen le construit directement dans la liste de propriétés, UILaunchStoryboardName désigne un fichier storyboard) et deux couvrent les variantes par schéma d’URL (UILaunchScreens, UILaunchStoryboards). Trois des quatre sont des dictionnaires ; UILaunchStoryboardName est la seule chaîne de caractères.⁴⁵⁶⁷
• Les projets créés à partir des modèles Xcode récents satisfont déjà la règle, et ils la satisfont par un réglage de compilation plutôt que par un fichier.⁸¹¹ Auditer en cherchant les quatre clés dans votre dépôt passe donc complètement à côté de la réponse.

La règle, énoncée avec précision

Trois détails de la phrase d’Apple comptent, et la couverture médiatique tend à les brouiller tous les trois.

D’abord, le déclencheur est le SDK avec lequel vous compilez, pas l’OS que font tourner vos utilisateurs. Un binaire compilé avec iOS 26 garde sa place sur le store. Recompilez avec Xcode 27 pour récupérer le moindre élément du nouveau SDK et l’exigence suit.

Ensuite, le point d’application est l’acceptation par l’App Store. Apple a écrit « refusées », ce qui place l’échec à l’examen de soumission et non au lancement. C’est précisément ce qui distingue la règle de l’écran de lancement de l’obligation d’adopter le cycle de vie par scènes livrée dans le même cycle, où la formulation d’Apple est que les apps « ne parviennent pas à se lancer ».¹ L’une vous coûte un build refusé ; l’autre, une app morte sur le téléphone d’un utilisateur.

Enfin, le périmètre, ce sont iOS et iPadOS. La note d’Apple nomme ces deux plateformes et s’arrête. Quiconque maintient une cible Catalyst ou tvOS doit considérer l’exigence comme non formulée, et non comme étendue par analogie. Le cycle 27 impose beaucoup ailleurs, du cycle de vie par scènes sur cinq plateformes au retrait d’ImageCreator d’Image Playground, mais la note sur l’écran de lancement reste étroite.

Laquelle des quatre clés s’applique

Apple propose deux façons de construire un écran de lancement et deux cardinalités, d’où les quatre clés.

UILaunchScreen configure l’interface de lancement directement dans la liste de propriétés, sans aucun fichier storyboard. Apple la présente comme le moyen « de configurer l’interface utilisateur pendant le lancement de l’app sans dépendre des storyboards », et elle accepte des clés enfants pour la couleur de fond, l’image, ainsi que la visibilité de la barre de navigation, de la barre d’onglets et de la barre d’outils.⁴ Pour une app dont le premier écran est un fond uni, un dictionnaire UILaunchScreen vide suffit à satisfaire la règle. Le système de build de Xcode emprunte lui-même cette voie : « Lorsque GENERATE_INFOPLIST_FILE est activé », INFOPLIST_KEY_UILaunchScreen_Generation « définit la valeur de la clé UILaunchScreen du fichier Info.plist comme un dictionnaire vide ».⁸

UILaunchStoryboardName désigne un storyboard par son nom de fichier, extension exclue : un fichier LaunchScreen.storyboard devient la chaîne LaunchScreen.⁵ Elle remonte à iOS 9, et c’est la seule des quatre à prendre une chaîne plutôt qu’un dictionnaire.⁵ Les apps dotées d’un état de lancement conçu graphiquement, ainsi que tout projet qui embarque le LaunchScreen.storyboard que Xcode ajoute encore à ses modèles à base de storyboard, ont besoin de cette clé.²

Les formes plurielles existent pour un cas bien précis, et toutes deux sont des dictionnaires et non des tableaux.⁶⁷ UILaunchScreens contient trois clés enfants : UILaunchScreenDefinitions, le tableau des configurations d’écran de lancement, chacune portant un UILaunchScreenIdentifier ; UIURLToLaunchScreenAssociations, la table de correspondance entre schéma d’URL et identifiant ; et UIDefaultLaunchScreen, le repli.⁶ UILaunchStoryboards reprend la même structure avec UILaunchStoryboardDefinitions, UIURLToLaunchStoryboardAssociations et UIDefaultLaunchStoryboard.⁷ L’une comme l’autre permettent à une app ouverte depuis myapp://compose de présenter un état de lancement différent de celui de la même app ouverte depuis l’écran d’accueil. Apple le dit sans détour : la plupart des apps devraient s’en passer. « Si vous n’avez besoin que d’un seul écran de lancement, utilisez plutôt UILaunchScreen. »⁶

En pratique, la décision se résume à une question. Si votre écran de lancement est un storyboard, déclarez UILaunchStoryboardName. Sinon, déclarez UILaunchScreen. Ne recourez à une clé plurielle que si vous savez déjà pourquoi vous en avez besoin.

Les apps réellement prises au piège

Une app créée à partir d’un modèle Xcode actuel passe sans que personne n’ait à y toucher, et c’est exactement pour cela que la règle est facile à balayer d’un revers de main — et facile à subir. La population à risque partage un trait : personne dans l’équipe n’a écrit le Info.plist à la main récemment.

Les listes de propriétés générées forment la catégorie la plus vaste, et Xcode en est le premier générateur. Xcode 13 a changé la valeur par défaut : les projets créés à partir de plusieurs modèles « ne nécessitent plus de fichiers de configuration tels que les fichiers d’entitlements et Info.plist », et vous configurez ces champs dans l’onglet Info de la cible et dans l’éditeur de réglages de compilation.⁹ Les chaînes d’outils multiplateformes, les frameworks d’encapsulation et les scripts de build qui synthétisent un plist au moment de l’empaquetage ajoutent une deuxième couche, et leurs modèles peuvent être antérieurs à UILaunchScreen tout court. Personne ne relit un fichier écrit par le système de build.

Les plists amputés sont la deuxième catégorie. Les storyboards de lancement disparaissent lors d’une optimisation de taille, d’une migration hors d’Interface Builder, ou d’un nettoyage qui a supprimé le dernier storyboard du projet et emporté l’écran de lancement avec lui. L’app continuait de compiler, alors la suppression semblait sans risque.

Les projets hérités viennent en troisième, et cette cohorte est plus restreinte que ne le supposent la plupart des articles. UILaunchStoryboardName est arrivée avec iOS 9 : un projet reconduit depuis 2015 possède donc déjà une clé conforme.⁵ Les apps qui n’en ont aucune des quatre sont plus anciennes encore : celles qui déclarent toujours leurs visuels de lancement via UILaunchImages, la clé iOS 7.0 qu’Apple a dépréciée en iOS 13.0 avec une seule consigne, « UILaunchImages est dépréciée ; utilisez plutôt les storyboards de lancement de Xcode ».¹⁰ Un tableau UILaunchImages ne figure pas sur la liste des quatre clés d’Apple : un projet qui s’appuie encore dessus sans avoir jamais adopté de référence à un storyboard n’a donc rien que l’exigence accepte. Dix ans de mises à jour de Xcode ne lui en auront pas ajouté une, parce que rien n’a jamais échoué à la compilation.

Auditer un Info.plist écrit par le système de build

Commencez par accepter que le fichier n’existe peut-être pas. GENERATE_INFOPLIST_FILE active la génération automatique, et chaque réglage de compilation INFOPLIST_KEY_* écrit une clé dans le plist produit par le build.⁸ Deux de ces réglages concernent les écrans de lancement : INFOPLIST_KEY_UILaunchScreen_Generation, qui écrit un dictionnaire UILaunchScreen vide, et INFOPLIST_KEY_UILaunchStoryboardName, qui écrit le nom du storyboard.⁸ Ni l’un ni l’autre ne laisse quoi que ce soit qu’une recherche textuelle puisse trouver. Le modèle iOS SwiftUI App actuel de Xcode embarque INFOPLIST_KEY_UILaunchScreen_Generation = YES dans ses réglages partagés : un projet créé ainsi comporte donc une cible conforme sans le moindre texte relatif à l’écran de lancement où que ce soit dans le dépôt.¹¹

Interrogez le système de build plutôt que le système de fichiers :

xcodebuild -showBuildSettings \
  -project YourApp.xcodeproj -target YourApp \
  -configuration Release -sdk iphoneos 2>/dev/null \
  | grep -E "^ +(GENERATE_INFOPLIST_FILE|INFOPLIST_FILE|INFOPLIST_KEY_UILaunch)"

Exécutée sur ma machine contre le projet Ace Citizenship, la commande renvoie trois lignes :¹¹

    GENERATE_INFOPLIST_FILE = YES
    INFOPLIST_FILE = Ace-Citizenship-Info.plist
    INFOPLIST_KEY_UILaunchScreen_Generation = YES

La troisième ligne constitue à elle seule la réponse en matière de conformité, et aucun fichier du dépôt ne la contient. Lisez la sortie dans cet ordre. GENERATE_INFOPLIST_FILE = YES accompagné d’une ligne INFOPLIST_KEY_UILaunch réglée sur YES signifie que le système de build écrit la clé à votre place : Apple conditionne chaque réglage INFOPLIST_KEY_* à l’activation de la génération, si bien que la même ligne devient inerte sous GENERATE_INFOPLIST_FILE = NO, et qu’une valeur NO n’écrit rien dans les deux cas.⁸ Génération désactivée, c’est dans le fichier désigné par INFOPLIST_FILE que doit se trouver votre clé d’écran de lancement : ouvrez-le et cherchez-y l’une des quatre. Génération activée et chemin de fichier présent, le système de build fusionne les deux et chacune des deux sources suffit à satisfaire l’exigence.⁸

Les deux options gagnent leur place. -configuration Release compte parce que l’examen de l’App Store voit le produit Release. -sdk iphoneos compte parce que Xcode écrit ces réglages par SDK sur les cibles multiplateformes : le projet Reps déclare INFOPLIST_KEY_UILaunchScreen_Generation trois fois, une fois pour [sdk=iphoneos*], une pour [sdk=iphonesimulator*] et une pour [sdk=appletv*], et Banana List déclare les deux premières. Retirez -sdk iphoneos et aucune ne se résout : la clé disparaît de la sortie et une cible pourtant conforme apparaît à tort comme exposée.¹¹

Vérifiez ensuite l’artefact que vous soumettez réellement. Dans la sortie de plutil -p, deux espaces en début de ligne signalent une clé de premier niveau :

plutil -p YourApp.xcarchive/Products/Applications/*.app/Info.plist \
  | grep -E '^  "UILaunch'

Sur une archive de Return compilée pour distribution en avril, une seule ligne revient ; la même commande sur un bundle dépourvu d’écran de lancement n’affiche rien et sort avec le code 1 :¹¹

  "UILaunchScreen" => {

Ici, choisissez plutil plutôt que PlistBuddy. Face à un chemin qui ne se résout pas, PlistBuddy -c "Print" écrit « File Doesn’t Exist, Will Create: » suivi d’un Dict { } vide sur la sortie standard, puis sort avec le code 0 ; redirigez cette sortie vers un grep sur les clés d’écran de lancement et la seule ligne qui révèle l’erreur est avalée, laissant une sortie vide qui ressemble exactement à une clé manquante. plutil, lui, nomme le fichier qu’il n’a pas pu ouvrir et sort avec le code 1.¹¹

Un balayage du dépôt a toujours son utilité, mais plus modeste qu’il n’y paraît : repérer les plists maintenus à la main qui méritent d’être lus.

find . -name "Info.plist" \
  -not -path "*/build/*" -not -path "*/DerivedData/*" \
  -not -path "*/.build/*" -not -path "*/Carthage/*" -not -path "*/Pods/*" \
  -print0 | xargs -0 grep -L -E "UILaunchScreen|UILaunchStoryboard"

Chaque chemin affiché est un candidat à vérifier dans les réglages de compilation, pas une cible qui échouera à la soumission. Sur Banana List, la commande renvoie exactement une ligne, ./Banana List/Info.plist, et cette cible embarque quand même un écran de lancement : ses réglages de compilation portent INFOPLIST_KEY_UILaunchScreen_Generation, et le bundle archivé contient UILaunchScreen. Sans les exclusions, la même commande renvoie 25 lignes sur ce dépôt, dont 24 artefacts de build situés dans build/, parmi lesquels des bundles de test-runner, XCTest.framework, un journal .xcresult et une app watch.¹¹

Ajouter la clé à la main demande quelques étapes plutôt qu’une simple modification de texte. La séquence d’Apple : dans les réglages de votre cible, sélectionnez l’onglet Info ; dans la section Custom iOS Target Properties, dépliez la clé Launch Screen ; cliquez sur le bouton Add, saisissez UILaunchScreen, puis appuyez sur Retour ; sélectionnez ensuite la clé UILaunchScreen, cliquez de nouveau sur Add et ajoutez les clés enfants correspondant aux options d’apparence souhaitées.² Sur un plist généré par Xcode, régler INFOPLIST_KEY_UILaunchScreen_Generation sur YES dans les réglages de compilation de la cible remplit le même office et survit au build suivant.⁸ Pour un plist généré par autre chose que Xcode, corrigez le modèle du générateur : le build suivant écrase tout ce que vous modifiez dans la sortie.

Ce que la règle ne dit pas

Apple n’a publié aucune date. Le déclencheur est formulé ainsi : « dès que l’App Store commence à accepter les apps compilées avec le SDK 27.0 », ce qui tombe historiquement autour de la sortie du système à l’automne, sans qu’Apple s’y soit engagée par écrit pour ce cycle.¹ Toute date précise que vous lirez relève de la déduction.

Apple n’a pas dit non plus que les apps existantes cesseraient de fonctionner, que les builds TestFlight seraient concernés, ni que l’exigence dépasserait iOS et iPadOS. La note couvre la soumission de nouveaux builds, et rien d’autre.

Le correctif est suffisamment mineur pour que la vraie question ne soit pas comment se conformer, mais de savoir si vous êtes déjà conforme. Pour un projet maintenu à la main, la réponse est presque certainement oui. Pour tout ce qui repose sur un plist généré, elle vaut la peine d’être confirmée auprès du système de build avant que le store ne commence à dire non.

FAQ

Une app créée à partir d’un modèle Xcode actuel est-elle déjà conforme ?

Presque certainement, et la preuve se trouve dans les réglages de compilation plutôt que dans un fichier. Le modèle iOS SwiftUI App de Xcode définit INFOPLIST_KEY_UILaunchScreen_Generation = YES dans ses réglages partagés, ce qui écrit un dictionnaire UILaunchScreen vide dans le Info.plist produit par le système de build.⁸¹¹ Confirmez-le en lançant xcodebuild -showBuildSettings sur la configuration Release avec -sdk iphoneos et en cherchant une ligne INFOPLIST_KEY_UILaunch.

Pourquoi une recherche de UILaunchScreen dans mon dépôt ne trouve-t-elle rien ?

Parce que depuis Xcode 13, les projets créés à partir de plusieurs modèles n’embarquent aucun Info.plist sur le disque ; Apple a déplacé ces champs dans l’onglet Info de la cible et dans l’éditeur de réglages de compilation.⁹ L’écran de lancement provient de INFOPLIST_KEY_UILaunchScreen_Generation ou de INFOPLIST_KEY_UILaunchStoryboardName au moment de la compilation.⁸ Une recherche textuelle dans les fichiers source ne peut voir ni l’un ni l’autre, et les fichiers Info.plist qu’elle trouve sont généralement des fragments partiels que le système de build fusionne, ou des artefacts de build sous build/ et DerivedData/.

Quelle clé ajouter si je n’en ai véritablement aucune ?

UILaunchStoryboardName si vous embarquez un LaunchScreen.storyboard, et UILaunchScreen sinon.⁴⁵ Un dictionnaire UILaunchScreen vide suffit pour une app qui se lance sur un fond uni, et c’est précisément ce que Xcode génère par défaut.⁸ Laissez de côté UILaunchScreens et UILaunchStoryboards à moins de présenter des états de lancement distincts selon le schéma d’URL ; la recommandation d’Apple elle-même est : « Si vous n’avez besoin que d’un seul écran de lancement, utilisez plutôt UILaunchScreen. »⁶

L’exigence s’applique-t-elle aux builds TestFlight ?

La note d’Apple ne le dit pas. Elle nomme une seule conséquence, le refus « dès que l’App Store commence à accepter les apps compilées avec le SDK 27.0 », et la distribution TestFlight n’y apparaît nulle part.¹ Comme les builds TestFlight passent par App Store Connect et par l’examen bêta, l’hypothèse prudente est qu’un build qui échoue à l’exigence échoue partout où il rencontre un examen, mais Apple ne l’a pas écrit. Quiconque dépend de la réponse devrait tester un envoi compilé avec le SDK 27.0 plutôt que de se fier à l’une ou l’autre lecture de ce silence.

Points clés à retenir

Pour les développeurs iOS : - Interrogez les réglages de compilation avant de fouiller les fichiers. Lancez xcodebuild -showBuildSettings -configuration Release -sdk iphoneos et cherchez INFOPLIST_KEY_UILaunchScreen_Generation ou INFOPLIST_KEY_UILaunchStoryboardName.⁸ Une recherche textuelle dans le dépôt ne peut voir ni l’un ni l’autre. - Choisissez UILaunchStoryboardName si vous embarquez un storyboard de lancement, et UILaunchScreen sinon. Laissez de côté les clés plurielles à moins de servir des états de lancement différents selon le schéma d’URL.

Pour les équipes qui livrent via des chaînes d’outils multiplateformes : - Auditez le bundle .app archivé avec plutil -p, pas le fichier dans le gestionnaire de versions. C’est la sortie du générateur que voit l’examen, et plutil échoue bruyamment sur un chemin erroné là où PlistBuddy affiche un dictionnaire vide et sort avec le code 0. - Corrigez le modèle de plist dans votre configuration de build plutôt que le fichier généré, sinon le build suivant écrase le correctif.

Pour les responsables de version : - L’échec se manifeste à la soumission sur l’App Store, pas à l’exécution : il vous coûte un cycle d’examen, pas un incident en production. Planifiez l’audit avant la première soumission compilée avec le SDK 27.0, et non après un refus. - Associez cette vérification à la migration vers le cycle de vie par scènes, qui partage le même déclencheur et s’accompagne d’une sanction plus lourde.

Le cycle 27 continue de convertir les suggestions en obligations : ImageCreator cesse de fonctionner, le cycle de vie par scènes devient une condition de lancement, et l’écran de lancement devient une barrière de soumission. Pour le reste de ce qui arrive dans le même SDK, voir Les nouveautés de SwiftUI pour iOS 27. Le sommaire complet de la série se trouve dans la série Écosystème Apple.

Références