Ouvrez un iPhone Duo neuf : les apps que vous utilisez déjà se lancent presque toujours. Une app ne plante pas seulement parce que personne ne l’a redessinée pour un écran pliable. Si le binaire a été compilé avec le SDK iOS 26 ou une version plus ancienne, l’écran intérieur déplié le garde dans une fenêtre de la taille d’un téléphone, au centre. Le reste de cet écran reste vide. Cette marge vide, c’est la bande noire dont on parle.
Les mises en page étirées et les appuis à côté sont une autre panne. Elles apparaissent quand une équipe recompile avec le SDK iOS 27 ou 27.1 et que le système agrandit la fenêtre au pliage. L’ancienne mise en page a été dessinée pour un écran fixe. Retirez la fenêtre de compatibilité, et ces hypothèses deviennent visibles.
Les anciennes apps tournent encore. Les bandes noires sont la fenêtre de compatibilité des binaires compilés avec le SDK iOS 26 ou avant, pas un plantage. Les bugs de mise en page et de zone tactile arrivent une fois la fenêtre agrandie, si le code suppose encore une seule taille, une seule orientation, ou une coupure nette entre iPhone et iPad.
Les faits ci-dessous ont été vérifiés le 15 octobre 2026. Tailles d’écran et dates de vente viennent de la page produit iPhone Duo d’Apple. Les trois modes de fenêtre viennent de Prepare your app for iPhone Duo. Le Tech Talk du même sujet couvre l’écran principal, l’orientation et les zones de sécurité. Cet article n’ouvre pas les titres connus de l’App Store sur un appareil. Il nomme des classes de code, pas des marques « déjà cassées ».
Les anciennes apps s’ouvrent-elles encore sur iPhone Duo ?
Oui. La page de préparation dit que chaque app s’exécute. Ce qui change, c’est si la fenêtre suit l’écran intérieur, l’écran extérieur et Split View.
L’iPhone Duo est le premier iPhone pliable d’Apple. L’écran intérieur fait 7,6 pouces, 50 % de plus que l’iPhone 18 Pro Max. Fermé, l’écran extérieur fait 5,4 pouces et dépasse 90 % de la surface d’écran de l’iPhone 18 Pro. Le rapport d’aspect est le même sur les deux. Les précommandes commencent le 16 octobre 2026 à 5 h PT, la disponibilité le 23 octobre. Ces chiffres viennent de la page produit, pas d’un fil de rumeurs.
Le système choisit la fenêtre d’après le SDK qui a compilé ce binaire. Le nom de l’app n’entre pas en compte, ni son aspect sur iPhone 18 Pro.
| SDK de compilation | Écran intérieur, ouvert | Ce que la doc ajoute |
|---|---|---|
| iOS 26 ou avant | Centré, avec de l’espace vide autour | Fermé, le contenu est à gauche de la barre d’état et de la caméra |
| iOS 27 | La majeure partie de l’écran intérieur, en évitant encore la barre d’état à droite | L’ouverture agrandit la fenêtre ; la fermeture la ramène à l’écran extérieur |
| iOS 27.1 ou après | Tout l’écran intérieur | Barres d’outils et d’onglets à la verticale sous la barre d’état ; à vérifier avant publication |
Les deux premières colonnes suivent la page de préparation. La phrase sur l’écran fermé, contenu à gauche de la barre d’état et de la caméra, est écrite pour le SDK iOS 26 et avant. Pour iOS 27 et après, le comportement documenté est : s’étendre sur l’écran intérieur, revenir à l’écran extérieur une fois plié. Ne dessinez pas le même cadre noir autour des trois cas d’écran extérieur.
Qui trace vraiment les bandes noires ?
Les bandes ne sont pas un décor peint par l’app. Pour un binaire compilé avec le SDK iOS 26 ou avant, le système refuse de l’étirer sur l’écran intérieur de 7,6 pouces et le place dans une taille que ce binaire connaît déjà. La zone restante reste vide. Les boutons à l’intérieur de cette fenêtre marchent encore.
Refermer le téléphone, c’est une autre image. Pour cet ancien SDK, la page de préparation dit que l’écran extérieur montre le contenu à gauche de la barre d’état et de la caméra. L’écran extérieur est plus large et plus court, et la page produit dit que les commandes essentielles passent sur le côté pour laisser plus de hauteur au contenu. Le cadre intérieur n’est pas la preuve que le téléphone fermé est noir sur les quatre bords.
La phrase qui voyage trop loin : « l’écran de couverture est un iPhone normal, donc les anciennes apps y sont bord à bord. » Apple écrit que le contenu reste à l’écart de la barre d’état et de la caméra. Qu’il remplisse l’écran extérieur, et que les commandes soient sur le côté, suit la note de ce SDK. Ne collez pas la fenêtre de compatibilité intérieure sur le couvercle.
Les bandes restent jusqu’au changement de SDK. iOS 27 réduit nettement la zone vide. iOS 27.1 est la version plein écran, et les barres standard peuvent se déplacer. Une recompilation sans passage sur la mise en page peut enlever les bandes et révéler les bugs de la section suivante. Peu d’équipes auront fini un passage 27.1 et une soumission avant le 23 octobre, donc les fenêtres de compatibilité seront encore courantes le jour du lancement. C’est un calendrier, pas une liste de fiches cassées sur le store.
Quelles apps montrent le plus souvent des bandes noires ?
Il n’y a qu’un test : ce binaire a-t-il été compilé avec le SDK iOS 26 ou avant ? Jeu ou nom connu ne change pas la règle. Sur l’écran intérieur ouvert, chaque binaire de ce groupe reste dans la fenêtre centrée.
Celles qu’on remarque d’abord sont celles qui sortent rarement : stationnement, accès à une porte, un outil d’approbation interne, une app métier que personne n’a reconstruite. On voit des bandes noires. Les listes et les boutons dans la fenêtre répondent encore, le plus souvent.
Les jeux demandent un second regard. Les Human Interface Guidelines demandent de remplir chaque pose et de changer le rapport d’aspect plutôt que de letterboxer ; si une marge est inévitable, elle doit porter un visuel. Un jeu qui letterboxe encore après un build au nouveau SDK choisit ce cadre. Ce n’est pas la fenêtre système. Les deux bandes se ressemblent et n’appartiennent pas à la même couche. Cet article ne classe pas un jeu nommé. Cela dépend du SDK du build en vente.
Quelles apps cassent le plus souvent la mise en page ?
La mise en page casse rarement tant que l’app reste dans la fenêtre de compatibilité. La taille n’a pas changé, donc une mise en page téléphone tient encore. La casse commence quand le pliage, la rotation ou Split View change la fenêtre et que le code garde une ancienne taille.
La page de préparation nomme les motifs qui étirent, rognent ou posent des commandes là où personne ne les voit :
- Traiter tout l’écran comme votre fenêtre.
UIScreen.main.bounds, une taille lue une fois au lancement, etUIWindow(frame: UIScreen.main.bounds). Un pliage redimensionne l’app au milieu de la session, le chiffre du lancement devient faux. Le Tech Talk dit aussi que l’écran principal est ambigu sur un appareil à deux écrans et sera déprécié. - Choisir la mise en page selon l’orientation. L’écran intérieur n’honore pas les orientations déclarées. L’orientation
UIDeviceouinterfaceOrientationne correspond pas à la largeur et à la hauteur réelles de la fenêtre. - Utiliser « est-ce un iPhone ? » comme interrupteur.
userInterfaceIdiom == .phoneou.pad, et toute branche qui traite une largeur regular comme un iPad. Une app iPhone peut être en largeur regular sur l’écran intérieur. - Une table de hauteurs connues. Des tests comme
bounds.height == 844ne correspondent pas à la fenêtre du Duo. - Visuels et vidéos en plein cadre rogné.
scaleAspectFillcoupe le sujet sur un cadre plus large.
Voici un exemple qui suit la doc. Une app de notes compilée avec le SDK iOS 26 s’ouvre centrée, avec de l’espace vide autour. Les boutons restent à leur place, les notes s’enregistrent. Recompilez avec le SDK iOS 27.1 : la fenêtre remplit l’écran intérieur, et le système place la barre d’onglets à la verticale sous la barre d’état. Si le Y d’un bouton du bas vient de la hauteur d’écran au lancement, il tombe sur la barre ou hors du contenu. L’entrée n’a pas changé. La fenêtre, si.
La confusion la plus fréquente bascule vers une barre latérale réservée à l’iPad parce que la largeur est regular. Cette branche ne tournait autrefois que sur iPad. L’écran intérieur de l’iPhone Duo peut aussi annoncer une largeur regular, donc la barre latérale apparaît sur ce téléphone.
Quelles apps ratent l’appui, ou inversent l’aperçu caméra ?
Les bugs d’interaction sont la couche suivante d’un bug de mise en page. Le contrôle est encore là, mais le doigt touche autre chose, ou l’aperçu regarde dans le mauvais sens.
Jeux et vidéo verrouillés sur une orientation
L’écran intérieur ignore les orientations déclarées. Un jeu paysage seulement, avec des commandes soudées à un bord, peut pousser un stick virtuel dans la zone de sécurité après un pliage, ou garder le letterbox de l’ancien ratio. La consigne est de changer le rapport d’aspect et de remplir l’écran. S’il faut une marge, mettez-y un visuel, pas une bande noire nue.
Apps caméra et d’appel qui choisissent elles-mêmes les objectifs
Le pliage change le sens dans lequel un objectif fait face à la personne qui tient le téléphone. Une app qui choisit « avant » ou « arrière » doit changer d’objectif à l’ouverture et à la fermeture. Le Tech Talk caméra pointe vers AVCaptureDeviceDirectionCoordinator : le coordinateur de l’écran extérieur signale les caméras arrière comme tournées vers l’avant, celui de l’écran intérieur comme tournées vers l’arrière. Sans lui, l’aperçu peut se mirer dans le mauvais sens ou garder l’objectif précédent après l’ouverture. C’est un bug d’interaction, pas une bande noire.
Barres du bas dessinées à la main et zones tactiles
Les barres de navigation, d’outils et d’onglets du système se placent hors de la zone de sécurité et évitent seules la barre d’état et la caméra. Une barre du bas dessinée à la main ne passe pas toute seule à la verticale. Sur l’écran extérieur, et sur l’écran intérieur en paysage, les commandes standard sont sur le côté. Seul l’écran intérieur en portrait a assez de hauteur pour garder des barres horizontales. Les zones de sécurité sont souvent asymétriques, et en Split View une commande verticale peut se trouver à gauche. Un test de toucher qui suppose « la barre est toujours en bas, et les deux côtés se correspondent » rate la cible.
Est-ce le même mode de compatibilité iPhone que sur iPad ?
Non. La fenêtre iPhone agrandie sur iPad répond à « ce binaire n’a pas d’interface iPad ». Les trois fenêtres du Duo répondent à « quel SDK a compilé ce binaire ». Les deux règles peuvent vivre dans un projet. Elles ne se remplacent pas.
Elles échouent aussi à des moments différents. Le mode iPad ne redimensionne pas parce que quelqu’un a plié l’appareil au milieu d’une session. Le Duo, si. Une mesure prise une fois dans viewIsAppearing ne suffit pas. Relisez la taille dans layoutSubviews, viewDidLayoutSubviews, ou le rappel qui s’exécute quand la taille va changer. En SwiftUI, GeometryReader ou onGeometryChange. Prenez l’échelle dans traitCollection.displayScale, pas dans UIScreen.main.scale. Créez la fenêtre avec UIWindow(windowScene:), et ne conservez pas un UIScreen.
Si l’équipe a déjà séparé la régression de release d’une piste bêta plus petite avant les téléphones d’automne, ce plan répondait à l’endroit où tourne la régression. Le Duo ajoute une règle : le même cas doit être regardé fermé, ouvert, tourné et en Split View, pas seulement en capture à une taille de simulateur. La séparation entre piste stable et piste de test est le sujet de faut-il changer le plan de test iPhone 18 avant l’événement d’automne. Mettez le Duo sur la piste de test. N’arrêtez pas la régression de release. Le simulateur demande un Mac avec Xcode 27.1. Comment séparer cette machine du travail quotidien est traité dans comment monter un environnement de test macOS 27. Les règles de fenêtre ne dépendent pas de la location d’un Mac.
Que cet article ne peut-il pas trancher à votre place ?
Savoir si une app nommée montre des bandes noires aujourd’hui dépend du SDK du build en vente, ou de l’ouverture de ce build dans le simulateur iPhone Duo de Xcode 27.1. La page de préparation cite aussi le simulateur redimensionnable de Device Hub, et le redimensionnement extrême d’une fenêtre iPhone Mirroring sous macOS 27. Elle dit que le simulateur Duo est le moyen de voir l’expérience native complète. Cet article ne l’a fait pour aucune app déjà en vente.
Savoir si le pli du charnière couvre un pixel, si les bandes d’un jeu sont voulues, et si une commande latérale bloque un geste maison, se vérifie dans cette pose. La doc dit quelle couche soupçonner. Elle ne dit pas si cette couche est déjà corrigée dans votre binaire.
Alors, jusqu’où les anciennes apps sont-elles cassées ?
Les apps compilées avec le SDK iOS 26 ou avant tournent encore. Sur l’écran ouvert, le résultat typique est une bande noire, pas un plantage. Fermé, le contenu laisse la place à la barre d’état et à la caméra. Ne décrivez pas cela comme le même cadre que sur l’écran intérieur.
Les bandes noires apparaissent d’abord sur les binaires qui n’ont pas changé de SDK, surtout les outils qui sortent rarement. La mise en page casse d’abord sur les apps passées à iOS 27 ou 27.1 mais qui taillent encore depuis le singleton d’écran, une hauteur fixe, l’orientation, ou une branche iPhone contre iPad. Les appuis ratés apparaissent d’abord dans les jeux à orientation verrouillée, les apps caméra qui gèrent le sens des objectifs, et les barres du bas dessinées à la main.
Les barres de navigation et d’onglets standard suivent le système. Les coordonnées que vous calculez vous-même, non. Pour connaître une app, ouvrez ce binaire dans le simulateur Duo ou sur le téléphone. Qu’elle soit correcte sur iPhone 18 Pro ne dit pas qu’elle l’est une fois le téléphone plié.