Hi Michael,
Thanks for confirming the behavior on the TestFlight build.
You're right that from a robustness standpoint our app already handles ImmersiveSpace dismissal gracefully, we handle the Digital Crown case and the state sync. So in that sense, no workaround is strictly needed to avoid a broken state.
However, I'd like to flag that the graceful-dismissal path isn't really the concern here. My expectation for "Lock In Place" is that it behaves like it does for regular windows, the window gets pinned to a world anchor and stays put, while the rest of the scene (including the ImmersiveSpace and its content) continues as-is. "Follow Me" already works this way and doesn't tear down the ImmersiveSpace, so the asymmetry feels unintentional. The fact that it only reproduces on TestFlight/Release builds and not on Debug also suggests this isn't by design.
So while I agree the app-side handling is fine, I'd push back that the ImmersiveSpace being dismissed as a side effect of locking a window is itself the bug, not just something to handle. Could you confirm whether the dismissal behavior is intended, or whether FB22290781 will stay open as an OS-level issue? I'd like to make sure it doesn't get closed as "works as designed," because from a user-experience perspective, Lock In Place tearing down immersive content is surprising and inconsistent with Follow Me.
Happy to provide anything else that would help the investigation.
Thanks,
Kunal
Topic:
Spatial Computing
SubTopic:
General
Tags: