Hi everyone,
I developed an application for the Apple Vision Pro. This app will only be used at events, so it’s currently just a development build.
Unfortunately, the app always disappears when I try to activate Guided Access on the device (Use Guided Access on Apple Vision Pro - Apple Support).
Here’s the debug log (check out the screenshot below). Do you have any ideas why this is happening?
Thanks a lot, and have a great Wednesday!
Best regards,
Tobias
We have the exact same issue. Would be great if this bug would be fixed! @baker-street have you found any workaround?
Unfortunately no. But we cleared for the event the first Page of the Apps on the home screen and activated point control for a faster setup without eye configuration. That worked okay but with the guided access it would have been a lot easier.
We have this issue as well. Please, Unity, this is a big issue for a very very major part of use at this point! Not many people own this device, but it gets shown at many many events!
If our customers can’t run our experience in Guided Access mode it majorly impacts user experience and quality of facilitation.
The manual approach that baker-street suggests is not an acceptable option for customers as this allows full access to the Apple Account used to log in.
Here are the steps to reproduce the issue:
I’ve tried doing a completely fresh project in Unity 6000.0.33f1, using the latest VisionOS XR Plugin v2.1.2 and right away, when you activate Guided Access in VisionOS, the app minimises and XCode/Unity logs:
-> applicationDidEnterBackground() AR data provider state changed. New state is Paused.
… and never gets out of pause while VisionOS is in Guided Access state.
This is not the intended behaviour Unity!
Note, the app isn’t crashing. It’s just reacting to a state change in VisionOS it shouldn’t react to.
When I then exit Guided Access and manually launch the app again, it continues from where it left and XCode/Unity logs
-> applicationDidBecomeActive () AR data provider state changed. New state is Running.
Unity, could you please look into why only Unity apps, and not native XCode apps, have this issue?
Gentle reminder that Discussions is not the correct way to report bugs in Unity…
Has anyone filed a report via the Bug Reporter, and if so, do you have an incident number you can share?
Noted, I’ve reported it now using the Bug Reporter with incident number IN-94474
Perfect, thank you! I’ve asked the team to process the report as a priority.
Hello there!
The ticket was just confirmed and sent over for the developers to look at, you can track it’s progress here:
Thanks. Crossing fingers it’s a trivial thing to fix 
Anyone else reading this, please go in and upvote the issue!
It’s been a couple weeks since we reported this issue and it was reproduced by Unity and assigned “in progress” on the issue tracker.
What is the status on solving the issue?
We can’t stress enough how big of a problem this is for the Apple ecosystem! It is making demo’ing Unity experiences completely impossible using Guided Access. Demoing without Guided Access forces facilitators to expose their private Apple Account data (photos, emails, messages) to anyone they demo it to and it adds a lot of stress and confusion for the audience.
(I posted this comment on the issue tracker itself as well)
Hey we faced the same issue as we have worked on multiple Vision Pro Apps for public events. We have found a work around to the current problem which works for us. If you are interested let me know: seppi@ditached.de
Just put it here
Hi,
We’ve received the bug and have reproduced it on our end. On investigation, it looks like a bug with how visionOS handles fully immersive scenes. With Unity visionOS Metal apps, we utilize Compositor Services and a full immersive space to render Unity content. When an app is backgrounded and foregrounded (such as would happen if you pressed the HomeView button), we get a call from visionOS to bring the app back into foreground.
This isn’t happening with apps that are put into the background by GuidedAccess - the app comes back briefly before being re-sent to background by the hands/eye setup, and after the hands/eye setup, there’s no visionOS call to bring the app back to foreground. Additionally, we were able to confirm the same behavior with non-Unity Metal-based app. We’ve submitted a bug report to Apple’s Feedback Assistant as FB16520915, and are in communication with them about this bug, so hopefully there will be a swift resolution.
Hello vcheung-unity.
It’s been 3 months now and we’ve continuously tested new versions of VisionOS to no avail. The issue persists.
Can you share if there has been any progress at all on this? We can’t access the Apple Feedback Assistant ID you provided.
We understand your point that this is an Apple issue, but at this point it’s honestly baffling that a resolution hasn’t been found. We really hope your team is actively pursuing this.
As a side note, we see that Apple now provides a new Guest mode using an iPad, but it requires 6 steps and a full eye calibration for the user to access which is far from the simple 2 steps using Guided Access.
Looking forward to your answer,
Hi,
I reached out to some engineers on Apple-side and they are aware and actively working on restoring CompositorServices apps after GuidedAccess, but unfortunately could not provide a timeline for when the fix might land. Sorry that I don’t have more positive news!
The number of things we can do on our side without access to the necessary APIs are limited, but some things that may work:
I know these workarounds aren’t ideal, but I’ll continue to ping our contacts to see when the GuidedAccess fix is slated to land.
I had some time to test these workarounds, especially the SwiftUI workaround, and I think that might do the trick - you can use the SwiftUI PolySpatial sample as a starting point. Change the PolySpatial app mode setting on your project to Hybrid app mode, create a VolumeCamera with a Metal VolumeWindowConfiguration, then have the Swift UI native window spawn on runtime start or on a timer. On the SwiftUI window, add a button that just deletes and re-initializes the VolumeCamera (disabling/enabling might work too). That should allow users to force a reset of the CompositorSpace with a press of a button.
Hope that helps!
