Windows, docks, hand menus and controls, in the scene.
WebXR UI Extensions is a library for building user interfaces inside a WebXR scene. It gives you movable, resizable windows that can be dragged, snapped into fixed regions of the scene, and filled with buttons, sliders and other controls. Panels are written in UIKitML, IWSDK's HTML and CSS-like markup for spatial panels. The core logic is plain TypeScript with no dependency on any 3D engine.
How it is built
Every Reality Toolkit WebXR family has the same shape. The logic lives in an engine-free core that carries the tests. A thin adapter binds that core to one engine, depends on it, and re-exports it, so your app installs one package. Where families need to agree on a shape, they share plain contracts rather than importing each other.
Your app
Owns the content: meshes, panels, placement, physics and sound files. Installs one adapter per family and wires families together with subscriptions in the one place where both halves are in scope.
One adapter per engine
The only place an engine name appears. It reads the engine each frame, feeds the core, applies the core's results back, and reports anything the engine cannot do instead of failing silently.
The engine-free core
All the logic, as plain TypeScript with no engine import. An architecture test fails the build the moment one lands, which is what lets the same behaviour run unchanged on every engine, and be tested without a headset.
Shared contracts
One description of input, poses and pointers, published from its own repository with zero dependencies, so an adapter written once feeds both the Interactions and UI Extensions families.
Where it sits in the stack
Four families, one rule: no package references a sibling family, not even a type. What crosses a boundary is a subscription your app makes, such as playing an Environment cue when an Interactions press fires.
The Service Framework for the web sits beside these four and keeps its own site: serviceframework.realitycollective.net. The layering rule explains the boundaries in full.
Why you would use it
One window API
The window manager is the one place an app drives a window from: show, hide, pin, dock, home, minimise and the title-bar buttons, with events for everything that changes.
Scenes as portable data
A SceneDescriptor lists windows and regions as plain data. The IWSDK, XR Blocks and plain three.js versions behave identically from identical data.
Markup, not components
A plain element carrying a data-uix attribute becomes a stepper, a toggle, an expandable section or a log view, so you write markup rather than wiring controls.
Pick an adapter
Install exactly one. Each re-exports the whole core, so an app installs one package. Depend on the core directly only for headless logic, tests, tooling or a new adapter.
Meta IWSDK
iwsdk-uiextensionsThe reference implementation: ECS systems binding the core to @iwsdk/core, a window factory, regions, hand menus and the shipped examples.
reference, full feature setRead more →Google XR Blocks and plain three.js
xrblocks-uiextensionsHosts the windowing core in any three.js WebXR scene, including XR Blocks Scripts, with uikit panels, follow mode and desktop controls.
experimental, partial feature setRead more →Developer tooling
uix-devtoolsAn edit-session launch gate, runtime UIKitML compilation and the uix-dev CLI with a Cloudflare quick tunnel and QR onboarding for headset testing. Never ship it.
dev dependency onlyRead more →Who does what
Read the ladder top to bottom. The middle column is the stage every engine goes through; the core owns the left, the adapter you install owns the right.
Five words you will meet
Where to next
Welcome to WebXR UI Extensions →Requirements, packages, use cases and a quickstart on one page.Basics →The concepts, one page per topic, in the same order as the Service Framework basics.Features →The additional capabilities that ship with the family, and the design decisions behind it.Host integrations →One page per package: the core and the adapter for each engine, with what it cannot do and why.Examples →The shipped demos and examples, broken down piece by piece.API reference →Generated from the TSDoc in every package of the family.Source and issues: GitHub. Questions go to the Reality Collective Discord.