viewDidAppear en iOS — qué es, cuándo se llama y ejemplos

Qué es viewDidAppear

viewDidAppear es un método de UIViewController que UIKit llama después de que la View ha sido añadida a la jerarquía de ventanas y la animación de transición se ha completado por completo. En este punto, la pantalla está en su estado final: es visible, se puede interactuar con ella y todas las animaciones de UIKit se han detenido. El desarrollador sobrescribe este método para realizar acciones que requieren que la pantalla esté garantizada frente a los ojos del usuario.

A diferencia de viewWillAppear, donde la pantalla solo se prepara para mostrarse, viewDidAppear señala que el usuario ya ve la interfaz. Esta es una diferencia crítica: iniciar una animación en viewWillAppear puede provocar pérdida de cuadros porque UIKit aún está procesando la transición. En viewDidAppear, la transición está completa y los recursos del controlador pueden usarse para renderizar nuevo contenido.

El método acepta un parámetro animated de tipo Bool, similar a viewWillAppear. Si es true, la aparición de la pantalla fue acompañada de animación. Este parámetro se puede usar para adaptar el comportamiento de la UI: por ejemplo, omitir una animación de entrada durante un retorno no animado.

Cuándo se llama viewDidAppear

viewDidAppear se llama en todos los escenarios donde la pantalla ha completado su proceso de aparición. Veamos los casos principales desde la perspectiva de un desarrollador iOS.

Cuando se completa una transición de navegación

Después de que UINavigationController finaliza una animación de push o pop, se llama a viewDidAppear en el controlador destino. Para la primera pantalla en la pila, se ejecuta después de la animación inicial de apertura. Este es el escenario principal, y es al que los desarrolladores apuntan principalmente al colocar lógica en viewDidAppear.

Después de descartar un modal

Cuando el usuario cierra un controlador presentado modalmente y regresa al anterior, UIKit llama a viewDidAppear en el controlador que regresa. El parámetro animated corresponderá a si el dismiss se realizó con animación. Este momento es importante para actualizar la UI después de recibir datos de una pantalla hija.

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

Al cambiar de pestaña en TabBar

UITabBarController llama a viewDidAppear en el controlador de la pestaña seleccionada después de completar la animación de cambio. Esto difiere de viewWillAppear, que se ejecuta al comenzar el cambio. Si una pestaña tiene una animación de bienvenida o necesitas rastrear el tiempo activo, viewDidAppear es el lugar correcto.

Al volver de segundo plano

Cuando la aplicación regresa de segundo plano a primer plano, el controlador visible puede tener viewWillAppear y viewDidAppear llamados si el ciclo de vida de la View fue suspendido temporalmente. Sin embargo, para un seguimiento confiable del retorno desde segundo plano, usa UIApplication.willEnterForegroundNotification por separado.

Tareas prácticas en viewDidAppear

viewDidAppear maneja tareas que requieren una pantalla visible para su correcta ejecución. Veamos los escenarios clave de uso en proyectos reales.

Enviar eventos de analítica

La tarea más común de viewDidAppear es el tracking de vistas de pantalla. Los sistemas de analítica como Firebase Analytics, Amplitude o Mixpanel deben recibir eventos solo después de que la pantalla se haya mostrado realmente al usuario. Enviar un evento en viewWillAppear puede subestimar el tiempo de visualización y crear 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 animaciones de entrada

Las animaciones que deben comenzar después de que la pantalla aparezca — aparición escalonada de elementos, paralaje, tutoriales — se inician en viewDidAppear. En este punto, el contexto gráfico está completamente listo y la animación será suave, sin pérdida de cuadros al inicio. Esto es especialmente importante para animaciones que usan UIViewPropertyAnimator.

Iniciar cargas asíncronas

Las operaciones asíncronas pesadas — carga de imágenes de alta resolución, análisis de JSON grandes, inicialización de video — es mejor iniciarlas en viewDidAppear en lugar de en viewDidLoad o viewWillAppear. Cuando se llama al método, el usuario ya ve la interfaz, por lo que puedes mostrar un esqueleto o loader sin retrasar la aparición de la pantalla.

Iniciar temporizadores e intervalos

Si la pantalla tiene elementos que requieren actualizaciones periódicas — temporizador de cuenta regresiva, indicador de progreso, animación de progreso — se inician en viewDidAppear y se detienen en viewDidDisappear. Esto evita que los temporizadores funcionen cuando la pantalla no es visible, ahorrando batería y recursos de CPU.

Iniciar reproducción de contenido

El contenido multimedia — video, audio, animaciones Lottie — se inicia en viewDidAppear, no antes. Si comienzas la reproducción en viewWillAppear, el usuario perderá los primeros segundos mientras la pantalla aún aparece. En viewDidAppear, puedes iniciar un AVPlayer o una animación Lottie con la certeza de que el usuario ve el contenido desde el primer fotograma. Esto es especialmente importante para pantallas de onboarding y pantallas de presentación donde el tiempo preciso es crucial.

Animaciones y rendimiento

El momento adecuado para iniciar una animación afecta directamente la percepción de suavidad de la interfaz. La diferencia entre comenzar en viewWillAppear y viewDidAppear puede ser imperceptible para animaciones simples, pero se vuelve crítica para escenas complejas.

Cuando UIKit realiza una transición push entre pantallas, toma capturas de pantalla, las anima y simultáneamente llama a viewWillAppear en el nuevo controlador. Si en ese momento inicias una animación pesada — paralaje, blur, transformación — UIKit puede perder cuadros de la animación de transición, creando un efecto de sacudida. viewDidAppear garantiza que la animación de transición está completa, dándote control total sobre el renderizado.

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

Usa retrasos y amortiguación para crear una aparición en cascada natural de los elementos. Este enfoque mejora la percepción de la interfaz y aumenta el dwell time — los usuarios pasan más tiempo explorando el contenido, lo que impacta positivamente en las métricas de comportamiento.

Errores comunes en viewDidAppear

El uso incorrecto de viewDidAppear puede provocar problemas de rendimiento, comportamiento inesperado de animaciones y tracking excesivo. Veamos los errores más frecuentes.

El primer error son las múltiples llamadas. viewDidAppear puede llamarse varias veces en ciertos escenarios: cambio de pestañas, retorno de segundo plano, transiciones modales. Si el método realiza una operación pesada sin verificar una bandera, se duplicará. Usa una bandera hasAppeared o dispatchOnce para acciones de una sola vez.

El segundo error es iniciar solicitudes de red sin cancelación al ocultar. Si el usuario sale de la pantalla antes de que se complete la solicitud, el resultado puede aplicarse a una View ya oculta. Usa URLSessionTask cancelables y cancélalos en viewDidDisappear.

El tercer error es hacer tracking en viewWillAppear en lugar de viewDidAppear. Algunos desarrolladores envían eventos de analítica en viewWillAppear, pero esto crea falsos positivos si la pantalla no apareció (por ejemplo, debido a un gesto de pop cancelado). viewDidAppear es el único indicador confiable de que el usuario realmente vio la pantalla.

El cuarto error es olvidar super. La llamada a super.viewDidAppear es necesaria para el correcto funcionamiento de UINavigationController, UITabBarController y UISplitViewController. Sin ella, los mecanismos estándar de navegación y actualización de la interfaz pueden romperse.

El quinto error es cambiar la orientación o el tamaño de la pantalla sin considerar viewDidLayoutSubviews. Si tu animación en viewDidAppear depende de las dimensiones finales de la View, recuerda que viewDidLayoutSubviews puede haberse llamado varias veces antes de viewDidAppear. En la primera aparición de la pantalla, el layout se completa antes de que se llame a viewDidAppear, pero en cambios de tamaño posteriores — por ejemplo, al rotar el dispositivo — viewDidAppear puede no llamarse y tu animación no se iniciará. En esos casos, usa viewDidLayoutSubviews con una verificación de la bandera firstLayout.

Una implementación correcta implica mantener una referencia al objeto de animación y cancelarla explícitamente al salir de la pantalla. El sexto error es iniciar animaciones infinitas sin una bandera de detención. Si inicias una animación repetitiva en viewDidAppear (por ejemplo, un indicador pulsante o un loader giratorio) pero no la detienes en viewDidDisappear, la animación consumirá recursos de GPU incluso cuando la pantalla esté oculta. Siempre mantén una referencia a la animación activa y llama a removeAllAnimations o setCompletion en el método de ciclo de vida correspondiente.

El séptimo error es ignorar viewDidDisappear para detener actividades. Si comenzaste a escuchar GPS, acelerómetro o giroscopio en viewDidAppear, asegúrate de detenerlo en viewDidDisappear. De lo contrario, los sensores seguirán funcionando en segundo plano, agotando la batería, incluso si el usuario ya ha cambiado a otra pantalla. Usa llamadas emparejadas de inicio y detención en los métodos de ciclo de vida correspondientes — esto garantiza una gestión correcta de los recursos del dispositivo.