AR / VR
Build Across Immersive Runtimes
Keep device tracking, runtime features, durable entities, and product state in separate layers so immersive applications can adapt across browsers, engines, and headsets.
Runtime APIs and product APIs solve different problems
WebXR exposes immersive capabilities through a compatible browser. OpenXR defines a native interface between applications or engines and XR runtimes. Platform SDKs add device-specific features. These layers provide poses, views, input, composition, and optional capabilities. They do not define your durable project, ownership, workflow, or shared world.
Build a product layer above the runtime. It owns stable entity IDs, permissions, revisions, asset references, shared frames, and durable anchors. Adapters resolve that state into the active browser, engine, or platform session.
Poses and reference spaces
A pose is meaningful only in a named space at a time. Viewer, local, floor-aligned, bounded, stage, and application spaces serve different purposes. Normalize runtime poses into a small internal model while preserving the original space and tracking state for diagnostics.
When a user recenters, relocalizes, or moves between mapped areas, update the transform chain instead of rewriting durable entity coordinates. Shared applications synchronize in an application frame and let each client resolve that frame into its current tracking space.
Anchors, hit tests, and depth
Runtime anchors stabilize content relative to tracked space. Product anchors add identity, ownership, persistence policy, and relocalization data. Store the product record and treat runtime handles as temporary. If an anchor cannot be resolved, expose an unresolved state rather than placing content at an arbitrary origin.
Hit tests and depth support placement, occlusion, and interaction with the environment. They can also reveal room geometry. Request only the feature needed, detect capability before entering a workflow, and provide a fallback such as manual placement or a conventional 2D view.
Input as intent
Controllers, hands, gaze, touch, keyboards, and accessibility input vary by client. Product code should respond to intent—select, grab, move, activate, teleport—rather than one button or gesture. Runtime adapters map available input to these actions and report capability.
Keep interactions reversible and constrained. Spatial movement should include snapping, bounds, permissions, and a commit point. Local motion can be responsive while the backend validates a semantic command on release.
Capability-driven design
Detect features such as hands, depth, anchors, passthrough, eye gaze, or bounded space at runtime. Represent capabilities as data so the interface can select compatible workflows. Avoid branching on device brand when a capability check expresses the real requirement.
Portability does not mean identical behavior. It means that missing features produce known fallbacks and that durable state survives when a user moves between clients. Build a tested capability matrix from observed behavior on real hardware.
Comfort, safety, and privacy
Immersive systems can affect balance, attention, and awareness of the physical environment. Avoid sudden movement, content that invades personal space, and flows that require walking while staring at a display. Provide seated options, reduced motion, clear boundaries, and a reliable way to return to non-immersive content.
Camera, depth, hands, gaze, and room mapping are sensitive. Minimize retention, prefer local processing, make sharing visible, and scope tool access to the task. Public spatial content needs moderation and emergency removal.
Continue the field guide
Turn Spatial Data Into a Reliable Contract
Use the journal for implementation patterns, standards context, engine integration, and platform-specific design decisions.
Read the Spatial Systems Journal