The Platform SDK v203 has an issue with asynchronous methods like Core.AsyncInitialize() and DeviceApplicationIntegrity.GetIntegrityToken(nonce) where awaiting callers using C#'s await syntax are intermittently not resumed, despite the platform initialization completing successfully. The Request<T>.OnComplete() callback mechanism works as expected, but the await syntax does not return. This issue was observed on Quest 3 running Horizon OS v2.5 PTC with Unity 6000.4.10 and can be resolved with a workaround using AwaitableCompletionSource to bridge the callback to an awaitable.
When launching an app through Meta Quest Developer Hub (MQDH) via Link, controllers do not automatically connect or render in the app until a user physically presses a button on the controllers. This issue is specific to the app launch flow initiated from MQDH through Link, suggesting a problem with controller initialization or wake state. Hand tracking and controller representation are not visible until user interaction occurs, although the underlying connection is eventually established after a button press, allowing controllers to function correctly.
The HighlightsAndShadows feature fails to work on Quest devices after upgrading from Unity version 6000.4.7.f1 to a higher version. In the Unity Editor, the issue manifests as purple rendering, while on Quest devices, the HighlightsAndShadows functionality completely fails. The regression is specifically tied to the Unity version upgrade path from 6000.4.7.f1, indicating a compatibility or breaking change introduced in later Unity versions.
The XR_FB_hand_tracking_aim OpenXR extension returns invalid pose data on Quest 3 headsets with firmware version V2.4, causing hand tracking to fail completely in Unity VR apps. Specifically, hand rays become locked to a single point and cannot be moved. This issue is 100% reproducible when deploying and running the Unity VR sample app on an affected headset. The problem is a regression introduced by the V2.4 firmware update, which breaks hand far interaction in OpenXR Unity applications.
The getting started documentation for Meta XR Simulator in Unity is lacking in detail and clear direction. Specifically, the setup and usage instructions are inadequate, making it difficult for developers to configure and use the XR Simulator. This results in a challenging onboarding process for developers attempting to follow the instructions.
The documentation for security vulnerability scans lacks an explanation for the constant scan duration of 10 minutes, even when only minor changes are made to the build. Developers are unclear if this is expected behavior or why incremental builds are not scanned more quickly, specifically in cases where the scope of changes is small, such as adding an audio listener.
The developer found the age group self-certification and youth requirements documentation to be helpful, complete, and well-written. No issues or gaps were identified in the content, indicating that the documentation effectively covers the necessary information for understanding and implementing age group self-certification and youth requirements.
The Meta XR Simulator documentation lacks clear instructions on how to connect controllers, causing developers to struggle with setting up and using controllers within the simulator environment. Specifically, the documentation page for XR Simulator interaction does not adequately explain the controller connection process, leaving developers without guidance on this crucial aspect of simulator usage.
The palm-up-pinch gesture used to invoke the Quest system menu during hand tracking sessions is causing frequent accidental app exits. Users, especially inexperienced VR users, are unintentionally triggering the gesture or interacting with the Meta icon prompt, leading to application exits. The issue arises from the ease of triggering the gesture during normal hand movements. A feature request has been made to restore the wrist button as an alternative method for accessing the system menu, which would require more deliberate user intent and reduce unintended app exits in hand-tracking applications.
The documentation for private app distribution on Meta for Work and Meta for Education states that private apps do not require formal review. However, the developer dashboard still displays 'app submissions' options for private apps, and the app remains listed as 'draft' in release channels even after following the documented steps. The documentation is unclear on whether a submission is still required to distribute a private app despite the stated exemption from formal review, causing confusion and potential issues with app distribution.