OpenXR's Spatial Containers Put Your App in a Window Beside Other Apps, and the Spec Landed in 1.1.63

A spatial container is a system-managed space where your app displays its content. Think of it as a window with volume, sitting in the room instead of on a desktop. The Khronos OpenXR Working Group has published two extensions that let you use them: XR_EXT_spatial_container, which creates and manages the containers, and XR_EXT_spatial_container_self_rendering, which lets you draw into one with OpenXR composition layers.

Your app can hold more than one container, and each one runs in one of two display modes. Bounded is the windowed mode, where you sit beside other apps and nobody takes the whole view. Immersive is the mode you already ship, full screen. The useful part is that you can ask to move a container between them while the app runs, instead of choosing once at startup. Ask is the right word. The runtime answers with an event, sometimes seconds later, and it can say no. It also only has to support one of the two modes, so check what it reports before you design around both.

You do not pick where the container goes. Khronos is blunt about it: "A spatial container's position is controlled by the system." The person wearing the headset can put it where it works for them, or the system can have it follow them when they are on the move. The system also shows and hides containers, and it alone decides which ones take input. You can request that a container be shown. You cannot request that it be interactable. If your app has always assumed it owns the frame from the moment it starts, that assumption is the thing you rewrite first. With containers enabled, your session never reaches the visible or focused states at all. It sits in idle for its whole life, and visibility and focus arrive as events for each container instead.

The spec is older than the announcement

Khronos posted the announcement on October 19, which is why it reached your feed this week. The extensions themselves are not new that day. Both went into the registry with the OpenXR 1.1.63 specification release on September 1, listed there as new ratified multi-vendor extensions. If you pull the registry every month, they have been in your headers for seven weeks.

What landed recently is the sample code. The OpenXR SDK 1.1.65 release on October 16 added spatial container example code and the matching Android manifest entries to hello_xr, the reference sample app, along with a command line option that switches hello_xr between its classic example and the new spatial container one. That new example is the sample the Khronos post links as khr.io/hellospatialcontainers, which lands on openxr_program_spatial_containers.cpp in the OpenXR-SDK-Source repo. It creates up to three containers and binds a controller button to flip the third between bounded and immersive. Start there. The normative wording is in the OpenXR 1.1 specification when you need it.

Who signed on

The working group puts eighteen months of collaboration behind these extensions, and the names attached are the ones that decide whether a cross-vendor API becomes real. Supporting quotes come from Google (Jared Finder, XR platform and SDK lead for Android XR), Meta, PICO, Unity, Varjo, the Godot XR Team, and Collabora, which says it served as a key reviewer of the extensions. The spec's own contributor list runs wider, with Valve, Qualcomm, NVIDIA, Microsoft and the LÖVR engine on it too. Collabora's Dr. Rylie Pavlik, a principal software engineer there and the OpenXR specification editor, calls the multi-app functionality "a step-change in capability and application model," and adds that it comes "without abandoning the familiarity of the majority of the OpenXR API." That second half is the part you will feel when you port.

The Godot XR Team says Godot will support spatial containers in its upcoming release, and the code is further along than that line suggests. The integration pull request merged on September 8 under the 4.8 milestone, so it is in the build behind Godot 4.8 beta 1, out October 15. Its author is Fredia Huya-Kouadio, Godot's lead Android maintainer, who also appears on the extension's contributor list and was one of the maintainers behind the OpenXR Vendors plugin v5.1 release in May. An engine implementation is what lets a two-person team use this without opening a single extension header. Monado is the other half of the question, and its main branch has no spatial container support yet. A ratified extension is portable only as far as the runtimes that implement it.

Nothing ships it yet

That is the honest limit. Khronos expects implementations to start rolling out across the ecosystem during 2026, which leaves about ten weeks, and it names no runtime that offers them today. Google comes closest to a commitment: it says it is "excited to bring Spatial Container support to Android XR." You can compile against the extension right now. You cannot yet ask a retail headset for a bounded container and get one.

The direction is not really in question, because a proprietary version already arrived. Late last month Horizon OS v2.9 reached Meta's Public Test Channel with a Window Manager in Quick Settings, and its windows now launch into the room instead of into a fixed row. Meta did that for 2D panels, on its own stack. Spatial containers bring the same idea to OpenXR apps, 3D volumes included, with a vendor-neutral API in front, which is the difference between writing your panel behavior once and writing it per platform. Khronos argued at SIGGRAPH in July that OpenXR was turning into a spatial computing platform rather than a portability layer. This is what that argument looks like once it reaches a header file.