--- title: "SwiftUI is not React, even if it looks like it: body, identity, modifiers and layout" description: "SwiftUI explained for people coming from React: what body is compared to render, why a view's identity matters, how modifier order changes the result, the layout system without flexbox and the map from hooks to property wrappers." author: Ramón Chancay date: 2026-09-03 lang: en tags: [SwiftUI, React, React Native, iOS, Layout, Property wrappers] canonical: https://www.ramonchancay.me/blog/swiftui-is-not-react --- # SwiftUI is not React, even if it looks like it: body, identity, modifiers and layout SwiftUI looks enough like React that a senior React Native developer writes their first screen in an hour and their first incomprehensible bug in the second. The declarative syntax, the state that triggers re-renders, the composition of small views: all of that is there. What is not there is React's execution model, and that is where the reflexes fail. `body` is not `render`, a view is not a component, the order of the modifiers changes the result and the layout is not flexbox. This post is the map of those differences, so that when SwiftUI does something you don't expect, you know why instead of trying random changes.
TL;DR
**In this article:** - **The model** — [body is not render](#body-is-not-render-the-view-is-a-description-not-an-instance) · [View identity](#view-identity-why-state-resets-or-doesnt) - **Composition** — [Modifier order](#the-order-of-modifiers-changes-the-result) · [Layout without flexbox](#the-layout-system-propose-decide-position) - **The translation** — [Hooks to property wrappers](#from-hooks-to-property-wrappers-the-complete-map) · [First-week mistakes](#the-mistakes-of-the-first-week) ## body is not render: the view is a description, not an instance In React, a component is a function that runs when its state or props change, and it produces elements that the reconciler compares with the previous ones. You think of "this component re-rendered" as an event that happens to something that exists between renders. In SwiftUI, a view is a `struct` that conforms to `View` and has a `body` property. That `struct` does not exist between evaluations: SwiftUI builds it, asks it for `body`, keeps what it needs and discards it. It can be created hundreds of times per second and nothing happens, because it is a value with no identity of its own, like an `Order` or an `Address`. What persists is not the view but an internal record that SwiftUI keeps per position in the tree. ```swift struct Counter: View { @State private var count = 0 // does not live in the struct: it lives in SwiftUI's store var body: some View { Button("Tapped \(count) times") { count += 1 // mutates the store; SwiftUI asks for body again } } } ``` Three consequences that change how you write: - **There is no instance lifecycle.** There is no `componentDidMount` and no `useEffect(() => ..., [])` that runs "when the component is created", because the struct is created all the time. What there is: `.onAppear` and `.task`, which fire when the view enters the screen, and `.onChange(of:)` to react to a value. - **Don't put expensive logic in `body` or in the initializer.** An `init` that creates a date formatter or opens a connection runs every time the parent is re-evaluated. Expensive state goes in `@State` with lazy initialization, in an observed object or in the environment. - **`body` must be pure.** It does not hit the network, does not write to disk, does not mutate state. If it does, you enter a re-evaluation cycle that SwiftUI cuts with a runtime warning that says exactly that: modifying state during view update is undefined behavior. The distinction is in the name: React *renders*; SwiftUI *evaluates a description* and decides on its own which part of the real UI needs to change. You don't control when `body` is called, and you shouldn't need to. ## View identity: why state resets (or doesn't) If the view does not exist between evaluations, how does SwiftUI know that the `@State` of a `Counter` is the same one as in the previous render? By identity. And identity is the concept that produces the most bugs in the first week. SwiftUI assigns every view an identity in two ways. **Structural identity** is its position in the tree: "the second child of the `VStack` that is inside the `if`". **Explicit identity** is the one you give with `.id(...)` or with the `id` of the elements of a `ForEach`. As long as the identity holds, state is kept; when it changes, state is discarded and created again. The classic case: ```swift struct Profile: View { let isEditing: Bool var body: some View { if isEditing { NameField() // identity A: "the child of the if in the true branch" } else { NameField() // identity B: "the child of the if in the false branch" } } } ``` Even though both branches build the same view, they are two different identities. When `isEditing` changes, the internal `@State` of `NameField` is lost. In React, a ternary with the same component in both branches keeps the instance. Here it doesn't. If you want to keep the state, you have to take the condition out of the structure: ```swift var body: some View { NameField() .disabled(!isEditing) // a single identity; only a modifier changes } ``` The other side: sometimes you want to reset the state on purpose. A detail screen that receives a different `orderId` should start from scratch, not keep the scroll position or the form of the previous order. That is what `.id(orderId)` is for: when the id changes, SwiftUI treats the view as new. ```text Is a view's state kept between evaluations? Did its position in the tree change? │ ├── yes (another branch of an if, another index) ──► reset │ └── no │ Does it have .id(x), and did x change? │ ├── yes ──► reset (on purpose) │ └── no ──► kept ``` In `ForEach`, identity comes from the `id` of each element. Using `ForEach(items.indices)` or `ForEach(0.. The day I stopped thinking "this component re-rendered" and started thinking "SwiftUI asked for this description again, and keeps whatever has identity", most of the strange behaviors stopped being strange. It is not a difference of API; it is a difference of who is in charge. ## Frequently asked questions ### Does SwiftUI have a virtual DOM or a reconciler? It has something equivalent in function but not in form. SwiftUI keeps a dependency graph between state and the views that read it, and with `@Observable` models it records which properties each `body` read: a property that was not read does not trigger an update of that view. What you shouldn't do is extrapolate that to the whole mechanism: SwiftUI still evaluates hierarchies and decides how to update the representation, which is why `.equatable()` and `EquatableView` exist for the cases where you want to control that comparison yourself. In practice, `React.memo` stops being a habit, not an impossibility. ### How do you build a reusable component with "children"? With `@ViewBuilder` in the initializer: `init(@ViewBuilder content: () -> Content)`. It is the equivalent of `children`, and it lets you pass several views in one block. For named "slots", several `@ViewBuilder` parameters. ### What about `some View`? Why doesn't it return a concrete type? `some View` is an opaque type: the function returns a concrete type that the compiler knows but that you don't name. The real type of a medium-sized `body` is a nesting of generics several lines long, and `some View` saves you from writing it. The practical restriction: every branch of an `if` inside `body` must return the same type or be inside a `@ViewBuilder`, which is what `body` already is. If you need to return different types from a helper function, `AnyView` exists, but it costs performance and disables selective comparison; there is almost always a better way. ### Can I use SwiftUI inside UIKit and vice versa? Yes, in both directions. `UIHostingController` puts a SwiftUI view inside UIKit; `UIViewRepresentable` and `UIViewControllerRepresentable` put UIKit inside SwiftUI. The second is what you will need for components SwiftUI does not cover yet, and it works similarly to writing a native module with a view in React Native, but without a JavaScript bridge. ### Do Previews replace Fast Refresh? Partly. A Preview shows an isolated view with sample data and updates as you edit, and since Xcode 15 the `#Preview` macro makes them easy to write. What it does not replace is the full app flow with real state: for that you have to build and run, and there the compile time comes back. The strategy that works for me is designing every view with Previews and fake data, and running the app only to test integration. ## Conclusion SwiftUI is not React with a different syntax. A view is a cheap description that is created and discarded, state lives outside of it and is tied to an identity that you can break by accident with an `if`, each modifier wraps the previous view and that is why order matters, and layout is a negotiation where the child decides its size. Hooks translate to property wrappers, but the useful translation is not one of names but of responsibilities: `@State` for what is private, `@Binding` to share upward, `@Environment` to inject downward. If you are about to write your first screen, do this: model state with private `@State` and `struct`, keep `body` pure and free of expensive work, review every `if` that wraps a view with state, read every chain of modifiers from the inside out and don't use `GeometryReader` until you have tried `frame` and `Spacer`. The [next post](/blog/state-and-architecture-from-zustand-to-observable-and-tca) goes one level up: when state stops being local and you have to choose between `@Observable`, MVVM and TCA, with the MV versus MVVM discussion that a senior is going to ask about anyway.