Migración gradual: UIKit y SwiftUI conviviendo

La pregunta que abrió este nivel vuelve al final, ya contestable con precisión: si adoptar TCA no obliga a reescribir la interfaz, ¿cómo se avanza entonces desde una app de doscientas pantallas de UIKit hasta donde quiera que se quiera llegar? La respuesta es que se avanza por donde el sistema ya tenía una junta. En una arquitectura donde las pantallas se comunican por delegados, segues y referencias mutuas, no hay ninguna junta: cualquier corte deja cables colgando, y por eso las migraciones grandes se plantean como reescrituras completas y fracasan. En una arquitectura donde cada feature habla con su padre a través de acciones y recibe del padre un store rebanado, las juntas están por todas partes, y una de ellas puede tener UIKit a un lado y SwiftUI al otro sin que ninguno de los dos se entere.

El store es la costura

Un UIHostingController es un UIViewController corriente que dibuja una vista de SwiftUI. Se empuja en una pila, se presenta como hoja o se añade como hijo igual que cualquier otro. Lo interesante no es él, sino de dónde saca la vista su store: del scope del padre, exactamente igual que lo sacaría un controlador escrito a mano.

final class BandejaViewController: UIViewController {
  private let store: StoreOf<Bandeja>

  private func abrirDetalle(id: Mensaje.ID) {
    store.send(.filaSeleccionada(id: id))
  }

  private func empujarDetalle(_ hijo: StoreOf<Detalle>) {
    let vc = UIHostingController(rootView: DetalleView(store: hijo))
    vc.title = "Detalle"
    navigationController?.pushViewController(vc, animated: true)
  }
}

DetalleView no sabe que su padre es un controlador. Bandeja no sabe que su hijo se dibuja con SwiftUI. La frontera entre los dos frameworks coincide con la frontera entre las dos features, que ya existía y que ya estaba definida por un Scope y un caso de acción. Ese es el truco entero, y explica por qué la migración se puede hacer de una pantalla en una: cada pantalla es un hijo, y cambiar el dibujo de un hijo no toca a nadie más.

Quedan asperezas de integración que conviene conocer de antemano. El UIHostingController trae su propio fondo, que hay que poner transparente si se aloja dentro de una vista con diseño propio. Cuando se usa como vista incrustada, sizingOptions con intrinsicContentSize hace que participe en el Auto Layout del contenedor. Y al añadirlo como hijo hay que respetar la coreografía de addChild, incorporación de la vista y didMove, porque sin ella los eventos de aparición no llegan y los efectos ligados al ciclo de vida no arrancan.

private func incrustar(_ hijo: StoreOf<Resumen>, en contenedor: UIView) {
  let vc = UIHostingController(rootView: ResumenView(store: hijo))
  vc.view.backgroundColor = .clear
  vc.sizingOptions = .intrinsicContentSize
  addChild(vc)
  contenedor.addSubview(vc.view)
  vc.view.frame = contenedor.bounds
  vc.didMove(toParent: self)
}

El viaje inverso, con un método vacío

A veces la pantalla nueva es la de SwiftUI y la vieja es un controlador que nadie quiere tocar todavía: un editor de texto complejo, una vista de cámara, un mapa con anotaciones personalizadas. UIViewControllerRepresentable lo envuelve, y aquí aparece un detalle que sorprende la primera vez.

struct EditorLegado: UIViewControllerRepresentable {
  let store: StoreOf<Editor>

  func makeUIViewController(context: Context) -> EditorViewController {
    EditorViewController(store: store)
  }

  func updateUIViewController(_ vc: EditorViewController, context: Context) {
    // Intencionadamente vacio.
  }
}

El método de actualización está vacío, y no por descuido. En un Representable corriente ese método es el que traslada los cambios del mundo declarativo al objeto imperativo, y suele acumular comparaciones para no reasignar de más. Con TCA no hace falta: el controlador recibió el store en su construcción y se observa a sí mismo con observe, de modo que se entera de los cambios por su cuenta y en el momento exacto. El Representable deja de ser un canal de datos y se queda en lo que debería haber sido siempre, un adaptador de ciclo de vida.

Dos fases, y la segunda es la barata

Antes de la primera pantalla hay una decisión estructural que conviene tomar bien, porque condiciona todo lo demás: dónde nace el store raíz. La respuesta es en el punto de arranque de la escena, una sola vez, y desde ahí baja rebanado hasta cada pantalla, sea del framework que sea. Un store creado dentro de un controlador es un store que muere cuando ese controlador se descarta, y con él mueren los efectos en vuelo y el estado que la pantalla siguiente esperaba encontrar.

final class SceneDelegate: UIResponder, UIWindowSceneDelegate {
  let store = Store(initialState: App.State()) { App() }
  var window: UIWindow?

  func scene(_ escena: UIScene, willConnectTo _: UISceneSession, options _: UIScene.ConnectionOptions) {
    guard let escena = escena as? UIWindowScene else { return }
    let raiz = BandejaViewController(store: store.scope(state: \.bandeja, action: \.bandeja))
    window = UIWindow(windowScene: escena)
    window?.rootViewController = UINavigationController(rootViewController: raiz)
    window?.makeKeyAndVisible()
  }
}

Con esa raíz en su sitio, la migración es siempre la misma operación repetida: cambiar quién dibuja un hijo sin cambiar quién lo alimenta. Y el error de planificación más caro es tratar adoptar TCA y pasar a SwiftUI como una sola tarea. Son dos, y separarlas cambia el perfil de riesgo del proyecto por completo, porque la primera aporta casi todo el valor y la segunda casi todo el riesgo visual.

En la primera fase la pantalla sigue siendo el mismo UIViewController, con las mismas vistas y el mismo xib si lo tenía. Lo que cambia es que sus propiedades mutables se mudan a un State, sus manejadores pasan a enviar acciones, sus llamadas a la red se vuelven dependencias y su lógica queda en un reducer. Al terminar hay tests donde no los había, y la pantalla se puede desplegar esa misma tarde. En la segunda fase se sustituye el controlador por un UIHostingController con una vista nueva, y el reducer, las dependencias y los tests no se tocan: siguen siendo los mismos archivos, verdes, sin editar una línea. Esa continuidad de la suite entre fases es lo que convierte la segunda en una operación mecánica y reversible.

El último punto de las tarjetas merece defensa explícita, porque va contra el instinto de terminar lo empezado. La homogeneidad del framework de dibujo no es un objetivo de ingeniería: no reduce fallos, no acelera nada y no simplifica ningún razonamiento. Lo que sí lo hace es la homogeneidad del dominio, es decir, que toda la app comparta la misma forma de representar el estado, de nombrar los eventos, de inyectar dependencias y de probar. Una app con ciento noventa pantallas en SwiftUI y diez en UIKit, todas sobre el mismo árbol de reducers, es una app coherente. Una app con doscientas pantallas en SwiftUI y la lógica repartida entre modelos de vista improvisados no lo es.

flowchart TD
R[Store raiz creado en el arranque] --> A[Feature bandeja aun en UIKit]
A --> S1[scope hacia el detalle]
S1 --> H[UIHostingController con vista SwiftUI]
A --> S2[scope hacia el editor]
S2 --> L[UIViewController heredado con observe]
N[Pantalla nueva en SwiftUI] --> S3[scope hacia el editor]
S3 --> W[UIViewControllerRepresentable]
W --> L
style R fill:#89b4fa,color:#11111b