At GDC 2017, the Khronos Group announced OpenXR as a proposed open, royalty-free API for XR (VR/AR) devices. The goal was to reduce fragmentation so developers could target multiple headsets and platforms with less device-specific code. This announcement set the stage for a multi-year standards process and vendor adoption push.
Khronos began formal development work on OpenXR in early 2017, organizing a working group and starting design discussions. This early phase focused on defining core concepts like sessions, spaces (coordinate systems), and device/input abstraction needed for cross-vendor interoperability. It marked the shift from a public idea to an engineering effort.
At SIGGRAPH 2018, Khronos and member companies demonstrated prototype OpenXR implementations running the same content across different headsets. Public demos helped validate that the draft API design could work across vendors and runtime systems. This was a key step toward a publishable specification.
Khronos released the OpenXR 0.90 provisional specification to the public for review and feedback. “Provisional” meant the API was not yet final and developers and implementers were encouraged to test it and report problems. This opened the standard to broader scrutiny before a stable 1.0 release.
Khronos ratified and publicly released OpenXR 1.0 at SIGGRAPH 2019. The 1.0 milestone established a stable baseline API intended to remain backwards compatible, giving hardware vendors and software developers a shared target. Khronos also highlighted shipping or imminent runtime implementations from major XR platform providers.
Khronos launched the OpenXR 1.0 Adopters Program and open-sourced the OpenXR Conformance Test Suite (CTS). The CTS is a set of tests used to verify whether a runtime correctly implements the OpenXR specification, supporting consistent behavior across vendors. This created a formal path for “conformant” OpenXR implementations.
Facebook (now Meta) achieved OpenXR 1.0 conformance for Oculus Quest 2, signaling that OpenXR was becoming a practical target for standalone VR platforms. Conformance meant the runtime had passed Khronos’s adopter process requirements, including CTS-based testing. This helped developers justify investing in OpenXR as a long-term interface.
Microsoft’s OpenXR runtime for HoloLens 2 and Windows Mixed Reality became conformant with OpenXR 1.0. This was important because it brought a major enterprise and mixed-reality platform into the same standards ecosystem as consumer VR. It strengthened OpenXR’s role as a cross-platform interoperability layer.
HTC achieved OpenXR 1.0 conformance for VIVE Cosmos and related VIVE runtimes. With multiple large XR vendors now conformant, OpenXR moved from a new spec to a workable interoperability baseline across competing ecosystems. This broadened the set of devices developers could target with one API design.
Valve’s SteamVR runtime became conformant with OpenXR 1.0, making OpenXR a realistic standard target for PC VR distribution. SteamVR’s position in the PC VR ecosystem meant many headsets and applications could align on OpenXR rather than vendor-specific APIs. This helped unify tooling and testing around a common runtime interface.
Collabora’s Monado open-source runtime achieved OpenXR 1.0 conformance for a simulation device, demonstrating that conformant OpenXR implementations could exist outside major proprietary platforms. This provided an open development base for research, Linux-focused XR work, and experimentation with runtime components. It reinforced the “open standard” story by pairing an open spec with an open runtime.
Khronos released OpenXR 1.1 to reduce fragmentation by moving widely used extensions into the core specification. This “promotion” approach kept OpenXR flexible (via extensions) while gradually standardizing proven features for better cross-platform portability. By this stage, Khronos stated that most major XR platforms had transitioned to using OpenXR.
OpenXR standard development and adoption (2016–2023)