TCA frente a `MVVM` con `@Observable`: la comparación honesta

La comparación entre TCA y MVVM está viciada desde la primera frase porque los dos términos no son de la misma especie. TCA es una librería concreta, con un runtime, una versión y un comportamiento que se puede ejecutar; MVVM es un nombre para una costumbre, y la costumbre de cada equipo es distinta. Comparar una implementación con una convención produce siempre el mismo espejismo: la implementación enseña todos sus costes porque están escritos, y la convención esconde los suyos porque están repartidos entre la cabeza de cada persona y las decisiones que nadie anotó. Esta lección intenta corregir ese sesgo del único modo que funciona, que es fijar un caso concreto, escribir las dos versiones completas y contar sobre el código y no sobre el recuerdo.

Dos respuestas al mismo problema, con distinto alcance

El MVVM de 2026 no es el de hace diez años. El framework de observación eliminó el ritual de ObservableObject y @Published, hizo la observación granular por propiedad y dejó una forma muy limpia: una clase anotada con @Observable que guarda estado mutable, expone métodos que lo mutan y usa async dentro de ellos. Ese modelo es bueno, y conviene decirlo sin condescendencia: resuelve bien la mayoría de las pantallas que la mayoría de la gente escribe. La diferencia de fondo no es estética. MVVM es un patrón sin árbitro: nada en el compilador ni en el runtime impide que dos objetos muten el mismo estado, que un método llame a otro método que muta a la mitad de una operación asíncrona, o que la vista escriba directamente en el modelo. TCA convierte esas mismas prohibiciones en propiedades del tipo: el estado solo es escribible desde dentro del reducer, los eventos son casos de un enum que el compilador obliga a agotar, y el trabajo asíncrono es un valor devuelto en lugar de una llamada suelta. De ahí una consecuencia que suele pesar más que cualquier argumento técnico: la varianza. Dos bases de código de MVVM escritas por equipos distintos pueden no parecerse en nada; dos de TCA se parecen tanto que alguien puede cambiar de proyecto y leer una feature el primer día. Lo que se compra no es solo una arquitectura sino la ausencia de discusión sobre ella.

Ceremonia: el mismo buscador, contado en declaraciones

El caso es el mínimo honesto: un campo de búsqueda con rebote de trescientos milisegundos, cancelación de la petición anterior y manejo del fallo. Cualquier ejemplo más pequeño favorece artificialmente a MVVM, porque la ventaja de TCA aparece exactamente donde hay asincronía que coordinar. Y las dos versiones inyectan el reloj y la red: comparar una implementación rigurosa con otra que no lo es no mide arquitecturas, mide rigor.

@Observable
final class BuscadorModel {
  var consulta = "" { didSet { programar() } }
  var resultados: [Item] = []
  var cargando = false
  private var tarea: Task<Void, Never>?
  private let api: API
  private let reloj: any Clock<Duration>

  init(api: API, reloj: any Clock<Duration>) { self.api = api; self.reloj = reloj }
  private func programar() {
    tarea?.cancel()
    cargando = true
    tarea = Task { [consulta] in
      try? await reloj.sleep(for: .milliseconds(300))
      guard !Task.isCancelled else { return }
      resultados = (try? await api.buscar(consulta)) ?? []
      cargando = false
    }
  }
}

@Reducer
struct Buscador {
  @ObservableState
  struct State: Equatable {
    var consulta = ""
    var resultados: [Item] = []
    var cargando = false
  }
  enum Action {
    case consultaCambiada(String)
    case respuesta(Result<[Item], any Error>)
  }
  @Dependency(\.api) var api
  @Dependency(\.continuousClock) var reloj
  private enum ID { case busqueda }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case let .consultaCambiada(texto):
        state.consulta = texto
        state.cargando = true
        return .run { send in
          try await reloj.sleep(for: .milliseconds(300))
          await send(.respuesta(Result { try await api.buscar(texto) }))
        }
        .cancellable(id: ID.busqueda, cancelInFlight: true)
      case let .respuesta(resultado):
        state.cargando = false
        state.resultados = (try? resultado.get()) ?? []
        return .none
      }
    }
  }
}

La versión de TCA es más larga, y negarlo sería deshonesto. Lo interesante es de qué está hecho el exceso: un caso de enum por evento, una rama por caso, un identificador para la cancelación y dos declaraciones de dependencia. Nada de eso es lógica; es nomenclatura obligatoria. Y a cambio desaparecen tres cosas que en la versión imperativa hay que sostener a mano: la propiedad que guarda la tarea, la comprobación de cancelación, y el orden implícito en que didSet dispara trabajo mientras el usuario sigue escribiendo.

Testabilidad: afirmar estados frente a afirmar transiciones

Aquí la diferencia deja de ser cuantitativa. Un test del modelo observable instancia la clase, llama al método, espera y comprueba el estado final. Puede hacerse bien, y con el reloj y la red inyectados es un buen test. Pero hay algo que estructuralmente no puede hacer: afirmar la secuencia. Que cargando pasó a verdadero antes de la petición y volvió a falso después es un hecho que ocurre entre dos instantes que el test no controla, y que solo se observa muestreando. Un test así verifica destinos, no caminos.

@Test func rebotarYResponder() async {
  let reloj = TestClock()
  let store = TestStore(initialState: Buscador.State()) {
    Buscador()
  } withDependencies: {
    $0.continuousClock = reloj
    $0.api.buscar = { _ in [Item(id: 1, nombre: "flan")] }
  }
  await store.send(.consultaCambiada("fl")) {
    $0.consulta = "fl"
    $0.cargando = true
  }
  await reloj.advance(by: .milliseconds(300))
  await store.receive(\.respuesta) {
    $0.cargando = false
    $0.resultados = [Item(id: 1, nombre: "flan")]
  }
}

El TestStore afirma cada transición en orden y falla si el estado cambió de una forma no declarada o si quedó un efecto vivo al terminar. Ese segundo criterio es el que casi nadie tiene en MVVM: una tarea huérfana que sigue corriendo después de que la pantalla desapareció no rompe ningún test, porque no hay nadie a quien le importe. La exhaustividad convierte el olvido en fallo, y esa es toda la tesis.

La curva: qué se aprende y cuándo se amortiza

La curva de TCA es real, empinada y está mal repartida: casi todo el coste se paga en las primeras semanas. Un ingeniero competente en Swift necesita del orden de dos a cuatro semanas para escribir features solo, y dos o tres meses para manejar con soltura la composición, las rutas de casos y las dependencias. Los errores de compilación son, con diferencia, la peor parte de la experiencia, porque una expansión de macro con constructores de resultados genéricos produce mensajes que no señalan la línea culpable. Frente a eso, la curva de MVVM es casi plana el primer día y no termina nunca, porque lo que se aprende no es un framework sino las convenciones de ese equipo concreto, que no están documentadas y cambian. El coste existe pero está disperso, y por eso no se percibe: se paga en revisiones de código donde se discute dónde va la lógica, y en sesiones de depuración donde la pregunta es quién mutó esto.

flowchart LR
subgraph MVVM
  V1[Vista] --> M1[Metodo del modelo]
  M1 --> P1[Mutacion directa y tarea suelta]
  P1 --> V1
end
subgraph TCA
  V2[Vista] --> A2[Accion]
  A2 --> R2[Reducer puro]
  R2 --> S2[Estado nuevo]
  S2 --> V2
  R2 --> E2[Efecto como valor]
  E2 --> A2
end
style P1 fill:#f38ba8,color:#11111b
style R2 fill:#a6e3a1,color:#11111b