@Vision Pro Engineer This fully answers the architecture question — thank you. Custom Metal surface shaders on visionOS with foveation + CompositorServices interop is exactly what we needed to hear, and the LowLevelTexture → ShaderGraphMaterial route (with the tessellated-grid geometry-modifier trick for approximate depth) is clear. The one thing that'd be transformative for us: a first-class way to render LowLevelRenderer content inside an existing RealityKit scene with shared depth — true mutual occlusion against normal entities, rather than texture-on-a-mesh with approximated depth. Filed as a feature request, FB23042990 — essentially a "LowLevelRendererComponent" or a render-callback hook on RealityView. Our use case is mixing custom-rendered content (splats, custom Metal materials, dynamic meshes) with standard entities in one coherent scene on visionOS. Still very interested in the surface-shader ABI follow-up when you have it — the function signature contract (reserved vs. available buffer/texture slots, how camera/instance uniforms arrive, how LowLevelArgumentTable maps to argument indices), ideally with a pointer to sample code. Thanks again!

@Vision Pro Engineer This is great, thank you — exactly what we were hoping existed. We already ship our own JavaScriptCore-based scripting layer, and I've been digging through the package to understand how it'd fit alongside ours. Two questions the repo doesn't quite answer, both about deployment rather than API: Runtime location / .reality files. When a .reality file authored with scripts is opened in QuickLook or a system RealityView, what provides the runtime? Is RealityKitScripting OS-resident on 27+ (so system viewers execute embedded ScriptingComponents without each app or file bundling it), or must the consuming app link the package? I assume the .reality carries only the ScriptingComponent source string and the runtime must be present in the opening process — just want to confirm. Bundle size / App Clips. The GitHub release ships as an embedded binary xcframework. At GA, will it stay an app-embedded dependency, or become an OS framework apps link against? This matters for us because we target App Clips (size-constrained) and earlier OS versions, so we need to know whether adopting it means shipping the runtime or linking a system one. And one architecture question: is this the same runtime that RCP 3 Script Graphs execute on — i.e. does a type exposed via @Scriptable / TypeSchema become available to both text scripts and the visual graph? Thanks again — genuinely useful!

Also been filing feedback on this for a while — FB9381211 (filed 2021, still open), referencing the USD Preview Surface ior spec. For what it's worth on iOS: I've been faking refraction by grabbing the camera texture and doing a screen-space UV sample with an offset based on the surface normal. Works for the passthrough background, but the obvious limitation is it doesn't refract other virtual entities sitting behind the glass — the camera frame doesn't contain them. Would love to see first-party support for proper transmission as well!

Hitting the same limitation for cultural-heritage / environment captures where the viewer should be able to walk through the space. Filed FB23039893 covering this (camera-traversable splat volumes) plus runtime-mutable splat data.

Thank you @Vision Pro Engineer, this is really helpful and clarifies the direction. I've filed three feedbacks with use-case details: FB23039893 — camera-traversable volumes + runtime-mutable splat data (animated/4D). This overlaps benyang's thread 831298 on the camera-enters-volume culling; happy to share captures. FB23039953 — per-component splat-count limit: documenting/raising it, plus sort correctness across multiple components when tiling one capture. FB23040041 — per-splat shader/modifier hook (reveal/dissolve, spatial clipping, per-splat opacity/color), ideally a geometry-modifier-style stage. Use cases are cultural-heritage and enterprise environment captures, where walk-through, animated reveals, and large scans are common. One more on the splat-count limit, if you're able to find out: is the per-component (and any per-scene/total) ceiling the same across all supported devices, or is it lower on older/memory-constrained hardware (e.g. older iPhones vs. M-series iPad vs. Vision Pro)? For planning our chunking it matters whether we can target a single fixed count or need to adapt per device. A queryable max (even approximate) would let us size chunks at runtime instead of hardcoding for the lowest common denominator. Filed as FB23039953. Thanks again!

Finally seems to be fixed in 26.2 Beta (25C5048a). 🙏

Still present in 26.2 Beta (25C5031i).

Starting from visionOS 26 you can use https://developer.apple.com/documentation/swiftui/view/onworldrecenter(action:)

The issue is still present in 26.1 (25B77).

@Vision Pro Engineer Hi, thanks for the additional information. This is also the workaround I am currently using. However I don't think this is ideal. My expectation as a user would be that I can start SharePlay from everywhere. Even when already in an immersive space. The information forwarded from the SharePlay team also seems to contradict with this WWDC Session: https://developer.apple.com/videos/play/wwdc2025/318?time=489 There it says: […]Now people can start sharing my app directly from the share menu. That covers apps that are windowed or volumetric, but if your shared experience uses an immersive space, then there are extra considerations you’ll need to make to ensure the share menu is always accessible. For example, I want to turn my windowed experience into a full-size board game table placed on the floor of my room, with themed 3D objects around me to make the game feel more real. To do that, I need to put it in an ImmersiveSpace. But now I have a problem. How do people share my app since there’s no window bar in an immersive space? To solve this, I can offer my own button to let people start sharing without needing to use a window or volume. When someone presses that button, my app calls the activate method on my BoardGameActivity. New in visionOS 26, calling activate on an activity automatically prompts the share menu, even outside of FaceTime. This works with windows and immersive spaces. From there, you can select nearby people or create a new FaceTime session to start sharing directly from your app." And this actually works when running my app locally. Just not in TestFlight (and potentially also not when released). So I am still hoping for a fix. Thank you!

Yep, started working again when I deleted my widgets.

@Vision Pro Engineer I did some more digging and it seems clear that the ImmersiveSpace gets backgrounded as soon as the FaceTime call gets initiated from the SharePlay UI. Again; that only happens in TestFlight environment. Maybe as a workaround I can try first dismissing the immersive space manually and then restarting it once the .activate() call has finished. Not great but I'm not sure if there is another way currently. Here a full video of whats happening: https://jumpshare.com/s/dOcSWPmHIPaiVBM3rE8v

Thanks for the quick response @Vision Pro Engineer ! I've filed FB20701196 with a minimal reproduction project. I created a simplified test app based on the structure of Apple's "Building a guessing game for visionOS" sample, and it has the exact same issue in TestFlight. The immersive space transitions to background state when FaceTime appears, but works fine in local builds. My FB includes: Since a clean implementation following the sample code structure hits this same issue in TestFlight, it seems like a platform bug rather than something wrong with my code. This is blocking our SharePlay launch, so really hoping for a fix soon. A public TestFlight link is attached to the radar but awaiting review. There are also screen recordings. Thank you!

Yes, this bug made me refrain from using ManipulationComponent so far in a production app. Surprised it made it into the release version.

I can confirm this bug still exists in the newest visionOS beta.