WWDC26：Foveated Streaming 把 PC / 雲端 OpenXR 內容帶進 visionOS

// 一句話結論

Foveated Streaming 的價值不是把 Vision Pro 變成普通串流螢幕，而是讓遠端 OpenXR renderer 負責重算力畫面，visionOS app 負責連線、空間組合、輸入轉送與效能量測。

Apple Developer · WWDC26 · Video ID: yPMGqbAU-ZIApple Developer 官方頁

Content map

這支影片在拆三個 visionOS 產品問題

算力邊界

既有 PC / OpenXR 場景不必全部重寫成原生 app

framework 讓外部 endpoint 串流 immersive content；Vision Pro 端可先承接現有高算力場景，再逐步加入原生 SwiftUI、RealityKit 或平台功能。

接收端架構

visionOS app 是 receiver，不是被動播放器

app 要建立 StreamingSession、連接 endpoint、把 StreamingSurface 放入 ImmersiveSpace，並處理狀態、錯誤、輸入與組合。

互動資料

手、控制器、麥克風等 input 會送往 endpoint

visionOS 自動提供 hand、controller position、microphone 等資料，外部 renderer 回傳 OpenXR content 的 video/audio，降低自建 streaming protocol 成本。

原生融合

串流畫面可以和 SwiftUI / RealityKit 一起構成體驗

session 強調不只顯示遠端影像，也能疊加 visionOS controls、spatial UI、RealityKit content，讓產品不像單純遠端桌面。

Implementation path

導入 Foveated Streaming 的接收端流程

先準備 streaming endpoint

PC 或 cloud instance 端負責 OpenXR rendering，並支援 Foveated Streaming 的 endpoint 連線。產品要先界定延遲、網路、GPU 與內容來源。

建立 visionOS receiver app

在 visionOS app 內建立 StreamingSession，管理 endpoint discovery / connection lifecycle，並把使用者可理解的連線狀態帶進 UI。

把 StreamingSurface 放進 ImmersiveSpace

session 內容透過 StreamingSurface 顯示在沉浸式空間中；這是把遠端 renderer 的畫面放到 visionOS spatial scene 的核心。

組合原生 SwiftUI 與 RealityKit

在遠端串流畫面旁放控制面板、狀態提示、3D 原生物件或現實世界輔助，避免體驗退化成只有影像。

量測效能與舒適度

用官方建議的 performance measurement 觀察 latency、frame pacing、streaming quality 與互動一致性，特別要測網路波動與 endpoint 負載。

重點 1：Foveated Streaming 是 visionOS 的第三條移植路徑

影片把 visionOS 體驗分成幾條路：iOS / iPadOS 相容或重新編譯、原生 spatial app、第三方引擎，以及把 PC / macOS 既有高算力內容延伸到 Apple Vision Pro。Foveated Streaming 專注最後一種：不用一開始就把整個 OpenXR 或 PC renderer 重寫，但仍可進入 visionOS 沉浸式體驗。

適合的場景不是所有 app，而是本來就需要外部 GPU、模擬器、CAD、訓練、工業視覺化或高保真 3D 內容的產品。若內容本身能在 Vision Pro 原生跑，仍應評估原生渲染是否更簡單。

StreamingSession管理 receiver 和 endpoint 的連線生命週期，是 app 端理解狀態與錯誤的中心。

StreamingSurface把遠端串流內容放入 ImmersiveSpace，可和原生 spatial elements 同場組合。

OpenXR bridge外部 endpoint 可以維持 OpenXR 內容與 renderer，Vision Pro 端接收 video/audio 與互動回路。

visionOS compositionSwiftUI 控制、RealityKit 物件、空間提示與串流內容應一起設計，而不是事後疊 UI。

重點 2：產品品質取決於連線、延遲與 fallback

官方 demo 看起來像一條順暢 pipeline，但實務上最難的是狀態管理：endpoint 找不到、網路抖動、使用者離開沉浸式空間、串流品質下降、輸入資料不同步，都會直接影響舒適度。這類產品應該把 streaming state 當成一級產品狀態，而不是背景細節。

先做 receiver shell，再接真 endpoint

先把 ImmersiveSpace、StreamingSurface、狀態 UI 與基本錯誤路徑跑通，再接入完整 renderer。

把 performance measurement 放進開發迴圈

每次 endpoint、network policy 或 spatial composition 改動後，都要量 latency、frame pacing 與使用者感知品質。

設計原生輔助層

用 SwiftUI / RealityKit 補足遠端畫面沒有的 controls、狀態、引導與安全邊界。

風險與遷移注意事項

Foveated Streaming 會把 app 風險從單機渲染擴大到跨裝置、網路與遠端 renderer。導入時要把以下項目納入設計與 QA，而不是等到 demo 完成後才補。

不要假設 endpoint 永遠可用PC / cloud renderer 可能離線、版本不相容或過載；receiver app 要有可恢復狀態。

舒適度比畫質更早成為 blockerspatial streaming 的延遲與 frame pacing 會影響使用者舒適度，不能只看靜態畫質。

輸入與權限要明確揭露手部、控制器、麥克風資料被送往 endpoint；產品要處理隱私、權限與使用者信任。

原生與遠端座標系要反覆驗證RealityKit 物件、SwiftUI 控制與遠端 OpenXR scene 的空間對齊，會影響互動可信度。

來源

主要來源為 Apple Developer 官方影片頁、官方 transcript、章節摘要與 YouTube 影片 metadata。官方頁：Use foveated streaming to bring immersive content to visionOS - WWDC26。YouTube：WWDC26: Use foveated streaming to bring immersive content to visionOS | Apple。

// TL;DR

→Foveated Streaming 讓 Vision Pro 可接收 PC / cloud OpenXR 高算力內容，但 app 端仍要負責 receiver lifecycle。
→核心 primitive 是 StreamingSession 與 StreamingSurface，導入時要設計連線狀態、沉浸式顯示與原生 UI 組合。
→最重要的 QA 不是只有畫面能跑，而是 latency、frame pacing、endpoint fallback、輸入同步與使用者舒適度。
→適合 CAD、模擬、訓練、工業視覺化與大型 3D 場景；簡單內容仍應優先評估原生 visionOS rendering。