viewWillAppear en iOS: la esencia del método y cómo usarlo

Qué es viewWillAppear

viewWillAppear es un método de UIViewController que UIKit llama inmediatamente antes de agregar la Vista a la jerarquía de ventanas. En este momento, la Vista ya tiene sus dimensiones finales después de los pases de Auto Layout, pero aún no es visible para el usuario: la animación de transición no ha comenzado o está en curso. El desarrollador sobrescribe este método para realizar operaciones que deben ocurrir antes de cada visualización de la pantalla.

A diferencia de viewDidLoad, que se dispara una sola vez, viewWillAppear se llama cada vez que la pantalla está a punto de aparecer: durante la apertura inicial, al regresar de un controlador hijo, después de cerrar una ventana modal y al cambiar de pestañas en TabBar. Esto lo convierte en un método clave para mantener un estado de interfaz actualizado.

El método acepta un parámetro animated de tipo Bool, que es true si la aparición de la pantalla va acompañada de animación. Este parámetro es conveniente para pasarlo a los métodos de NavigationBar y TabBar, que también tienen un parámetro similar para un comportamiento consistente.

Cuándo se llama viewWillAppear

El momento de la llamada a viewWillAppear depende del tipo de navegación, pero la regla general no cambia: el método se dispara antes de que la Vista se vuelva visible. Consideremos los escenarios principales.

En la primera apertura de la pantalla

Después de viewDidLoad, UIKit comienza la preparación para la visualización: la Vista se agrega a la jerarquía, se activan los pases de layout, e inmediatamente antes de que comience la animación de transición, se llama a viewWillAppear. En este momento, la pantalla aún no es visible, pero todas las subvistas tienen tamaños correctos y se puede actualizar su contenido de forma segura.

Al regresar de NavigationController

Cuando el usuario toca el botón de retroceso o llama programáticamente a popViewController, UIKit regresa a la pantalla anterior y llama a su viewWillAppear. Este es el escenario principal para usar viewWillAppear: actualizar una lista después de agregar un elemento o sincronizar configuraciones.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    updateBadgeCount()
}

Al cerrar una ventana modal

Después de cerrar un controlador presentado modalmente, UIKit llama a viewWillAppear en el controlador que lo presentó. Este escenario requiere atención especial si usas delegados o closures para devolver datos: viewWillAppear garantiza que la pantalla se actualice después de recibir el resultado.

Al cambiar de pestañas en TabBar

TabBarController llama a viewWillAppear en el controlador de la pestaña seleccionada cada vez que se cambia. Si la pestaña muestra datos dinámicos — tasas de cambio, notificaciones, estado del usuario — viewWillAppear es el lugar ideal para actualizarlos.

Tareas prácticas en viewWillAppear

viewWillAppear resuelve varias tareas específicas que son imposibles o subóptimas de realizar en otros métodos. Veamos las principales.

Actualizar datos de tabla

El uso más común de viewWillAppear es recargar una UITableView o UICollectionView cada vez que aparece la pantalla. Si los datos pudieron haber cambiado en la pantalla anterior (elemento agregado, estado modificado), llamar a reloadData en viewWillAppear garantiza que el usuario vea información actualizada.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    viewModel.synchronize()
    tableView.reloadData()
}

Configurar NavigationBar y TabBar

En viewWillAppear es conveniente configurar la apariencia de la NavigationBar: ocultarla o mostrarla, cambiar su color, establecer un título grande. Si diferentes pantallas tienen diferentes estilos de NavigationBar, viewWillAppear es el lugar correcto para estos cambios, ya que viewDidLoad se llama solo una vez.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    navigationController?.setNavigationBarHidden(
        false, animated: animated
    )
    navigationController?.navigationBar.prefersLargeTitles = true
    tabBarController?.tabBar.isHidden = false
}

Suscribirse a notificaciones temporales

Las notificaciones que solo tienen sentido cuando la pantalla es visible — notificaciones de teclado, notificaciones de cambio de contenido — se suscriben en viewWillAppear y se cancelan en viewDidDisappear. Esto evita manejadores innecesarios cuando la pantalla no está activa y protege contra fugas de memoria.

Restaurar el estado de la interfaz

Si la pantalla puede ocultarse por la aplicación o minimizarse, viewWillAppear es un lugar conveniente para restaurar el estado de la interfaz: cambiar segmentos, restaurar la posición de desplazamiento, restablecer cambios temporales. El usuario obtiene la pantalla en un estado predecible cada vez que aparece.

Actualizar badges y contadores

En pantallas que muestran contadores de mensajes no leídos, calificaciones o notificaciones, viewWillAppear es el lugar adecuado para actualizarlos. Si el usuario pudo haber cambiado la cantidad en otra pantalla, aquí se llama al recálculo y actualización de UITabBarItem.badgeValue o indicadores personalizados. Esto garantiza que el usuario siempre vea números actualizados independientemente de cuánto tiempo haya estado en otras pantallas.

Se debe prestar especial atención al trabajar con collectionView: si los datos en la pantalla se presentan como una cuadrícula con celdas que contienen contadores o estados, su actualización en viewWillAppear debe ser selectiva. En lugar de un reloadData completo, usa reloadItemsAtIndexPaths para las celdas visibles, para evitar parpadeos y pérdida de la posición de desplazamiento.

Diferencias entre viewWillAppear y viewDidLoad

Comprender la diferencia entre viewWillAppear y viewDidLoad es la base de una arquitectura correcta de UIViewController. Estos métodos tienen diferente frecuencia de llamada, diferente contexto y diferente propósito.

viewDidLoad se llama una vez y es adecuado para configuraciones que no cambian con el tiempo: registrar celdas, establecer delegados, inicializar constantes. viewWillAppear se llama en cada aparición y es adecuado para operaciones que deben repetirse: actualizar datos, configurar elementos visibles, sincronizar estado.

La regla de oro: si una operación debe ejecutarse solo una vez — ponla en viewDidLoad. Si debe ejecutarse cada vez que regresas a la pantalla — ponla en viewWillAppear.

Errores comunes en viewWillAppear

El uso incorrecto de viewWillAppear puede provocar problemas de rendimiento, actualizaciones excesivas y un estado inconsistente de la interfaz. Veamos los errores más comunes.

El primer error — duplicar la lógica de viewDidLoad. Si registras celdas de tabla tanto en viewDidLoad como en viewWillAppear, el registro se realizará múltiples veces, aunque una configuración única es suficiente. Mueve todas las configuraciones únicas a viewDidLoad.

El segundo error — reloadData incondicional en cada aparición. Si los datos no han cambiado, recargar la tabla provoca consultas innecesarias al data source y redibujado de celdas, reduciendo el rendimiento. Verifica si el estado realmente ha cambiado antes de llamar a reloadData.

El tercer error — trabajar con solicitudes de red sin considerar que la pantalla puede ocultarse nuevamente antes de que la solicitud se complete. Si inicias una solicitud URLSession en viewWillAppear y el usuario navega inmediatamente a otra pantalla, el resultado puede aplicarse a una Vista ya oculta. Usa tareas cancelables o verifica isViewLoaded y window antes de actualizar.

El cuarto error — olvidar llamar a super. No llamar a super.viewWillAppear puede romper el comportamiento de los controladores padre (UINavigationController, UITabBarController) y provocar un manejo incorrecto de gestos y transiciones. super siempre debe llamarse.

El quinto error — modificar constraints sin llamar a layoutIfNeeded. Si cambias constraints programáticamente en viewWillAppear, UIKit no los aplica inmediatamente — los cambios se acumulan hasta el siguiente pase de layout. Para una aplicación inmediata de los cambios después de modificar constraints, llama a view.layoutIfNeeded(). Esto es especialmente importante al ajustar la altura de elementos dependientes del contenido.

El sexto error — intentar realizar animaciones en viewWillAppear. Como se mencionó anteriormente, UIKit todavía está procesando la animación de transición, y tu animación puede competir con la del sistema. Si necesitas que un elemento aparezca con un efecto, usa la animación de entrada en viewDidAppear, y en viewWillAppear solo configura el estado inicial: transparencia 0, transform a escala 0.8, y así sucesivamente.

El séptimo error — ignorar el parámetro animated. Algunos desarrolladores no verifican el valor de animated en viewWillAppear y realizan operaciones que deberían depender de la presencia de animación. Por ejemplo, ocultar la NavigationBar cuando animated = false se puede hacer sin animación, y cuando animated = true — con animación, para que la transición se vea suave. Siempre pasa el parámetro animated a los métodos UIKit correspondientes.

El octavo error — modificar la interfaz cuando la pantalla no es visible. Si inicias una solicitud de red en viewWillAppear y su bloque de completion actualiza la interfaz cuando la pantalla ya pudo haber desaparecido, el usuario verá parpadeos o un estado inconsistente. Siempre verifica isViewLoaded y window antes de actualizar la interfaz en closures. Esta simple acción previene crashes y redibujados innecesarios de la interfaz.