Common Oculus Store Review Submission Issues

Of the many apps and games that are submitted to review for consideration on the Oculus Store, we find that some submission issues tend to crop up more often than others. In order to help ease the submission process, we've compiled a list of the more common issues that we recommend reviewing and addressing before you submit.

Failure to meet required frame rate*
Rift apps should always retain 90fps, while mobile apps should retain 60fps. We provide tools to help you test app performance to hit this target.

Entitlement Checks not implemented*
The Entitlement Check is a test which verifies that the currently logged-in user is actually entitled to use the app in question. All apps submitted to the Oculus Store must perform this check right after the app starts up, and quit if the check returns false. The entitlement check should be implemented using the Oculus Platform SDK.

Controls and objectives are confusing due to lack of documentation/tutorials
Our app review team doesn't necessarily have all context, so please make sure the app explains what the experience is intended to be, what users are expected to do, and how to use the controls. This can be done through descriptions and/or in-game tutorials. This is especially important if you are creating something with new or unconventional concepts.

App does not show something in the headset within 4 seconds of launching
It's OK to have an app with long load times, however, it is best practice to provide users with an indication that the app has not crashed and is currently loading. We require apps to include some sort of indicator in the headset within 4 seconds of launching.

Description text, screenshots, trailer movies etc. contain appearances or logos of non-Oculus platforms/products
We also have certain rules on art assets, eg. not placing text on the top right of the banner image. For details, refer to the Art Guidelines.

Supported Modes are unnecessarily set to 360-only or roomscale-only
360-only or roomscale-only supported mode settings should only be used if your game involves such large amounts of 360 rotation and/or roomscale movement that the game would be unplayable without it. Most times, you can get by with also including Forward-Facing or Standing in the list of supported modes. Even if your app involves full 360 rotation, it is recommended to enable forward-facing players to play, by implementing snap turn controls.

The registration of the hand models in VR do not match the real-world hands
The in-VR hand or controller model must match the position and angle of the real-world hand as much as possible. A quick way to test for this would be trying to touch one hand with another hand to see if the models touch each other, or to look under the space between the headset and your nose to see if your real-world arm seamlessly flows into the in-VR hand. Be sure to also check out our best practices on Touch button functionality mapping, especially if you are porting your app from other hardware. Following them should make your app easier to learn for new players.

The app does not pause when headset is taken off or the player calls up the Universal Menu/Dash
Remember that the PC VRC guidelines state “Single player apps must pause when the user removes the HMD or opens the Universal Menu.” In the case of apps made with Unity, make sure “Run in Background” in the Application Settings is not checked. This is not the case, however, for online multiplayer games. Also, Rift Core 2.0 software replaces the Universal Menu with Dash, adding a separate application lifecycle state. (Docs: Unity, Unreal, Native code.) While not mandatory, we strongly recommend adding support to Dash as well.

Positional tracking is disabled
We see this occasionally in ports from mobile apps. Except for cases like 360 video, where positional tracking is impossible, always enable positional tracking when available.

For PC applications, we also recommend running the VRC Validator on your app to find any technical problems prior to submission.

Support for older phones, eg. Note 4
If you are developing using newer phones like the S7 or S8, you may discover upon submission that your app misses performance targets on older phones like the Galaxy Note 4. While it is certainly best to have your app cover the widest range of devices, if it is difficult to support older devices, you may also choose not to. You can do so by writing in the Message For Reviewers text field, eg “My app does not run on Note 4”.

Incorrect back button behavior
The “Back” button, available on the Gear VR headset and on the controller, should behave as a general Back or Pause button when short-pressed, depending on context. If the behavior has not been implemented, it will be flagged during technical review.

Specifically, if you're...