OpenXR
Also known as: Open XR, OpenXR standard
OpenXR is a royalty-free, open standard from the Khronos Group that lets virtual, augmented, and mixed reality apps work across many headsets using one common interface.
Before it, developers had to support each company's proprietary system separately. While OpenXR has been adopted by most major XR platforms, including Meta, Valve, Microsoft, and Android XR, Apple's visionOS uses its own frameworks instead.
OpenXR, explained at three levels
At home
Think of OpenXR like a standard wall outlet. Any appliance with the right plug works in any outlet, whoever made the appliance or the wiring. Before OpenXR, each VR headset had its own plug, so apps had to be rebuilt for each brand. OpenXR defines one shared way for apps to ask a headset where your head and hands are and to send it images to display.
At work
OpenXR is a royalty-free open standard from the Khronos Group that defines one interface between XR applications and headsets. Developers write an app once against OpenXR, and it runs on any conforming device, including Meta Quest, SteamVR headsets, Pico, and Android XR devices. For businesses, that lowers the cost of supporting several headsets and reduces lock-in to a single hardware vendor.
At home
OpenXR has two sides. Apps speak to it, and each headset maker supplies a 'runtime', the software that answers. When a game asks 'where are the user's hands right now?', the runtime for your headset, such as Meta's or SteamVR's, answers in the standard format. Controls work through actions: the app asks for 'grab' or 'teleport', and the runtime maps those to whatever buttons your controller has.
At work
OpenXR defines a core API for sessions, tracking spaces, input actions, and frame submission, where the app renders images through Vulkan, DirectX, or OpenGL and hands them to the runtime. Optional features arrive as extensions, prefixed by vendor, such as hand tracking, eye tracking, passthrough, and scene understanding. Widely adopted extensions move into the core, as several did in OpenXR 1.1 in 2024. Engines such as Unity, Unreal, and Godot expose this directly.
At home
A standard only removes lock-in for features it covers. New capabilities, such as a new kind of passthrough or body tracking, usually appear first as one company's extension, so apps that use them run only on that brand until others agree on a shared version. While the core works across devices, in my opinion OpenXR's ongoing challenge is that the newest features keep bringing back a little lock-in.
At work
When targeting OpenXR, check each platform's conformance status, which required extensions it supports, and how your engine exposes them. Abstract controls through the action system rather than reading buttons directly, so new controllers and hand tracking work without code changes. Plan separate work for Apple Vision Pro, since visionOS uses its own frameworks such as RealityKit and ARKit. Use the OpenXR conformance test suite and validation layers in testing.
Real-world examples
At home
Sophie bought a VR game on a PC store and was pleased it worked with both her old headset and her new one from a different brand, because the game used OpenXR.
At work
Thomas runs a small Toronto studio building VR training apps. Because his team targets OpenXR through their game engine, they ship one version that works on several headsets clients already own.
How it compares
| feature | OpenXR | Proprietary XR APIs |
|---|---|---|
| Ownership | Open standard, Khronos Group | Single company |
| Device support | Many headsets | One vendor's devices |
| Lock-in risk | Lower | Higher |
| Newest features | Often via extensions | Sometimes earlier |
OpenXR lets developers build once for many headsets.
For analysts
When commissioning XR apps, I'd require OpenXR support where possible, so you can change headset vendors later without paying to rebuild the app.
History & origin
As VR headsets multiplied after 2016, the industry suffered from fragmentation: Oculus, SteamVR, and Windows Mixed Reality each had separate software interfaces. The Khronos Group, which also manages OpenGL and Vulkan, formed the OpenXR working group in 2017 with major companies. OpenXR 1.0 was released in July 2019. Meta made OpenXR its preferred interface and deprecated its older proprietary APIs in the early 2020s, and game engines such as Unity, Unreal, and Godot added OpenXR support. OpenXR 1.1 arrived in 2024, folding common extensions into the core standard, and Google built Android XR around it. In my view, OpenXR is one of the reasons small studios can afford to ship on several headsets at once.