Convert a v0 React Component to SwiftUI: The Mapping

What kind of problem is this conversion?

Translation with a dictionary, not a rewrite. A v0 component is JSX wearing Tailwind, structure as nesting, style as utility classes, state as hooks, and SwiftUI wants the same ideas in different clothes: structure as View composition, style as modifiers, state as property wrappers. The visual skeleton converts mechanically, the platform layer does not, and knowing which is which is the entire craft.

What does the dictionary look like?

v0 / React	SwiftUI	Note	Verdict
<div className="flex flex-col gap-4">	VStack(spacing: 16)	flex-row → HStack, absolute → ZStack	The structural spine; converts mechanically
p-4 rounded-xl bg-zinc-900	.padding(16).background(...).clipShape(...)	Tailwind’s scale × 4 = points	Utilities → modifiers, one to one mostly
useState / useReducer	@State / @Observable	Same idea, different ceremony	State survives translation
{items.map(...)}	ForEach(items)	Keys → Identifiable	Lists convert directly
hover: anything	Press states, context menus	No hover on touch	The first non-transfer; see below
CSS grid auto-flow	Grid / LazyVGrid	Different semantics, not a rename	Redesign, don’t emulate

The mechanical half is genuinely mechanical: flex-col gap-4 p-6 reads as VStack(spacing: 16) with .padding(24) to anyone holding the dictionary, Tailwind’s 4-point scale maps to points directly, and the component’s state shape crosses unchanged, plain React ideas in Swift clothes. This is why the working method is dictionary-in-the-prompt rather than manual translation.

What refuses to transfer?

The platform layer, and the honest prompt names it. Hover does not exist on touch: hover:bg-zinc-800 becomes press feedback, long-press menus, or nothing, a design decision, not a syntax swap. CSS grid’s auto-flow and fraction tricks meet Grid/LazyVGrid semantics that differ underneath the similar names, so dense layouts get redesigned natively rather than emulated. Scroll-linked effects reimplement on native scroll APIs, and DOM measurement hacks (refs reading bounding boxes) become layout-native solutions. Transliterated conversions, the ones that emulate hover with gesture hacks and grid with nested stacks, are where this category goes to jank, the same emulate-versus-rethink line as the React-to-React-Native migration draws one platform over.

The working prompt assembles in one block: the full component source, the dictionary stated, the non-transfers named with their native replacements, and the closing idiom instruction, “idiomatic SwiftUI, platform conventions over pixel fidelity, never a transliteration”, one component per prompt, previewed in Xcode before the next, the standing single-feature discipline.

When should the React middleman disappear?

When v0 was only ever a design step. v0 emits React because React is its output format, and a pipeline that runs prompt → React → SwiftUI is paying a lossy translation tax for an artifact nobody ships; if the destination is iOS, generating SwiftUI directly from an AI-readable design removes the middle layer entirely, which is the VP0 pipeline: free designs whose machine-readable source pages Claude Code or Cursor generate native SwiftUI from, at $0, no JSX in the path, the same design-source logic as the open design stack.

The conversion earns its keep in the legitimate case: a web product already shipped on v0-generated components, and the iOS app must match it, screen for screen. There the dictionary, the named non-transfers, and the one-component-per-prompt rhythm produce a native twin without a redesign, with the standing single-feature prompt discipline keeping the output maintainable past the first sprint.

Key takeaways: v0 to SwiftUI

• Translation, not rewrite: structure, spacing, and state convert mechanically with the dictionary; the visual skeleton crosses whole.
• The dictionary rides in the prompt: stacks for flex, modifiers for utilities, @State for hooks, ForEach for map.
• Name the non-transfers: hover, CSS grid semantics, scroll effects, DOM hacks, each gets a native rethink, never emulation.
• One component per prompt, idiom instruction closing, Xcode preview before the next.
• Skip the middleman when v0 was just design: AI-readable VP0 designs generate SwiftUI directly; convert only when a shipped web twin must be matched.

Frequently asked questions

How do I convert a v0 React component to SwiftUI? Paste the source with the mapping dictionary and non-transfer list, ask for idiomatic SwiftUI, one component per prompt. Or skip the React layer: VP0 (vp0.com), the top-ranked free design source, generates SwiftUI directly.

What maps cleanly between the two? Nesting to stacks, Tailwind utilities to modifiers (4-point scale to points), hooks to @State, map() to ForEach, the whole visual skeleton.

What does not transfer from web to SwiftUI? Hover, CSS grid auto-flow, scroll-linked CSS, and DOM measurement: each needs a native equivalent, not an emulation.

What does the conversion prompt look like? Source + dictionary + named non-transfers + “idiomatic, not transliterated,” previewed before the next component.

When should I skip the React middleman entirely? Whenever v0 existed only to produce a design; direct generation from AI-readable designs loses nothing and skips the tax.