viewDidAppear dans iOS — ce que c’est, quand il est appelé et exemples

Qu’est-ce que viewDidAppear

viewDidAppear est une méthode de UIViewController qu’UIKit appelle après que la View a été ajoutée à la hiérarchie des fenêtres et que l’animation de transition est complètement terminée. À ce stade, l’écran est dans son état final : il est visible, interactif et toutes les animations UIKit sont arrêtées. Le développeur surcharge cette méthode pour effectuer des actions qui nécessitent que l’écran soit garanti devant les yeux de l’utilisateur.

Contrairement à viewWillAppear, où l’écran se prépare seulement à s’afficher, viewDidAppear signale que l’utilisateur voit déjà l’interface. C’est une différence cruciale : lancer une animation dans viewWillAppear peut provoquer des pertes d’images car UIKit traite encore la transition. Dans viewDidAppear, la transition est terminée et les ressources du contrôleur peuvent être utilisées pour rendre du nouveau contenu.

La méthode accepte un paramètre animated de type Bool, similaire à viewWillAppear. Si true, l’apparition de l’écran était accompagnée d’une animation. Ce paramètre peut être utilisé pour adapter le comportement de l’interface : par exemple, sauter une animation d’entrée lors d’un retour non animé.

Quand viewDidAppear est appelé

viewDidAppear est appelé dans tous les scénarios où l’écran a terminé son processus d’apparition. Examinons les principaux cas du point de vue d’un développeur iOS.

Lorsqu’une transition de navigation est terminée

Après que UINavigationController a terminé une animation push ou pop, viewDidAppear est appelé sur le contrôleur cible. Pour le premier écran de la pile, il s’exécute après l’animation d’ouverture initiale. C’est le scénario principal, et c’est celui que les développeurs visent principalement lorsqu’ils placent la logique dans viewDidAppear.

Après avoir fermé un modal

Lorsque l’utilisateur ferme un contrôleur présenté modalement et revient au précédent, UIKit appelle viewDidAppear sur le contrôleur de retour. Le paramètre animated correspondra au fait que le dismiss a été effectué avec animation ou non. Ce moment est important pour mettre à jour l’interface après avoir reçu des données d’un écran enfant.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    logScreenView()
    startOnboardingAnimation()
}

Lors du changement d’onglets TabBar

UITabBarController appelle viewDidAppear sur le contrôleur de l’onglet sélectionné après avoir terminé l’animation de changement. Cela diffère de viewWillAppear, qui est déclenché au début du changement. Si un onglet a une animation de bienvenue ou si vous devez suivre le temps actif, viewDidAppear est l’endroit approprié.

Lors du retour de l’arrière-plan

Lorsque l’application revient de l’arrière-plan au premier plan, le contrôleur visible peut voir viewWillAppear et viewDidAppear appelés si le cycle de vie de la View a été temporairement suspendu. Cependant, pour un suivi fiable du retour de l’arrière-plan, utilisez UIApplication.willEnterForegroundNotification séparément.

Tâches pratiques dans viewDidAppear

viewDidAppear gère les tâches qui nécessitent un écran visible pour une exécution correcte. Examinons les principaux scénarios d’utilisation dans des projets réels.

Envoi d’événements d’analyse

La tâche la plus courante de viewDidAppear est le suivi des vues d’écran. Les systèmes d’analyse comme Firebase Analytics, Amplitude ou Mixpanel ne devraient recevoir des événements qu’après que l’écran a été effectivement montré à l’utilisateur. Envoyer un événement dans viewWillAppear peut sous-estimer le temps de visualisation et créer des faux déclenchements.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    Analytics.logEvent(
        name: "screen_view",
        parameters: [
            "screen_name": "ProfileScreen",
            "screen_class": String(describing: self)
        ]
    )
}

Lancement des animations d’entrée

Les animations qui doivent commencer après l’apparition de l’écran — apparition progressive des éléments, parallaxe, tutoriels — sont démarrées dans viewDidAppear. À ce stade, le contexte graphique est complètement prêt et l’animation sera fluide, sans perte d’images au début. Ceci est particulièrement important pour les animations utilisant UIViewPropertyAnimator.

Lancement des chargements asynchrones

Les opérations asynchrones lourdes — chargement d’images haute résolution, analyse de grands JSON, initialisation de vidéo — sont mieux démarrées dans viewDidAppear plutôt que dans viewDidLoad ou viewWillAppear. Au moment où la méthode est appelée, l’utilisateur voit déjà l’interface, vous pouvez donc afficher un squelette ou un chargeur sans retarder l’apparition de l’écran.

Démarrage des minuteries et intervalles

Si l’écran contient des éléments nécessitant des mises à jour périodiques — minuteur de compte à rebours, indicateur de progression, animation de progression — ils sont démarrés dans viewDidAppear et arrêtés dans viewDidDisappear. Cela empêche les minuteries de fonctionner lorsque l’écran n’est pas visible, économisant la batterie et les ressources CPU.

Démarrage de la lecture de contenu

Le contenu multimédia — vidéo, audio, animations Lottie — est démarré dans viewDidAppear, pas avant. Si vous commencez la lecture dans viewWillAppear, l’utilisateur manquera les premières secondes pendant que l’écran apparaît encore. Dans viewDidAppear, vous pouvez démarrer un AVPlayer ou une animation Lottie avec la certitude que l’utilisateur voit le contenu dès la première image. Ceci est particulièrement important pour les écrans d’intégration et les écrans de démarrage où le timing précis est crucial.

Animations et performances

Le bon moment pour lancer une animation affecte directement la perception de fluidité de l’interface. La différence entre commencer dans viewWillAppear et viewDidAppear peut être imperceptible pour des animations simples, mais devient critique pour des scènes complexes.

Lorsque UIKit effectue une transition push entre les écrans, il prend des captures d’écran, les anime et appelle simultanément viewWillAppear sur le nouveau contrôleur. Si vous lancez une animation lourde à ce moment — parallaxe, flou, transformation — UIKit peut perdre des images de l’animation de transition, créant un effet saccadé. viewDidAppear garantit que l’animation de transition est terminée, vous donnant un contrôle total sur le rendu.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)

    UIView.animate(
        withDuration: 0.6,
        delay: 0.3,
        usingSpringWithDamping: 0.8,
        initialSpringVelocity: 0.5
    ) {
        self.cardView.alpha = 1.0
        self.cardView.transform = .identity
    }
}

Utilisez des retards et l’amortissement pour créer une apparition en cascade naturelle des éléments. Cette approche améliore la perception de l’interface et augmente le temps de visite — les utilisateurs passent plus de temps à explorer le contenu, ce qui impacte positivement les métriques comportementales.

Erreurs courantes dans viewDidAppear

L’utilisation incorrecte de viewDidAppear peut entraîner des problèmes de performances, un comportement inattendu des animations et un suivi excessif. Examinons les erreurs fréquentes.

La première erreur est celle des appels multiples. viewDidAppear peut être appelé plusieurs fois dans certains scénarios : changement d’onglet, retour de l’arrière-plan, transitions modales. Si la méthode effectue une opération lourde sans vérification de drapeau, elle sera dupliquée. Utilisez un drapeau hasAppeared ou dispatchOnce pour les actions uniques.

La deuxième erreur est de lancer des requêtes réseau sans annulation lors du masquage. Si l’utilisateur quitte l’écran avant la fin de la requête, le résultat peut être appliqué à une View déjà masquée. Utilisez des URLSessionTask annulables et annulez-les dans viewDidDisappear.

La troisième erreur est le suivi dans viewWillAppear au lieu de viewDidAppear. Certains développeurs envoient des événements d’analyse dans viewWillAppear, mais cela crée de faux déclenchements si l’écran n’est pas apparu (par exemple, en raison d’un geste pop annulé). viewDidAppear est le seul indicateur fiable que l’utilisateur a effectivement vu l’écran.

La quatrième erreur est d’oublier super. L’appel à super.viewDidAppear est nécessaire au bon fonctionnement de UINavigationController, UITabBarController et UISplitViewController. Sans lui, les mécanismes standard de navigation et de mise à jour de l’interface peuvent se briser.

La cinquième erreur est de changer l’orientation ou la taille de l’écran sans tenir compte de viewDidLayoutSubviews. Si votre animation dans viewDidAppear dépend des dimensions finales de la View, rappelez-vous que viewDidLayoutSubviews peut avoir été appelé plusieurs fois avant viewDidAppear. Lors de la première apparition de l’écran, la mise en page est terminée avant l’appel de viewDidAppear, mais lors des changements de taille ultérieurs — par exemple, lors de la rotation du périphérique — viewDidAppear peut ne pas être appelé et votre animation ne démarrera pas. Dans ces cas, utilisez viewDidLayoutSubviews avec une vérification du drapeau firstLayout.

Une implémentation correcte implique de conserver une référence à l’objet d’animation et de l’annuler explicitement en quittant l’écran. La sixième erreur est de lancer des animations infinies sans drapeau d’arrêt. Si vous lancez une animation répétitive dans viewDidAppear (par exemple, un indicateur pulsant ou un chargeur rotatif) mais ne l’arrêtez pas dans viewDidDisappear, l’animation consommera des ressources GPU même lorsque l’écran est masqué. Gardez toujours une référence à l’animation active et appelez removeAllAnimations ou setCompletion dans la méthode de cycle de vie correspondante.

La septième erreur est d’ignorer viewDidDisappear pour arrêter les activités. Si vous avez commencé à écouter le GPS, l’accéléromètre ou le gyroscope dans viewDidAppear, assurez-vous de l’arrêter dans viewDidDisappear. Sinon, les capteurs continueront de fonctionner en arrière-plan, déchargeant la batterie, même si l’utilisateur est passé depuis longtemps à un autre écran. Utilisez des appels couplés de démarrage et d’arrêt dans les méthodes de cycle de vie correspondantes — cela garantit une gestion correcte des ressources de l’appareil.