That falls under accessibility: provide downgraded alternatives, like head movement for eye gaze, or ray-based hand tracking. Another option is going back to classic XR controllers (like AVP + PS VR2 controller)

According to visionOS interaction guidelines, far eye–hand input = indirect interaction, near touch input = direct interaction, both are "natural interactions." The OS handles them and maps both to the same spatial gesture events, so developers can write one set of code to support both.

3. Multiple videos or livestreams can be watched and interacted with at the same time, including cross-room interactions.

What OS architecture and development paradigm shifts follow?

Which New Web APIs are essential for the mainstream Web to get a boarding pass to such devices?

More analysis:

webspatial.dev/docs/introdu...

webspatial.dev/docs/introdu...

we need new Web APIs like WebSpatial to bring the new XR development paradigm to the Web. Only then can web-based solutions have a real shot at replacing native apps in many scenarios, especially in AI-related use cases and those that blend with mobile real-world environments.

It also breaks away from mainstream web development, missing out on another big Web advantage (the significantly larger pool of web developers compared to 3D developers).

Just like native spatial apps on visionOS don't prioritize using 3D engines but instead adopt 2D frameworks like SwiftUI,

This kind of heavy, all-in immersive experience not only fails to leverage Web's strengths (like URL-based on-demand access) and just repeats the limitations of native XR apps (where each app creates its own isolated space instead of blending into the existing space).

Then step into the shadows. Join us. We're recruiting in San Jose: jobs.bytedance.com/en/mobile/po...

it's still a 3D engine that uses WebGL to render everything - 2D and 3D - on the canvas or dual-eye screens. It doesn’t support visionOS's Shared Space. Its development mindset is based on 3D graphics APIs - unfamiliar to most web developers who think in terms of 2D GUIs. See the doc for details.

I like R3F. But on one hand, R3F is like React Native - uses React-like syntax but isn't real React, so it's disconnected from the regular HTML/CSS-based React code used on standard websites. It needs its own ecosystem and can't integrate with the mainstream React world.

On the other hand,

How can Web Apps have this kind of capability too, and achieve the UI demonstrated in my first three screenshots: bsky.app/profile/dext...

where the TikTok camera interface becomes the default Home screen. App distribution wouldn't just rely on icon grids, but also come from the context of the live environment (as part of multimodal input). Unless glasses or lightweight headsets completely replace phones before that happens.

The physical screen's background is inevitably trending toward dynamic content - XR headsets also use solid, opaque screens with cameras, so many of their functions are also possible on smartphones.

Its final form might look like a "TikTok OS,"

After the iPhone GUI switched to Liquid Glass, the Home/Launcher screen background could be a live camera feed instead of a static wallpaper, making the phone feel almost transparent (though sadly, they didn't roll out that feature this time).

So the Glass Material / Liquid Glass not only affects where GUI software can be used and what it can do, but also impacts the whole system architecture and how apps are developed.

Android XR can't really do this. It only performs alpha blending. The same limitation keeps its Home Space from mixing 2D and 3D apps the way visionOS Shared Space does (bsky.app/profile/dext...).

- pre-raster layout info in browser engines, ECS data in 3D engines, node graph data for building shaders - so the OS can render all apps and environments together (bsky.app/profile/dext...).