Migrar código legado sin naufragar

Casi todos los relatos de migración fallida a Swift 6 empiezan igual: alguien cambia el modo de lenguaje del proyecto entero un viernes, obtiene mil cuatrocientos errores y concluye que el modelo es impracticable. El diagnóstico es correcto sobre el método y falso sobre el modelo. La comprobación estricta no se diseñó como un interruptor sino como una rampa: modos de comprobación graduales, características activables una a una, adopción módulo a módulo, y anotaciones específicas para convivir con dependencias que aún no han migrado. Y hay algo más importante que la mecánica: la mayor parte de esos mil cuatrocientos errores no son mil cuatrocientos problemas, son unas pocas decenas de decisiones de propiedad que nunca se tomaron, repetidas en todos los sitios donde faltaban. Migrar bien consiste en encontrar esas decisiones, no en apagar diagnósticos uno por uno.

El orden correcto: fases, no un interruptor

La secuencia tiene cuatro escalones y saltárselos es la causa habitual del naufragio.

El primero es activar la comprobación en modo intermedio y después completo, todavía en modo de lenguaje 5, donde los problemas aparecen como avisos. Eso permite medir el tamaño real del trabajo sin bloquear la compilación ni detener al equipo.

El segundo es habilitar las características futuras de una en una, cada una con su propio ciclo de corrección: la comprobación estricta, el aislamiento de variables globales, los valores por omisión aislados, el análisis por regiones, la inferencia de seguridad en capturas y la eliminación de la inferencia hacia arriba. Cada bandera acota el tipo de error que verás, y esa acotación es justamente lo que hace tratable la corrección.

// Package.swift
.target(
    name: "Nucleo",
    swiftSettings: [
        .enableUpcomingFeature("StrictConcurrency"),
        .enableUpcomingFeature("GlobalConcurrency"),
        .enableUpcomingFeature("RegionBasedIsolation"),
        .swiftLanguageMode(.v6)
    ]
)

El tercero es elegir el orden de los módulos, y aquí la regla es contraintuitiva para mucha gente: se migra desde las hojas hacia la raíz. Un módulo base ya anotado ofrece a sus consumidores información correcta sobre aislamiento y seguridad, de modo que los errores que aparezcan arriba serán reales. Migrar primero la capa de interfaz sobre dependencias sin anotar produce una avalancha de diagnósticos falsos que desaparecerán solos cuando las bases migren, y corregirlos es trabajo tirado.

El cuarto es el modo de lenguaje 6 por módulo, cuando el anterior ya está limpio. Para el módulo de una aplicación con interfaz gráfica hay un atajo que cambia la escala del problema: desde Swift 6.2 puede fijarse el aislamiento por omisión al actor principal, de modo que todo el código del módulo pertenece al hilo principal salvo que se diga lo contrario. La mayoría de un programa de interfaz vive ahí de todos modos, y esa única opción elimina la mayor parte de los diagnósticos de golpe, dejando el trabajo de aislamiento donde de verdad importa: en las pocas rutas que hacen trabajo pesado en segundo plano.

flowchart TB
A[Comprobacion completa como avisos] --> B[Medir el volumen real]
B --> C[Activar caracteristicas futuras una a una]
C --> D[Migrar modulos de las hojas hacia la raiz]
D --> E[Modo de lenguaje 6 por modulo]
E --> F{Es el modulo de la app}
F -->|si| G[Aislamiento por omision al actor principal]
F -->|no| H[Aislamiento explicito por tipo]
style A fill:#f9e2af,color:#11111b
style G fill:#a6e3a1,color:#11111b
style H fill:#89b4fa,color:#11111b

El catálogo de errores y lo que dicen de verdad

Cuatro familias cubren casi todo lo que verás, y cada una apunta a un problema de diseño distinto.

Variable global mutable. El diagnóstico dice que una variable global no es segura para acceso concurrente. Lo que dice de verdad es que tienes estado compartido sin dueño. Las salidas honestas son tres: convertirla en let de un tipo seguro si nunca cambia, aislarla a un actor global si pertenece a un subsistema, o moverla dentro de un actor. La cuarta, nonisolated(unsafe), no es una salida sino un aplazamiento con nombre.

// Antes: singleton mutable sin dueño
final class Ajustes { static var compartidos = Ajustes() }

// Despues: el subsistema entero declara su dominio
@MainActor final class Ajustes { static let compartidos = Ajustes() }

Captura no segura en una tarea o una clausura. El diagnóstico habla de una captura cuyo tipo no es Sendable. Antes de tocar el tipo, comprueba si el análisis por regiones lo resuelve solo reordenando: en muchísimos casos el objeto es local y basta con no guardarlo en ningún sitio antes de enviarlo. Cuando el objeto sí debe seguir vivo en el origen, no hay reordenación que valga y toca decidir dueño o copia.

Conformidad con aislamiento incompatible. Un tipo aislado al actor principal que intenta conformar a un protocolo cuyos requisitos no lo están. Es el error más frecuente al integrar con protocolos heredados de Objective-C, donde el patrón de delegado es omnipresente. Desde Swift 6.2 existe la conformidad aislada a un actor global, que expresa exactamente esa situación en lugar de obligar a romper el aislamiento del tipo; cuando no aplica, la respuesta correcta suele ser separar en dos tipos la parte de interfaz y la parte de datos, que casi siempre estaban mezcladas por comodidad y no por diseño.

Diagnósticos originados en una dependencia. Un módulo o una biblioteca de C sin anotar produce errores sobre código que no es tuyo. Para eso está @preconcurrency import, que degrada esos errores mientras la dependencia se pone al día, y @preconcurrency sobre una conformidad concreta cuando el problema es un único protocolo importado.

Las decisiones que resuelven casi todo

Tres decisiones estructurales, tomadas antes de escribir la primera anotación, hacen la diferencia entre una migración de días y una de meses.

La primera es dibujar el mapa de dominios del módulo antes de tocar nada: qué estado mutable existe, quién lo lee, quién lo escribe y desde dónde. La mayoría de los proyectos descubre en este paso que tiene tres o cuatro dominios naturales —interfaz, persistencia, red, un caché— y que el noventa por ciento de sus tipos pertenece sin discusión a uno de ellos.

La segunda es decidir el dueño de cada estado mutable y hacerlo explícito. Un tipo tiene tres destinos posibles y solo tres: convertirse en tipo de valor y viajar por copia, quedar bajo un actor o un actor global, o permanecer como clase con sincronización interna y conformidad no comprobada. Elegir conscientemente entre esos tres es el trabajo real de la migración; todo lo demás es notación.

// Destino 1: era una clase compartida sin necesidad
struct Sesion: Sendable { let id: UUID; let inicio: Date }

// Destino 2: estado que muta y tiene un subsistema propio
actor RegistroDeEventos { private var pendientes: [Evento] = [] }

// Destino 3: envoltorio sobre algo ya sincronizado por debajo
final class ColaNativa: @unchecked Sendable { /* cerrojo propio */ }

La tercera es separar el trabajo de interfaz del trabajo pesado. Con el aislamiento por omisión al actor principal, la migración se reduce a identificar las rutas que hacen cómputo o entrada y salida costosos y sacarlas explícitamente del hilo principal. Ese conjunto suele ser mucho más pequeño de lo que la gente teme, y tenerlo enumerado es valioso mucho más allá de la concurrencia.

Presupuesto, trampas y deuda

Conviene entrar con expectativas calibradas. La curva de errores no es descendente: sube de golpe al activar cada característica, se derrumba cuando se toman las decisiones de propiedad, y deja una cola larga de casos individuales que exigen pensar. El tramo doloroso es el primero de cada bandera, no el conjunto, y por eso activarlas todas a la vez multiplica la sensación de desastre sin acelerar nada.

Las trampas son pocas y muy reconocibles. La primera es anotar hasta que compile: repartir el actor principal por todo el proyecto silencia los diagnósticos y traslada al hilo de interfaz trabajo que nunca debió estar ahí, con un coste que aparecerá como falta de fluidez semanas después. La segunda es envolver en tareas: rodear cada llamada conflictiva con una tarea nueva convierte errores de compilación en race conditions de lógica, que es exactamente el intercambio contrario al que ofrece Swift 6. La tercera es marcar tipos como seguros para callar al compilador, que ya no es un aplazamiento sino una mentira incorporada al sistema de tipos y sobre la que se construirá código futuro.

Hay además dos herramientas de convivencia que evitan bloqueos mientras las dependencias se ponen al día, y conviene usarlas con intención en lugar de a ciegas.

@preconcurrency import BibliotecaAntigua   // degrada errores de ese modulo

extension TipoImportado: @retroactive @unchecked Sendable { }  // ultimo recurso

La primera línea es un acuerdo temporal con un módulo que todavía no describe su aislamiento, y su vida útil termina cuando la dependencia migra. La segunda es una afirmación sobre un tipo que no es tuyo y que puede cambiar en cualquier versión: sirve para desbloquear una tarde, no para quedarse un año.

La deuda, en cambio, es perfectamente manejable si se trata como tal. Las tres anotaciones de escape son cadenas de texto buscables, así que su recuento es una métrica objetiva del proyecto, medible en cada integración continua. Un módulo migrado con doce excepciones documentadas y con dueño está en mucha mejor situación que uno con cero excepciones y el modo estricto desactivado, porque en el primero la deuda está localizada y en el segundo está en todas partes.