OpenXR, the open standard most VR and AR headsets use to run apps, now has an official way to MULTITASK. The Khronos Group, which maintains the standard, announced on October 19, 2026 a pair of RATIFIED extensions that add “spatial containers”: system-managed spaces where an app can show 3D content next to other apps, then switch to a full-screen immersive mode when needed. Khronos compares them to windows on a desktop computer, and the idea will be familiar to anyone who has used Apple Vision Pro.
The two extensions are XR_EXT_spatial_container, the core API for creating and managing containers, and XR_EXT_spatial_container_self_rendering, which lets an app draw into a container with standard OpenXR composition layers. Google, Meta, PICO, Unity, Godot, Varjo and Collabora all put their names behind the work in the Khronos announcement, which says it took about 18 MONTHS of collaboration between runtime and engine makers.
What spatial containers actually do
Each container can run in one of two modes. In BOUNDED mode it occupies a limited volume, so several apps can appear at once, much like apps sitting side by side in a room. In IMMERSIVE mode it behaves like a classic full-screen VR app. An app can create one or more containers and request a switch between the two modes.
The key design choice is that the SYSTEM, not the app, controls where a container sits. That lets the headset or glasses place content where the user wants it, or have a container follow the wearer while walking. The OpenXR specification also treats mode changes as requests rather than commands: a runtime may take “many seconds” to answer, so it can show its own safety prompt before a user drops into a fully immersive scene, and it may DENY the request outright. New containers start hidden and in bounded mode, and the spec notes that any runtime can still run today’s full-screen apps by quietly wrapping them in a single immersive container. In other words, existing OpenXR apps DO NOT break.
The Apple comparison, and where Quest stands today
Apple has offered this model on Vision Pro since its 2024 LAUNCH. visionOS calls the multitasking mode the Shared Space and the full-screen mode a Full Space, and Apple’s headset does not support OpenXR at all. Google’s Android XR uses a similar split between Home Space and Full Space. As Road to VR points out, Meta’s Quest headsets work differently today: only ONE immersive app runs at a time, alongside system features and 2D windows such as the browser.
OpenXR Takes a Page From Apple With New Cross-Platform Spatial Multitasking API
— Road to VR (@RtoVR) October 20, 2026
See more 👉roadtovr.com
What OpenXR adds is a CROSS-PLATFORM version of the same idea. Apple’s approach only works on Apple hardware. A spatial container written to the Khronos spec should, in principle, run on any OpenXR runtime that implements it, from Quest and PICO headsets to SteamVR, Steam Frame and Android XR devices.
Who has committed, and to what
The supporting quotes in the announcement are worth reading closely, because they vary a lot in how firm they are.
- Google is the most concrete platform owner. Jared Finder, Android XR’s platform and SDK lead, said Google is “excited to bring Spatial Container support to Android XR.” No date was given.
- Meta endorsed the model without promising a ship date. Nikita Lutsenko, a distinguished software engineer for wearables at Meta, said multi-app capability “belongs in an open standard.”
- PICO said a standard multi-app model is “the foundation” for multitasking XR workspaces. That matters as ByteDance prepares its next headset, the PICO Space Pro that has surfaced in Japanese filings.
- Godot said it will support spatial containers “in its upcoming release.” The engine’s 4.8 cycle is already in beta, as we covered when Godot 4.8 beta 1 added Vision Pro hand tracking.
- Unity and Varjo backed the extension in general terms, without naming a release.
The timing is tighter than it looks
The extensions are not brand new. They first appeared in the OpenXR 1.1.63 specification, dated September 1, 2026, and the OpenXR SDK 1.1.65 released on October 16 added example code for them to the hello_xr sample app. We noted that release in our look at OpenXR 1.1.65’s seven new multi-vendor extensions. This week’s blog post is the public launch.
Khronos says implementations are “expected to start rolling out across the OpenXR ecosystem during 2026.” As of October 20, that leaves 72 DAYS. A first runtime in preview before the end of the year is plausible, especially from Google. Broad support across headsets, engines and stores this year is UNLIKELY, and Khronos says the working group is still writing a further extension that would let apps hand rendering to a system-provided renderer tuned for each device, from high-end headsets to low-power glasses.
What it means for buyers and developers
For people choosing a headset this fall, nothing changes YET. Khronos has not named any shipping headset that supports spatial containers today, so our Steam Frame vs Quest 3 buying guide still applies as written.
The bigger story is where XR hardware is heading. Meta’s next headset, the Meta VR Glasses unveiled at Connect, is a lighter, controller-free headset due in SPRING 2027. Display glasses are multiplying too. Devices like that are far more useful if several apps can live in the room at once, which is exactly the gap this standard fills. For developers, the practical takeaway is simple: the spec and sample are public NOW, and building for one open multitasking API is a better bet than waiting for each platform to invent its own.
Sources: Khronos Group blog (October 19, 2026); OpenXR registry reference pages; OpenXR-Registry and OpenXR-SDK-Source release notes on GitHub; Road to VR (October 20, 2026).