TCA no es SwiftUI: el store no sabe quién lo mira

Un equipo con doscientas pantallas escritas en UIKit lee sobre TCA, se entusiasma con la testabilidad y la composición, y a los diez minutos se topa con la pregunta que decide el proyecto: para adoptar esto, ¿hay que reescribir la interfaz entera? La respuesta corta es que no, y la larga es más interesante que la corta, porque para justificarla hay que saber exactamente dónde acaba la arquitectura y dónde empieza el dibujo. El Store de TCA es una caja que guarda un valor, recibe acciones, ejecuta un reducer y despacha efectos. Nada de eso menciona una vista. Lo que sí menciona una vista es el problema de mantener la pantalla sincronizada con ese valor, y ahí SwiftUI y UIKit ofrecen respuestas radicalmente distintas: una la calcula el framework, la otra la escribes tú. Este nivel entero trata de escribirla bien.

Dónde termina la arquitectura y dónde empieza la vista

Haz el ejercicio mental de recorrer los tipos que has usado hasta aquí y preguntarte cuáles necesitan saber que existe una pantalla. Reducer es un protocolo con una función que toma estado y acción y devuelve un efecto. Effect es un valor que describe trabajo asíncrono. @Dependency es una búsqueda en un contenedor con ámbito. Scope, ifLet y forEach son operadores sobre reducers. TestStore conduce el sistema paso a paso. Ninguno de los seis necesita un píxel. El único tipo con vocación de frontera es Store, y su contrato es minúsculo: mantiene un valor de estado observable, expone send para recibir acciones y scope para producir sub-stores.

Que la biblioteca envíe además ayudantes de SwiftUI —los antiguos WithViewStore y ForEachStore, los modificadores de presentación, los bindings— no contradice nada: son una capa que se apoya en ese contrato, del mismo modo que la capa de UIKit se apoya en él. La distinción operativa que importa es esta: el núcleo define qué es verdad en cada instante; la capa de presentación resuelve cómo se refleja esa verdad en objetos de dibujo. Son dos problemas separables, y TCA los tiene separados desde su primera versión.

@Reducer
struct Contador {
  @ObservableState
  struct State: Equatable {
    var cuenta = 0
    var cargando = false
  }
  enum Action {
    case incrementarPulsado
    case sincronizarPulsado
    case datoRecibido(Int)
  }
  @Dependency(\.numeros) var numeros

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .incrementarPulsado:
        state.cuenta += 1
        return .none
      case .sincronizarPulsado:
        state.cargando = true
        return .run { send in await send(.datoRecibido(numeros.actual())) }
      case let .datoRecibido(valor):
        state.cargando = false
        state.cuenta = valor
        return .none
      }
    }
  }
}

Ese archivo es idéntico en una app de SwiftUI y en una de UIKit. No hay una versión para cada framework, ni un protocolo que conformar, ni una bandera de compilación. Es literalmente el mismo texto.

Lo que no cambia: casi todo

Merece la pena hacer el inventario explícito, porque es el argumento que convence a un equipo escéptico. Sobreviven sin tocar el State y el Action, el body del reducer con todos sus operadores, los efectos y su cancelación, el árbol completo de dependencias con sus valores de producción y de prueba, la modularización en paquetes, la composición padre-hijo y, punto decisivo, la suite de tests entera. Un TestStore no instancia vistas; conduce el reducer. Por eso los tests que escribas hoy contra una feature dibujada con UIViewController seguirán pasando mañana si esa misma feature pasa a dibujarse con SwiftUI, sin editar una línea.

Lo que sí cambia: el bucle de sincronización

Lo que cambia es una sola cosa, aunque se manifieste de tres maneras. SwiftUI mantiene la pantalla sincronizada recalculando una función: cuando el estado leído por un body cambia, el framework invalida esa vista y vuelve a evaluarla, y después reconcilia el árbol resultante contra el anterior. UIKit no tiene esa función ni ese árbol. Una vista de UIKit es un objeto mutable con propiedades que alguien tiene que asignar, y no existe ningún momento en el que el sistema decida volver a preguntarte cómo debería verse la pantalla. Ese hueco es todo el trabajo del nivel.

struct ContadorView: View {
  let store: StoreOf<Contador>

  var body: some View {
    VStack {
      Text("\(store.cuenta)")
      Button("Incrementar") { store.send(.incrementarPulsado) }
      if store.cargando { ProgressView() }
    }
  }
}

final class ContadorViewController: UIViewController {
  private let store: StoreOf<Contador>
  private let etiqueta = UILabel()
  private let indicador = UIActivityIndicatorView()

  init(store: StoreOf<Contador>) {
    self.store = store
    super.init(nibName: nil, bundle: nil)
  }

  override func viewDidLoad() {
    super.viewDidLoad()
    observe { [weak self] in
      guard let self else { return }
      etiqueta.text = "\(store.cuenta)"
      indicador.isHidden = !store.cargando
    }
  }
}

Los dos ficheros hablan con el mismo store y expresan la misma relación entre estado y pantalla. La diferencia es quién ejecuta esa relación: arriba la ejecuta el framework cada vez que lo cree necesario, abajo la ejecuta una closure que tú registras y que TCA vuelve a invocar cuando cambia algo que esa closure leyó. Las tres manifestaciones del cambio son entonces predecibles, y las tres ocupan una lección de este nivel.

Conviene fijar esa lista porque acota el presupuesto de la migración con una precisión inusual: lo que hay que reescribir es el archivo de la vista, y solo el archivo de la vista. La cuarta tarjeta funciona además como prueba diagnóstica. Si al portar una pantalla a UIKit descubres que también hay que tocar el reducer, no has encontrado una limitación del framework: has encontrado un trozo de lógica que vivía en la vista de SwiftUI y que la migración acaba de sacar a la luz.

flowchart TD
N[Nucleo con Reducer y State y Action y Effect] --> S[Store]
D[Dependencias inyectadas] --> S
S --> P1[Capa SwiftUI con body recalculado]
S --> P2[Capa UIKit con closure observe]
P1 --> V1[Arbol declarativo reconciliado por el framework]
P2 --> V2[Objetos mutables asignados por ti]
S --> T[TestStore sin capa de presentacion]
style S fill:#89b4fa,color:#11111b