OpenXR Spatial Containers Bring Windowed Multitasking to 3D Apps

The most useful part of the new OpenXR Spatial Container extensions is the behavior they standardize: 3D apps can sit in a bounded window alongside other apps, then expand into a full immersive space. That's the multitasking model desktop and phone users take for granted, and until now it hasn't had a common, cross-vendor definition for volumetric content.

OpenXR is the open API that Khronos manages for AR, VR, and MR development, and it's the same consortium behind OpenGL, Vulkan, and WebGL. The pitch has always been that developers write once and run on any compliant headset without reaching for vendor-specific core APIs. Almost every headset, engine, and runtime supports it today. Apple Vision Pro and PlayStation VR2 on PS5 are the notable exceptions.

What a Spatial Container actually does

A Spatial Container is a system-managed space that an app can request and fill with volumetric 3D content. Apps can own more than one container, and each one can switch between two modes. The first is a bounded display mode meant for running several apps at once. The second is a full-screen immersive mode, which is what most current OpenXR titles already deliver.

The detail I'd flag for developers is placement. The system controls where a container sits. Users can choose a preferred location, or the system can keep a container following them as they move through a room. That's a sensible division of labor. An app shouldn't be deciding where its window lands relative to everything else a person is doing, and a runtime that owns placement can keep multiple 3D apps from fighting over the same patch of floor.

Two extensions, and a renderer on the way

The first release is two ratified extensions in the OpenXR Registry. XR_EXT_spatial_container is the core piece, letting apps create and manage containers. XR_EXT_spatial_container_self_rendering lets an app draw into a container using OpenXR composition layers. If you've written OpenXR rendering code before, that second one is where your existing work will matter most, since it keeps the rendering model familiar.

The Khronos OpenXR Working Group says it is also building extensions for a system-provided renderer, tuned to the hardware underneath. The stated range runs from high-performance headsets down to lower-power devices. That's the part I'd watch most closely. Self-rendering gives developers control, but it also means every app carries its own performance budget. A shared renderer that adapts to the device could make multitasking far more practical on lighter hardware, where a few 3D windows at once would otherwise stress the chip quickly.

How it compares with what's shipping now

The closest reference point is visionOS on Apple Vision Pro. Its Shared Space lets windowed and volumetric 3D apps run side by side in a system-managed environment, and apps can move into a Full Space for immersive use. RealityKit handles much of the rendering on that side. The OpenXR extensions aim for a similar shape without tying it to one vendor's framework.

Pico OS 6, which is slated for the upcoming Pico Space Pro, is built around a similar idea. It uses a system-level compositor and what Pico calls the Pico Spatial Engine, a unified rendering architecture that lets 2D and 3D apps share the same space. The background can be a virtual environment or passthrough. Pico's approach shows the model is achievable on a shipping product, not just a spec sheet.

The current picture on the other two major platforms is more limited. Google's Android XR and Meta's Horizon OS both support multitasking for 2D apps, but each only runs a single 3D app at a time. That's the gap Spatial Containers are meant to close, and it's where the standard's value to buyers will show up first. If you own a headset that can only host one immersive app, a common container model is the path to windowed 3D apps that don't require a platform rewrite.

Where Google and Meta might go

Google's XR platform and SDK lead, Jared Finder, is quoted in Khronos's announcement saying the company is "excited to bring Spatial Container support to Android XR." That's a clear signal of intent, and Android XR's existing 2D multitasking makes it a natural place for the model to land.

Meta hasn't committed to the extensions in its statement, and that's the more interesting story. The company announced "Augments" for Quest 3 at Meta Connect 2023, and the idea was system-managed 3D apps built in Meta Spark Studio, the now-defunct Windows and macOS tool for smartphone AR filters. Spark Studio supported importing and animating 3D assets, with advanced behavior written in JavaScript. In June 2024, Meta CTO Andrew Bosworth said the feature was being rebuilt from scratch because the original approach "wasn't good enough." He returned to the topic in August 2025, saying the company was rebuilding the system from the ground up.

Recent Horizon OS and developer updates have focused on spatial window management and better spatial apps. Put those next to a standard for system-managed 3D containers, and a revised Augments-style system looks like a reasonable thing for Meta to build on. Nothing has been confirmed, though, so I'd treat it as a possibility rather than a roadmap.

What to watch next

The specs, along with sample code in the OpenXR SDK's hello_xr examples, are available now. Khronos expects implementations to start rolling out across the ecosystem this year. For developers, the practical step is reading the self-rendering extension and the sample to see how an existing OpenXR app would adapt to bounded containers. For buyers, the question is simpler: which headset makers adopt the extensions, and how soon.

My read is that the first real test won't be a demo. It'll be whether three or four 3D apps can share a room on mid-range hardware without the frame rate falling apart. If the forthcoming system renderer delivers on that, Spatial Containers will change what a headset feels like to use day to day, rather than just what its developers can build.