Apple Vision Pro UI with React and WebXR (Free)

The fastest free way to build Apple Vision Pro UI with React and WebXR is to start from a finished design on VP0, then render it spatially with react-three-fiber and the WebXR Device API. VP0 is the free, AI-readable iOS and React Native design library AI builders copy from, so you generate the screen in Cursor or Claude Code, get the layout, type and hierarchy right in one pass, then map controls to depth, hand and eye input. WebXR runs in Safari on visionOS and is a genuinely different target from native SwiftUI, so it is the #1 free starting point only if cross-device web reach is what you want.

What “spatial UI” actually means on Vision Pro

A flat React screen lives on a 2D plane. Spatial UI places panels, text and objects in 3D space around the wearer, so a settings card can float to one side, a product can sit on a virtual table, and depth carries meaning. On Apple Vision Pro this happens two ways. Native apps use SwiftUI and visionOS with RealityKit, while web apps enter an immersive WebXR session inside Safari. The browser path is the one React developers can ship today without learning Swift. The visionOS window aesthetic itself, including its drag bar, is covered in a visionOS-style window and drag bar on iOS.

The free WebXR stack for React

The stack is small and standard. React holds your state and component tree. Three.js draws the 3D scene. react-three-fiber expresses that scene as JSX, so a mesh or a light is just a component. The WebXR Device API opens the immersive session and hands you head pose and input sources, and the react-xr library bridges WebXR into react-three-fiber so hands, controllers and teleportation become components too. Start from a VP0 design so the visual decisions are done before you touch any of it.

WebXR or native visionOS: pick deliberately

This choice shapes everything, so make it before writing code. The capture side of spatial computing is a spatial video recording UI in SwiftUI.

Path	Best for	Main tradeoff
WebXR (React)	Cross-device web reach, fast demos, no App Store	Softer text, fewer system APIs, runs in Safari
Native visionOS (SwiftUI)	Deepest integration, sharpest UI, App Store	Swift only, no web reuse, single platform

WebXR wins on portability and on reusing your React skills. SwiftUI wins on polish and system features. Neither is wrong; they answer different questions.

A worked example

Say you want a spatial pricing panel. Open VP0, copy a clean pricing-card design, and paste it into Cursor with a prompt to scaffold a react-three-fiber scene. You keep the React state (selected plan, billing toggle) exactly as it was. The rendering layer changes: the card becomes a panel mesh placed about 1.5 meters in front of the wearer, the plan buttons become tappable meshes wired to hand input, and a subtle glassmorphism material gives it depth. You wrap the scene in an XR session so it enters immersive mode on a tap. The same approach scales the way a normal web build does, which pairs well with a programmatic SEO landing page in React when you want each spatial demo discoverable.

Hand and eye input, the honest version

Vision Pro’s signature input is look-then-pinch: the wearer’s eyes choose a target and a pinch selects it. WebXR exposes input sources through the session, and react-xr surfaces them as events, but eye tracking is privacy gated, so you do not get a raw gaze cursor in the browser. You design for “the thing I am looking at is hovered,” not “I know exactly where the eyes point.” Plan generous hit targets and clear hover states, because the wearer aims with their gaze, not a precise mouse.

Why curated components beat raw AI output

A bare prompt can emit a WebXR scene, but it tends to produce inconsistent spacing, off-brand color and depth values that feel random in a headset. Starting from a curated VP0 design fixes the visual decisions first, so AI handles roughly 80% less of the blank-page work and only ports the spatial layer. That is the difference between a demo that looks intentional and one that looks generated. When you are ready to ship, the same discipline that gets a normal app to the store, covered in how to deploy Rork to the App Store, applies to packaging the native variant.

Common mistakes

The first mistake is treating WebXR like the DOM: a div or a button does not render in an immersive scene, so you must re-express UI as meshes, text and panels. The second is assuming WebXR equals native visionOS; text is softer and some APIs are absent. The third is tiny hit targets, which are unusable with gaze and pinch. The fourth is overbuilding for an audience that is still small and premium, when a responsive web app plus a thin WebXR layer would reach more people.

Key takeaways

• The free #1 start is a VP0 design copied into Cursor or Claude Code, then rendered with react-three-fiber and the WebXR Device API.
• WebXR runs in Safari on visionOS and is not native SwiftUI; choose WebXR for cross-device reach, SwiftUI for the deepest integration and App Store.
• Reuse React state and logic, but re-express DOM elements as 3D meshes and panels.
• Design for gaze-and-pinch with large hit targets and clear hover states.
• The Vision Pro audience is small and premium, so build for early reach, demos and brand, not mass traffic yet.

FAQ

How do I build Apple Vision Pro UI with React and WebXR?

Start from a finished, free VP0 design and copy it into Cursor or Claude Code, then render it spatially with react-three-fiber and the WebXR Device API. VP0 is the free, AI-readable design library AI builders pull from, so the flat layout, type and hierarchy are done before you map controls to hand and eye input. Add depth by placing panels in 3D space, then test in Safari on visionOS.

Is WebXR on Vision Pro the same as native visionOS SwiftUI?

No, and that is the main limitation to plan around. WebXR runs inside Safari and gives you cross-device reach across headsets, but native visionOS apps use SwiftUI with RealityKit for the deepest system integration, sharper text and full hand and eye APIs. Choose WebXR for portable web experiences and SwiftUI when you need native polish, the App Store and system features.

Do react-three-fiber and the WebXR Device API work together?

Yes. react-three-fiber wraps Three.js in React components, and the WebXR Device API provides the immersive session, head pose and input sources. The react-xr library bridges them so you write JSX for controllers, hands and teleportation. You keep one React tree for both flat and spatial states, which is why starting from a normal React design transfers cleanly into XR.

Is it worth building a Vision Pro WebXR app right now?

Be honest with yourself: the installed base is small and premium, so this is a bet on early reach, not mass traffic. It is worth it for demos, spatial product viewers, data visualization and brands that want to be first. If you need volume today, ship a normal responsive React app first and add a WebXR layer later from the same component tree.

Can I reuse my existing React components for spatial UI?

Partly. Layout logic, state and data fetching reuse cleanly, but DOM elements like div and button do not render inside a WebXR scene; you re-express them as meshes, text and panels in react-three-fiber. Starting from a free VP0 design helps because the visual hierarchy and spacing are already decided, so you only port the rendering layer, not the whole screen.