Concevoir pour l'iPhone Duo : ce qui bouge, ce qui se divise et ce qui reste

Que demande la conception pour l’iPhone Duo ? Deux dispositions, et non une disposition par posture : « Une disposition en compact width pour l’écran externe et une disposition en regular width pour l’écran interne vous donnent les fondamentaux valables pour toutes les postures », et le conseil d’Apple est de « concevoir votre app pour qu’elle se redimensionne librement ». (4:32)¹² Sur cette base viennent se poser quatre motifs décrits par le guide et ses trois Tech Talks d’accompagnement : les commandes migrent sur le côté de l’écran en conservant un ordre de haut en bas ; le contenu se décale par rapport à ces commandes, sauf s’il occupe délibérément toute la surface ; les éléments interactifs se déplacent pour s’écarter de la pliure, alors que le contenu défilant reste en place ; et un nouveau conteneur, l’arrangement, divise ou superpose deux vues selon des règles. Les Tech Talks présentent les API derrière ces deux derniers points, et les arrangements arrivent avec iOS 27.1.³

Apple a publié Designing for iPhone Duo dans les Human Interface Guidelines l’après-midi de la keynote, accompagné de trois Tech Talks destinés aux designers : « Design for iPhone Duo », « Strike a pose with adaptive layouts on iPhone Duo » et « Raise the bar with iPhone Duo ».¹²³⁴ L’article côté développement publié ici détaille le calcul des points et les règles du SDK. Celui-ci porte sur les décisions de design que réclame le guide, citées d’après les mots mêmes d’Apple avec l’horodatage dans chaque Tech Talk, et sur ce que je compte en faire dans mes propres apps.

TL;DR : Concevez pour deux classes de taille et laissez le système gérer les postures. Les barres passent à la verticale sur le côté de l’écran externe ainsi que sur l’écran interne en paysage ; seul l’écran interne en portrait conserve des barres horizontales.⁴ Les éléments dotés d’une icône passent à la verticale, les éléments purement textuels restent à l’horizontale, et le haut de la barre verticale revient à Back ou Close, suivi d’une action mise en avant comme Done.⁴ Le contenu se décale par rapport à la barre via la zone sûre horizontale, sauf s’il est immersif et ne défile pas.² À la pliure, en posture livre, « des éléments comme les alertes migrent du côté trailing » (4:09) et, sur une table, les commandes interactives descendent dans la moitié basse, tandis que « le contenu à défilement continu, comme les articles, les fils, les documents et les listes, ne se déplace pas » (3:46).³ Les arrangements constituent le nouveau conteneur de disposition, en split ou en overlay, et la règle de choix donnée par Apple est celle que vous appliquez déjà : une pile horizontale ou verticale devient un split, un ZStack devient un overlay.³

Une règle avant les motifs

Deux des Tech Talks et le guide répètent la même phrase, et c’est de cette phrase qu’il faut partir. Vince, de l’équipe design d’Apple : « Les gens utiliseront l’iPhone Duo dans de nombreuses postures différentes, et vous voudrez que votre app soit superbe dans toutes. Cela ne veut pas dire concevoir une disposition sur mesure pour chaque posture. Concentrez-vous plutôt sur deux classes de taille : compact width sur l’écran externe et regular width sur l’écran interne. Évitez les largeurs fixes, les points de rupture ou toute mesure liée à un écran particulier » (3:50).² Le guide dit la même chose dans sa section consacrée aux postures.¹ Vince ajoute une disposition facultative, pour l’appareil posé sur une table comme un ordinateur portable, où « les médias peuvent occuper le haut, tandis que les commandes tactiles reposent sur une base stable en bas » (4:48), à condition qu’elle « comporte exactement les mêmes commandes et la même hiérarchie générale que les autres postures » (4:57).²

Image tirée de la diffusion de l’événement Apple du 9 septembre 2026, à 11 h 05 PT : la posture debout. La liste du guide est « partiellement plié comme un livre, posé sur une surface, ou dressé sur ses tranches ».

Tout ce qui suit présuppose cette base, la même que celle que vérifie la liste de contrôle de l’iPhone redimensionnable et qu’explique l’article sur le redimensionnement de l’iPad. Si une disposition est bâtie à partir des classes de taille, des marges de disposition et des marges de la zone sûre, la promesse de Vince est la suivante : « votre app devrait déjà s’adapter à l’iPhone Duo » (4:27).²

Le côté : ce qui migre et ce qui reste

Sur l’écran externe, les commandes qui vivaient en haut et en bas « migrent vers le côté droit de l’écran afin de maximiser l’espace vertical et de les rendre plus faciles à atteindre avec le pouce droit » (1:18).² Le côté accueille la barre d’onglets, les barres d’outils, les commandes de navigation comme Back, la barre d’état et la Dynamic Island, « qui s’étend verticalement à l’arrivée des Live Activities » (1:48).² Sur l’écran interne, les barres restent verticales en paysage et redeviennent horizontales en portrait, « la seule posture où nous avons conservé des barres horizontales » (5:27), parce qu’« il y a largement assez d’espace vertical pour le contenu de l’app » (5:32).² En Split View, « lorsqu’une app se trouve du côté gauche, les commandes migrent elles aussi vers le bord gauche de l’écran » (3:11).² Et la barre est alignée sur le matériel : elle « reste du même côté de l’appareil dans les langues qui s’écrivent de droite à gauche » (4:21).⁴

Image tirée de la diffusion de l’événement Apple du 9 septembre 2026, à 10 h 59 PT : l’appareil à demi plié, écran interne face à nous, et les commandes latérales sur son bord droit.

Deux choses déterminent si une commande donnée passe à la verticale. La première est son conteneur. Anna, de l’équipe UI Frameworks : « assurez-vous d’utiliser les barres fournies par des conteneurs de navigation comme TabView ou NavigationStack » (2:19), car le contenu issu d’instances personnalisées de UIToolbar, UINavigationBar ou UITabBar « ne sera pas pris en compte » (2:58).⁴ Dans les vues divisées, « seule la colonne de détail participe » (3:43), et les inspecteurs « n’en reçoivent pas » de leur côté (3:53).⁴ La seconde est le contenu de l’élément. Les barres verticales ont « une hauteur d’élément flexible et une largeur fixe » (6:10), ce qui « les rend mieux adaptées aux représentations d’éléments composées uniquement d’un symbole » (6:13).⁴ Ainsi, « les éléments dotés d’une icône, comme les boutons back et share, changent d’axe pour passer à la verticale. Et les éléments purement textuels, comme le bouton edit, restent sur l’axe horizontal » (7:06).⁴ La version de Vince s’adresse aux designers : « Les éléments de barre d’outils trop larges pour l’espace disponible à droite, comme un bouton texte ou un contrôle segmenté, doivent rester dans la barre de navigation sur l’iPhone Duo » (6:22).²

La règle d’ordonnancement est brève. « Réservez le haut aux commandes de navigation principales, comme back ou close, suivies des actions mises en avant, telles que done » (4:47).⁴ En SwiftUI, un Back ou un Close personnalisé utilise le placement cancellationAction (5:02) et une action mise en avant utilise topBarPinnedTrailing (5:24) ; en UIKit, il s’agit d’un élément leading avec leftItemSupplementsBackButton laissé à sa valeur par défaut false (5:06), et de pinnedTrailingGroup pour l’action mise en avant (5:27).⁴ Tout le reste conserve son regroupement d’origine, « un espaceur vertical séparant visuellement les placements du haut et du bas » (5:34).⁴

Les règles du Tech Talk sur les barres, élément par élément, chacune avec son repère :⁴

• Le test pour un élément personnalisé : « se contente-t-il de renforcer le symbole, ou porte-t-il une information autonome ? » (9:36)
• Un décompte a sa place dans un badge, ce qui transforme un élément texte-plus-symbole en un élément purement symbolique qui « se sent chez lui dans une barre verticale » (9:23) ; « un bouton panier affichant un montant » reste horizontal (9:52).
• Un élément qui alterne entre symbole et texte, comme Edit, reste horizontal ; le bouton Edit du système le fait déjà, et un bouton personnalisé adopte l’AxisBehavior strictement horizontal (8:11, 8:32).
• Une vue personnalisée ou complexe reste horizontale par défaut (8:40) ; si elle « prend bien en charge une représentation verticale » (8:48), l’axis behavior privilégiant la verticale lui ouvre la barre (8:54).
• Donnez un titre à chaque élément, même lorsqu’il affiche un symbole, car « le système s’en sert dès qu’un élément passe dans un menu de débordement ou dans une forme étendue » (7:44).
• Les barres d’accessoires de clavier « doivent rester attachées au clavier plutôt que de migrer sur l’axe vertical » (10:00).
• Les vues personnalisées lisent la propriété d’environnement toolbarVerticalEdge, ou le trait équivalent en UIKit, pour savoir si une barre verticale est présente (10:35).

Le débordement est l’endroit où s’expriment les préférences de design, et le Tech Talk énonce cinq règles :⁴

• « Par défaut, les éléments débordent de bas en haut » (13:23) ; chaque élément peut porter une priorité de visibilité haute, basse ou personnalisée, attribuée d’abord « par groupes » (13:36), puis au sein d’un groupe. Les API de priorité et de débordement font partie des ajouts aux barres d’outils de la WWDC26, traités dans l’article de ce site sur SwiftUI dans iOS 27 ; à 13:49, le Tech Talk vous renvoie à la session WWDC26 d’Apple sur les nouveautés de SwiftUI.
• Décidez ce qui se comprime en premier : dans les vues axées sur la navigation, « la barre d’outils se comprime d’abord, afin que les destinations principales restent accessibles » (12:07), ce qui est le comportement par défaut ; dans les vues orientées tâche, « la barre d’onglets se comprime d’abord afin de préserver les actions fréquemment utilisées » (12:18), ce que l’on règle avec toolbarCompressionBehavior (12:22).
• Fondez le menu de débordement propre à l’app dans celui du système, avec ToolbarOverflowMenu en SwiftUI ou additionalOverflowItems en UIKit (12:36, 12:43), et réservez les points de suspension au seul débordement (12:53).
• « Les actions fréquemment utilisées, comme Compose dans Mail ou New Note dans Notes, doivent figurer parmi les dernières à passer dans le débordement » (13:59).
• Les éléments porteurs d’un badge « doivent rester visibles plus longtemps afin de préserver la lisibilité d’un coup d’œil » (14:11).

Les barres verticales ne sont pas obligatoires. Une disposition d’une seule page au centre de gravité bas, comme Calculator, ou une feuille comportant un unique élément de barre d’outils tel que Close, peut désactiver la barre avec toolbarVerticalBehavior ou preferredVerticalBarBehavior (14:28, 14:37, 14:47).⁴

Centré, ou décalé

Avec la barre d’un côté, « beaucoup de couches sont désormais asymétriques » (6:33).² Vince propose trois positions. La plupart des contenus adoptent un décalage pour ne pas se retrouver cachés derrière les commandes, et « si votre app s’aligne sur les marges horizontales de la zone sûre, ce décalage se produit automatiquement » (6:58).² Certaines interfaces restent centrées sur l’écran entier, sans décalage, ce qui « fonctionne bien pour des interfaces immersives et très visuelles qui ne défilent pas, à condition d’être sûr que les éléments interactifs ne seront pas bloqués par les commandes à droite » (7:10).² Les deux se mélangent aussi : « une image de fond ou un en-tête pleine largeur avec un contenu de premier plan défilant et rentré » (7:22), pour peu que « chaque élément interactif vive à l’intérieur de cette zone défilante, afin que rien ne soit recouvert » (7:28).² La note du guide sur la zone sûre ajoute le cas de Split View : le bord opposé peut porter les commandes de l’autre app, la zone sûre compte donc sur les deux bords.¹

La pliure : le déplacement

Image tirée de la diffusion de l’événement Apple du 9 septembre 2026, à 11 h 08 PT : les couches de l’écran. Partiellement pliée, la courbe qui traverse le centre est la « folding region » du guide.

Maria, Human Interface Designer au sein du système de design d’Apple, ouvre sur le principe : « Un bon design pour l’iPhone Duo repose sur le fait de savoir quand s’adapter » (2:25).³ Beaucoup d’interfaces « peuvent s’écouler naturellement autour des reserved regions » (2:30), et les autres recourent au déplacement, « qui ajuste le cadre des éléments existants en fonction de l’espace disponible, en gardant le contenu important visible, atteignable et non masqué, même lorsque l’appareil est partiellement plié » (2:39).³ Le motif a une portée, « d’un bouton à un conteneur entier ou à des parties plus larges d’une disposition » (3:03), assortie de deux règles : « Si un élément peut s’adapter de façon autonome, déplacez-le seul. Et lorsque des éléments fonctionnent ensemble, déplacez-les ensemble pour préserver leur relation » (3:17), ainsi que « prenez garde aux mouvements excessifs » (3:26), car « éloigner un élément de son point d’origine affaiblit leur relation visuelle » (3:29).³ Son exemple est un menu contextuel sur une photo sélectionnée : plutôt que de centrer le menu dans la région trailing, « les deux éléments se déplacent ensemble et s’alignent autour de la pliure » (3:39).³

L’exception est celle sur laquelle les designers s’appuieront le plus : « Le contenu à défilement continu, comme les articles, les fils, les documents et les listes, ne se déplace pas. Ces expériences s’adaptent déjà par le défilement ; les faire passer d’une région disponible à une autre risque donc d’interrompre la continuité » (3:46).³ Vince le dit dans l’autre sens : le système écarte les éléments interactifs de la courbure parce que « les boutons sont difficiles à toucher quand ils atterrissent en plein dans la pliure » (9:28), le comportement est intégré aux « feuilles, alertes, menus, boutons de barre d’outils, et plus encore » (9:40), et « le contenu défilant n’a pas besoin d’éviter cette région » (9:57).²

L’orientation de la pliure fixe les régions : en posture livre, elle court verticalement et les régions sont la gauche et la droite ; sur une table, ou en portrait, elle court horizontalement et les régions sont le haut et le bas.²³ La destination d’un élément déplacé dépend de la posture, et ce sont les raisons données par Maria qui sont utiles. En posture livre, « des éléments comme les alertes migrent du côté trailing. Cela les maintient plus près de l’endroit où elles apparaîtront lorsque l’appareil se ferme et que l’expérience se poursuit sur l’écran externe » (4:09).³ Calé sur une table, « la région du haut convient bien au contenu qui gagne à être visible à distance » (4:29), et « la région du bas convient bien aux commandes interactives » (4:39), où « des éléments tactiles comme les commandes de lecture peuvent migrer, offrant une surface plus stable pour le toucher » (4:43).³ Le Tech Talk consacré aux principes va dans le même sens : en portrait, partiellement plié, « les éléments interactifs migrent vers la moitié basse de l’écran, ce qui les rend plus faciles à atteindre tout en gardant l’appareil stable sur la surface » (2:33).² Quand plusieurs régions conviendraient, restez contextuel : un champ de recherche « tire parti de l’espace supplémentaire » (5:00) lorsque l’appareil est ouvert et, à mesure qu’il se plie, sa « largeur et sa position s’adaptent pour rester au-dessus de la vue qu’il interroge » (5:04).³

Le système fait l’essentiel du travail. « Les feuilles d’action, les alertes, les menus et les popovers sont autant d’expériences contextuelles légères qui peuvent apparaître au-dessus d’une reserved region » (5:23), et il « repositionne automatiquement les composants autour de la reserved region » (5:34).³ Une vue divisée « garde les deux colonnes visibles en ajustant leur largeur et en les plaçant dans un partage égal, 50/50 » (5:40).³ La grille, elle, vous appartient : dans la maquette Fitness de Maria, « je peux préserver les marges extérieures tout en augmentant l’espacement autour de la charnière, en gardant chaque conteneur dans sa région » (5:56).³ Son résumé de tous ces exemples tient lieu de cahier des charges : « nous déplaçons, redimensionnons ou réorganisons ce qui est déjà là. Gardez le contenu, les fonctionnalités et les dispositions accessibles, pour que les gens puissent profiter de l’expérience complète quelle que soit leur manière d’utiliser l’iPhone Duo » (6:04).³

Les reserved regions, la mécanique sous le déplacement

Maria introduit le terme dans le Tech Talk sur les dispositions adaptatives : « De nouvelles caractéristiques matérielles jouent elles aussi un rôle dans la forme de l’espace disponible. Cela comprend la charnière et les deux caméras réparties sur l’écran externe et l’écran interne. Nous appelons cela des reserved regions » (0:37), et elle conseille de les traiter « exactement comme toutes les autres zones auxquelles votre disposition s’adapte déjà » (0:53), son exemple étant les commandes de fenêtre sur iPadOS.³ Il y en a trois : la caméra externe, la caméra interne tant qu’elle est active, et la pliure (1:00, 1:18, 1:32).³ L’article côté développement reprend les définitions du guide pour chacune et consigne ma vérification, à savoir que le guide ne lie aucune documentation pour ces API ; cette section s’en tient donc à la mécanique.¹ Harry, ingénieur UI Frameworks, décrit l’API. « En SwiftUI, vous interrogez les reserved regions à l’aide d’un GeometryProxy issu d’un GeometryReader ou du modificateur onGeometryChange. Utilisez la nouvelle méthode reservedRegion sur le geometry proxy pour obtenir les régions disponibles dans votre vue. » (6:38) En UIKit, « vous utiliserez la méthode reservedRegion disponible sur UIView » (7:03), et « vous pouvez interroger la propriété frame d’une reserved region pour l’intégrer à votre propre disposition » (7:07).³

Il en existe deux sortes. La pliure « s’appuie sur une division reserved region, parce qu’elle divise une grande zone en plusieurs zones plus petites » (6:55), et elle « n’est active que lorsque quelqu’un a plié l’appareil. À plat, elle est inactive et sa largeur est nulle » (7:26).³ La caméra est une occlusion region : celles-ci « ne divisent pas les zones, elles les occultent » (7:54), et la région « est active quand la caméra est active, et inactive quand la caméra est inactive » (8:12).³ Les régions inactives s’interrogent avec l’option includeInactive, et la raison qu’a Harry de s’y intéresser tient à une décision de design : « dans les dispositions en grille, vous pourriez préférer un nombre pair de colonnes dès qu’une division region est présente, quel que soit son état d’activité » (7:41).³ Le guide reprend ce point comme une règle.¹ À 16 h 15 PT le jour de la keynote, le guide ne liait aucune page de documentation pour ces API, et la page développeur d’Apple date la bêta de Xcode 27.1 de « plus tard ce mois-ci ».¹⁵

Les arrangements : split ou overlay

Image tirée de la diffusion de l’événement Apple du 9 septembre 2026, à 11 h 00 PT : l’écran interne qu’Apple annonce 80 pour cent plus grand, la toile à laquelle les arrangements sont destinés.

La définition de Harry : « Un conteneur de disposition s’intercale entre ces conteneurs de navigation et de contenu. Ces conteneurs de disposition agencent deux vues selon un ensemble de règles. On les appelle des arrangements » (9:20).³ Les règles prennent des entrées, « la classe de taille horizontale et verticale de la vue, le rapport entre sa largeur et sa hauteur, et la présence éventuelle de division regions actives » (10:37), et produisent des sorties : « dois-je afficher cette vue, tout simplement » (10:52) et, si oui, « quel est son cadre » (10:54).³ Puis la date : « dans iOS 27.1, vous pouvez utiliser les arrangements fournis par le système dans vos propres apps » (11:02).³

En SwiftUI, une ArrangementView prend une vue primaire et une vue secondaire (11:25) et un style défini par arrangementViewStyle (11:57) ; en UIKit, un UIArrangementViewController prend des contrôleurs de vue primaire et secondaire (11:39).³ Le style split, qui est le style par défaut, « divise horizontalement lorsque la vue est plus large que haute » (12:13) et verticalement lorsqu’elle est plus haute ; il peut être restreint à un seul axe, et s’il ne peut pas diviser sur son axe principal, il « choisit de n’afficher qu’une seule vue » (12:49).³ Le style overlay « préfère positionner les contenus l’un au-dessus ou au-dessous de l’autre » (13:31), et lorsque l’appareil se plie, il « préfère positionner les vues primaire et secondaire côte à côte » (13:51), ce qu’une vue peut détecter via la propriété d’environnement overlayArrangementZIndex pour basculer entre une forme réduite et une forme développée (14:01).³

Choisir entre les deux constitue le conseil le plus clair du Tech Talk, et le guide le reprend. « Si vous mettez déjà en œuvre une disposition de type split dans certaines parties de votre app avec des composants comme un HStack ou un VStack, envisagez le split arrangement. Si vous mettez déjà en œuvre une disposition de type overlay avec des composants comme un ZStack, envisagez l’overlay arrangement » (14:44).³ En l’absence de motif existant, utilisez un overlay « lorsqu’il existe une relation claire de premier plan et d’arrière-plan entre vos vues » (15:10), comme des commandes par-dessus un contenu lisible dans Accessibility Reader, et un split « lorsqu’il s’agit davantage d’une relation principal-détail » (15:32), comme un podcast et sa transcription, où « il est important qu’aucun des deux ne soit jamais masqué » (15:43).³ Les deux limites, à savoir des conteneurs de navigation autour d’un arrangement plutôt qu’à l’intérieur, et pas d’arrangement dans une List ni une ScrollView, se trouvent à 16:15 et 16:26 dans le Tech Talk ; le guide n’énonce que la première, dans la phrase que cite l’article côté développement.¹³

L’écran interne : trois dispositions honnêtes

« Vous ne voulez pas une simple app iPhone étirée » (7:39).² Vince propose trois formes. Une vue divisée, qui fait apparaître « plusieurs niveaux de la hiérarchie de votre app en même temps » (7:46), à condition que cette hiérarchie « ne change pas entre l’écran externe et l’écran interne » (7:51), car les gens « ouvriront et fermeront peut-être souvent l’appareil pendant qu’ils utilisent votre app, elle doit donc être prévisible et cohérente dedans comme dehors » (7:59).² Une refonte du flux, à la manière de Music, où « une disposition empilée verticalement » (8:15) devient « une disposition à deux colonnes dès qu’il y a plus d’espace horizontal » (8:18).² Ou une barre d’onglets présentée « comme une barre latérale sur l’écran interne » (8:26), ce qui « fonctionne le mieux pour les apps à forte densité d’information, comme cet exemple tiré de Health » (8:33).² L’exemple Mail du guide relève de la vue divisée : une liste ou un message quand l’appareil est fermé, les deux côte à côte quand il est ouvert.¹

Les feuilles ont leurs propres règles. Sur l’écran externe, « les commandes des feuilles migrent elles aussi sur le côté » (8:46), ce que vous pouvez désactiver pour une feuille ne comportant qu’un seul bouton de barre d’outils ; dans ce cas, « les feuilles s’arrêtent juste avant la caméra frontale et la barre d’état se repositionne d’elle-même » (9:04).² Sur l’écran interne, les feuilles « utilisent des barres horizontales standard » (9:13) par défaut et, lorsque l’appareil est partiellement plié, elles « glissent sur le côté pour ne pas reposer dans la pliure » (9:20).² Le Tech Talk sur les barres ajoute l’exception liée au placement : les feuilles de l’écran interne sont « centrées par défaut, et leurs éléments restent horizontaux » (4:03), mais avec l’API preferredPlacement, « les feuilles placées à gauche restent sans barre verticale, tandis que celles placées à droite en reçoivent une » (4:11).⁴

L’audit

Le Tech Talk sur les barres et celui sur les dispositions adaptatives se terminent chacun par une liste d’audit ; les voici réunies. La liste finale du Tech Talk sur les barres (15:10) : construire avec les SDK les plus récents, car les barres verticales sont activées par le SDK (2:06) ; auditer les barres et leur ordre (4:41), et mettre à jour les éléments personnalisés pour qu’ils puissent se disposer verticalement ; et attribuer des priorités de visibilité « pour que le système puisse s’adapter » (15:26).⁴ Puis, dans le Tech Talk sur les dispositions adaptatives (16:40) : « commencez par auditer les dispositions centrées de votre app. Demandez-vous si vous pouvez en faire une disposition à deux colonnes, ou quel motif de déplacement a du sens dans ce cas d’usage » ; utiliser les conteneurs et les présentations standard pour obtenir le comportement gratuitement (16:49) ; recourir à ArrangementView pour les dispositions split ou overlay personnalisées ; et « identifier dans vos vues les commandes disposées manuellement les plus prioritaires et envisager d’adopter l’API ReservedRegions pour mettre en œuvre votre propre déplacement là où c’est nécessaire » (17:06).³

Ce que je compte en faire

Trois de mes apps sont des apps iPhone, et le guide les trie proprement. Ce tri est ma lecture, pas celle d’Apple.

• Get Bananas est une liste. Les listes ne se déplacent pas, la barre d’onglets et la barre d’outils migrent d’elles-mêmes sur le côté si je continue d’utiliser les conteneurs système, et la seule décision de design est la priorité de visibilité : l’action d’ajout d’un article est mon Compose, elle doit donc être la dernière à passer dans le débordement.
• Reps consigne chaque série sous forme de ligne comportant la charge, les répétitions et une action d’enregistrement, dans une grille pendant l’entraînement : c’est exactement l’exemple Fitness de Maria. La décision : en posture livre, une ligne à trois colonnes place la colonne du milieu sur la charnière, la grille passe donc à deux colonnes appariées. En posture table, l’action d’enregistrement se situe dans la moitié basse. Le compromis est une pression de plus par série, contre une cible qui n’atterrit jamais dans la pliure, là où, dit Vince, « les boutons sont difficiles à toucher » (9:28).² Le minuteur de repos reste en haut, la région dont Maria dit qu’elle convient bien au « contenu qui gagne à être visible à distance » (4:29).³
• Return trace des graphiques de santé, qui relèvent du contenu défilant. Là où un graphique et son sélecteur de plage cohabitent aujourd’hui dans une pile verticale, la règle de Harry fait correspondre cette pile à un split arrangement, qui garde les deux visibles pendant que l’appareil se plie ; le graphique lui-même ne devrait jamais se déplacer.

Points clés à retenir

Pour les designers : - Deux classes de taille, pas des postures : compact width à l’extérieur, regular width à l’intérieur.¹ Le seul supplément facultatif que suggèrent les designers d’Apple est une disposition pour la table qui conserve les mêmes commandes.² - Les icônes passent à la verticale, le texte reste horizontal ; le haut de la barre latérale accueille Back ou Close, puis Done ; les actions fréquentes et les éléments badgés débordent en dernier.⁴ - Le contenu défilant ne se déplace jamais ; les alertes, les menus, les feuilles et les commandes, si, et la destination suit l’usage : les alertes du côté trailing en posture livre et dans la région haute sur une table, les commandes tactiles dans la moitié basse.²³

Pour les ingénieurs design : - La pliure est une division region, active uniquement lorsque l’appareil est plié et de largeur nulle à plat ; la caméra interne est une occlusion region, active uniquement tant que la caméra l’est ; les deux s’interrogent depuis un GeometryProxy ou une UIView.³ - Les arrangements arrivent avec iOS 27.1 : une pile devient un split, un ZStack devient un overlay, et les conteneurs de navigation restent en dehors.³ - Utilisez les barres système issues des conteneurs de navigation, sans quoi la disposition verticale n’aura jamais lieu.⁴

Questions fréquentes

Ai-je besoin d’une disposition par posture ?

Non. Apple recommande de concevoir pour deux classes de taille, compact width sur l’écran externe et regular width sur l’écran interne, et d’éviter les largeurs fixes, les points de rupture ou les mesures liées à un écran.¹² Le seul supplément facultatif, issu du Tech Talk sur le design, est une disposition pour la posture table dotée des mêmes commandes et de la même hiérarchie.²

Quelles commandes restent horizontales sur l’iPhone Duo ?

Les éléments purement textuels, les éléments trop larges pour la barre latérale comme les contrôles segmentés, les éléments qui alternent entre symbole et texte comme Edit, les barres d’accessoires de clavier et, si vous le décidez, la barre entière dans une app d’une seule page au centre de gravité bas ou dans une feuille ne comportant qu’un unique élément de barre d’outils.²⁴

Qu’est-ce que le déplacement ?

C’est le motif d’Apple qui consiste à déplacer, redimensionner ou réorganiser des éléments existants pour qu’ils restent visibles et atteignables lorsque l’appareil est partiellement plié. Les alertes, les menus, les popovers, les feuilles et les boutons de barre d’outils en bénéficient via le système ; le contenu défilant en est exempté.²³

Quand les arrangement views et les API de reserved region seront-elles disponibles ?

Le Tech Talk sur les dispositions adaptatives indique que les arrangements fournis par le système sont utilisables dans vos apps à partir d’iOS 27.1, et la page développeur d’Apple situe la bêta de Xcode 27.1 plus tard en septembre. Le guide de design ne lie encore aucune documentation pour l’une ou l’autre de ces API.¹³⁵

Le contenu défilant doit-il éviter la pliure ?

Non. Le Tech Talk sur le design comme celui sur les dispositions adaptatives exemptent le contenu défilant ; il s’adapte déjà par le défilement.²³

Sources