Bring your app to Meta VR Glasses
Updated: Sep 18, 2026
Meta VR Glasses use eyes and hands as their primary input and ship without controllers. This guide helps you decide whether to optimize an existing Quest app for Meta VR Glasses, plan replacements for controller interactions, find the available build-path instructions, test the result, and publish it through the Meta Horizon Store.
You need:
- An existing Quest app
- A development environment for your build path
- A Quest 3 or Quest 3S for testing
- Alternatively, a supported simulator for preliminary development in your build path
A simulator can help you develop and debug an input path, but it does not replace the physical device required for final testing. The sections on field of view and testing apply across build paths.
Decide whether to migrate
Start with two separate questions:
- Can the binary be installed? The app must be 64-bit. A binary containing only 32-bit native libraries cannot run on Meta VR Glasses, even if it runs on another Quest device.
- Can someone use the app without controllers? Meta Quest Touch Plus controllers are separately available and are not included with Meta VR Glasses. A controller-required immersive app can be installed, but the Switch to Controllers dialog blocks entry until controllers are active. A 2D Android app uses eyes and hands without controllers.
If every required flow already works with eyes and hands, verify the app with the testing guidance below. Otherwise, migrate the input path.
App compatibility for Meta VR Glasses explains architecture, launch behavior, and Store targeting.
Find your build-path guidance
Changes depend on your build path.
| Build path | Published guidance | Coverage |
|---|
Android | | Complete route for standard 2D Android interaction and compatibility work |
Native | | Partial. No single published Meta guide combines eye-gaze targeting and hand-pinch activation into an end-to-end Native migration. |
Spatial SDK | | Complete route for look-and-pinch interaction |
Unity | | Complete Interaction SDK route |
Unreal | | Complete Interaction SDK route with head-mounted display (HMD) gaze fallback |
Web | | Complete route for IWSDK. Partial for WebXR apps that do not use IWSDK because no single published Meta guide combines eye-gaze targeting and hand-pinch activation. |
For Unity,
Device Readiness Check scans a project for controller dependencies and produces a prioritized readiness report. Some findings have an automated fix, but code changes stay under your control.
These tools do not design eyes and hands interactions, and do not replace real device testing. See
AI tooling overview for Meta VR CLI setup and the agent tools used to run these skills.
Convert controller interactions
Use this table as a design starting point. The exact implementation depends on your build path.
| Controller input | Eye and hand input |
|---|
Controller ray targeting | Eye or hand ray |
Trigger or grip button | Pinch, poke, or palm grab |
Trigger or grip hold | Pinch and hold |
Trigger or grip movement | Pinch and drag, or palm grab |
Thumbstick scroll | Directional swipe, or pinch and drag |
Thumbstick locomotion | Teleport |
Microgestures provide thumb taps and directional swipes for actions such as navigation and scrolling. They are discrete: a tap or a swipe fires once and carries no magnitude, so map continuous movement to pinch and drag instead.
Artificial locomotion input maps covers the recommended hand mapping for locomotion.
Update 2D Android apps for eyes and hands
Prepare the app for this interaction model:
- Do not request eye-tracking permission in a 2D-only app (see Eye tracking permissions)
- Keep Android accessibility information accurate so the system can identify interactive elements
- Use interactive targets that are at least 48 density-independent pixels (dp), per Eyes best practices
- Keep essential actions available without hover
- Support window widths from 360 dp through 1280 dp (see Window sizing)
Adapt to the field of view
Targeting with your eyes becomes less precise near the edge of the visible area. Keep important actions near the center and avoid placing small targets at the edge.
Meta VR Glasses field of view and display values explains the nominal visible field of view, render extent, and display resolution.
For 2D and panel-based apps, the system can resize a window when angular scaling would push it beyond the field of view. Check that text remains legible, actions remain reachable, and content does not clip.
Use free-resize mode in the device developer settings to test the layout. See
Window sizing for the test steps.
No current Spatial SDK page validates an end-to-end Meta XR Simulator workflow. Test a Spatial SDK app on a physical device until a supported simulator setup is published.
The Unity Interaction SDK includes a
GazeExamples scene for this workflow. For the full control reference, see the Meta XR Simulator guide for
Unity,
Unreal, or
native OpenXR.
Start with the app’s existing Meta Horizon Store app page. In the Developer Dashboard, open its Production release channel and confirm the intended build’s
Supported devices. If the device needs a different binary, see
Create apps for app-page guidance and
Target app builds by device for separate device-targeted builds.
If the Quest and Meta VR Glasses builds use the same Store application, start with that application’s existing Platform Services configuration. Cross-device play is not automatic: the builds still need compatible networking and service configuration. Cloud Backup can restore app data when the app is installed, but it does not continuously synchronize saved data between devices. See
Platform services on Meta VR Glasses.