visionOS – Starting GroupActivity FaceTime Call dismisses Immersive Space

Hello,

I am in the process of implementing SharePlay support in my visionOS app. Everything runs fine when I test locally, but when my app is distributed via TestFlight, calling try await activity.activate() shows the SharePlay dialog as usual, but then when I start a new FaceTime call, my ImmersiveSpace gets dismissed. This is only happening when the app is distributed via TestFlight, when I run it locally the ImmersiveSpace stays active as expected.

Looking at the console on my Mac I found this log: Invalid initial client settings class: UIApplicationSceneClientSettings; expected class: MRUISharedApplicationSceneClientSettings; bundle ID: com.apple.facetime; scene ID: com.apple.facetime:SFBSystemService-DDA8C751-C0C4-487E-AD85-59EF4E6C6050

Does anyone have an idea how I can fix this? It's driving me nuts and I wasted over a day looking for a workaround but so far been unsuccessful.

Thanks!

Hi @scavengar

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. I'd greatly appreciate it if you could open a bug report, and post the FB number here once you do.

Bug Reporting: How and Why? has tips on creating your bug report.

In the meantime try deploying Building a guessing game for visionOS to TestFlight as a means of debugging. If that reproduces the issue, please add that information to the bug report. Otherwise try comparing your code to the sample code as a means of debugging.

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!

@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

Hi @arthurfromberlin

Thanks for the response and detail. Can you attach a sysdiagnose to the feedback request? You can find instructions on how to capture a sysdiagnose here. The issue is tricky to debug since it only happens via TestFlight so the logs will help.

Hi @arthurfromberlin and @scavengar

It is unexpected for a visionOS app to behave differently when deployed to TestFlight. The feedback @arthurfromberlin filed will help us investigate that issue.

In the meantime, I spoke with the SharePlay team and want to share their recommendations:

Starting SharePlay from immersive spaces:

There's no reliable way for a person to initiate a SharePlay session while remaining in an immersive space, since the system may background the immersive space to present the FaceTime UI during call initiation.

Recommended approach:

We recommend that SharePlay experiences start in a shared space, then allow participants to transition to the immersive experience once everyone has joined the activity and is ready to participate.

To keep the group synchronized as participants enter and leave the immersive space, use SystemCoordinator.groupImmersionStyle.

For additional guidance, see Creating fully immersive experiences in your app.

@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!

visionOS – Starting GroupActivity FaceTime Call dismisses Immersive Space
 
 
Q