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.

Okay I just wasted over 24h solving this, so hopefully this will save someone some pain: On visionOS 26 if you have an ImmersiveSpace and a regular WindowGroup in you app and want to use SharePlay with the ImmersiveSpace, you should set groupActivityAssociation on the view within the ImmersiveSpace: ImmersiveSpace(id: "immersiveSpaceID", for: AppScene.self) { $scene in let view = makeMyView() if #available(visionOS 26.0, *) { view .groupActivityAssociation(.primary("immersiveSpaceID")) // if you don't set this you might be in for a bad time } else { view } } If you don't do this, and query the device anchor during your SharePlay session, you will get a transform that is offset – supposedly based on the shared displacement. 💀 Once groupActivityAssociation is set, everything works just as expected. Feels like a bug to me, but at least it seems to be undocumented behavior. https://developer.apple.com/documentation/SwiftUI/View/groupActivityAssociation(_:) In my particular case I have a window that I hide but not dismiss while the ImmersiveSpace is active, and apparently by default the window will get the primary association.

I just discovered https://developer.apple.com/documentation/swiftui/environmentvalues/immersivespacedisplacement and will try if that gives me what I want.

Did anyone find a solution for this? Struggling with the same problem and no reply from Apple so far.

Same problem here, really frustrating and annoying since I can't seem to find anything on my side that would cause this. And it worked perfectly fine just days ago.