For most of the XR industry’s formative years, writing an application for one headset meant writing it for one headset only. Oculus had its SDK. SteamVR had OpenVR. Windows Mixed Reality had its own runtime. Microsoft HoloLens required a completely separate development path. Every time a new device arrived, developers faced a choice: invest engineering time in a new native integration, or leave the platform unsupported. OpenXR was designed to end that cycle.

The Fragmentation Problem OpenXR Solves

Before OpenXR, a developer targeting the major XR platforms needed to maintain separate codepaths for each runtime. The fundamental abstractions — how to query headset pose, submit rendered frames, enumerate input actions — were implemented differently on every platform. Common code was difficult to write because the platforms disagreed on basic architectural concepts.

This was costly in two specific ways. First, engineering resource: maintaining three or four platform SDKs in parallel for a commercial XR application wasn’t unusual, adding significant ongoing overhead. Second, it created platform lock-in: an application built primarily on the Oculus SDK was structurally dependent on Meta’s ecosystem. Switching or expanding to new platforms required near-total rewrites of the XR integration layer.

OpenXR, developed by the Khronos Group — the same standards body behind OpenGL and Vulkan — is a royalty-free open standard providing a single API surface covering the full XR rendering and input pipeline. An application built to the OpenXR standard calls the same functions regardless of which headset is running it. The platform-specific implementation is handled by the conformant runtime on that device.

Conformant Runtimes in 2026

The conformant runtime list covers the devices that matter for commercial XR development:

  • Meta Quest (2, 3, 3S, Pro): OpenXR has been the primary and recommended API since Quest Software 31. The legacy Oculus PC SDK is deprecated for new development.
  • Valve SteamVR: OpenXR is supported as the default runtime for PC VR on SteamVR, covering Valve Index, HTC Vive series, and any SteamVR-compatible device.
  • Microsoft Windows Mixed Reality and HoloLens 2: Microsoft’s Mixed Reality runtime achieved Khronos conformance in 2021. HoloLens 2 is OpenXR-native.
  • HTC Vive (standalone and PC): The VIVE Runtime for OpenXR is conformant across the Focus 3, Focus Vision, and XR Elite product lines.
  • PICO (ByteDance): PICO’s OpenXR runtime is conformant across the PICO 4 and PICO 4 Ultra — important for enterprise deployments in markets where Meta devices face restrictions.
  • PlayStation VR2: Sony’s OpenXR implementation went conformant in 2024, opening the platform to cross-platform toolchains.

Khronos maintains the official conformant products list at khronos.org/conformance/adopters/conformant-products/openxr. Cross-reference it when evaluating a new device for deployment.

Targeting OpenXR in Unity

Unity’s OpenXR Plugin (com.unity.xr.openxr) is the recommended integration path as of Unity 2022 LTS and later. Setup is straightforward:

  1. Install the XR Plugin Management and OpenXR Plugin packages via Package Manager.
  2. In Project Settings > XR Plug-in Management, enable OpenXR for each target platform (Android for standalone headsets, PC for PCVR).
  3. Add Interaction Profiles for each target device under the OpenXR settings — these map physical controller inputs to OpenXR input paths.
  4. Use Unity’s XR Interaction Toolkit (XRI) for interaction logic. XRI abstracts device-specific button mappings behind semantic actions (Select, Activate, UI Press).

The critical practice is to avoid calling platform-specific APIs directly from gameplay code. Any feature requiring a platform extension — passthrough video, eye tracking, face tracking — should be wrapped behind an abstraction layer so it degrades gracefully on devices that don’t support that extension. Unity’s XR Hands package handles hand tracking through OpenXR’s hand tracking extension in a similarly abstracted way.

Targeting OpenXR in Unreal Engine

Unreal Engine 5’s OpenXR integration is provided through the built-in OpenXR plugin (enabled in Edit > Plugins > Virtual Reality > OpenXR). Unreal’s approach differs slightly from Unity’s: rather than a separate interaction toolkit, Unreal’s standard Input System and the Enhanced Input plugin handle controller input, with OpenXR interaction profiles mapped in the project’s input configuration.

For hand tracking in Unreal, the XRHandTracking plugin interfaces with the OpenXR hand tracking extension. Passthrough and mixed reality composition use the OpenXR Extensions Plugin which exposes extension APIs including XR_FB_passthrough (Meta), XR_MSFT_passthrough (Microsoft), and the more recent vendor-neutral XR_HTC_passthrough.

Unreal’s visual fidelity advantage makes it the preferred engine for high-end VR experiences and enterprise simulations requiring realistic rendering. Unity remains more common for AR and lightweight standalone applications where performance headroom is tighter.

Remaining Gaps

OpenXR has achieved critical mass for core rendering and input, but gaps remain.

Hand tracking profiles are the most significant ongoing inconsistency. The core XR_EXT_hand_tracking extension defines joint poses, but gesture recognition and interaction semantics — what constitutes a pinch, a grab, or a point — aren’t standardised. Each platform implements these differently, and applications relying on gesture-based input require per-platform handling that partially reintroduces the fragmentation problem OpenXR was designed to solve.

Eye tracking is covered by XR_EXT_eye_gaze_interaction but implementation quality, gaze accuracy, and whether devices expose gaze data for foveated rendering varies significantly across conformant runtimes.

Spatial anchors and scene understanding — placing persistent content in real-world coordinates and understanding room geometry — remain extension-fragmented. Meta’s Scene API, Microsoft’s Spatial Anchors, and ARKit/ARCore represent competing implementations with no current unified standard, though the OpenXR working group has active items in this area.

Vendor-specific features such as Meta’s Social Presence, Apple Vision Pro’s eye rendering, and device-specific display optimisations will always require extension calls. The OpenXR philosophy is that the core is stable and extensions handle differentiation — this is architecturally sound, but it means developers targeting premium device features will always have per-platform code at the extension boundary.

Why It Matters for Enterprise

For enterprise XR programmes, OpenXR isn’t just a developer convenience — it’s a procurement and vendor-risk consideration. An enterprise application built on OpenXR can be deployed to Meta Quest, HoloLens, and PICO devices with the same codebase and a device-specific build.

When hardware refresh cycles arrive or vendor hardware strategies change — and Microsoft’s HoloLens programme demonstrated that strategies do change — the application doesn’t need to be rewritten. For UK enterprises investing in XR at scale, that’s a meaningful risk reduction.

From a procurement perspective, OpenXR conformance is now a reasonable requirement to include in vendor RFPs for enterprise XR software development. It signals architectural hygiene and reduces long-term maintenance costs. The ROI case for OpenXR-first development is no longer aspirational — it’s commercially straightforward.