ViewController Lifecycle dans iOS : concepts clés, étapes et méthodes

Qu’est-ce que le ViewController Lifecycle

ViewController Lifecycle est un ensemble de méthodes que UIViewController reçoit de UIKit tout au long de son existence. Chaque écran dans une app iOS passe séquentiellement par les étapes de création, chargement de la View, apparition à l’écran, disparition et libération de mémoire. UIKit appelle automatiquement les méthodes correspondantes à chaque étape, et le développeur les remplace pour ajouter sa propre logique.

L’architecture UIViewController est fondamentale pour UIKit et reste pertinente même à l’ère de SwiftUI — de nombreux projets utilisent encore l’approche classique ou une architecture hybride. Comprendre le Lifecycle permet de prévoir quand les subviews sont disponibles, quand il est sûr de modifier la mise en page et quelles opérations effectuer lors de l’apparition ou de la disparition de l’écran.

Chaque méthode du cycle de vie a un but spécifique : certaines sont appelées une seule fois pendant toute la durée de vie du contrôleur, d’autres — à chaque apparition ou disparition. Mélanger la logique entre les méthodes conduit à des bogues difficiles à trouver : fuites mémoire, mises à jour incorrectes des données et requêtes réseau inutiles.

Cycle complet des méthodes de UIViewController

Six méthodes forment le cycle de vie complet de UIViewController. L’ordre d’appel est fixe et ne dépend pas de la méthode de navigation — push, present ou unwind segue suivent tous le même calendrier.

loadView — création de la View racine

loadView est la première méthode du cycle, appelée lorsque la View du contrôleur n’existe pas encore. Si vous utilisez Storyboard, UIKit charge automatiquement la View à partir du fichier xib. Lors de la création programmatique de l’interface, vous remplacez cette méthode en assignant la View racine manuellement. Dans la plupart des projets, loadView n’est pas touché — le travail se fait dans viewDidLoad.

Remplacer loadView n’est nécessaire que dans des cas spécifiques : lorsque toute l’interface est créée en code sans Storyboard, ou lorsque la View racine doit être d’une classe non standard. Apple recommande de ne pas appeler super.loadView lors du remplacement — vous assumez l’entière responsabilité de la création de la View.

override func loadView() {
    view = UIView()
    view.backgroundColor = .white
}

viewDidLoad — initialisation unique

viewDidLoad est la méthode la plus utilisée du cycle. Elle est appelée une fois après que la View est chargée en mémoire mais pas encore affichée à l’écran. Ici, vous configurez les subviews, remplissez les tableaux avec des données, enregistrez les cellules et vous abonnez aux notifications qui durent toute la vie du contrôleur.

Une caractéristique importante : viewDidLoad n’est pas rappelé lors de la réaffichage de l’écran. Si vous devez mettre à jour les données chaque fois que l’écran apparaît — utilisez viewWillAppear. Placez uniquement les opérations uniques dans viewDidLoad qui sont nécessaires à la configuration de base.

viewWillAppear — préparation avant l’affichage

viewWillAppear est appelé chaque fois juste avant que la View ne devienne visible pour l’utilisateur. Cette méthode reçoit un paramètre animated indiquant si l’apparition est animée. Ici, vous mettez à jour les données, rechargez les tableaux, configurez la NavigationBar et masquez ou affichez des éléments selon l’état de l’application.

Utilisez viewWillAppear pour la synchronisation d’état entre les écrans : si l’utilisateur a pu modifier des données sur l’écran précédent, cette méthode est l’endroit approprié pour mettre à jour l’interface. Chaque appel à viewWillAppear précède l’apparition de l’écran, même lors du retour d’un contrôleur enfant.

viewDidAppear — écran complètement visible

viewDidAppear notifie que la View est complètement apparue à l’écran et que toutes les animations de transition sont terminées. À ce stade, l’écran est prêt pour l’interaction — l’utilisateur voit l’interface complète et peut interagir avec elle. Cette méthode convient pour lancer des animations qui doivent commencer après l’apparition, démarrer des minuteries et suivre les impressions d’analyse.

Contrairement à viewWillAppear, viewDidAppear garantit que l’écran est non seulement visible mais aussi entièrement rendu. Si vous lancez une animation dans viewWillAppear, certaines images peuvent être sautées car UIKit n’a pas encore terminé la transition. Pour des animations fluides, utilisez viewDidAppear.

viewWillDisappear — préparation au masquage

viewWillDisappear est appelé avant la disparition de la View de l’écran — lors du passage à un autre contrôleur, de la fermeture d’une fenêtre modale ou de la mise en veille de l’app. C’est l’endroit approprié pour sauvegarder l’état, se désabonner des notifications, arrêter les processus actifs et libérer les ressources qui ne sont pas nécessaires lorsque l’écran n’est pas visible.

Il est important de se rappeler : viewWillDisappear ne garantit pas que la View disparaîtra finalement — le geste peut être annulé. Par conséquent, sauvegardez également les données critiques dans viewDidDisappear, qui n’est appelé qu’après la disparition réelle.

viewDidDisappear — écran masqué

viewDidDisappear termine le cycle d’apparition et de disparition. Il est appelé après que la View est déjà masquée de l’écran. Dans cette méthode, les animations sont enfin arrêtées, les objets temporaires sont supprimés et la sauvegarde des données initiée dans viewWillDisappear est confirmée.

Cette méthode précède également le deinit du contrôleur — si votre UIViewController est détruit, viewDidDisappear sera la dernière méthode du Lifecycle avant l’appel de deinit. Utilisez-la pour le nettoyage final qui doit avoir lieu avant la destruction de l’objet.

Quand chaque méthode est appelée

La séquence des appels dépend de la façon dont l’écran apparaît : pour la première fois, lors du retour, ou lors d’une présentation modale. Considérons trois scénarios principaux du point de vue de UIKit.

Ordre lors de la première ouverture

Lorsqu’un écran apparaît pour la première fois, UIKit parcourt le cycle complet de création : loadView est appelé, puis viewDidLoad, après quoi l’animation d’apparition commence. Pendant l’animation, viewWillAppear est appelé, et après la fin — viewDidAppear. C’est le seul scénario où toutes les méthodes de loadView à viewDidAppear se déclenchent séquentiellement.

override func viewDidLoad() {
    super.viewDidLoad()
    print("viewDidLoad — View chargée en mémoire")
}

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    print("viewWillAppear — Va bientôt apparaître")
}

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    print("viewDidAppear — Écran complètement visible")
}

Ordre lors du retour

Lorsque l’utilisateur revient à un écran précédent, UIKit n’appelle pas viewDidLoad à nouveau — la View est déjà chargée en mémoire. Au lieu de cela, seuls viewWillAppear et viewDidAppear sont appelés sur l’écran de retour, et sur l’écran actuel — viewWillDisappear et viewDidDisappear. loadView et viewDidLoad sont sautés puisque l’écran existe déjà dans la pile de navigation.

Cas particuliers avec present et dismiss

La présentation modale suit les mêmes règles : le nouveau contrôleur parcourt le cycle complet lors de la première apparition, tandis que le contrôleur actuel reçoit viewWillDisappear et viewDidDisappear. Lors du dismiss, l’ordre est inversé : le contrôleur de retour obtient à nouveau viewWillAppear et viewDidAppear, tandis que celui qui est rejeté reçoit les méthodes finales. Ce comportement est uniforme pour tous les types de transition dans UIKit.

Scénarios pratiques d’utilisation

Examinons quatre scénarios clés où la compréhension du Lifecycle impacte directement la qualité du code et l’expérience utilisateur. Pour chaque scénario, nous fournissons un exemple avec des recommandations.

Initialisation des données dans viewDidLoad

viewDidLoad est l’endroit pour la configuration initiale qui ne dépend pas de la visibilité de l’écran. Ici, vous configurez le collectionView, enregistrez les fichiers nib pour les cellules, créez des sources de données et des layouts. Si vous chargez des données depuis le réseau, dans viewDidLoad il est préférable de seulement lancer la requête, et de mettre à jour l’UI dans viewWillAppear lorsque l’écran est prêt à être affiché.

override func viewDidLoad() {
    super.viewDidLoad()
    tableView.register(
        MyCell.self,
        forCellReuseIdentifier: MyCell.identifier
    )
    viewModel.loadInitialData()
}

Mise à jour du contenu dans viewWillAppear

Utilisez viewWillAppear pour la synchronisation des données chaque fois que l’écran apparaît. Par exemple, si l’utilisateur a pu modifier les paramètres sur l’écran précédent, ici vous mettez à jour les valeurs affichées, rechargez le tableau et ajustez l’état de la NavigationBar. Cela garantit que l’écran affiche toujours des données à jour dans tout scénario de navigation.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    navigationController?.setNavigationBarHidden(false, animated: animated)
}

Analytique et animations dans viewDidAppear

viewDidAppear est idéal pour lancer des animations qui doivent commencer après que l’utilisateur a vu l’écran. Ici vous envoyez également des événements d’analyse : affichage d’écran, début d’onboarding ou lecture vidéo. Lancer des animations avant la fin de la transition conduit à une interface saccadée — UIKit n’a pas assez de temps pour préparer un nombre suffisant d’images.

Sauvegarde d’état dans viewWillDisappear

Dans viewWillDisappear, vous sauvegardez les brouillons, arrêtez les minuteries et vous désabonnez de NotificationCenter. C’est le dernier moment où l’écran est encore visible et accessible pour des opérations nécessitant le contexte de l’utilisateur. Pour les données critiques, utilisez également viewDidDisappear comme protection contre les gestes annulés.

Erreurs courantes lors du travail avec Lifecycle

L’utilisation incorrecte des méthodes du cycle de vie est l’une des sources les plus fréquentes de bogues dans les apps iOS. Examinons les principales erreurs que les développeurs commettent à différentes étapes du travail avec UIViewController.

La première erreur — créer des subviews dans init ou loadView lors de l’utilisation de Storyboard. Si vous utilisez Interface Builder, ne remplacez pas loadView inutilement. Créer une View dans loadView alors qu’un storyboard existe entraîne l’ignorance du fichier xib et un écran vide.

La deuxième erreur — s’abonner aux notifications de clavier dans viewDidLoad sans se désabonner. Si vous vous êtes abonné à UIResponder.keyboardWillShowNotification mais ne vous êtes pas désabonné lors du masquage de l’écran, le bloc continuera à être appelé même après le deinit du contrôleur — c’est une fuite mémoire avec un potentiel crash de l’app.

La troisième erreur — les minuteries et les requêtes réseau démarrées avant l’apparition de l’écran. Charger des images ou exécuter des animations alors que la View n’est pas encore visible est un gaspillage de ressources. Déplacez les mises à jour visuelles dans viewWillAppear ou viewDidAppear.

La quatrième erreur — sauvegarder les données uniquement dans viewWillDisappear. Avec un geste de pop interactif, l’utilisateur peut commencer un balayage et l’annuler — la méthode a été appelée mais l’écran n’a pas disparu. Dupliquez la sauvegarde critique dans viewDidDisappear ou dans le gestionnaire applicationDidEnterBackground.