Migrar pantalla a pantalla: la estrategia incremental

La pregunta que todo equipo con una base de código de UIKit acaba haciéndose no es si migrar, sino cómo. Y la respuesta que suena más razonable —una reescritura limpia, en una rama aparte, con el diseño por fin bien hecho— es la que tiene el peor historial documentado de la industria: durante meses no se entrega valor, el producto original sigue cambiando y la rama nueva persigue un blanco móvil, y cuando por fin se fusiona reintroduce fallos que la versión vieja había corregido durante años. La alternativa madura es la estrategia incremental: la app sigue siendo la de siempre, se entrega cada semana, y por dentro una pantalla tras otra cambia de tecnología sin que nadie fuera del equipo lo note. Hacerlo bien no es cuestión de voluntad sino de orden, y elegir ese orden con criterios explícitos es la totalidad del trabajo estratégico.

Por qué incremental gana

El argumento no es de gusto sino de riesgo. Una migración incremental mantiene invariante lo único que de verdad importa: que la app se puede publicar hoy. Cada pantalla convertida es un cambio pequeño, revisable, medible y reversible; si la nueva versión de la pantalla de ajustes degrada una métrica, se revierte esa pantalla y no medio producto. Una reescritura completa, en cambio, convierte todo el proyecto en una única apuesta que solo se puede validar al final, justo cuando ya no queda margen para reaccionar.

Hay además un argumento de aprendizaje que se subestima. Un equipo que migra pantalla a pantalla escribe su primera pantalla declarativa con poca experiencia y la décima con mucha, y puede volver sobre la primera con lo aprendido. Un equipo que reescribe entero toma todas las decisiones de arquitectura en el momento de máxima ignorancia, las consolida en cien archivos y luego convive con ellas para siempre.

El orden: qué migrar primero

Las pantallas no son intercambiables y la intuición aquí engaña. La tentación es empezar por la pantalla más importante —para demostrar que se puede— o por la más fea —para que se note—, y ambas son malas primeras opciones: la más importante concentra el riesgo y la más fea suele ser fea justo por la complejidad que la hará difícil. El criterio útil combina cuatro variables: cuántas hojas del árbol es la pantalla, cuánta lógica de negocio arrastra, con qué frecuencia cambia y cuánto tráfico recibe.

De ese cuadro sale la regla operativa más útil de toda la migración: empieza por las hojas y avanza hacia la raíz. Una hoja tiene una sola frontera, no decide rutas, no comparte estado con hermanas y su conversión no obliga a tocar nada más. A medida que las hojas de una rama se van convirtiendo, llega un momento en que el contenedor intermedio ya solo alberga vistas declarativas, y entonces convertirlo es casi gratis porque el trabajo difícil ya está hecho.

flowchart BT
A[Hoja de detalle] --> D[Contenedor de seccion]
B[Hoja de ajustes] --> D
C[Hoja de perfil] --> D
D --> E[Pila de navegacion]
E --> F[Raiz de la app]
style A fill:#a6e3a1,color:#11111b
style B fill:#a6e3a1,color:#11111b
style C fill:#f9e2af,color:#11111b
style E fill:#f38ba8,color:#11111b

Antes de convertir nada conviene además fijar el criterio de terminado, porque una pantalla migrada a medias es peor que una sin migrar. Una conversión está cerrada cuando la pantalla se comporta igual o mejor que antes en accesibilidad, cuando sus pruebas pasan sin haber relajado ninguna afirmación, cuando su versión antigua se ha borrado del proyecto y cuando no ha dejado ninguna pieza de puente nueva fuera de la capa de adaptación. Sin ese criterio explícito, el equipo acumula pantallas que nadie considera pendientes y que sin embargo siguen costando dinero.

Hay una excepción que conviene aplicar desde el primer día y que no depende del árbol: todo lo nuevo se escribe en SwiftUI. Una pantalla que no existía no tiene equivalente que mantener, no puede regresionar contra nada y su coste de migración es exactamente cero porque nunca se escribió dos veces. Un equipo que solo aplicara esta regla ya vería su proporción de código declarativo crecer sola con cada versión.

La navegación es lo último

Aquí está el error estratégico que más migraciones ha descarrilado: empezar cambiando el contenedor de navegación. Es comprensible —parece la raíz del problema— y es exactamente al revés. La navegación es el único estado que todas las pantallas comparten, de modo que cambiarla obliga a que todas se adapten a la vez, que es justamente la reescritura completa que querías evitar, solo que disfrazada.

Mientras la pila de navegación viva en UIKit, la regla es simple: una pantalla declarativa se empuja envuelta en su anfitrión y navega hacia fuera llamando a un enrutador que le llega inyectado. Ese enrutador es un protocolo diminuto, la vista no sabe qué tecnología hay al otro lado, y el día que el contenedor se convierta bastará con cambiar su implementación.

protocol Enrutador {
    func abrirDetalle(id: String)
    func cerrar()
}

struct ListaView: View {
    let enrutador: Enrutador
    var body: some View {
        List(elementos) { elemento in
            Button(elemento.titulo) { enrutador.abrirDetalle(id: elemento.id) }
        }
    }
}

final class EnrutadorUIKit: Enrutador {
    weak var navegacion: UINavigationController?
    func abrirDetalle(id: String) {
        navegacion?.pushViewController(DetalleFactory.crear(id: id), animated: true)
    }
    func cerrar() { navegacion?.popViewController(animated: true) }
}

Antes de la navegación hay algo que sí conviene migrar pronto y que casi nadie prioriza: el sistema de diseño. Colores, tipografías, espaciados e iconografía compartidos entre ambos mundos, definidos una sola vez en un paquete propio. Sin eso, cada pantalla convertida es una negociación estética nueva, la app se ve inconsistente durante la transición y esa inconsistencia visible es el argumento con el que la migración se suele cancelar.

Convivir durante años

Conviene decirlo sin rodeos: una app grande tarda años en migrar, y eso no es un fracaso sino la forma normal del proceso. Lo que distingue una convivencia sana de una insoportable no es la proporción de cada tecnología, sino si el borde entre ambas está nombrado. Una app con la mitad de cada mundo, con una capa de adaptación explícita, un enrutador común y un sistema de diseño compartido, es perfectamente mantenible. Una app con el noventa por ciento declarativo y puentes improvisados en veinte sitios distintos es un campo de minas.

Esa capa de adaptación es pequeña y merece nombre y carpeta propios: los envoltorios de las vistas de UIKit que aún se usan, los anfitriones y sus fábricas, el protocolo de enrutamiento con sus dos implementaciones y los adaptadores de entorno que reinyectan el modelo en cada frontera. Toda pieza de puente vive ahí y en ningún otro sitio. La ventaja es que la carpeta hace visible la deuda: se puede contar, se puede vigilar su crecimiento y, cuando la migración termine, se borra entera.

Dentro de esa capa hay una pieza que conviene diseñar bien desde el primer día: la fábrica de pantallas. Cada pantalla se pide por su nombre y devuelve un controlador, sin que quien la pide sepa de qué mundo viene. Eso permite convertir una pantalla cambiando una sola línea, mantener las dos versiones a la vez detrás de un interruptor y revertir en producción sin publicar una versión nueva.

enum PantallaFactory {
    static func detalle(id: String, modelo: AppModel) -> UIViewController {
        guard Flags.detalleEnSwiftUI else { return DetalleViewController(id: id) }
        let vista = DetalleView(id: id).environment(modelo)
        return UIHostingController(rootView: vista)
    }
}

El interruptor merece un comentario, porque tiene una fecha de caducidad que casi nadie fija. Mantener las dos implementaciones vivas es útil durante una o dos versiones, mientras las métricas confirman que la nueva no degrada nada; a partir de ahí deja de ser una red de seguridad y se convierte en el doble de código que mantener, con el agravante de que la versión antigua se pudre sin que nadie la ejecute. La disciplina es escribir la fecha de retirada del interruptor en el mismo cambio que lo introduce.

Conviene además decidir pronto qué ocurre con las pruebas. Las de interfaz suelen sobrevivir a la migración si los identificadores de accesibilidad se conservan, y esa es una razón excelente para tratarlos como parte del contrato de la pantalla y no como un detalle. Las de lógica, si extrajiste el dominio antes de tocar la interfaz, no se enteran del cambio: siguen ejecutándose sobre los mismos tipos puros y son la única red que te avisa de una regresión real de comportamiento.