UIKit — qu'est-ce que c'est, concepts clés et architecture

Qu'est-ce que UIKit ?

UIKit est un framework d'Apple qui fournit des classes pour créer et gérer des interfaces utilisateur sur iOS, iPadOS et macOS (via Mac Catalyst). Il fonctionne au-dessus de Core Animation, Core Graphics et Quartz Core, en abstraisant le rendu de bas niveau en objets de haut niveau — boutons, étiquettes, images et conteneurs. UIKit a fait ses débuts avec iPhone OS 1 en 2007 et reste le framework principal pour le développement iOS aux côtés de SwiftUI.

Le framework suit une approche impérative : le développeur crée des instances des classes UIButton, UILabel, UIImageView, définit leurs propriétés (couleur, police, position) et les ajoute à la hiérarchie des vues via addSubview. Chaque modification de l'interface est effectuée explicitement — aucune mise à jour magique en coulisses. Cela distingue UIKit des frameworks déclaratifs comme SwiftUI, où la description de l'état redessine automatiquement l'interface.

Classes principales d'UIKit

Le framework comprend plusieurs catégories de classes. UIView est l'élément de base dont héritent tous les composants visuels. UIWindow est le conteneur de niveau supérieur à travers lequel les vues sont affichées à l'écran. UIViewController gère un ensemble de vues et répond aux rotations d'écran, à l'apparition du clavier et aux notifications système. UIApplication est le point d'entrée qui traite les événements tactiles et les pressions de boutons.

Pour le texte, on utilise UILabel (texte statique), UITextField (saisie monoligne), UITextView (saisie multiligne). Pour les boutons — UIButton, y compris les boutons système, personnalisés et avec l'iconographie SF Symbols. Pour la navigation — UINavigationController, UITabBarController et UISplitViewController. Au total, UIKit compte plus de 200 classes publiques.

Architecture d'UIKit : couches et hiérarchie des vues

L'architecture d'UIKit est construite sur des couches : chaque couche est responsable d'un aspect de l'affichage. Au niveau le plus bas se trouve Core Graphics — le moteur de rendu des chemins, du texte et des images. Au-dessus se trouve Core Animation, qui gère la composition des couches (CALayer) et les animations entre les états. UIKit construit une API orientée objet par-dessus : UIView, UIViewController et UIResponder.

Chaque application a une hiérarchie de vues — un arbre dont la racine est UIWindow. En dessous se trouve le UIViewController racine, sa vue, et les sous-vues imbriquées à l'intérieur. Les événements tactiles se propagent le long de la chaîne de réponse : de la vue la plus imbriquée à ses parents et jusqu'à UIApplication. Si aucun objet ne traite le toucher, il est ignoré.

UIView et CALayer

Chaque UIView contient une CALayer qui gère le rendu des pixels à l'écran. La vue gère les touches et l'accessibilité ; la couche gère les graphiques — ombre, cornerRadius, bordure, transformation. Cette séparation permet de décharger les graphiques lourds sur un thread séparé (serveur de rendu) sans bloquer le thread principal. Apple recommande de travailler directement avec CALayer s'il y a plus de 200 vues à l'écran — cela réduit la charge du CPU.

Chaîne de réponse en détail

La chaîne de réponse commence par l'objet qui reçoit en premier un événement tactile. S'il ne traite pas l'événement (la méthode touchesBegan n'est pas surchargée), l'événement passe au répondeur suivant dans la chaîne : next, superview, next responder, UIViewController, UIWindow, UIApplication, App Delegate. Cela permet d'intercepter les gestes globaux et les événements clavier au niveau de la scène sans ajouter de gestionnaire à chaque vue.

Cycle de vie d'UIViewController

Chaque UIViewController passe par une séquence d'événements strictement définie. Le cycle de vie comprend les phases : initialisation, chargement de la vue, apparition à l'écran, mise à jour de la mise en page lors de la rotation, masquage, sortie de l'écran et libération de la mémoire. Le développeur surcharge les méthodes correspondantes pour exécuter du code personnalisé à chaque étape.

class ProfileViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        setupUI()
    }

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        loadUserProfile()
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        clearCache()
    }
}

Dans viewDidLoad, l'interface est configurée — les sous-vues sont créées, les contraintes sont définies, les délégués sont souscrits. Dans viewWillAppear, des opérations sont effectuées avant l'affichage : chargement de données fraîches depuis le réseau, mise à jour des valeurs. viewDidDisappear est l'endroit pour se désabonner des notifications et nettoyer les données temporaires. L'appel à super est obligatoire dans toutes les surcharges, sinon la chaîne d'événements se brise.

Gestion de la mémoire et viewDidUnload

Dans les anciennes versions d'iOS, il existait la méthode viewDidUnload, appelée en cas de manque de mémoire. Depuis iOS 6, la méthode a été supprimée — UIKit décharge désormais automatiquement les vues des contrôleurs lorsqu'elles ne sont pas visibles. Le développeur a seulement besoin de déclarer toutes les références aux vues comme weak pour que l'ARC puisse libérer correctement la mémoire lors de la réception d'un avertissement système.

Transitions entre contrôleurs

UIKit prend en charge deux types de transitions : segue (via Storyboard) et la navigation programmatique via UINavigationController. Une transition programmatique ressemble à ceci : navigationController?.pushViewController(detailVC, animated: true). Dans ce cas, le cycle de vie de detailVC se déroule normalement — viewDidLoad est appelé une fois, viewWillAppear est appelé à chaque apparition.

Auto Layout et mise en page adaptative

Auto Layout est un système de positionnement basé sur des relations mathématiques (contraintes). Au lieu de coordonnées X et Y codées en dur, le développeur décrit des règles : « le bouton est à droite de l'étiquette avec un espacement de 16pt » ou « la vue s'étend sur la largeur de l'écran avec des marges de 20pt à gauche et à droite. » Le système résout le système d'équations résultant à l'exécution, adaptant l'interface à n'importe quelle taille d'écran.

Les contraintes peuvent être définies dans Interface Builder (par glisser-déposer) ou programmatiquement en Swift. Chaque contrainte est une instance de la classe NSLayoutConstraint avec des paramètres : firstItem, firstAttribute, relation, secondItem, secondAttribute, multiplier, constant. Les contraintes sont activées via isActive = true ou en masse via NSLayoutConstraint.activate().

Safe Area et Layout Margins

Avec l'introduction de l'iPhone X (2017), Apple a introduit la Safe Area — la zone de l'écran exempte du notch, des coins arrondis et de l'indicateur de la barre d'accueil. Les contraintes doivent être attachées à view.safeAreaLayoutGuide, pas à view. Les Layout Margins ajoutent un remplissage interne à la vue, par défaut 8pt ou 16pt selon le contexte. L'utilisation de safeAreaLayoutGuide garantit un affichage correct sur toutes les générations d'iPhone et d'iPad.

Animation des contraintes

Auto Layout prend en charge l'animation en modifiant les constantes des contraintes. Il suffit de mettre à jour la constant d'une contrainte et d'appeler UIView.animate avec layoutIfNeeded à l'intérieur du bloc d'animation. Le système recalcule en douceur la position de toutes les vues dans la hiérarchie. Cette technique est utilisée pour les blocs extensibles, les panneaux de clavier adaptatifs et les changements d'orientation de l'écran.

Travailler avec les tableaux et les collections

UITableView et UICollectionView sont deux outils puissants d'UIKit pour afficher des listes et des grilles. UITableView convient aux listes verticales à une colonne (chat, paramètres, fil d'actualités). UICollectionView est pour les grilles, les listes horizontales, les carrousels et les mises en page personnalisées (galerie, produits, calendrier). Les deux classes utilisent le modèle de délégation pour séparer les données de leur apparence.

La source de données est le protocole UITableViewDataSource avec les méthodes obligatoires numberOfRowsInSection et cellForRowAt. Le UITableViewDelegate gère les tapotements sur les cellules, les hauteurs de ligne et les événements de défilement. Le mécanisme d'identifiant de réutilisation réutilise les cellules qui ont disparu de l'écran, ce qui est crucial pour les performances sur les grandes listes.

class ContactsViewController: UITableViewController {

    private let contacts = ["Anna", "Boris", "Victor"]

    override func viewDidLoad() {
        super.viewDidLoad()
        tableView.register(UITableViewCell.self,
                           forCellReuseIdentifier: "cell")
    }

    override func tableView(_ tableView: UITableView,
                          numberOfRowsInSection section: Int) -> Int {
        return contacts.count
    }

    override func tableView(_ tableView: UITableView,
                          cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "cell",
                                                 for: indexPath)
        var content = cell.defaultContentConfiguration()
        content.text = contacts[indexPath.row]
        cell.contentConfiguration = content
        return cell
    }
}

L'exemple montre un contrôleur minimal pour afficher un tableau de chaînes. La cellule est configurée via UIListContentConfiguration — une API moderne (iOS 14+) qui a remplacé les obsolètes textLabel et detailTextLabel. L'enregistrement de la classe de cellule dans viewDidLoad est obligatoire, sinon l'application plante avec une exception à l'exécution.

UICollectionView et Compositional Layout

À partir d'iOS 13, Apple recommande UICollectionViewCompositionalLayout pour construire des mises en page complexes. Le développeur décrit la section, le groupe, l'élément et leurs tailles de manière déclarative — obtenant une grille avec une géométrie arbitraire : une bande, une grille 2x2, un carrousel ou un ornement. Compositional Layout a remplacé l'obsolète UICollectionViewFlowLayout pour tous les nouveaux projets. Combiné avec DiffableDataSource, la mise à jour d'une collection se réduit à un seul appel apply(snapshot), et les animations de changement sont effectuées automatiquement.

Exemples de code Swift

Vous trouverez ci-dessous deux exemples pratiques d'utilisation d'UIKit dans des tâches réelles : créer une vue personnalisée avec ombre et coins arrondis, et gérer un geste de balayage pour supprimer un élément d'une liste.

extension UIView {
    func applyCardStyle() {
        layer.cornerRadius = 12
        layer.shadowOpacity = 0.15
        layer.shadowRadius = 8
        layer.shadowOffset = CGSize(width: 0, height: 2)
        layer.masksToBounds = false
    }
}

@objc private func handleSwipe(_ gesture: UISwipeGestureRecognizer) {
    guard let swipedView = gesture.view else { return }
    UIView.animate(withDuration: 0.3) {
        swipedView.alpha = 0
        swipedView.transform = CGAffineTransform(translationX: 300, y: 0)
    } completion: { _ in
        swipedView.removeFromSuperview()
    }
}

L'extension applyCardStyle ajoute une ombre et des coins arrondis à n'importe quelle vue — utile pour les cartes produit, les profils et les notifications. La méthode handleSwipe avec animation supprime un élément lorsque l'utilisateur balaye vers la droite dessus. Le gestionnaire est ajouté à la vue via addGestureRecognizer avec une configuration UISwipeGestureRecognizer(direction: .right). Définir masksToBounds = false est important pour éviter que l'ombre ne soit coupée par les limites de la vue.

Pour des interfaces plus complexes, utilisez UIStackView — un conteneur qui distribue automatiquement les vues imbriquées horizontalement ou verticalement. Stack View simplifie la mise en page : il n'est pas nécessaire de définir des contraintes pour chaque élément, une seule contrainte pour la pile elle-même suffit.