Auto Layout : qu'est-ce que c'est, mise en page adaptative des interfaces iOS

Qu'est-ce qu'Auto Layout ?

Auto Layout est le système de mise en page adaptative d'Apple qui utilise des contraintes mathématiques (constraints) pour positionner les éléments d'interface. Contrairement à la mise en page basée sur les frames (frame-based layout), où chaque élément a des coordonnées fixes x, y, width, height, Auto Layout décrit des relations entre les éléments : « le bouton est à 8pt du bord droit du parent » ou « la largeur du champ de texte est égale à la moitié de la largeur de l'écran ». Le mécanisme est basé sur l'algorithme Cassowary, développé à l'University of Washington (Greg J. Badros, 1999) et implémenté par Apple dans iOS 6. Cassowary résout un système d'inégalités linéaires avec des priorités — Required (1000), Default High (750), Default Low (250) — permettant de gérer les conflits de contraintes. Auto Layout prend en charge trois types de taille : intrinsic (taille naturelle de l'élément déterminée par le contenu), explicit (contrainte explicitement définie) et compressible/stretchable (mode élastique via Content Hugging Priority et Compression Resistance Priority).

Intrinsic Content Size et Priorités

Chaque élément d'interface dans Auto Layout a un Intrinsic Content Size — une taille naturelle déterminée par son contenu. Pour UILabel, cela dépend du texte et de la police, pour UIImageView — des dimensions de l'image. Content Hugging Priority (résistance à l'étirement) et Compression Resistance Priority (résistance à la compression) contrôlent le comportement de l'élément lorsque l'espace disponible change. Valeurs standard : 251 pour hugging et 749 pour compression resistance. Si deux éléments se disputent l'espace, la priorité détermine lequel s'étire en premier. Comprendre ces priorités est la clé pour résoudre Ambiguous Layout (disposition ambiguë), qu'Xcode met en évidence dans le débogueur.

Anatomie d'une Contrainte

Une contrainte est décrite par l'équation : view1.attribute = multiplier × view2.attribute + constant. Les attributs incluent leading, trailing, top, bottom, centerX, centerY, width, height, firstBaseline, lastBaseline. Multiplier est utilisé pour les relations proportionnelles (largeur de view1 = 0,5 × largeur de superview). Constant définit un décalage fixe (leading = superview.leading + 16). Les outils d'Interface Builder permettent de créer visuellement des contraintes par Ctrl-glisser, mais les mises en page complexes nécessitent une création programmatique via NSLayoutConstraint ou VFL (Visual Format Language), qu'Apple recommande de remplacer par NSLayoutConstraint depuis iOS 9.

Comment fonctionnent les Constraints dans iOS

Le système de contraintes est résolu comme un problème de programmation linéaire : l'algorithme Cassowary trouve la disposition optimale de tous les éléments qui satisfait toutes les contraintes en tenant compte de leurs priorités. Si les contraintes se contredisent, une Unsatisfiable Layout se produit — une exception qu'Xcode journalise avec une description détaillée du conflit. Si les contraintes sont insuffisantes pour déterminer la position d'au moins un élément, un Ambiguous Layout se produit — les éléments s'affichent à des positions arbitraires. Apple recommande un ensemble minimal : pour chaque élément, position (x, y) et size (width, height) doivent être définis — explicitement ou via intrinsic content size. Les contraintes peuvent être de première classe : l'élément leader (par exemple, superview) et le suiveur (vue enfant) créent une hiérarchie.

Algorithme Cassowary et priorités

Cassowary utilise la méthode Sequential Quadratic Programming pour résoudre des systèmes d'inégalités linéaires. Chaque contrainte a une priorité de 1 à 1000. Required (1000) est une contrainte obligatoire ; si elle ne peut pas être respectée, l'application plante avec NSConstraintException. Default High (750) est recommandée ; Default Low (250) est la moins importante. En cas de conflit, Cassowary relâche les contraintes de priorité inférieure. Par exemple, si deux éléments nécessitent une largeur fixe mais que l'écran est trop étroit, la contrainte de priorité inférieure est relâchée. Dans Xcode Debug View Hierarchy (outil de débogage disponible depuis Xcode 6) ne met en évidence que les problèmes avec les contraintes Required — les autres sont traités sans erreur.

UIStackView : gestion automatique des Constraints

UIStackView est un conteneur présenté dans iOS 9 (2015) qui crée et gère automatiquement les contraintes pour les arrangedSubviews imbriquées. UIStackView prend en charge deux axes : horizontal et vertical. Les paramètres de distribution déterminent la répartition de l'espace : fill (remplissage proportionnel selon hugging priority), fillEqually (tailles égales), fillProportionally (proportionnel à l'intrinsic content size), equalSpacing (espacement égal), equalCentering (distances égales entre centres). Alignment définit l'alignement transversal : fill, leading, center, trailing (pour horizontal) ou fill, top, center, bottom (pour vertical). UIStackView gère automatiquement l'espacement, l'alignement de la ligne de base et l'adaptation au Dynamic Type.

import UIKit

class StackViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let stack = UIStackView()
        stack.axis = NSLayoutConstraint.Axis.vertical
        stack.distribution = .fillEqually
        stack.spacing = 8
        stack.translatesAutoresizingMaskIntoConstraints = false
        
        let label = UILabel()
        label.text = "Auto Layout Guide"
        label.font = UIFont.preferredFont(forTextStyle: .headline)
        
        let button = UIButton(type: .system)
        button.setTitle("Apply", for: .normal)
        
        stack.addArrangedSubview(label)
        stack.addArrangedSubview(button)
        view.addSubview(stack)
        
        NSLayoutConstraint.activate([
            stack.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            stack.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            stack.leadingAnchor.constraint(greaterThanOrEqualTo: view.leadingAnchor, constant: 16),
            stack.trailingAnchor.constraint(lessThanOrEqualTo: view.trailingAnchor, constant: -16)
        ])
    }
}

Le code crée un UIStackView vertical avec deux éléments (UILabel et UIButton), répartis uniformément (fillEqually) avec un espacement de 8pt. La pile est centrée sur l'écran avec des marges d'au moins 16pt des bords. translatesAutoresizingMaskIntoConstraints = false est obligatoire lors de la création programmatique de contraintes — sans cela, Auto Layout ne fonctionne pas. Chez IT Sectr, UIStackView est utilisé dans 80% des écrans de projets iOS pour construire des formulaires adaptatifs, des listes de paramètres et des cartes.

Piles de vues imbriquées

Les UIStackView peuvent être imbriqués : une pile horizontale dans une pile verticale est un modèle standard pour les mises en page complexes. La pile externe gère les lignes, la pile interne gère les colonnes dans chaque ligne. La combinaison d'axis, alignment et distribution à chaque niveau offre une flexibilité pratiquement illimitée sans une seule contrainte manuelle. Apple recommande UIStackView comme outil de mise en page principal dans UIKit, recourant à NSLayoutConstraint manuel uniquement pour les cas non couverts par les piles : vues superposées, positionnement précis des pixels, animation personnalisée des bounds.

NSLayoutConstraint : création programmatique de contraintes

NSLayoutConstraint est une API programmatique pour créer des contraintes individuelles dans le code. Chaque contrainte est créée via un initialiseur avec des paramètres : item, attribute, relatedBy, toItem, attribute, multiplier, constant. Depuis iOS 9, Apple a introduit l'Anchor API — une syntaxe plus lisible via les propriétés view.leadingAnchor, view.trailingAnchor, view.topAnchor, view.bottomAnchor, view.centerXAnchor, view.centerYAnchor, view.widthAnchor, view.heightAnchor. L'Anchor API définit automatiquement relatedBy = .equal et utilise First Item/Second Item des Anchors, réduisant le code de 40% par rapport au NSLayoutConstraint classique.

import UIKit

class ConstraintViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let childView = UIView()
        childView.backgroundColor = .systemBlue
        childView.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(childView)
        
        NSLayoutConstraint.activate([
            childView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 24),
            childView.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16),
            childView.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -16),
            childView.heightAnchor.constraint(equalToConstant: 120),
            childView.bottomAnchor.constraint(lessThanOrEqualTo: view.bottomAnchor, constant: -24)
        ])
    }
}

Le code positionne childView avec des marges depuis safeAreaLayoutGuide (top) et les bords de l'écran (leading/trailing). lessThanOrEqualTo pour bottom garantit que la vue ne dépasse pas la limite inférieure. L'Anchor API lève une exception au moment de la compilation si les ancres sont incompatibles (par exemple, leadingAnchor mélangé avec rightAnchor), empêchant les erreurs d'exécution. Apple recommande l'Anchor API comme standard pour l'Auto Layout programmatique depuis iOS 9.

Safe Area et Layout Margins dans Auto Layout

Safe Area est la zone de l'écran non recouverte par les éléments système : Dynamic Island, Notch, Status Bar, Home Indicator, coins arrondis. Dans iOS 11, Apple a remplacé topLayoutGuide/bottomLayoutGuide par safeAreaLayoutGuide, qui s'adapte automatiquement à l'orientation de l'appareil et à la présence de découpe d'écran. Les Layout Margins sont les marges internes par défaut de la vue (16pt sur iOS, 20pt sur iPadOS). Pour UILayoutGuide, vous pouvez définir des directionalLayoutMargins personnalisés en tenant compte de la localisation RIGHT-TO-LEFT. Auto Layout respecte automatiquement la safe area lors de l'utilisation de safeAreaLayoutGuide dans les ancres.

Adaptation pour Dynamic Island et Notch

Sur les appareils avec Dynamic Island (iPhone 14 Pro et ultérieurs) et Notch (iPhone X–13), la Safe Area exclut 44pt en haut en portrait (59pt avec Dynamic Island à l'état actif). Home Indicator ajoute 34pt en bas. Pour une adaptation correcte, toutes les contraintes supérieures doivent être liées à safeAreaLayoutGuide.topAnchor, pas à view.topAnchor. Les contraintes inférieures doivent être liées à safeAreaLayoutGuide.bottomAnchor ou view.bottomAnchor avec une marge pour Home Indicator. Chez IT Sectr, nous testons tous les écrans sur les simulateurs iPhone SE (2022), iPhone 14 Pro Max et iPad Pro 12.9″ — trois appareils couvrant toutes les variations de safe area.

Erreurs fréquentes d'Auto Layout

Les erreurs les plus fréquentes lors de l'utilisation d'Auto Layout : oubli de translatesAutoresizingMaskIntoConstraints = false, contraintes Required en conflit (priorité 1000), Ambiguous Layout (contraintes insuffisantes pour déterminer la position), Content Hugging Priority incorrect pour UILabel multi-lignes et mélange des ancres leading/trailing avec left/right. Xcode 15+ affiche les problèmes de mise en page dans le Runtime Issue Navigator et propose des corrections automatiques. Pour les mises en page complexes, utilisez Debug View Hierarchy : les marqueurs jaunes indiquent un ambiguous layout, les rouges indiquent unsatisfiable.