What is a build?

A Build is a standalone version of the project you made inside the Unity Editor. Below are some considerations. 

To Build or not to Build?

In some cases you're going to have to Build. For instance, if you run your project on one of the standalone headsets such as the Quest, Building is a necessity. 

In other cases you can opt for running the project from the Unity Editor. For instance, if you use one of the wired headsets (which includes a Quest using Link on a Windows PC), you could theoretically forego Building altogether. But even then you might consider creating a Windows Standalone Build. 

There's advantages and disadvantages to both solutions. Running from the Editor allows you greater and easier control over the program running in the HMD, since you have all the options the Unity Inspector provides you. However, keep in mind that the Unity Editor is a resource-hog, which results in lower frame rates in the HMD compared to running a standalone version. Lower frame rates can result in a less pleasant experience for your participants, including nausea. 

The biggest downsides of Building a standalone are: 

1. More difficult bug-catching process (since you have more limited access to the Unity Console)

1. Your project will behave slightly differently in Build compared to the Editor. It is unclear why this is the case, but it is an unfortunate reality. You might find that colours and lighting are different (for example, colour space, lighting/baking settings, or platform-specific shaders), scripts do not execute the way you expect them to (which you'll have to debug using a Development Build), or assets which are not loading as you expect them to (such as AssetBundles, Third party assets, or others).

1. Building can be very slow. Depending on the size and settings of your project (see below), Building can take dozens of minutes or in some cases a few hours. All this time your Unity Editor is completely locked, and you are not able to continue working. This is a main hindrance to Building, which can result in fewer test-builds, which can provide you with a whole host of additional problems (see below). 

Build often and test the build thoroughly

If you decide to run your project from a standalone build, it is highly recommended that you build early, build often, and test your builds thoroughly. For the above mentioned reasons, you want to check often whether your Build runs as you expect it to. Below are a few ways to improve this process. 

Build to Device

When building for a standalone headset or mobile device, Unity 6+ uses Build Profiles (File > Build Profiles) instead of the old Build Settings window. Each platform has its own build profile with dedicated settings.

Meta Quest (Unity 6.1+)

1. Go to File > Build Profiles > Add Build Profile and select Meta Quest (or Android for generic Android headsets).
2. The Meta Quest build profile defaults to Vulkan, IL2CPP scripting backend, ARM64 architecture, minimum API level 29, target API level 32, and stereo instancing. You can override these per profile in Player Settings.
3. To deploy, use Build & Run (File > Build Profiles > Build & Run) to build and sideload the APK directly. Alternatively, use ADB or the Meta Quest Developer Hub to sideload the APK manually.

Wired headsets (Link / SteamVR / OpenXR)

1. Use a Windows Standalone (or Mac/Linux Standalone) build profile.
2. Run the build via the Meta Quest Link, SteamVR, or OpenXR runtime on your PC — no separate Android build is needed.
3. This approach avoids the overhead of the Unity Editor and gives you higher frame rates than running from the Editor.

Reduce Build Times

1. The first Build you do takes forever. Build as soon as you've set up the absolute basics of your project, such as selecting a build profile / platform, configuring the render pipeline, and a few standard assets. 

1. Repeat step one every time you import a large amount of assets, especially textures, materials, and shaders. Go grab a cup of coffee and/or some lunch. 

1. Put shader variants in a preset:

  Track the shader variants you use, then use Graphics Settings > Shader loading > Create asset to make a Shader Variant Collection. Add that collection to Preloaded shaders so Unity prewarms them on startup. This reduces shader compilation hitches at runtime (not primarily a build-time optimisation, but improves the player experience).

1. Only disable Optimize Mesh Data (Edit > Project Settings > Player > Other Settings > Optimization) if you switch materials or shaders at runtime and see stripped vertex attributes causing issues; otherwise leave it enabled — it reduces build size, loading times, and runtime memory.

1. Use the least amount of Graphics APIs you can get away with. For Quest and Android XR devices, Vulkan is the recommended API — OpenGL ES is now considered a legacy API. Only include OpenGLES3 as a fallback if you need to support older devices that lack Vulkan support.

 Edit > Project Settings > Player > Other Settings > Graphics APIs. By default, Unity 6 Android projects have Auto Graphics API enabled (tries Vulkan first). To use a single API, uncheck Auto Graphics API and remove the ones you do not need. 

1. Remove Packages / Assets you do not need. See Package Manager, uninstall ones that are unnecessary. Same goes for assets downloaded from the Assetstore or elsewhere. Purge all that's not needed. 

A helpful Asset for this is Asset Hunter Pro. It analyses your latest Build report, and lists all the files that are not included in the Build, therefore could be considered to be unnecessary. Always make backup / Git commit prior to purging assets with AHP, and manually check all suggested assets, since AHP cannot distinguish between truly-unnecessary and not-needed-in-the-final-project.

As a sidenote to this, make a separate Unity Project in which you can download any Asset Packs you want to use in your main project. More often than not, you will only need a handful components from the pack, and not have the entire Asset hanging around in your main project. See this helpful guide by Tarodev. Keeps your main project nice and fast. 

Offload Builds to another machine

You could get a separate device run the builds for you. Strictly speaking this does not reduce the build-times, but the Builds will not be done on your main machine. Therefore, your Unity Editor will not lock up, allowing you to continue working on your project. 

A 'manual' solution to not having your main Unity Editor lock up, is to use a separate computer for Building. From your main computer, commit your changes to your VCS, and pull them on the second PC. On that computer, create a Build. While this is building you can still use your main device!

Another option is to offload your builds to Unity Build Automation (formerly Unity Cloud Build). 

Build Automation requires your project to be on a version control platform such as Git / GitHub (which you should anyway!). If you commit to a predefined branch, it will automatically trigger the building process. You'll receive an email once the build is done. Keep in mind that under the standard settings, recommitting to that branch before your previous Build is done will cancel the previous build. 

Additionally, you can set a (recurring) scheduled build. For instance, you can push your final commits of the day to the designated branch, and the service will build your project overnight.