La convergencia entre plataformas

Cerramos el nivel con la pregunta más profunda de todas, la que convierte esta comparación en algo más que una curiosidad de catálogo: por qué tres plataformas que no se hablaban entre sí —la web, iOS y Android— llegaron, cada una por su cuenta, al mismo patrón. La respuesta no es que se copiaran, sino que las tres se sometieron a la misma presión selectiva, y bajo esa presión solo sobrevivía una forma. Esa presión tiene nombre: la interfaz declarativa que reconcilia. Cuando React, SwiftUI y Jetpack Compose hicieron que la vista fuera una función del estado, las tres necesitaron un estado único y autoritario del que derivarla, y las tres redescubrieron el flujo unidireccional como quien redescubre el ojo. Explicamos esa convergencia y la rematamos con la foto de 2026, para separar lo que caduca —las librerías— de lo que no —la ecuación—.

Por qué convergieron: una sola presión selectiva

La causa de la convergencia no está en las librerías de estado, sino en cómo se dibuja la pantalla.

Es un cambio de plano en la mirada: dejamos de comparar Redux frente a TCA y observamos el suelo común sobre el que ambas crecieron. La pregunta ya no es cuál es mejor, sino qué obligó a las dos a tener la misma forma.

Durante décadas la interfaz fue imperativa: el código tomaba un widget y le ordenaba cambiar, y el estado vivía disperso en los propios widgets. Cada componente guardaba su trocito de verdad, y sincronizarlos era trabajo manual y frágil.

Con React en 2013, SwiftUI en 2019 y Jetpack Compose en 2021, las tres plataformas mayoritarias abrazaron el mismo modelo declarativo: describes cómo debe verse la pantalla para un estado dado y el framework reconcilia el árbol de vistas para que coincida. La vista pasó a ser f(estado) en los tres mundos.

Y aquí está el eslabón que lo explica todo: una interfaz que reconcilia necesita un estado único, inmutable y autoritario contra el que comparar. Si el estado estuviera disperso y fuera mutable, el algoritmo de reconciliación no sabría qué diferencia calcular ni cuándo.

Tres plataformas, un mismo descubrimiento

El enlace de dos vías, que durante años pareció una comodidad, resulta que pelea contra el diff: si la vista puede escribir de vuelta en el estado por su cuenta, el framework pierde la única fuente contra la que reconciliar.

La única forma de alimentar limpiamente una vista declarativa es un estado que solo cambie por hechos con nombre, a través de una transición pura, en un solo sentido. Dicho de otro modo, el flujo unidireccional dejó de ser una opinión arquitectónica para convertirse en un requisito técnico del render moderno: no lo adoptas porque te guste, sino porque la alternativa ya no encaja.

Nadie repartió un memorándum entre Facebook, Apple y Google, ni hubo un comité que fijara el patrón.

Cada plataforma dedujo el flujo unidireccional por su cuenta porque la misma presión —renderizar por reconciliación— selecciona la misma solución, igual que la física de la luz selecciona el ojo una y otra vez en linajes que no comparten ancestro. La convergencia no se coordinó; se impuso.

Las huellas de esa deducción independiente están a la vista. Google documenta el patrón con ese mismo nombre, “Unidirectional Data Flow”, como su guía oficial para Compose.

Apple construyó SwiftUI sobre fuentes de verdad observables y, con el framework Observation, afinó cómo la vista se recomputa a partir del estado. Y React trae useReducer y el contexto de fábrica, sin necesidad de librería alguna. Tres caminos separados, un mismo destino.

Cuando tres organizaciones sin ningún incentivo para coordinarse dan con la misma forma en cuanto adoptan el render declarativo, la explicación robusta no es el contagio cultural, sino que el problema solo admitía esa solución. La coincidencia sería que difirieran, no que coincidan.

flowchart TD
D[UI declarativa que reconcilia] --> W[React en la web]
D --> I[SwiftUI en iOS]
D --> A[Compose en Android]
W --> U[flujo unidireccional de datos]
I --> U
A --> U
U --> E[nuevo estado es funcion pura del estado y el hecho]
style D fill:#f9e2af,color:#11111b
style U fill:#cba6f7,color:#11111b
style E fill:#a6e3a1,color:#11111b

El estado del arte en 2026

La foto de hoy muestra a los cuatro miembros en momentos vitales muy distintos, y leerla bien evita dos errores gemelos: confundir la salud de una librería con la validez de su idea, y confundir su declive con su muerte.

El primero toma la subida de una herramienta como prueba de que es mejor; el segundo toma la bajada de otra como prueba de que caducó. Un 38% no es una lápida, sino el suelo de casos donde Redux sigue siendo la mejor opción, y conviene recordar que las encuestas miden intención o uso declarado, nunca idoneidad para tu problema concreto.

Redux cedió su trono —cayó de en torno al 57% al 38% de uso entre 2021 y 2026— porque el estado de servidor emigró a TanStack Query y los componentes de servidor encogieron el estado de cliente.

Pero su reducer está hoy por todas partes: en el useReducer de React, en el set de Zustand, en el createSlice de Redux Toolkit. La librería se replegó; la idea es aire que se respira, y confundir una cosa con la otra es el error de lectura que este nivel te enseña a no cometer.

Elm, el lenguaje, está prácticamente congelado —su última versión mayor es de 2019 y su comunidad es pequeña—, y sin embargo la Elm Architecture es la arquitectura más clonada de la historia reciente.

Sus herederos van desde Mobius, de Spotify, que es TEA sobre la JVM de Android, hasta la influencia sobre lenguajes nuevos. Elm ganó de la manera más paradójica posible: siendo copiado hasta la extenuación por mundos que jamás ejecutarán una línea suya.

TCA vive su madurez, reconstruido sobre el framework Observation de Swift y apoyado en macros como @Reducer y @ObservableState que borran casi todo el boilerplate de sus primeras versiones.

Sigue siendo la elección seria para apps grandes de iOS que valoran el testing exhaustivo y la composición, precisamente las dos virtudes que la lección anterior le atribuía. Su declive de ceremonia es la prueba de que la familia entera tiende a lo mismo: conservar la disciplina, tirar el texto.

Y el Android de 2026 practica el flujo unidireccional como doctrina oficial: un ViewModel que expone StateFlow<UiState> y Compose que lo consume, con MVI —Orbit, Mobius o hecho a mano con Coroutines— formalizando la disciplina.

Lo que en la web fue una elección de librería, en Android es la recomendación de la plataforma. Esa diferencia de estatus es reveladora: donde el patrón nace de la comunidad, compite; donde lo bendice el dueño de la plataforma, se vuelve el camino por defecto.

Lo que no cambia

Da un paso atrás y mira lo que ha sobrevivido a todo esto.

La ecuación nuevoEstado = f(estado, hecho), con f pura, más vista = f(estado), más un solo sentido de circulación, ha superado la muerte de Flux, la congelación de Elm, el declive de Redux y tres cambios completos de paradigma de interfaz.

Y ha saltado sin inmutarse entre JavaScript, Elm, Swift y Kotlin. Las herramientas ganan y pierden guerras; la idea no se retira, solo cambia de nombre y sigue trabajando donde ya no la ves.

Con esto se cierra el bloque de arquitecturas del track y, con él, el mapa entero del estado: primitivos reactivos, máquinas de estado, la familia unidireccional y el estado de servidor.

Lo que te llevas no es una lista de librerías que memorizar, sino un plano para ubicar cualquier herramienta futura en dos ejes —cuánta reactividad automática te da y cuánta disciplina te impone— y, dentro de la disciplina unidireccional, un criterio para reconocerla bajo cualquier nombre y en cualquier plataforma.

Esa es la última moraleja del nivel, y quizá del track entero: las herramientas son el vocabulario de una época, pero los invariantes son la gramática. Quien aprende la gramática lee cualquier vocabulario nuevo sin que se lo tengan que enseñar, y esa es la única habilidad que no se deprecia.