L'iPhone pliable arrive le 23 octobre. Voici ce qui casse dans votre app, et comment le corriger.

Apple a ouvert les soumissions App Store pour l'iPhone Duo le 5 octobre, et l'appareil sera en vente le 23 octobre. C'est le premier iPhone pliable d'Apple : un petit écran externe que vous utilisez lorsque l'appareil est fermé, et un grand écran interne lorsque vous l'ouvrez. Le problème pour les développeurs, c'est que la taille de votre app change au moment où quelqu'un plie ou déplie l'appareil, et cette taille ne correspond pas toujours à l'écran physique. Pour y remédier, Apple a livré le release candidate de Xcode 27.1 le 5 octobre avec le simulateur de pliage, un Device Hub pour vérifier chaque position, et un ensemble d'API de mise en page construites autour de la pliure.
Voici la partie qui fixe l'échéance. Les apps compilées avec le SDK iOS 27 se redimensionnent déjà pour remplir la majeure partie de l'écran interne. Compilez avec le SDK iOS 27.1 et votre app obtient le badge « optimisée pour iPhone Duo », avec les barres d'outils et les onglets qui se déplacent dans une barre verticale sous la zone de statut. Les anciennes compilations fonctionnent toujours, mais avec des bordures noires. À partir d'avril 2027, chaque soumission App Store devra inclure des captures d'écran de l'iPhone Duo, donc même si vous ignorez le matériel pour l'instant, vous ne pouvez pas ignorer le travail de mise en page très longtemps.
Ce qui casse réellement
Deux choses, principalement. La première concerne les tailles d'écran codées en dur. Les recommandations officielles d'Apple sont sans équivoque : recherchez UIScreen.main dans votre projet et supprimez-le. Lisez la taille depuis la vue ou la fenêtre (view.bounds, window.bounds, ou GeometryReader dans SwiftUI), et relisez-la à chaque changement, car une pliure peut redimensionner votre app en pleine session. La seconde concerne la logique d'orientation. Sur l'iPhone Duo, l'orientation de l'appareil ne vous indique plus la forme de votre app, donc tout ce qui repose sur UIDevice.current.orientation ou interfaceOrientation doit disparaître. Comparez la largeur et la hauteur de l'espace que vous avez réellement.
Pour les mises en page qui doivent réagir à la pliure elle-même, deux nouveaux outils sont disponibles. Les régions réservées vous permettent d'interroger le proxy de géométrie pour savoir où se trouvent la charnière et les caméras : une région .division marque la pliure, une région .occlusion marque une caméra, et chacune rapporte son cadre et si elle est active en ce moment. La région de la pliure n'est active que lorsque l'appareil est partiellement ouvert, ce qui est un détail utile, car vous pouvez la lire lorsque l'appareil est à plat et disposer un nombre pair de colonnes pour qu'aucune ne tombe jamais sur le pli. Le deuxième outil, ArrangementView dans SwiftUI (ou UIArrangementViewController dans UIKit), est un conteneur à deux panneaux qui sépare ou superpose vos vues principale et secondaire, et déplace le séparateur sur la pliure pour vous.
On a déjà vu ce film
Dans nos projets iOS et Android natifs, les apps qui ont traversé sans encombre l'ère du multitâche iPad et de la Split View étaient toujours celles qui dimensionnaient leurs vues par rapport à leur conteneur plutôt qu'à l'écran. Celles qui codaient les dimensions en dur avaient besoin d'une vraie chirurgie, et ce n'était jamais l'affaire d'un après-midi. Nous avons vu la même division dans les projets de santé et d'IoT, où un build téléphone et un build tablette partageaient une même base de code : l'équipe qui faisait confiance aux size classes a livré, l'équipe qui gérait des cas particuliers pour les dimensions d'écran a passé un sprint à défaire son travail. L'iPhone Duo est la même leçon sous une nouvelle forme. Si votre mise en page s'adapte déjà à l'iPad et à iPhone Mirroring sur Mac, vous êtes en grande partie prêt.
Un mot de mise en garde sur le raccourci. Xcode 27.1 vous permet de demander à l'assistant de code de « préparer mon app pour l'iPhone Duo », et il va rechercher ces patterns et proposer des corrections. C'est vraiment utile pour trouver chaque UIScreen.main dans une grande base de code. Ce n'est pas une raison de merger le diff sans le lire. Les modifications de mise en page touchent exactement les écrans sur lesquels vos utilisateurs passent le plus de temps, et une réécriture automatisée qui déplace un contrôle loin de la pliure peut tout aussi facilement pousser une cible de tap sous une caméra. Examinez-le comme n'importe quelle autre pull request.
L'action de cette semaine
Orientez une lane CI vers Xcode 27.1, compilez avec le SDK iOS 27.1, et faites passer vos trois ou quatre écrans les plus fréquentés par toutes les positions dans le simulateur : fermé, ouvert, livre et pivoté. Avant tout cela, recherchez UIScreen.main, UIDevice.current.orientation et les constantes de frame fixes dans la base de code. Cette recherche seule vous indique l'ampleur réelle du travail, bien avant que vous écriviez une ligne de nouveau code de mise en page. Pour la plupart des apps, c'est moins important qu'il n'y paraît. Pour quelques-unes, c'est une réécriture, et il vaut mieux le savoir maintenant qu'en mars 2027.
C'est aussi un bon moment pour penser au-delà d'iOS. La discipline que l'iPhone Duo impose, dimensionner par rapport à un conteneur et ne jamais faire confiance à un viewport fixe, est la même qui permet à une application web d'être lisible d'un téléphone à un moniteur ultra-large. Lorsque nous développons des applications cloud-native pour des clients enterprise, cette réactivité est simplement acquise. Le mobile natif est enfin soumis à la même pression, et les équipes qui considèrent cela comme une habitude architecturale plutôt qu'un correctif ponctuel passeront beaucoup moins de temps à courir après le prochain facteur de forme. Vous pouvez voir comment nous avons abordé le travail multiplateforme dans notre portfolio, et la page développement couvre notre approche du développement web et mobile ensemble.
Si préparer une app pour un nouveau facteur de forme sans réécrire votre mise en page de zéro vous semble familier, parlons-en.