---
title: SwiftUI Is Like React + CSS-in-JS
url: https://varstatt.com/jurij/p/swiftui-is-like-react-plus-css-in-js
author: Jurij Tokarski
date: 2026-03-04
description: I had to jump into an iOS codebase with no SwiftUI experience. The fastest way in was mapping everything I already knew to the Swift equivalent.
section: Blog (https://varstatt.com/jurij/archive)
---
A client brought me into an iOS project mid-stream. The app was already built — screens, navigation, state management, the works — and I needed to understand it fast enough to contribute meaningfully.
The codebase was SwiftUI. I had zero SwiftUI experience.
My usual move in this situation is to find the mental model that bridges the gap. I've been doing web development long enough that React, CSS, and async JavaScript are second nature. So instead of starting from scratch, I used Claude Code to explore the codebase and kept asking one question: *what's the web equivalent of this?*
After a few hours of that, something clicked. SwiftUI is not exotic. If you know React, you already know 80% of the concepts — just with different syntax and a few iOS-specific primitives layered on top.
This post is the reference I built during that session. I stripped the client-specific code and kept the patterns that apply universally.
## Core Concept: SwiftUI = React + CSS-in-JS + Declarative UI
SwiftUI is declarative and component-based, just like React. Instead of JSX you write Swift, but the mental model is the same: describe what the UI should look like, and the framework figures out how to render it.
The three things that felt foreign to me at first — and clicked once I found the right analogy:
- **No CSS files.** Styles live directly on the component as chained modifiers. Think CSS-in-JS but without the library — it's just how the language works.
- **No DOM.** SwiftUI renders to native UIKit controls under the hood. You never touch them directly, just like you never touch the DOM in React.
- **State drives everything.** Change a `@State` variable and the view re-renders. Same contract as `useState`, same mental model, different syntax.
## 1. Components — Structs that return a view, not JSX
In React a component is a function that returns JSX. In SwiftUI it's a `struct` that conforms to the `View` protocol and implements a `body` property. The props become `let` constants declared directly on the struct, and instead of a `return` statement you describe the layout inline.
```jsx
function NoteCard({
title,
subtitle,
dateLabel
}) {
return (
{title}
{subtitle}
{dateLabel}
);
}
```
```swift
struct NoteCardView: View {
let title: String?
let subtitle: String
let dateLabel: String
var body: some View {
VStack(
alignment: .leading,
spacing: 8
) {
if let title = title {
Text(title)
}
Text(subtitle)
Text(dateLabel)
}
.padding(16)
.background(Color("NeutralCool0"))
}
}
```
Key differences:
- `struct` instead of `function`
- `var body: some View` instead of `return`
- Swift types (`String?`, `Int`) instead of JavaScript types
- Modifiers (`.padding()`, `.background()`) instead of CSS classes
## 2. Layout — Named containers instead of flex properties
On the web layout is a property you set on an element — `display: flex`, `flex-direction: row`. In SwiftUI layout is structural: you pick a container (`VStack`, `HStack`, `ZStack`) and nest views inside it. There are no flex properties to remember because the direction is baked into the container name.
Layout containers:
- `VStack` → `display: flex; flex-direction: column`
- `HStack` → `display: flex; flex-direction: row`
- `ZStack` → `position: relative` + absolute children
- `Spacer()` → `flex-grow: 1`
- `LazyVGrid` → CSS Grid
## 3. Styling — Modifiers chain where CSS classes would go
There are no class names, no stylesheets, no CSS-in-JS library. Every visual property is a modifier method chained directly onto the view. Order matters — `.padding()` before `.background()` gives a different result than after it, just like stacking CSS properties in a specific order can change rendering.
Common modifiers:
- `.padding(16)` → `padding: 16px`
- `.padding(.horizontal, 20)` → `padding-left: 20px; padding-right: 20px`
- `.background(Color.red)` → `background-color: red`
- `.foregroundColor(.blue)` → `color: blue`
- `.font(.system(size: 17))` → `font-size: 17px`
- `.fontWeight(.medium)` → `font-weight: 500`
- `.cornerRadius(12)` → `border-radius: 12px`
- `.frame(width: 100, height: 50)` → `width: 100px; height: 50px`
- `.frame(maxWidth: .infinity)` → `width: 100%`
- `.shadow(...)` → `box-shadow: ...`
- `.overlay(...)` → `::before` or `::after` pseudo-element
## 4. State Management — Property wrappers instead of hooks
`@State` is `useState`. The syntax is different but the contract is identical: declare a variable, mutate it, the view re-renders. What takes more time to learn is the broader family of property wrappers — SwiftUI has several, each with a specific purpose, where React hooks tend to blur together.
```swift
struct CounterView: View {
@State private var count = 0
@State private var loading = false
var body: some View {
VStack {
Text("\(count)")
Button("Increment") {
count += 1
}
if loading {
ProgressView()
}
}
}
}
```
State property wrappers:
- `@State` → `useState()` — local component state
- `@StateObject` → `useState()` with object — owns an ObservableObject
- `@ObservedObject` → props (object) — observes external ObservableObject
- `@Published` → state in class component — triggers UI updates
- `@Binding` → props callback — two-way data binding
For shared state, `ObservableObject` fills the same role as React Context or Redux. You mark properties with `@Published` and the views that observe it re-render automatically — no dispatch, no selectors.
```swift
class AppViewModel: ObservableObject {
@Published var items: [Item] = []
@Published var isLoading: Bool = false
@Published var error: String? = nil
func loadItems() async {
isLoading = true
let result = try await repository.fetchItems()
self.items = result
isLoading = false
}
}
```
## 5. Conditional Rendering — Plain if/else, no ternary tricks
React leans on ternaries and `&&` because JSX is an expression — it has to return something. SwiftUI uses plain `if/else` blocks because the body is just code, not an expression. The result is actually easier to read once you have three or four states to handle, since you're not nesting ternaries.
```jsx
{isLoading ? (
) : error ? (
) : (
)}
```
```swift
if viewModel.isLoading {
ProgressView("Loading...")
} else if let error = viewModel.error {
ErrorView(message: error)
} else if viewModel.items.isEmpty {
Text("Nothing here yet")
} else {
ScrollView {
ForEach(viewModel.items) { item in
ItemCardView(...)
}
}
}
```
Key differences:
- No ternary nesting — `if/else` reads linearly
- `if let` unwraps optionals inline — common Swift pattern
- Empty state (`items.isEmpty`) fits naturally as another branch
## 6. Lists — ForEach maps items to views
`ForEach` is `Array.map()`. The one gotcha: items need to conform to the `Identifiable` protocol, which is SwiftUI's version of React's `key` prop — it needs a stable identity to track which items changed between renders. In practice this usually means your model has an `id` property, which it probably already does.
Key differences:
- `ForEach` replaces `.map()` — no `key` prop needed if item conforms to `Identifiable`
- For grids, swap `VStack` for `LazyVGrid` — CSS Grid with lazy loading built in
- `LazyVGrid` takes an array of `GridItem` values to define columns
## 7. Event Handlers — Actions as trailing closures
Web events are attributes you attach to elements. In SwiftUI interactive views like `Button` take an action closure as their first argument. For non-interactive views you attach `.onTapGesture`, `.onAppear`, or `.onDisappear` as modifiers — the same way you'd add `onClick` to a `div` in React.