Application programming interface
An application programming interface (API) is a defined interface between software components that lets one program request services or data from another without knowing how the other component is built internally. An API specifies the functions, data structures, parameters, and return values a developer can call, hiding the implementation behind that contract. The term covers everything from a single function library to a network service reached over the internet.[1]
In virtual reality (VR) and augmented reality (AR), APIs are the means by which an application talks to headset hardware, tracking systems, controllers, and the host operating system. A VR program does not address the display panels or inside-out tracking cameras directly; it calls an API such as OpenXR, WebXR, OpenVR, ARKit, or ARCore, and a runtime supplied by the hardware vendor carries out the request. Because a single API can sit in front of many different devices, it is the layer that decides how portable an XR application is across headsets and platforms.[2][3]
Definition and scope
An API is a contract, not a program. It states what a caller may ask for and what it will get back, while leaving the provider free to change the code behind the contract. The same idea applies at several levels: a function library exposes an in-process API; an operating system exposes a system-call API; and a remote server exposes a web API reached over a network.[1]
An API differs from an application binary interface (ABI). An API is defined at the level of source code, so a program written against an API must be recompiled for each target. An ABI is defined at the binary level and fixes details such as calling conventions and data layout, so a compiled program can run against any implementation that honours the same ABI. POSIX is an example of an API specification, while the Linux Standard Base defined an ABI.[1]
An API is also distinct from a software development kit (SDK). An SDK is a package of tools, libraries, documentation, and sample code that a developer downloads to build for a platform; the API is the set of callable interfaces inside it. Several VR and AR products are both at once. OpenVR, for instance, is described by its maintainer as both an SDK and an API.[4]
Origin and history
The phrase "application program interface" was first recorded in 1968, in a paper by Ira W. Cotton and Frank S. Greatorex titled "Data structures and techniques for remote computer graphics," presented at an AFIPS conference. The work aimed to free programmers from the idiosyncrasies of particular graphics displays and to give them hardware independence, which is the same separation of application from device that modern XR APIs provide.[1] The term was carried into databases by Christopher J. Date in a 1974 paper, "The Relational and Network Approaches: Comparison of the Application Programming Interface."[1]
As networked computing spread through the 1970s and 1980s, developers wanted to call code located on other machines, which led to remote procedure calls. During the 1990s competing standards including CORBA, COM, and DCOM offered ways to expose interfaces across processes and networks.[1] The style most associated with present-day web APIs, Representational State Transfer (REST), was defined by Roy Fielding in his 2000 doctoral dissertation, "Architectural Styles and the Design of Network-based Software Architectures," at the University of California, Irvine, as an abstraction of the architectural elements of the World Wide Web.[1][5]
How APIs work
A caller invokes an API by naming a function or endpoint, passing arguments in the form the contract requires, and receiving a result or an error code. The provider validates the request and performs the work behind the interface. Two broad patterns dominate.
In a procedural or library API, the application links against a library and calls functions in the same process or against a local runtime. Most native VR and AR APIs work this way: an application calls into a runtime supplied by the headset vendor. In OpenXR, for example, an application creates an instance (a connection to the runtime), creates a system that selects the display and input devices, sets up buffers for the rendered views, and then drives a render loop that submits frames each cycle.[2]
In a web API, the application sends a request to a remote server, commonly over HTTP, and receives structured data, often encoded as JSON or XML. REST and similar styles describe how such requests and responses are organised. Web APIs separate the caller and provider by a network rather than by a process boundary, but the contract idea is the same.[1]
APIs in virtual and augmented reality
XR APIs sit between an application and the headset's runtime. They let a program detect what hardware is present, query its capabilities, read the predicted pose of the head and controllers each frame, and submit rendered images for display at the correct refresh rate. Because the runtime is provided by the device vendor, the same application binary can run on different headsets as long as each one ships a conformant runtime for the API the application targets. This is the mechanism behind the long-running effort to reduce fragmentation in the VR and AR market.[2][6]
OpenXR
OpenXR is a royalty-free open standard from the Khronos Group that defines a common API for VR and AR development across many devices. Version 1.0 was released on 29 July 2019 at SIGGRAPH, after a 0.90 provisional specification, with the stated goal of letting a developer build an application once and port it to multiple platforms.[6] Architecturally, OpenXR defines the application-facing interface used by developers and a device-side interface that hardware vendors implement as a runtime; the runtime is a software library on the host that maps each OpenXR function to the capabilities of the underlying device.[2] Version 1.1, released on 15 April 2024, folded several widely used extensions into the core specification to cut fragmentation, including local-floor reference spaces, stereo with foveated rendering, the grip surface pose, the XrUuid data type, and the xrLocateSpaces function.[7] Vendors with conformant OpenXR implementations include Acer, ByteDance, Canon, HTC, Magic Leap, Meta, Microsoft, Sony, Xreal, Qualcomm, Valve, Varjo, and Collabora's Monado open-source runtime. OpenXR is also supported by the major game and rendering engines, including Unity, Unreal Engine, Godot, and Blender.[7]
WebXR Device API
The WebXR Device API brings VR and AR to web browsers. It lets a web page detect whether XR is available, request a session in inline, immersive-vr, or immersive-ar mode, poll device and input state each frame through reference spaces and input sources, and present imagery at the device's frame rate.[3] It is developed by the W3C Immersive Web Working Group, with incubation handled by the Immersive Web Community Group, and as of 9 June 2026 it stood at the status of a W3C Candidate Recommendation Draft.[3] WebXR replaced the earlier WebVR proposal and is the standard means of running VR and AR experiences inside a browser without a native install.[3]
OpenVR and SteamVR
OpenVR is an SDK and API that Valve released on 30 April 2015 for building SteamVR software. It is the default API and runtime for SteamVR and acts as the interface between VR hardware and software; its central system interface is IVRSystem (renamed from the earlier IHmd).[4] OpenVR was built for multiple vendors rather than a single headset, so applications could target devices including the HTC Vive and others through one interface.[4] Valve has since moved its development toward OpenXR. In statements reported in 2020, Valve said new SteamVR features would appear on the OpenXR side rather than as new OpenVR APIs, while existing OpenVR applications would continue to work on current and future hardware.[8]
Meta Quest APIs
Meta's Quest platform exposes native development through OpenXR. Meta deprecated its older Mobile SDK and the VrApi library on 31 August 2022 and made OpenXR the default backend, so new platform features are delivered as OpenXR extensions and through the Meta XR Core SDK rather than as updates to the legacy Oculus APIs.[9] Platform-specific capabilities, such as Meta's own OpenXR extensions, sit alongside the standard OpenXR core that an application can call to remain portable.[9]
ARKit and ARCore
On mobile devices, two vendor APIs dominate AR. ARKit is Apple's AR API for iOS, iPadOS, and visionOS, introduced for iOS 11 at the Worldwide Developers Conference in June 2017; it uses the device camera, processor, and motion sensors for scene understanding so developers can place virtual content in the real world. Apple has stated the framework requires devices with an Apple A9 or later processor.[10] ARCore is Google's equivalent for Android. Google released ARCore 1.0 on 23 February 2018, out of developer preview and able to run on about 100 million Android phones at launch, providing environmental understanding for placing virtual objects on real surfaces.[11]
Engine and framework APIs
Most VR and AR titles are not written directly against a hardware API. Developers more often use a game engine such as Unity or Unreal Engine, which provides its own higher-level API and connects to OpenXR or a vendor runtime underneath. For browser-based work, JavaScript frameworks including A-Frame, three.js, and Babylon.js wrap the WebXR Device API in a higher-level scene API. In each case the engine or framework API is layered above the device API, and the device API is layered above the vendor's runtime.[7][3]
Selected VR and AR APIs
| API | Maintainer | First release | Scope |
|---|---|---|---|
| OpenVR | Valve | 30 April 2015 | SteamVR runtime and headsets |
| ARKit | Apple | June 2017 (iOS 11) | Mobile AR on iOS / iPadOS / visionOS |
| ARCore | 23 February 2018 (1.0) | Mobile AR on Android | |
| OpenXR | Khronos Group | 29 July 2019 (1.0) | Cross-platform VR and AR |
| WebXR Device API | W3C Immersive Web WG | Candidate Recommendation Draft (9 June 2026) | VR and AR in web browsers |
Current status
By the mid-2020s the XR industry had largely converged on OpenXR as the common native API, with conformant runtimes from most major headset makers and support in the leading engines, while WebXR served the same role for browser-delivered content.[7][3] Older vendor-specific paths have been wound down: Valve has directed new SteamVR development to OpenXR, and Meta deprecated its legacy mobile API in favour of an OpenXR backend.[8][9] On mobile, ARKit and ARCore remain the dominant AR APIs for their respective operating systems.[10][11]
References
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 "API". https://en.wikipedia.org/wiki/API.
- ↑ 2.0 2.1 2.2 2.3 "OpenXR Overview". https://www.khronos.org/openxr/.
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 "WebXR Device API". 2026-06-09. https://www.w3.org/TR/webxr/.
- ↑ 4.0 4.1 4.2 "OpenVR". https://en.wikipedia.org/wiki/OpenVR.
- ↑ Fielding, Roy T. (2000). "Architectural Styles and the Design of Network-based Software Architectures". https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
- ↑ 6.0 6.1 "Khronos Releases OpenXR 1.0 Specification Establishing a Foundation for the AR and VR Ecosystem". 2019-07-29. https://www.khronos.org/news/press/khronos-releases-openxr-1.0-specification-establishing-a-foundation-for-the-ar-and-vr-ecosystem.
- ↑ 7.0 7.1 7.2 7.3 "Khronos Releases OpenXR 1.1 to Further Streamline Cross-Platform XR Development". 2024-04-15. https://www.khronos.org/news/press/khronos-releases-openxr-1.1-to-further-streamline-cross-platform-xr-development.
- ↑ 8.0 8.1 Hamilton, Ian (2020-06-25). "Valve: Future SteamVR Features Will Be On 'OpenXR Side' As Valve Transitions From OpenVR". https://www.uploadvr.com/valve-openxr-transition-openvr/.
- ↑ 9.0 9.1 9.2 "OpenXR Mobile SDK". https://developers.meta.com/horizon/documentation/native/android/mobile-intro.
- ↑ 10.0 10.1 "ARKit". https://en.wikipedia.org/wiki/ARKit.
- ↑ 11.0 11.1 "Announcing ARCore 1.0 and new updates to Google Lens". 2018-02-23. https://blog.google/products/google-ar-vr/announcing-arcore-10-and-new-updates-google-lens/.