viewDidAppear no iOS — o que é, quando é chamado e exemplos

O que é viewDidAppear

viewDidAppear é um método de UIViewController que UIKit chama depois que a View foi adicionada à hierarquia de janelas e a animação de transição foi totalmente concluída. Neste ponto, a tela está em seu estado final: está visível, pode-se interagir com ela e todas as animações UIKit foram interrompidas. O desenvolvedor sobrescreve este método para realizar ações que exigem que a tela esteja garantidamente diante dos olhos do usuário.

Ao contrário do viewWillAppear, onde a tela está apenas se preparando para ser exibida, viewDidAppear sinaliza que o usuário já vê a interface. Esta é uma diferença crítica: iniciar uma animação em viewWillAppear pode causar perda de quadros porque UIKit ainda está processando a transição. Em viewDidAppear, a transição está completa e os recursos do controlador podem ser usados para renderizar novo conteúdo.

O método aceita um parâmetro animated do tipo Bool, semelhante ao viewWillAppear. Se for true, o aparecimento da tela foi acompanhado por animação. Este parâmetro pode ser usado para adaptar o comportamento da UI: por exemplo, pulando uma animação de entrada durante um retorno não animado.

Quando viewDidAppear é chamado

viewDidAppear é chamado em todos os cenários onde a tela concluiu seu processo de aparecimento. Vamos ver os principais casos da perspectiva de um desenvolvedor iOS.

Quando uma transição de navegação é concluída

Depois que UINavigationController termina uma animação de push ou pop, viewDidAppear é chamado no controlador de destino. Para a primeira tela na pilha, ele é executado após a animação inicial de abertura. Este é o cenário principal, e é o que os desenvolvedores visam principalmente ao colocar lógica em viewDidAppear.

Após dispensar um modal

Quando o usuário fecha um controlador apresentado modalmente e retorna ao anterior, UIKit chama viewDidAppear no controlador que retorna. O parâmetro animated corresponderá a se o dismiss foi realizado com animação. Este momento é importante para atualizar a UI após receber dados de uma tela filha.

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

Ao alternar abas do TabBar

UITabBarController chama viewDidAppear no controlador da aba selecionada após completar a animação de alternância. Isso difere do viewWillAppear, que é executado ao iniciar a alternância. Se uma aba tem uma animação de boas-vindas ou você precisa rastrear o tempo ativo, viewDidAppear é o lugar certo.

Ao voltar do segundo plano

Quando o aplicativo retorna do segundo plano para o primeiro plano, o controlador visível pode ter viewWillAppear e viewDidAppear chamados se o ciclo de vida da View foi temporariamente suspenso. No entanto, para rastreamento confiável do retorno do segundo plano, use UIApplication.willEnterForegroundNotification separadamente.

Tarefas práticas em viewDidAppear

viewDidAppear lida com tarefas que exigem uma tela visível para execução correta. Vamos ver os cenários principais de uso em projetos reais.

Enviar eventos de análise

A tarefa mais comum do viewDidAppear é o tracking de visualizações de tela. Sistemas de análise como Firebase Analytics, Amplitude ou Mixpanel devem receber eventos apenas depois que a tela for realmente mostrada ao usuário. Enviar um evento em viewWillAppear pode subestimar o tempo de visualização e criar falsos positivos.

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

Iniciar animações de entrada

As animações que devem começar após a tela aparecer — aparecimento escalonado de elementos, paralaxe, tutoriais — são iniciadas em viewDidAppear. Neste ponto, o contexto gráfico está completamente pronto e a animação será suave, sem perda de quadros no início. Isso é especialmente importante para animações que usam UIViewPropertyAnimator.

Iniciar carregamentos assíncronos

Operações assíncronas pesadas — carregar imagens de alta resolução, analisar JSON grandes, inicializar vídeo — é melhor iniciá-las em viewDidAppear do que em viewDidLoad ou viewWillAppear. Quando o método é chamado, o usuário já vê a interface, então você pode mostrar um esqueleto ou loader sem atrasar o aparecimento da tela.

Iniciar temporizadores e intervalos

Se a tela tem elementos que exigem atualizações periódicas — temporizador de contagem regressiva, indicador de progresso, animação de progresso — eles são iniciados em viewDidAppear e parados em viewDidDisappear. Isso evita que os temporizadores funcionem quando a tela não está visível, economizando bateria e recursos de CPU.

Iniciar reprodução de conteúdo

O conteúdo de mídia — vídeo, áudio, animações Lottie — é iniciado em viewDidAppear, não antes. Se você iniciar a reprodução em viewWillAppear, o usuário perderá os primeiros segundos enquanto a tela ainda está aparecendo. Em viewDidAppear, você pode iniciar um AVPlayer ou animação Lottie com a certeza de que o usuário vê o conteúdo desde o primeiro quadro. Isso é especialmente importante para telas de onboarding e telas de inicialização onde o tempo preciso é crucial.

Animações e desempenho

O momento certo para iniciar uma animação afeta diretamente a percepção de suavidade da interface. A diferença entre começar em viewWillAppear e viewDidAppear pode ser imperceptível para animações simples, mas torna-se crítica para cenas complexas.

Quando UIKit realiza uma transição push entre telas, ele tira capturas de tela, as anima e simultaneamente chama viewWillAppear no novo controlador. Se você iniciar uma animação pesada neste momento — paralaxe, blur, transformação — UIKit pode perder quadros da animação de transição, criando um efeito de sacudida. viewDidAppear garante que a animação de transição está completa, dando a você controle total sobre a renderização.

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
    }
}

Use atrasos e amortecimento para criar um aparecimento em cascata natural dos elementos. Esta abordagem melhora a percepção da interface e aumenta o dwell time — os usuários passam mais tempo explorando o conteúdo, o que impacta positivamente as métricas comportamentais.

Erros comuns em viewDidAppear

O uso incorreto do viewDidAppear pode levar a problemas de desempenho, comportamento inesperado de animações e tracking excessivo. Vamos ver os erros mais comuns.

O primeiro erro são as chamadas múltiplas. viewDidAppear pode ser chamado várias vezes em certos cenários: alternância de abas, retorno do segundo plano, transições modais. Se o método realiza uma operação pesada sem verificar uma bandeira, ela será duplicada. Use uma bandeira hasAppeared ou dispatchOnce para ações de única vez.

O segundo erro é iniciar requisições de rede sem cancelamento ao ocultar. Se o usuário sair da tela antes da requisição ser concluída, o resultado pode ser aplicado a uma View já oculta. Use URLSessionTask canceláveis e cancele-os em viewDidDisappear.

O terceiro erro é fazer tracking em viewWillAppear em vez de viewDidAppear. Alguns desenvolvedores enviam eventos de análise em viewWillAppear, mas isso cria falsos positivos se a tela não apareceu (por exemplo, devido a um gesto de pop cancelado). viewDidAppear é o único indicador confiável de que o usuário realmente viu a tela.

O quarto erro é esquecer o super. A chamada super.viewDidAppear é necessária para o funcionamento correto de UINavigationController, UITabBarController e UISplitViewController. Sem ela, os mecanismos padrão de navegação e atualização da interface podem quebrar.

O quinto erro é mudar a orientação ou o tamanho da tela sem considerar viewDidLayoutSubviews. Se sua animação em viewDidAppear depende das dimensões finais da View, lembre-se que viewDidLayoutSubviews pode ter sido chamado várias vezes antes de viewDidAppear. Na primeira aparição da tela, o layout é concluído antes de viewDidAppear ser chamado, mas em mudanças de tamanho posteriores — por exemplo, ao girar o dispositivo — viewDidAppear pode não ser chamado e sua animação não será iniciada. Nesses casos, use viewDidLayoutSubviews com uma verificação da bandeira firstLayout.

Uma implementação correta envolve manter uma referência ao objeto de animação e cancelá-la explicitamente ao sair da tela. O sexto erro é iniciar animações infinitas sem uma bandeira de parada. Se você iniciar uma animação repetitiva em viewDidAppear (por exemplo, um indicador pulsante ou um loader giratório) mas não pará-la em viewDidDisappear, a animação consumirá recursos de GPU mesmo quando a tela estiver oculta. Sempre mantenha uma referência à animação ativa e chame removeAllAnimations ou setCompletion no método de ciclo de vida correspondente.

O sétimo erro é ignorar viewDidDisappear para interromper atividades. Se você começou a ouvir GPS, acelerômetro ou giroscópio em viewDidAppear, certifique-se de pará-lo em viewDidDisappear. Caso contrário, os sensores continuarão funcionando em segundo plano, drenando a bateria, mesmo que o usuário já tenha mudado para outra tela. Use chamadas emparelhadas de início e parada nos métodos de ciclo de vida correspondentes — isso garante um gerenciamento correto dos recursos do dispositivo.