On submission, your app will first go into technical review, where our team will analyze your app on a number of vectors, including the Virtual Reality Checks (VRCs). This process will vary in length, but can take up to 7-10 business days, so be sure to include time for this review in your development timeline.
The following document will provide you with a series of best practices, technical challenges we often witness, and commonly failed VRCs. Please review and test for each of these items prior to submitting your app for review, as this will save you a great deal of time (and resources) as you work to launch your app on the Oculus Store.
Our team is made up of expert technical reviewers, passionate VR advocates, and independent developers who have experienced this process. We are excited to support you and your team throughout this process.
The Oculus Platform Command Line Utility (CLI) enables a number of features that will streamline your upload process. The utility allows you to upload builds at a maximum of 1GB as opposed to the developer dashboard, which has a maximum requirement of 400MB for Quest uploads and 200MB for Go uploads. It also helps minimize iteration time by only uploading those parts of your app that have changed, and automating the ingestion process with specific commands. Lastly, to streamline your submission process, the utility will pre-validate a number of items including a few VRCs.
To save you time going between applications, some functionality from the Platform Utility is also included within the Platform Tool available in both Unity and Unreal. See the following documentation for more information on the Unreal-specific implementation: Upload Apps to the Oculus Store with Oculus Platform Tool.
When using the Oculus Platform CLI, or Platform Tool within your preferred engine, make sure you have a stable internet connection, as inconsistent connections can disrupt the upload process. Also remember to keep your app access login token private, as sharing this token publicly can lead to significant privacy issues.
For mobile apps, when you initially submit your build to any channel in the Oculus store, the system runs an automated security vulnerability scan on your app package. This scan is intended to provide an initial check for any major vulnerabilities, Android exploits, or unsecure features.
See the Security Vulnerability Testing documentation page for more information on this step of the technical review process.
Focus Awareness enables different forms of the Oculus System UI to display on top of your app without pausing it. This functionality is now strongly recommended for all Quest apps, as it helps to ensure a more engaging user experience. To enable your app to be focus aware, check out the following documentation:
Your App ID is a unique identifier specific to your app’s entry within the developer dashboard, it assures that your builds and release channels are associated to your app.
Remember to create a unique App ID per each targeted hardware platform, and while it is not required for initial development, not having your App ID created + enabled within your engine of choice will result in a number of issues, especially if you are using platform services. These include:
Simply begin by creating a unique app within the development dashboard. The App ID is automatically generated for you within the dashboard.
Note: The Oculus Dashboard does not automatically associate the App ID to your project, you must configure it within your engine. We recommend this configuration as soon as the App ID is generated. See below for the documentation on how to set the App ID within your engine of choice:
Prior to starting development, set your platform to the correct setting witin your engine, this will help ensure that your workflow is targeting the correct headset.
As an example, initially targeting PC, then changing your platform to Mobile/Android a year into development can make for a number of challenges, especially in regards to performance requirements.
See below for how to set your platform within each engine:
If you plan to generate revenue within the Oculus Store, you will need to make sure all financial information is accurate and up to date. Be sure to review the technical documentation for managing your financial information, while the outline below features common developer challenges + tips to streamline the store payment process and app submission.
Keep your financial information up to date: While it may be obvious, you would be surprised by the number of support requests we receive regarding outdated financial/legal information. We strongly recommend reviewing this information prior to moving forward with app submission and launch.
The importance of dashboard Role assignments: How each member of your organization is categorized within the developer dashboard can be especially important when it comes to the payment process. Note that the dashboard offers a Role labeled “Finance”. We recommend the following documentation for more on Creating an Organization and Managing Users.
Financial information and payout issues: To reiterate, make sure your financial information is up to date within the dashboard, as well as the information provided to your bank. Inaccurate information can (and has) lead to banks rejecting Oculus Store revenue payouts.
Financial Entity information and changing ownership: Along with all other financial information, the FE field (financial entity) is especially important if you’re changing ownership of your organization within the dashboard. If this is the case, review all of your financial information for accuracy and review the Dashboard Best Practices.
Reach out to FB support for financial requests: The Oculus financial systems are managed in partnership with FB support. Please reach out to them should you have any challenges with this process.
If you are developing for a standalone device like the Oculus Quest, the Android manifest file is required to ensure that the various Android level settings and permissions are properly configured.
The Android Manifest file is not automatically generated, to do so, your app must align with the required specs. See the following doc for a detailed overview of the Oculus app manifest specifications: Application Manifests for Release Builds.
Depending on the functionality of your VR App, we find that managing permissions within the Android Manifest can lead to hiccups in the upload and submission process. We will pay especially close attention to any permissions that Google considers dangerous, including camera, location, microphone, reading + writing external storage, etc.
Be sure to keep in mind that you should only enable those permissions that you are leveraging within your app, and to remove any other permissions that might be leftover.
If you are developing for a standalone device like the Oculus Quest, a keystore is essential to the submission and publishing process. The keystore is a file which is generated within your game engine and acts as a sort of ID badge. It authenticates who you are and that you have the rights to publish your app.
We recommend saving your keystore in a secure, but memorable location so that you do not lose or forget your keystore.
Note: If you lose your keystore, you will not be able to update or publish your app. The only way to generate a new keystore is to delete every version of your build, which would leave all users unable to use your app.
See the following Oculus documentation for steps to sign your app, and assure it is signed within Unity or Unreal: Android Application Signing.
For more information on Android App signing check out this doc on android.com: Sign your app.
The entitlement check is another essential step in the process of app submission and publishing (and a commonly failed VRC). This check ensures your app was purchased by the user, and they have the right to launch your app, ultimately acting as a form of protection from content piracy.
Note: If you have the role of developer within the developer organization of your app, you automatically have the entitlement, and are free to test the entitlement check.
See below for steps to implement the entitlement check per each engine, as well as the steps to check your entitlement.
For VR development, It is crucial that you optimize your app for the target platform, especially to streamline technical review.
We provide a number of tools and best practices to help you analyze + optimize your app to meet frame rate. See below for a snapshot of these resources, as well as the specific performance requirements within the VRC section below.
Tools to help you analyze your app for performance issues:
Best practices for performance analysis and optimization:
VRCs were created to help ensure that your app does not include any technical issues that would cause discomfort, or negatively impact the user experience. The VRC portion of the technical review process involves the Oculus Store Team manually reviewing your app along with each VRC that aligns with your target platform. To save time and effort during this process, you should thoroughly test each of the VRCs before uploading your app for review.
Note: For each VRC the focus should be on the user experience of your app, and not just to check off a box. During our team’s review, user impact will be the focus, as we want to ensure your app delivers maximum value to your audience.
See below for the more commonly failed VRCs, along with a link for more information on how the VRC is tested.
Internet requirement notification:If your app requires Internet connectivity for its core functionality, notify users without an active Internet connection that one is required.
Quest Functional VRC 7
When headset off, do not send commands (PC Only):The app must not submit frames or accept input when the user removes the HMD or opens Oculus Dash.
PC Input VRC 1
Focus aware with Universal Menu or Dash:If an app is “focus aware” it must continue rendering while the Universal Menu is up, but hide any user hands or controllers and ignore all input.
Quest Input VRC 4
PC Input VRC 9
VRCs specific to the back button (Go/GearVR only):The app must open Oculus Dash if the user long-presses the back button. When the user presses the back button, the app must either go back one level in your UI or display a menu with an option to quit the app.
Mobile Input VRC 2
Mobile Input VRC 3
Required framerate (Quest):The app displays graphics in the headset at 72 frames per second.
Quest Performance VRC 1
Required framerate (PC):The app must display graphics in the headset at 90 frames per second (Rift), or 80 frames per second (Rift S) on Nvidia 970 GPU (PC VRC 3) and AMD 290 GPU (PC VRC 5) running Windows 10.
Note: Your app must meet these requirements at default, on boot. In other words, your app must function as intended on a recommended spec PC as defined by Oculus without any modifications to in-app settings. Be sure to review the resources within the Performance Optimization section above.
PC Performance VRC 3
PC Performance VRC 5
Convergence errors:App must render without convergence errors or unusual distortion.
PC Performance VRC 7
Play mode requirements:When configuring the submission metadata for your app, it must meet the requirements for either sitting, standing, or roomscale play modes.
Note: This includes the expected UX for each mode, for example:
Check out the Locomotion Best Practices for more on tracking + locomotion design.
Hands hidden when not tracked:For apps that support hand tracking, hands must be hidden if they are not being tracked or if tracking confidence is low.
Quest Input VRC 6
Input selection:For apps that support hand tracking, the app must properly respect when input is switched between controllers and hands.
Quest Input VRC 7
System gesture:For apps that support hand tracking, the system gesture is reserved, and should not trigger any other actions within the app.
Quest Input VRC 8
Following technical review, your app will be shared with our Content Store Team, where they will review your app for the more non-technical, UX, design, and content-focused aspects.
To prepare for this phase of app submission, be sure to check out the Content Review Best Practices Guide.