--- title: "SwiftUI no es React, aunque se parezca: body, identidad, modifiers y layout" description: "SwiftUI explicado para quien viene de React: qué es body frente a render, por qué la identidad de una vista importa, cómo el orden de los modifiers cambia el resultado, el sistema de layout sin flexbox y el mapa de hooks a property wrappers." author: Ramón Chancay date: 2026-09-03 lang: es tags: [SwiftUI, React, React Native, iOS, Layout, Property wrappers] canonical: https://www.ramonchancay.me/es/blog/swiftui-no-es-react --- # SwiftUI no es React, aunque se parezca: body, identidad, modifiers y layout SwiftUI se parece a React lo suficiente como para que un senior de React Native escriba su primera pantalla en una hora y su primer bug incomprensible en la segunda. La sintaxis declarativa, el estado que dispara re-renders, la composición de vistas pequeñas: todo eso está. Lo que no está es el modelo de ejecución de React, y ahí es donde los reflejos fallan. `body` no es `render`, una vista no es un componente, el orden de los modifiers cambia el resultado y el layout no es flexbox. Este post es el mapa de esas diferencias, con el objetivo de que cuando SwiftUI haga algo que no esperas, sepas por qué en vez de probar cambios al azar.
Resumen para perezosos
**En este artículo:** - **El modelo** — [body no es render](#body-no-es-render-la-vista-es-una-descripción-no-una-instancia) · [Identidad de vistas](#identidad-de-vistas-por-qué-el-estado-se-reinicia-o-no) - **La composición** — [Orden de modifiers](#el-orden-de-los-modifiers-cambia-el-resultado) · [Layout sin flexbox](#el-sistema-de-layout-proponer-decidir-posicionar) - **La traducción** — [Hooks a property wrappers](#de-hooks-a-property-wrappers-el-mapa-completo) · [Errores de la primera semana](#los-errores-de-la-primera-semana) ## body no es render: la vista es una descripción, no una instancia En React, un componente es una función que se ejecuta cuando cambia su estado o sus props, y produce elementos que el reconciliador compara con los anteriores. Piensas en "este componente se re-renderizó" como un evento que le pasa a algo que existe entre renders. En SwiftUI, una vista es un `struct` que conforma `View` y tiene una propiedad `body`. Ese `struct` no existe entre evaluaciones: SwiftUI lo construye, le pide `body`, guarda lo que necesita y lo descarta. Se puede crear cientos de veces por segundo y no pasa nada, porque es un valor sin identidad propia, como un `Order` o un `Address`. Lo que persiste no es la vista, sino un registro interno que SwiftUI mantiene por posición en el árbol. ```swift struct Counter: View { @State private var count = 0 // no vive en el struct: vive en el almacén de SwiftUI var body: some View { Button("Toqué \(count) veces") { count += 1 // muta el almacén; SwiftUI vuelve a pedir body } } } ``` Tres consecuencias que cambian cómo escribes: - **No hay ciclo de vida de instancia.** No existe `componentDidMount` ni un `useEffect(() => ..., [])` que se ejecute "cuando el componente se crea", porque el struct se crea todo el tiempo. Lo que hay es `.onAppear` y `.task`, que se disparan cuando la vista entra en pantalla, y `.onChange(of:)` para reaccionar a un valor. - **No pongas lógica cara en `body` ni en el inicializador.** Un `init` que crea un formateador de fechas o abre una conexión se ejecuta cada vez que el padre se re-evalúa. El estado caro va en `@State` con inicialización perezosa, en un objeto observado o en el entorno. - **`body` debe ser puro.** No lanza red, no escribe en disco, no muta estado. Si lo hace, entras en un ciclo de re-evaluación que SwiftUI corta con un warning en tiempo de ejecución que dice exactamente eso: modificar el estado durante la actualización de la vista es comportamiento indefinido. La distinción se ve en el nombre: React *renderiza*; SwiftUI *evalúa una descripción* y decide por su cuenta qué parte de la UI real necesita cambiar. Tú no controlas cuándo se llama `body`, y no deberías necesitarlo. ## Identidad de vistas: por qué el estado se reinicia (o no) Si la vista no existe entre evaluaciones, ¿cómo sabe SwiftUI que el `@State` de un `Counter` es el mismo que el del render anterior? Por identidad. Y la identidad es el concepto que más bugs produce en la primera semana. SwiftUI asigna a cada vista una identidad de dos formas. La **identidad estructural** es su posición en el árbol: "el segundo hijo del `VStack` que está dentro del `if`". La **identidad explícita** es la que das con `.id(...)` o con el `id` de los elementos de un `ForEach`. Mientras la identidad se mantenga, el estado se conserva; cuando cambia, el estado se descarta y se crea de nuevo. El caso clásico: ```swift struct Profile: View { let isEditing: Bool var body: some View { if isEditing { NameField() // identidad A: "el hijo del if en la rama true" } else { NameField() // identidad B: "el hijo del if en la rama false" } } } ``` Aunque las dos ramas construyen la misma vista, son dos identidades distintas. Al cambiar `isEditing`, el `@State` interno de `NameField` se pierde. En React, un ternario con el mismo componente en las dos ramas conserva la instancia. Aquí no. Si quieres conservar el estado, hay que sacar la condición de la estructura: ```swift var body: some View { NameField() .disabled(!isEditing) // una sola identidad; solo cambia un modifier } ``` La otra cara: a veces quieres reiniciar el estado a propósito. Una pantalla de detalle que recibe un `orderId` distinto debería empezar de cero, no conservar el scroll ni el formulario del pedido anterior. Para eso está `.id(orderId)`: cuando cambia el id, SwiftUI trata la vista como nueva. ```text ¿Se conserva el estado de una vista entre evaluaciones? ¿Cambió su posición en el árbol? │ ├── sí (otra rama de un if, otro índice) ──► se reinicia │ └── no │ ¿Tiene .id(x) y cambió x? │ ├── sí ──► se reinicia (a propósito) │ └── no ──► se conserva ``` En `ForEach`, la identidad viene del `id` de cada elemento. Usar `ForEach(items.indices)` o `ForEach(0.. El día que dejé de pensar "este componente se re-renderizó" y empecé a pensar "SwiftUI volvió a pedir esta descripción, y conserva lo que tiene identidad", la mayoría de los comportamientos raros dejaron de serlo. No es una diferencia de API; es una diferencia de quién está a cargo. ## Preguntas frecuentes ### ¿SwiftUI tiene un DOM virtual o un reconciliador? Tiene algo equivalente en función pero no en forma. SwiftUI mantiene un grafo de dependencias entre el estado y las vistas que lo leen, y con modelos `@Observable` registra qué propiedades leyó cada `body`: una propiedad que no se leyó no provoca la actualización de esa vista. Lo que no conviene es extrapolar eso a todo el mecanismo: SwiftUI sigue evaluando jerarquías y decidiendo cómo actualizar la representación, y por eso existen `.equatable()` y `EquatableView` para los casos en que quieres controlar esa comparación tú. En la práctica, `React.memo` deja de ser un hábito, no una imposibilidad. ### ¿Cómo se hace un componente reutilizable con "children"? Con `@ViewBuilder` en el inicializador: `init(@ViewBuilder content: () -> Content)`. Es el equivalente de `children`, y permite pasar varias vistas en un bloque. Para "slots" con nombre, varios parámetros `@ViewBuilder`. ### ¿Qué pasa con `some View`? ¿Por qué no devuelve un tipo concreto? `some View` es un tipo opaco: la función devuelve un tipo concreto que el compilador conoce pero que tú no nombras. El tipo real de un `body` mediano es una anidación de genéricos de varias líneas, y `some View` evita escribirlo. La restricción práctica: todas las ramas de un `if` dentro de `body` deben devolver el mismo tipo o estar dentro de un `@ViewBuilder`, que es lo que `body` ya es. Si necesitas devolver tipos distintos desde una función auxiliar, `AnyView` existe pero cuesta rendimiento y anula la comparación selectiva; casi siempre hay una forma mejor. ### ¿Puedo usar SwiftUI dentro de UIKit y viceversa? Sí, en ambas direcciones. `UIHostingController` mete una vista de SwiftUI en UIKit; `UIViewRepresentable` y `UIViewControllerRepresentable` meten UIKit en SwiftUI. Lo segundo es lo que vas a necesitar para componentes que SwiftUI todavía no cubre, y funciona de forma parecida a escribir un módulo nativo con vista en React Native, pero sin puente de JavaScript. ### ¿Las Previews reemplazan a Fast Refresh? En parte. Una Preview muestra una vista aislada con datos de ejemplo y se actualiza al editar, y desde Xcode 15 el macro `#Preview` las hace fáciles de escribir. Lo que no reemplaza es el flujo completo de la app con estado real: para eso hay que compilar y correr, y ahí vuelve el tiempo de compilación. La estrategia que me funciona es diseñar cada vista con Previews y datos falsos, y correr la app solo para probar integración. ## Conclusión SwiftUI no es React con otra sintaxis. Una vista es una descripción barata que se crea y se descarta, el estado vive fuera de ella y se asocia a una identidad que puedes romper sin querer con un `if`, cada modifier envuelve a la vista anterior y por eso el orden importa, y el layout es una negociación donde el hijo decide su tamaño. Los hooks se traducen a property wrappers, pero la traducción útil no es de nombres sino de responsabilidades: `@State` para lo privado, `@Binding` para compartir hacia arriba, `@Environment` para inyectar hacia abajo. Si vas a escribir tu primera pantalla, haz esto: modela el estado con `@State` privado y `struct`, deja `body` puro y sin trabajo caro, revisa cada `if` que envuelve una vista con estado, lee cada cadena de modifiers de adentro hacia afuera y no uses `GeometryReader` hasta haber probado `frame` y `Spacer`. El [siguiente post](/es/blog/estado-y-arquitectura-de-zustand-a-observable-y-tca) sube un nivel: cuando el estado deja de ser local y hay que decidir entre `@Observable`, MVVM y TCA, con la discusión MV frente a MVVM que un senior va a preguntar de todas formas.