El modificador .task: trabajo con vida propia

Una vista de SwiftUI no es un objeto: es un valor efímero que el framework crea, compara y destruye docenas de veces por segundo. Anclar trabajo asíncrono a algo tan volátil parecería temerario, y sin embargo .task lo consigue con una garantía muy precisa: la tarea vive exactamente lo que vive la identidad de la vista, y muere cancelada —no abortada— cuando esa identidad desaparece. Entender esa diferencia es entender toda la concurrencia de la interfaz.

La vista como raíz de un árbol de tareas

.task no es azúcar sintáctico sobre onAppear más Task. El modificador registra un cierre asíncrono que SwiftUI arranca cuando la vista entra en la jerarquía, y guarda el handle resultante junto al nodo del árbol de vistas. Cuando ese nodo se destruye, SwiftUI invoca cancel sobre el handle.

struct DetalleView: View {
    let id: Perfil.ID
    @State private var perfil: Perfil?

    var body: some View {
        Group {
            if let perfil { PerfilCard(perfil: perfil) }
            else { ProgressView() }
        }
        .task {
            perfil = try? await ServicioPerfil.cargar(id)
        }
    }
}

Dos propiedades hacen que esto sea sólido y no una convención frágil:

1. Hereda el aislamiento de actor del cuerpo de la vista. El cierre corre en el actor principal, así que asignar a perfil es legal sin ceremonia alguna. Lo veremos a fondo en la lección 15.2.
2. Es una tarea con contexto estructurado. Hereda prioridad y valores de tarea locales, y puede ajustarse con .task(priority: .background) cuando el resultado no es urgente para el primer fotograma.

La consecuencia práctica: no necesitas guardar el handle en una propiedad, ni cancelarlo en onDisappear, ni preocuparte por una vista que ya no existe recibiendo datos. Ese ciclo lo cierra el framework.

Cancelación cooperativa: nadie te mata, te avisan

Aquí vive el malentendido más caro del modelo. En Swift, cancel no interrumpe la ejecución: activa un bit en la tarea. Si tu código no lo consulta, sigue corriendo hasta el final, consumiendo CPU y batería para producir un resultado que nadie va a leer.

Las APIs de la biblioteca estándar y de Foundation sí lo consultan, y ahí es donde la mayoría de la gente cree que la cancelación es automática:

try await Task.sleep(for: .seconds(2))        // lanza CancellationError
let (datos, _) = try await URLSession.shared.data(from: url)  // lanza

Pero un bucle de cálculo puro, o un for await sobre un flujo que nunca suspende de forma cancelable, no comprueba nada. Ahí la responsabilidad es tuya:

.task {
    for pagina in 0..<total {
        try Task.checkCancellation()          // aborta lanzando
        let bloque = await indexar(pagina)
        guard !Task.isCancelled else { return } // aborta en silencio
        acumular(bloque)
    }
}

checkCancellation es la forma correcta cuando quieres propagar el error hacia arriba; isCancelled sirve cuando prefieres salir limpiamente conservando el trabajo parcial ya hecho.

Hay un tercer mecanismo, mucho menos conocido y muy útil cuando la cancelación exige liberar un recurso externo. withTaskCancellationHandler registra un cierre síncrono que el runtime invoca en el instante en que llega la cancelación, sin esperar al siguiente punto de suspensión:

await withTaskCancellationHandler {
    await lector.consumir(flujo)
} onCancel: {
    lector.cerrarConexion()      // se ejecuta ya, no cuando toque
}

El cierre de onCancel puede correr en cualquier hilo y de forma concurrente con el cuerpo, así que solo debe tocar estado seguro para concurrencia. A cambio, es la única vía para cortar de inmediato un socket, un AVCaptureSession o cualquier recurso que no consulte el bit por su cuenta.

.task(id:) y la reidentificación

Si el trabajo depende de una entrada que cambia mientras la vista sigue viva —una selección, un término de búsqueda, un filtro—, .task solo no basta: el cierre corrió una vez, con el valor viejo. La variante con identificador resuelve exactamente eso.

struct BusquedaView: View {
    @State private var termino = ""
    @State private var resultados: [Item] = []

    var body: some View {
        List(resultados) { ItemRow(item: $0) }
            .searchable(text: $termino)
            .task(id: termino) {
                try? await Task.sleep(for: .milliseconds(300))  // debounce
                resultados = (try? await api.buscar(termino)) ?? []
            }
    }
}

Cuando termino cambia, SwiftUI compara el nuevo valor con el anterior usando Equatable, cancela la tarea en curso y arranca una nueva. El sleep inicial convierte eso en un debounce gratuito: si el usuario sigue tecleando, la tarea anterior se cancela durante la espera y jamás llega a pedir nada a la red. Es el equivalente declarativo de un operador de tipo switch to latest, sin librería reactiva de por medio.

Conviene no confundir dos identidades distintas. El modificador .id sobre la vista destruye y reconstruye todo su estado, incluidos los @State. .task(id:) reinicia solo la tarea y deja el estado intacto. Elegir mal el nivel de granularidad es una fuente clásica de parpadeos y de estado perdido.

flowchart TD
A[La vista entra en la jerarquia] --> B[SwiftUI arranca la tarea hija]
B --> C{Cambia el valor de id}
C -->|si| D[Cancel a la tarea anterior]
D --> B
C -->|no| E{La vista desaparece}
E -->|si| F[Cancel y fin del ciclo]
E -->|no| G[La tarea sigue viva]
style D fill:#f9e2af,color:#11111b
style F fill:#a6e3a1,color:#11111b

Las fronteras del modificador

La regla mental que conviene interiorizar: .task expresa trabajo cuyo resultado solo interesa mientras esta pantalla exista. Todo lo demás —persistencia, envíos, sincronización— necesita un dueño con un ciclo de vida más largo, y ese dueño rara vez es una vista.