WebGPU Lands in XR Blocks, but Not in the Part Developers Build With

Google has spent 2026 treating XR Blocks as the layer underneath everything it wants developers to try on Android XR, which makes the library's release feed a steadier read on the platform's direction than most of what gets said from a stage. Version 0.22.0 was tagged on October 10 at 00:26 UTC, against commit 466cbff, and it is the first release since v0.21.1 on August 25, a gap of more than six weeks in a repository that had been shipping every few weeks through the summer.

The lead item in Google's own release notes is WebGPU. The limit on it arrives in the same bullet.

What the WebGPU work actually covers

THREE.WebGPURenderer now runs inside the XR Blocks desktop simulator, and the notes describe the change in plumbing terms rather than feature terms: the simulator compositor renders through an intermediate render target, Simulator.renderFrame is unified, the reticle moves to a TSL NodeMaterial, and the simulator camera, the depth pipeline and depth occlusion all accept the new renderer. The depthmap sample runs on WebGPU.

Then comes the sentence that decides how much of this is usable today. "The spatial UI is not yet supported on WebGPURenderer," the notes say, and Google calls the change "initial simulator support, not end-to-end coverage." Spatial UI is the panel, card and text layer most XR Blocks samples are assembled from, so a project built on it cannot switch renderers and keep its interface without rewriting the layer that draws it. For teams tracking the three.js migration, where WebGPURenderer and TSL are where the engine itself is heading, 0.22.0 supplies a place to test the renderer rather than a route to ship against it.

The on-device pile arrives without a measurement

The larger share of this release is a set of samples that run models locally, and the list covers a Gemma 4 assistant with spatial scene context and markdown replies, on-device super-resolution, an EfficientSAM circle-to-search demo, offline spatial captions and translation, interactive Teachable Machines training, photo-to-3D reconstruction, and world-aligned metric depth from a single camera photo. The objects3d pipeline moved from SlimSAM to EfficientSAM-Ti on LiteRT.

No numbers accompany any of it. The notes carry no frame rates, no latency, no accuracy numbers, and no list of devices the samples ran on. "On-device" states where a model executes and says nothing about what executing it there costs. The distance between a workstation running the desktop simulator and glasses-class silicon is where that cost shows up, and it is the first wall a prototype built from these samples will hit. Budget time to measure on the hardware the work is aimed at.

Toolchain churn is the other half of the release

Underneath the features, the repository was rebuilt. three.js moved to r186. Bundling moved from Rollup to Rolldown, linting from ESLint to Oxlint, and TypeScript to 7. Gemini calls across the SDK and the samples moved from generateContent to the Interactions API, with the default Flash model now gemini-3.8-flash. The What's Changed list runs to 96 pull requests and credits two first-time contributors.

Model names pinned inside a prototyping library age quickly, and the version history is the evidence, since August's release set that same default to gemini-3.7-flash. The documentation sidebar still offers a migration guide written for v0.20.0. Upgrades in this repository are code changes wearing a version number, and six weeks between tags means a project pinned to 0.21.1 now sits several structural decisions behind.

Where this leaves Android XR developers

XR Blocks describes itself in the documentation as a lightweight, cross-platform library for rapidly prototyping XR and AI experiences, built on three.js, targeting Chrome v136 and later with WebXR support on Android XR. That description has not moved since Google wired the library underneath Gemini-generated WebXR scenes in March, and it remains the clearest statement of where Google expects this work to happen: in a browser, against a standard, with the spatial plumbing supplied by a library instead of an engine.

The practical reading of 0.22.0 is narrow. Keep shipping on WebGLRenderer. Keep the spatial UI where it is. Pull the release for the on-device samples, and if WebGPU sits anywhere on the roadmap, spend an afternoon in the simulator finding out what breaks. Google has been unusually direct that it has not finished this job, and the next tag is the one that decides whether the interface layer follows.