Votre app fonctionne, mais laisse une zone vide, coupe du contenu ou place une commande sous une barre système sur iPhone Duo.
Reproduisez le défaut avec Xcode 27.1 et le simulateur iPhone Duo, puis vérifiez les dimensions fixes, les hypothèses d’orientation et la disposition des barres avant de réécrire l’interface. Une app construite avec un ancien SDK peut s’exécuter sans exploiter pleinement l’écran : privilégiez une adaptation ciblée, suivie d’une nouvelle validation, plutôt qu’une refonte systématique.
Ce guide s’adresse aux développeurs indépendants qui veulent vérifier le rendu d’une app construite avec un ancien SDK, aux équipes SwiftUI ou UIKit qui utilisent des dimensions, orientations ou barres personnalisées, ainsi qu’aux petites équipes qui souhaitent intégrer le contrôle du simulateur à leur processus de publication.
Dernière mise à jour : 23 octobre 2026. Les informations sur la disponibilité de l’iPhone Duo, les différences entre SDK et les outils de simulation sont vérifiées dans les ressources officielles de préparation d’Apple et les notes de version de Xcode 27.1.
Distinguer l’exécution de l’adaptation à l’iPhone Duo
Commencez par séparer deux questions : l’app peut-elle s’exécuter, et son interface tire-t-elle parti de l’espace disponible ? Ce ne sont pas les mêmes critères. Les informations officielles indiquent que l’iPhone Duo est disponible depuis le 23 octobre 2026 ; elles précisent aussi que le comportement de l’app dépend du SDK utilisé pour la construire. Une app construite avec un ancien SDK peut fonctionner sans adopter la disposition la plus complète. Une app construite avec le SDK iOS 27 s’adapte dynamiquement aux dimensions d’affichage, tandis que le SDK iOS 27.1 ou ultérieur permet une disposition plus complète, avec des changements à prendre en compte pour les barres d’outils et les barres d’onglets. Ces différences sont décrites dans le guide de préparation Apple pour iPhone Duo et les notes de version de Xcode 27.1.
Ne déduisez donc pas d’un espace inutilisé que l’app est incompatible, et ne lancez pas immédiatement une migration complète. Inspectez d’abord le résultat réel dans le simulateur. Si le parcours principal reste utilisable et que le défaut se limite à une marge ou à une barre mal placée, une correction localisée peut suffire. En revanche, si une action importante devient inaccessible lors d’un changement de taille, corrigez le comportement avant la publication.
Relevez le SDK utilisé pour la construction, la configuration du simulateur et l’écran précis où apparaît l’anomalie. Gardez ces éléments avec une capture avant correction : sans état de référence, vous risquez de confondre une amélioration visuelle avec un changement de logique ou une différence de données.
Attention : la compatibilité avec un appareil ne garantit pas que tous les espaces disponibles, toutes les postures ou tous les changements de dimensions soient exploités comme vous le souhaitez. Fondez la décision de reconstruire sur le rendu observé, pas seulement sur le fait que l’app se lance.
Reproduire le passage entre l’écran extérieur et l’écran intérieur
Une disposition conçue autour d’une seule largeur peut laisser du vide, tronquer une vue ou déplacer les commandes quand l’espace change. Le passage de l’écran extérieur à l’écran intérieur est précisément le type de transition qui révèle cette hypothèse. Les directives de conception Apple pour iPhone Duo présentent les principes à suivre pour concevoir une interface adaptée à l’appareil ; servez-vous-en pour vérifier vos choix plutôt que de supposer qu’une maquette unique se redimensionnera correctement.
Pour reproduire le défaut, partez d’un écran comportant un élément facile à repérer : une barre de navigation, une liste, un lecteur audio, un panneau de montage vidéo ou une fiche produit. Notez l’état initial et les dimensions affichées par le simulateur, puis reproduisez le changement d’écran ou de taille qui déclenche le décalage. Comparez les captures en examinant les mêmes repères : position du titre, limites de la zone de contenu, visibilité des commandes et espacement entre les éléments interactifs. Le but n’est pas d’obtenir deux captures identiques, mais de vérifier que l’interface conserve sa hiérarchie et reste utilisable.
Recherchez ensuite les contraintes codées en dur. Une largeur ou une hauteur imposée, un espacement calculé à partir d’un modèle d’appareil, ou une condition qui associe une dimension à un seul type de matériel peut enfermer l’interface dans un cas précis. Préférez un raisonnement fondé sur l’espace réellement disponible à une supposition du type « cet appareil a telle taille ». Les classes de taille de SwiftUI permettent de prendre en compte différentes catégories d’espace, mais elles ne corrigent pas automatiquement une logique métier qui suppose une largeur fixe.
Consignez le résultat sous une forme qui facilite la comparaison après modification du code : vue concernée, transition reproduite, élément déplacé ou masqué et comportement attendu. Si la capture montre un espace libre alors que le contenu devrait occuper la zone, examinez les contraintes de taille. Si un élément est coupé, cherchez plutôt une vue parente qui ne se redimensionne pas ou une zone sûre mal prise en compte. Si les commandes changent de position sans devenir inaccessibles, vérifiez d’abord que ce déplacement ne correspond pas à une adaptation prévue.
Vérifier l’emplacement des barres et l’accès aux commandes
Les changements associés au SDK iOS 27.1 peuvent révéler une hypothèse jusque-là peu visible : une app construite autour d’une barre supposée fixe peut se retrouver avec un contenu trop proche du bord, une commande recouverte ou un onglet mal aligné. Apple signale que la disposition des barres d’outils et des barres d’onglets fait partie des points à prendre en compte pour les apps construites avec le SDK iOS 27.1 ou une version ultérieure. Évitez toutefois d’en faire un diagnostic automatique : comparez le rendu avant et après le changement de SDK et vérifiez le comportement concret de chaque écran concerné.
Pour chaque écran du parcours principal, vérifiez que le titre reste lisible, que la zone de contenu n’est pas recouverte, que les commandes importantes répondent au toucher et que les actions secondaires ne disparaissent pas derrière une barre. Dans une app de création audio ou vidéo, examinez aussi le lecteur, la chronologie et les commandes de lecture : un décalage peut laisser l’interface visuellement plausible tout en rendant une action difficile à atteindre. Dans un outil de design, contrôlez les panneaux, les poignées de transformation et les menus contextuels, car leur position peut dépendre de l’espace réellement disponible.
Si votre interface UIKit dessine sous les barres, inspectez le calcul des marges et la relation entre la vue principale et la zone sûre. La documentation UIKit de safeAreaLayoutGuide décrit cette zone de référence, qui vous aide à déterminer si un contenu censé rester accessible est contraint au bon espace. Dans SwiftUI, vérifiez plutôt les conteneurs et les règles d’insertion ou d’ignorance des zones sûres déjà appliquées. N’ajoutez pas une marge supplémentaire sans avoir identifié l’origine de celle qui existe déjà : vous pourriez corriger un écran tout en créant un espace vide sur un autre.
Distinguez trois types de symptômes. Le premier est un défaut de visibilité : le bouton ou le contenu est masqué. Le deuxième est un défaut d’interaction : l’élément est visible, mais sa zone tactile ne correspond plus à sa position. Le troisième est un changement visuel sans perte d’accès ni de hiérarchie. Les deux premiers demandent généralement une recherche de cause fonctionnelle ; le troisième doit être comparé aux intentions de conception et aux autres tailles d’écran avant d’être considéré comme un bogue.
Examiner séparément les orientations et les interfaces personnalisées
Les interfaces dessinées sur mesure, les conteneurs complexes et les écrans verrouillés dans une orientation demandent une vérification distincte. Une transition peut conserver une ancienne position, réorganiser le contenu de façon inattendue ou laisser un élément interactif à l’endroit où il se trouvait avant le changement. Ne classez pas automatiquement ces symptômes comme un problème propre au simulateur : un état conservé incorrectement ou un calcul de disposition dépendant d’une valeur périmée peut produire le même résultat.
Reproduisez le défaut dans l’orientation ou la posture qui le déclenche, puis vérifiez séparément le contenu, l’interaction et l’état. Le contenu ne doit pas être coupé ; les éléments interactifs doivent répondre à l’endroit où ils sont affichés ; enfin, une action commencée avant la transition — lecture en cours, sélection dans une liste ou panneau ouvert — doit rester cohérente après celle-ci. Si l’affichage est corrigé mais que la sélection disparaît, vous avez probablement aussi un problème de conservation d’état, pas seulement un problème de contraintes visuelles.
Pour une interface personnalisée, identifiez le composant responsable de la taille : la vue, son parent, le conteneur de navigation ou la couche qui dessine les commandes. Une vue qui mesure son parent et une vue dont la taille est fixée localement ne réagissent pas de la même manière lors d’une transition. Dans UIKit, inspectez la mise à jour des traits et les contraintes activées après le changement ; la documentation Apple sur UITraitCollection décrit les informations de contexte utilisées par l’interface. Dans SwiftUI, vérifiez que les vues conditionnelles dépendent de l’espace disponible ou de la classe de taille pertinente, plutôt que d’une identification fragile du matériel.
Note de diagnostic : si le décalage n’apparaît qu’après une interaction, répétez le test avec un état initial identique. Une divergence reproductible après l’ouverture d’un panneau ou la sélection d’un élément peut révéler un défaut de logique d’état ; modifier les seules marges ne suffira pas nécessairement.
Corriger selon votre pile SwiftUI ou UIKit
Dans un projet SwiftUI, commencez par repérer les dimensions absolues et les conteneurs qui imposent une taille, puis vérifiez leur comportement quand l’espace disponible change. Les classes de taille et les règles de composition peuvent aider à choisir entre une présentation compacte et une présentation plus large. Le bon objectif n’est pas de créer une interface entièrement distincte pour chaque posture, mais de conserver une structure commune qui réorganise ses éléments lorsque le contexte l’exige.
Dans un projet UIKit, inspectez les contraintes Auto Layout, la réponse aux changements de traits et l’utilisation des zones sûres. Vérifiez qu’une vue ne garde pas une largeur calculée dans un état antérieur et que les contraintes prioritaires ne forcent pas la compression d’un contenu important. Les traits et les guides de zone sûre fournissent des points d’inspection, mais ne désignent pas une solution de code universelle : la correction dépend de la hiérarchie des vues, du comportement attendu et de l’endroit où l’espace est contraint.
Appliquez le changement le plus limité qui supprime la cause reproduite. Si un seul écran utilise une largeur fixe, corrigez cette contrainte et examinez ses vues enfants. Si plusieurs écrans partagent une barre personnalisée, évaluez le composant commun au lieu d’ajouter des décalages locaux partout. Si le défaut vient d’un calcul qui déduit la taille disponible du modèle d’appareil, remplacez cette déduction par une réponse aux dimensions ou aux traits observés.
Après chaque modification, rejouez le cas qui échouait et contrôlez un écran adjacent : une correction locale qui déplace le problème n’est pas une correction validée. Pour éviter les changements qui masquent le défaut sans le résoudre, gardez les captures avant et après, ainsi que la description de la transition ayant permis de reproduire l’anomalie. Cette trace est particulièrement utile lorsque plusieurs personnes interviennent sur le même composant ou que le test doit être rejoué dans un environnement de construction distant.
Valider dans le simulateur avant de décider d’une vérification sur appareil
Le simulateur iPhone Duo sert à reproduire et à contrôler des scénarios de disposition dans Xcode ; il ne constitue pas une validation sur appareil physique. Les notes de version de Xcode 27.1 indiquent les changements associés à cette version, et les exigences système de Xcode permettent de vérifier la compatibilité du Mac utilisé. Consultez ces sources avant d’attribuer un échec de test à votre code : un environnement qui ne satisfait pas aux exigences du logiciel peut empêcher une reproduction fiable.
Suivez un ordre de contrôle reproductible :
- Relevez la version de Xcode, le SDK qui a servi à construire l’app et la configuration du simulateur.
- Lancez l’écran sans interaction, puis capturez son état initial et le défaut observé.
- Reproduisez le passage entre les dimensions d’affichage et la posture qui déclenche l’anomalie.
- Inspectez les contraintes fixes, les hypothèses sur le modèle d’appareil, les zones sûres et les barres.
- Modifiez une seule cause plausible à la fois, puis rejouez exactement la même transition.
- Vérifiez la visibilité et l’interaction des commandes, ainsi que la conservation de l’état.
- Conservez les captures et les résultats avec le changement de code ; passez à une validation sur appareil lorsque le comportement matériel ou tactile reste déterminant.
| Option de validation | Cas où elle convient | Limite à garder en tête | Appréciation |
|---|---|---|---|
| Inspection d’une app construite avec un ancien SDK | Vérifier si le défaut est réellement visible avant de décider d’une reconstruction | Ne prouve pas que l’app utilise toute la disposition disponible | Adaptée au triage |
| Reconstruction avec le SDK iOS 27.1 et contrôle du simulateur | Vérifier les changements de disposition associés au SDK et corriger les hypothèses de taille | Le rendu du simulateur ne remplace pas le contrôle sur appareil physique | Prioritaire pour l’adaptation |
| Vérification sur un seul écran ou une seule capture | Comparer rapidement un état statique connu | Ne couvre ni les transitions, ni l’interaction, ni la conservation d’état | Insuffisante seule |
| Refonte complète avant reproduction du défaut | Envisager une refonte si plusieurs composants partagés échouent de façon reproductible | Risque de modifier bien davantage que la cause établie | À réserver aux défauts structurels |
Si votre Mac local ne peut pas faire tourner Xcode 27.1, un environnement distant peut éviter l’achat d’une machine réservée aux essais ponctuels, mais il faut aussi tenir compte de la connexion, de l’accès aux fichiers et de la disponibilité de la version logicielle requise. Pour des tests matériels fréquents ou une charge durable, une machine locale ou un appareil physique peut être plus approprié. Une fois les scénarios à reproduire et les exigences définis, vous pouvez examiner les options de Mac distant de MACGPU et vérifier qu’elles correspondent à votre besoin de simulation et de construction ; cette vérification ne remplace pas un essai sur appareil lorsqu’il est nécessaire.