viewWillDisappear en iOS — la esencia del método y cómo usarlo correctamente

Qué es viewWillDisappear

viewWillDisappear es un método de UIViewController que UIKit llama justo antes de que la Vista del controlador comience a desaparecer de la pantalla. En este momento la pantalla sigue siendo visible para el usuario, pero la transición ya se ha iniciado: NavigationController comenzó la animación push/pop, la vista modal comenzó a cerrarse o TabBar comenzó a cambiar a otra pestaña. El desarrollador sobrescribe este método para realizar operaciones que requieren que la pantalla siga siendo accesible pero se prepara para ocultarla.

A diferencia de viewDidDisappear, que se activa después de que la pantalla está oculta, viewWillDisappear proporciona la última oportunidad para guardar datos y liberar recursos mientras el usuario aún puede ver la interfaz. Esto es críticamente importante para la UX: guardar un borrador o detener un temporizador debe ocurrir antes de que el usuario cambie a otra pantalla.

El método acepta un parámetro animated, que indica si la desaparición es animada. Un valor true significa que UIKit está realizando una transición animada, false significa que la pantalla desaparece instantáneamente, por ejemplo durante un dismiss sin animación o una eliminación programática de la jerarquía.

Cuándo se llama viewWillDisappear

viewWillDisappear se llama en todos los escenarios donde la pantalla actual deja de estar activa. Revisemos los casos principales específicos del desarrollo iOS.

Al hacer push de una nueva pantalla

Cuando UINavigationController hace push de un nuevo controlador, se llama a viewWillDisappear en el actual al inicio de la animación de transición. En este momento la pantalla actual aún es visible debajo del nuevo controlador que se desliza sobre ella. Este es el escenario estándar donde viewWillDisappear se activa con animated = true.

Al hacer pop de la pantalla actual

Cuando el usuario toca el botón de retroceso o realiza un deslizamiento interactivo hacia atrás, se llama a viewWillDisappear en el controlador actual. Con un gesto interactivo esta llamada puede ser cancelada si el usuario cambia de opinión y devuelve la pantalla a su lugar. Esta es una característica importante a considerar al diseñar el guardado de estado.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    saveDraftData()
    NotificationCenter.default.removeObserver(self)
}

Al hacer dismiss de un controlador

Al cerrar una vista modal, se llama a viewWillDisappear en el controlador que se cierra al inicio de la animación de dismiss. En este punto puedes pasar los resultados de vuelta a través de un delegado o cierre, ya que el controlador que presentó la modal aún no ha recuperado el control.

Al cambiar de pestaña en TabBar

UITabBarController llama a viewWillDisappear en el controlador de la pestaña que se abandona justo después de que el usuario toca otra pestaña. Si la pestaña actual tiene procesos activos — reproducción de medios, descarga de archivos, temporizador — deben pausarse o detenerse aquí.

Tareas prácticas en viewWillDisappear

viewWillDisappear resuelve tareas específicas de gestión de recursos y estado. Revisemos los escenarios clave con ejemplos de código.

Guardar datos de usuario

La tarea más importante de viewWillDisappear es guardar los datos que el usuario ingresó o modificó en la pantalla actual. Borradores de mensajes, campos de formulario editados, configuraciones seleccionadas — todo esto debe guardarse antes de que la pantalla desaparezca. Usa Core Data, UserDefaults o almacenamiento de archivos para la persistencia.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    guard hasUnsavedChanges else { return }
    draftStorage.save(currentDraft)
}

Desuscribirse de notificaciones

NotificationCenter, KVO y los publishers de Combine a los que te suscribiste en viewWillAppear o viewDidLoad deben cancelarse en viewWillDisappear. Si no lo haces, las notificaciones llegarán a la pantalla oculta, provocando actualizaciones de UI que el usuario no ve, o — peor — fallos debido al acceso a objetos ya desasignados.

Detener animaciones y temporizadores

Las animaciones UIView iniciadas en viewDidAppear y los temporizadores que funcionan mediante Timer o DispatchSource deben detenerse en viewWillDisappear. Las animaciones continuas en una pantalla oculta desperdician GPU y batería sin ningún beneficio para el usuario. Deténlas explícitamente llamando a invalidate en los temporizadores y removeAllAnimations en las capas.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    countdownTimer?.invalidate()
    countdownTimer = nil
    loadingIndicator.layer.removeAllAnimations()
}

Pasar datos de vuelta

Si un controlador se abrió para obtener un resultado — seleccionar un elemento, ingresar texto, confirmar una acción — viewWillDisappear es el último momento en que el controlador original aún existe en la pila y puede recibir datos. Llama al delegado o cierre antes de que se invoque deinit.

Estrategia de guardado de estado

El guardado confiable del estado es una de las tareas más difíciles en el desarrollo iOS. viewWillDisappear es un elemento importante pero no el único de la estrategia. Veamos un enfoque integral.

Nivel 1 — guardado en viewWillDisappear. Guardado rápido de datos livianos que deben estar disponibles inmediatamente al regresar. Adecuado para el estado de la UI: posición de desplazamiento, segmento seleccionado, texto en campos de entrada. Problema: en un gesto de pop interactivo cancelado, el guardado ocurre aunque el usuario se quedó en la pantalla — los datos se sobrescriben innecesariamente.

Nivel 2 — guardado en viewDidDisappear. Duplica el guardado del primer nivel pero se activa solo después de que la pantalla esté garantizadamente oculta. Esto es una protección contra gestos cancelados. Sin embargo, si ya te desuscribiste de las notificaciones en viewWillDisappear, viewDidDisappear puede no tener acceso a algunos datos.

Nivel 3 — guardado a través de notificaciones de la aplicación. UIApplication.willResignActiveNotification y UIApplication.didEnterBackgroundNotification capturan la minimización de la app. Si el usuario minimizó la aplicación, es posible que no se haya llamado a viewWillDisappear — pero el guardado a través de estas notificaciones garantiza la integridad de los datos al finalizar la sesión.

Recomendación: usa una combinación de los tres niveles para datos críticos del usuario. Para estado no crítico, el primer nivel es suficiente. Es importante no volver a guardar los mismos datos múltiples veces — usa una bandera dirty que indique que los datos han cambiado desde el último guardado.

Se debe prestar especial atención a la estrategia para pantallas CRUD donde el usuario ingresa datos. En tales pantallas no se recomienda guardar cada pulsación de tecla en viewWillDisappear — eso es excesivo. Usa auto-guardado con retardo (debounce) mediante Timer, y usa viewWillDisappear solo para el guardado forzado final si hay cambios no guardados. Este enfoque equilibra el rendimiento y la integridad de los datos.

Para aplicaciones que usan Core Data, una medida adicional es llamar a saveContext en viewWillDisappear solo cuando haya cambios reales en el contexto de objetos gestionados. Verificar context.hasChanges antes de guardar evita escrituras innecesarias en el almacenamiento persistente y prolonga la duración de la batería del dispositivo. Combina esta verificación con el guardado global en applicationDidEnterBackground.

Errores comunes en viewWillDisappear

El uso incorrecto de viewWillDisappear puede provocar pérdida de datos, fugas de memoria y comportamiento inestable de la aplicación. Revisemos los errores frecuentes de los desarrolladores iOS.

Primer error — guardar datos solo en viewWillDisappear. Como se discutió anteriormente, con un gesto de pop interactivo el método se llama aunque la pantalla no haya desaparecido. Si el guardado tiene efectos secundarios — enviar datos al servidor, cambiar el estado — esto puede provocar falsas activaciones. Agrega una verificación de isBeingDismissed o isMovingFromParent.

Segundo error — no desuscribirse de NotificationCenter. Esta es una de las fugas de memoria más comunes en iOS. Si te suscribiste en viewWillAppear a UIResponder.keyboardWillShowNotification pero no te desuscribiste en viewWillDisappear, el cierre continúa llamándose. Al hacer deinit del controlador, el cierre hará referencia a un objeto desasignado — caída de la app garantizada.

Tercer error — realizar operaciones síncronas pesadas. Guardar grandes cantidades de datos, escribir en Core Data o en el sistema de archivos en viewWillDisappear bloquea el hilo principal. Si la operación dura más que la animación de transición, UIKit pausa el hilo y la interfaz se congela. Transfiere los guardados pesados a colas en segundo plano.

Cuarto error — olvidar llamar a super. No llamar a super.viewWillDisappear puede romper UINavigationController y UITabBarController, que usan este método para sus estados internos. Siempre llama a super primero o al final, siguiendo la documentación de Apple.

Este problema se agrava en iOS con multitarea activa y cambio entre aplicaciones. Quinto error — usar DispatchQueue.main.async después de guardar en viewWillDisappear. Si envías asíncronamente un bloque a la cola principal después de llamar a super.viewWillDisappear, no hay garantía de que el controlador aún exista cuando se ejecute el bloque. Siempre usa referencias débiles [weak self] dentro de los cierres para evitar acceder a memoria desasignada y prevenir caídas de la aplicación.