OpenXR, WebXR or native SDKs: how to choose an enterprise XR stack

Vendor lock-in in XR is rarely a single decision. It accumulates in five layers, and a team can be portable in one while tied down in another: the runtime that drives displays, cameras and trackers; the engine or framework developers write against; the store or distribution channel; device management, which enrolls, locks down and updates devices; and the content format, which decides whether 3D assets can move to another tool.

A project that writes to an open runtime API but stores every scene in one engine's proprietary format, and ships only through one vendor's store, is still locked in. The aim is not zero dependency but knowing which dependencies you chose and what replacing each would cost. ColdAI builds on open runtimes such as OpenXR and WebXR where the task allows it⁸.

OpenXR is a royalty-free standard from the Khronos Group that gives applications a common API for tracking, input and rendering on AR and VR devices¹. Vendors ship OpenXR runtimes, and an app written against the API, usually through an engine, runs on any conformant one. Khronos lists runtimes from vendors including Meta, Google for Android XR, HTC, Pico, Valve, Varjo, Magic Leap and Microsoft, and engine support in Unreal Engine, Unity and Godot¹.

Two caveats matter. Many features enterprise apps want, such as passthrough, scene understanding and some hand or eye tracking, arrive as extensions, some shared across vendors and some owned by one. OpenXR 1.1 moved several widely used extensions into the core specification¹, but an app relying on a vendor extension still needs a fallback. And conformance covers the API, not the store, the management console or the device lifecycle; those stay vendor-specific.

Android XR shows the engine route at work: Google's guidance states that Unity's Android XR support is built on OpenXR⁶. Apple is the notable absence. visionOS apps are built with Apple's frameworks, such as SwiftUI, RealityKit and ARKit, or through Unity's visionOS support⁵, and Apple does not appear among the runtime vendors Khronos lists¹.

WebXR is a W3C API, developed by the Immersive Web Working Group, that lets a web page start an immersive session on a headset or phone². Its attraction is distribution: a link replaces store submission, packaging and per-device installs, and updates reach everyone on their next visit. That suits product viewers, sales configurators and light internal pilots.

The constraints are real. The specification requires a secure context, and an immersive session normally starts only from a user action such as a tap, with the user's consent². That makes unattended kiosk flows awkward in a browser. Immersive AR sits in a separate AR module that a browser may or may not implement². At the visionOS 2 release in 2024, for instance, Safari on Apple Vision Pro enabled immersive VR sessions by default but not the AR module³⁴, so check current release notes. Performance headroom is lower than native, and vendor-specific sensors are reachable only if the browser exposes them.

Every platform also offers its own SDK, and new hardware features usually appear there first. On Apple Vision Pro, ARKit provides scene reconstruction, image anchoring and skeletal hand tracking with the user's permission⁵; Android XR documents its Jetpack XR SDK as one route alongside OpenXR, Unity, Godot, Unreal Engine and WebXR⁹.

Native makes most sense when one platform has been chosen deliberately and the experience depends on a feature only it offers, or must behave like part of the operating system. The cost arrives the day another device joins the estate: a second codebase. Teams that go native usually confine platform code to a thin layer and keep business logic, data access and content shared.