Essentials

Platform services on Meta VR Glasses

Updated: Aug 25, 2026
Meta VR Glasses use the same Store delivery system and Platform Services as Quest. If you plan to publish your Quest and Meta VR Glasses builds under one Store app, start with your app’s existing service configuration. If you plan to use separate Store apps, configure and verify each one independently.

Reuse your Quest services

When both builds use the same Store application:
  • Store and entitlement: Use the existing delivery path and continue to run the entitlement check for the current app.
  • In-app purchases: Use the app’s existing add-on products and purchase settings.
  • Presence and invites: Publish compatible destination, join availability, lobby, match, and deep-link state. Test whether a person can accept an invite and travel to its destination on every supported build.
  • Multiplayer: Keep app identity, client protocol, backend, destination names, and matchmaking settings aligned across builds.
If the builds use separate Store applications, verify each service’s settings and history separately, and configure any sharing between the applications.
Regardless of the Store application setup, test each service flow on the device and on the Quest devices you support.
Note: Using the same Store application does not create cross-device play. Both builds need compatible network protocols, backend services, app identity, and matchmaking rules.

Verify access for an existing owner

When the device receives the same Store application, use that application’s normal entitlement check. Do not infer access from the device or account alone, and do not assume that a separate application identity shares ownership or purchase history.
Passing the entitlement check is not always enough to play:
  • The binary has to run on the device. See App compatibility for Meta VR Glasses.
  • An immersive app that requires controllers installs, but is not playable until controllers are active.
  • Release-channel, free, and test grants are not consumer purchases. Test these grants separately from consumer purchases.

Cloud Backup is not save sync

Cloud Backup backs up data. It does not keep saved data synchronized between devices.
Backups are held per app, per device, and per person. When someone installs your app on the device, the system looks for a backup made on that device. Finding none, it restores their most recent backup from any device they own, which is how progress carries over from Quest.
What that means in practice:
  • Automatic restore runs only when the app is installed. After installation, each device keeps a separate backup history; the devices do not synchronize saved data. From the Cloud Backups page, a person can still restore a selected backup or copy it to another device.
  • Cloud Backup captures data only from supported app directories. A custom folder in the app root is not captured. If Cloud Backup does not capture all required app data, the restored data is incomplete.
  • Each backup has a 100 MB limit. If a backup exceeds this limit, the backup fails and its data is not captured.
Keep the data you want restored in supported app directories, and keep each backup within 100 MB. To identify supported directories, see the Cloud Backup guide for your build path:

Check capabilities, not the device model

Do not use a reported device model or User-Agent string as a feature contract. Check the capability that drives the behavior through your engine or runtime. If your backend needs the capability-check result, send that result over your own authenticated channel. See App compatibility for Meta VR Glasses for compatibility behavior.

Keep releases compatible

Quest and the device can run different versions of your app. To keep releases compatible:
  • Keep shared service contracts backward compatible while both versions are live.
  • Gate server features that need a newer client.
  • Reject incompatible multiplayer versions with a clear message.
  • Track service failures by app version, release channel, service operation, and error code.
  • Repeat your entitlement, purchase, backup, and social tests before each release.

Platform services by build path

For platform-specific setup, see the Platform Services guide for your build path: