Safe area et marges de contenu sur iPhone Duo : guide pour développeurs

Pendant des années, la safe area de l'iPhone a surtout été une affaire de haut et de bas : l'encoche ou la Dynamic Island en haut, l'indicateur d'accueil en bas. La safe area de l'iPhone Duo est différente. La navigation, les éléments de barre d'outils, les informations d'état et les Live Activities peuvent partager une même barre verticale le long du côté de l'écran : les insets gauche et droit sont donc souvent inégaux. Ce guide explique ce qui a changé, quelles API utiliser en SwiftUI et en UIKit, et comment vérifier votre mise en page avant de publier.

Tout ce qui suit provient des Tech Talks d'Apple consacrés à l'iPhone Duo, de la documentation d'Apple et des réponses sur les forums développeurs, ainsi que des publications du développeur iOS @sarunw. Nous n'avons pas testé ces API nous-mêmes sur un appareil réel. La plupart sont arrivées avec iOS 27.1 et Xcode 27.1 : certains détails peuvent donc encore changer d'une version à l'autre.

Pourquoi la safe area de l'iPhone Duo est-elle asymétrique ?

Sur l'iPhone Duo, de nombreuses commandes passent du haut et du bas de l'écran vers le côté. Le Tech Talk d'Apple « Design for iPhone Duo » le dit clairement : les commandes « sont placées le long du côté de l'appareil », et « la plupart des contenus ont besoin d'un décalage pour ne pas être masqués par les commandes ». La barre verticale est traitée en détail dans notre guide sur la barre d'outils verticale de l'iPhone Duo.

Ce décalage, c'est l'inset horizontal de la safe area. Dans Prepare your app for iPhone Duo, Apple indique que les safe areas sont « souvent asymétriques », en particulier sur l'iPhone Duo, où des boutons verticaux peuvent apparaître sur le côté gauche en paysage et en multitâche Split View. En Split View, le bord opposé peut aussi accueillir les commandes d'une autre app : les deux côtés comptent donc.

La barre verticale suit le matériel, et non le sens de lecture. Dans les langues qui s'écrivent de droite à gauche, elle reste du même côté de l'appareil : n'associez donc pas « le côté de la barre » à leading ou trailing. Lisez l'inset réel de chaque bord.

Comment gérer les insets horizontaux de la safe area ?

La règle d'Apple est courte : « Évitez de supposer que les insets des côtés opposés sont égaux. » Placez le contenu de premier plan dans la safe area, laissez les arrière-plans s'étendre en dessous et calculez les tailles à partir du rectangle réduit par les insets plutôt qu'à partir d'un seul côté.

SwiftUI place déjà le contenu dans la safe area par défaut. En UIKit, le Tech Talk d'Apple montre l'erreur courante et sa correction :

// À éviter : suppose que les insets gauche et droit sont égaux
let width = view.bounds.width - view.safeAreaInsets.left * 2

// Traiter chaque côté indépendamment
let width = view.bounds.inset(by: view.safeAreaInsets).width

La première ligne double l'inset gauche, ce qui est faux dès que la barre ne se trouve que d'un côté. La seconde ligne soustrait chaque bord séparément : elle fonctionne donc sur tout appareil et dans toute position.

Pour les arrière-plans, Apple recommande .ignoresSafeArea() en SwiftUI et, en UIKit, de dimensionner la vue d'arrière-plan selon view.bounds. Le Tech Talk « Design for iPhone Duo » suggère aussi une combinaison : « une image d'arrière-plan ou un en-tête pleine largeur avec un contenu de premier plan défilant et décalé », tant que chaque élément interactif reste dans la zone délimitée par les insets.

Dois-je rogner le contenu défilant sous la barre verticale ?

Non. Sur les forums développeurs, un ingénieur d'Apple a expliqué que le côté de la barre possède un inset de safe area qui « deviendra automatiquement un content inset de la scroll view », de sorte que tout le contenu reste accessible. Ne le rognez pas manuellement.

Que sont les marges asymétriques sur l'iPhone Duo ?

Les safe areas vous indiquent où se trouve l'interface système. Les marges vous indiquent à quelle distance du bord de son conteneur votre contenu doit se placer. Sur l'iPhone Duo, les deux peuvent varier selon le côté.

Selon @sarunw, l'iPhone Duo a « 20 points d'un côté, 0 à côté de la barre ». Cela correspond à la documentation d'Apple sur le nouveau guide de marges de conteneur, qui indique que les marges de mise en page système « vont de 16 à 20 points sur iPhone » et que sur l'iPhone Duo « la marge peut aussi être asymétrique, avec des valeurs différentes de chaque côté de l'appareil à côté d'une barre verticale ». Le Tech Talk d'Apple en explique la raison : les marges asymétriques permettent au contenu de premier plan de « se rapprocher des boutons verticaux et de la barre d'état, tout en préservant la marge du côté opposé ».

Les valeurs exactes en points proviennent de l'observation d'un développeur, et non d'une spécification d'Apple. Apple recommande de lire ou d'appliquer le guide « au lieu d'inscrire ces valeurs dans votre mise en page ».

Comment utiliser .contentMargins(for: .container) en SwiftUI ?

iOS 27.1 ajoute contentMargins(for:edges:alignment:), un modificateur qui applique à une vue un retrait défini par un ContentMarginGuide. SwiftUI fournit un guide, container, décrit comme « les marges du conteneur dans lequel se trouve la vue ». Le paramètre edges vaut par défaut tous les bords, et alignment est facultatif.

Voici l'exemple de la documentation d'Apple. Il aligne une grille sur les marges système horizontales :

NavigationStack {
    AlbumGrid()
        .contentMargins(for: .container, edges: .horizontal)
}

Les bords que vous excluez restent inchangés, même lorsque le guide a une valeur pour eux. Cela fait de .horizontal un bon choix pour l'iPhone Duo, où ce sont les marges horizontales qui varient.

Lorsqu'une vue ne remplit pas la taille proposée, alignment la positionne à l'intérieur des marges. La documentation d'Apple utilise un bouton de rédaction placé dans le coin inférieur de fin (bottom-trailing) des marges de son conteneur :

ZStack {
    MessageList()
    ComposeButton()
        .contentMargins(
            for: .container, alignment: .bottomTrailing)
}

Il s'agit d'un modificateur différent des anciens contentMargins(_:for:) et contentMargins(_:_:for:), qui définissent une longueur fixe pour un emplacement comme le contenu défilant. Le nouveau prend un guide au lieu d'un nombre : la valeur peut donc varier selon l'appareil, le conteneur et la position.

Lire les marges depuis GeometryProxy

Si vous disposez les vues manuellement, GeometryProxy gagne contentMargins(for:edges:), qui renvoie des EdgeInsets. Cette méthode s'ajoute à la propriété existante safeAreaInsets :

GeometryReader { proxy in
    let margins = proxy.contentMargins(for: .container, edges: .horizontal)
    let safeArea = proxy.safeAreaInsets
    // margins.leading et margins.trailing peuvent différer sur iPhone Duo.
    CustomCanvas(leading: margins.leading, trailing: margins.trailing)
}

CustomCanvas représente ici votre propre vue. L'essentiel est de lire les deux bords séparément au lieu de supposer une valeur unique.

Comment fonctionnent les marges de mise en page en UIKit sur l'iPhone Duo ?

UIKit dispose déjà de marges de mise en page : layoutMargins, directionalLayoutMargins et layoutMarginsGuide. Le Tech Talk d'Apple indique qu'elles sont asymétriques sur l'iPhone Duo, tout comme les safe areas. Ancrer le contenu au margins guide de la vue racine d'un view controller récupère ces valeurs sans effort supplémentaire.

Il y a un changement à connaître. Dans un fil de discussion sur des marges qui semblaient défectueuses, un ingénieur d'Apple a expliqué que « dans iOS 27.1, les marges de mise en page par défaut d'une UIView deviennent nulles sur l'iPhone Duo », et que ce changement s'étend aux autres appareils dans iOS 27.2. Un view controller donne toujours à sa vue racine les systemMinimumLayoutMargins. Pour en hériter dans une sous-vue, réglez preservesSuperviewLayoutMargins sur true.

NSLayoutConstraint.activate([
    titleLabel.leadingAnchor.constraint(equalTo: view.layoutMarginsGuide.leadingAnchor),
    titleLabel.trailingAnchor.constraint(equalTo: view.layoutMarginsGuide.trailingAnchor)
])

// Une sous-vue personnalisée qui doit hériter des marges du view controller
cardView.preservesSuperviewLayoutMargins = true

Pour le contenu de cellules personnalisées, le même ingénieur a suggéré de lire les directionalLayoutMargins recommandées depuis UIListContentConfiguration.cell() plutôt que de s'appuyer sur la valeur par défaut d'UIView. Si vos cellules perdent soudain leur espacement intérieur sur l'iPhone Duo, vérifiez d'abord ce point.

Quel est l'effet de la barre verticale sur les apps compilées avec d'anciens SDK ?

La part de l'écran utilisée par votre app dépend du SDK avec lequel vous la compilez. Apple décrit trois étapes :

Les anciennes apps continuent de fonctionner, mais elles ne profitent pas de l'expérience complète. C'est en compilant avec le SDK iOS 27.1 que les insets et marges asymétriques commencent à compter, car votre contenu atteint alors le bord à côté de la barre. Apple précise aussi que l'iPhone Duo respecte UIRequiresFullScreen, mais que votre app est tout de même redimensionnée lorsque l'appareil est ouvert ou fermé.

La caméra est un cas à part. Sur les forums développeurs, Apple suggère d'interroger les régions d'occlusion plutôt que d'ignorer toute la safe area lorsque vous voulez un contenu pleine largeur. Notre guide sur les régions réservées et le pli présente ces API.

Que vérifier avant de publier ?

Les recommandations de design d'Apple consistent à « construire vos mises en page avec les marges de mise en page et les insets horizontaux de la safe area » et à éviter « les largeurs fixes, les points de rupture ou toute mesure liée à un écran précis ». Cela vous donne une courte checklist :

1. Compilez avec Xcode 27.1 et le SDK iOS 27.1, puis exécutez votre app sur le simulateur iPhone Duo dans toutes les positions : fermé, ouvert, portrait et paysage.
2. Recherchez dans votre code safeAreaInsets.left * 2 et les calculs similaires. Remplacez-les par bounds.inset(by:) ou par des valeurs propres à chaque bord.
3. Ne codez pas en dur 16 ou 20 points. Appliquez .contentMargins(for: .container, edges: .horizontal) en SwiftUI ou ancrez-vous à layoutMarginsGuide en UIKit.
4. Repérez les vues et cellules UIKit qui ont perdu leur espacement intérieur parce que les marges par défaut d'UIView sont désormais nulles sur l'iPhone Duo.
5. Gardez chaque bouton et champ de texte dans la safe area. Ne laissez que les arrière-plans et les images décoratives s'étendre d'un bord à l'autre.
6. Testez le multitâche Split View, où les commandes d'une autre app peuvent se trouver sur le bord opposé.
7. Testez une langue qui s'écrit de droite à gauche. La barre reste du même côté de l'appareil.

Si vous adaptez toute une app, notre checklist de préparation pour l'iPhone Duo place ces points aux côtés des size classes, des feuilles et de la charnière.

À retenir

• Sur l'iPhone Duo, les commandes peuvent se trouver sur le côté : les insets horizontaux de la safe area comptent donc autant que ceux du haut et du bas.
• Ne supposez jamais que les insets gauche et droit sont identiques. Utilisez bounds.inset(by: safeAreaInsets) ou lisez chaque bord.
• iOS 27.1 ajoute .contentMargins(for: .container, edges: .horizontal) et GeometryProxy.contentMargins(for:edges:) pour des marges système qui peuvent être inégales à côté d'une barre verticale.
• En UIKit, ancrez-vous à layoutMarginsGuide, et notez que les marges par défaut d'UIView sont nulles sur l'iPhone Duo dans iOS 27.1.
• Compilez avec le SDK iOS 27.1 pour atteindre le bord de l'écran, puis testez chaque position, Split View et les mises en page de droite à gauche.

Ensuite, découvrez comment le système déplace les barres sur le côté dans notre guide de la barre d'outils verticale, ou découvrez des apps qui exploitent déjà pleinement l'écran sur Built for the Fold.