visionOS Foveated Streaming: When an OpenXR Port Should Stay on the PC

Apple WWDC26 Foveated Streaming session showing a pilot using Apple Vision Pro inside a real aircraft cockpit
Apple demonstrates a PC-rendered flight simulator combined with a physical cockpit and Vision Pro receiver.

Apple Vision Pro can receive a PC-rendered OpenXR world while a native visionOS app handles pairing, controls, and spatial composition. The shortcut is real, but so are its network and entitlement boundaries.

A pilot sits inside a physical cockpit while Apple Vision Pro renders the virtual one around it. The detailed landscape does not have to run on the headset. Apple’s Foveated Streaming framework lets a visionOS receiver connect to a local PC or cloud endpoint and display streamed OpenXR content inside an ImmersiveSpace.

That changes the first porting question. A team with a high-fidelity PC simulator may not need to rebuild its renderer in RealityKit before reaching Vision Pro. It can keep the OpenXR application and GPU workload on the endpoint, then build a smaller native receiver for discovery, pairing, controls, and visionOS-specific composition. The trade is a networked system with two applications, an entitlement, and a performance budget.

Context: the renderer is already valuable

Foveated Streaming fits when the existing OpenXR experience is too large, specialized, or hardware-bound to move onto the headset. Apple highlights X-Plane 12, iRacing, and Innoactive’s Autodesk VRED workflow as examples. In each, the PC owns expensive rendering or simulation while Vision Pro supplies a wireless spatial display and native interaction layer.

It is a poor starting point for a lightweight app that could run natively, or a product that must work away from a capable endpoint. Streaming does not erase the renderer; it turns endpoint availability, network quality, pairing, and version compatibility into product dependencies.

Constraint: the system has three boundaries

The end-to-end Foveated Streaming path
Boundary Responsibility Release proof
PC or cloud endpoint OpenXR application, NVIDIA CloudXR runtime, rendering, video/audio stream, session protocol Correct runtime, stable frame production, certificate identity, endpoint recovery
Network and pairing Bonjour discovery on local networks, QR pairing, certificate-bound secure connection, session state Discovery, revoke/re-pair, reconnect, packet loss, local and remote paths
visionOS receiver FoveatedStreamingSession, entitlement, ImmersiveSpace, SwiftUI/RealityKit composition, controls Status UI, pause/end flow, input alignment, alpha/depth composition, privacy behavior
The port is not a single SDK call. It is a renderer, a secure session protocol, and a native receiver that must fail together coherently.

Intervention: stream detail where the person looks

Vision Pro uses eye-tracked foveation to preserve more detail in the region of focus and compress the periphery more aggressively. Apple says the framework shares an approximate gaze region for stream optimization while protecting raw eye-tracking privacy. The endpoint returns video and audio; visionOS supplies tracked input such as hands and controllers.

The receiver can add native windows, progressive immersion, ARKit alignment, and RealityKit content. If the endpoint supplies alpha and depth correctly, native and streamed objects can compose and occlude each other. A bidirectional message channel can carry product controls or state that should remain in a SwiftUI interface.

Result: a faster first port, not a finished release

In its WWDC26 session, Apple says a team can get an OpenXR application streaming in roughly a day and add visionOS-specific capabilities in about a week. Treat that as a vendor onboarding estimate, not an independent schedule. It describes a first working path, not entitlement approval, production networking, accessibility, thermal tests, or a complete failure model.

The receiver sample requires com.apple.developer.foveated-streaming-session. Streamed pixels are presented directly by visionOS so the app process cannot read them, an important privacy boundary that also limits what the receiver can inspect. Plan diagnostics around exposed session statistics and endpoint telemetry rather than screen scraping.

Transfer limits: when to build native instead

Choose native RealityKit or another on-device engine when the experience must travel without a PC, the content is small enough for the headset, or latency sensitivity exceeds the network path. Choose Foveated Streaming when the existing OpenXR renderer, simulation hardware, or massive dataset is the asset you need to preserve.

A hybrid can be stronger than either extreme: stream the expensive world, render stable spatial controls natively, and keep critical status outside the video. That split should survive a paused or degraded stream without trapping the person in an unresponsive immersive space.

Official sources