• What is a build?
• To Build or not to Build?
• Build often and test the build thoroughly
• Build to Device
• Reduce Build Times
  • Offload Builds to another machine

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 can create 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 HDM, 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)
2. 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 (which could be due to the baking of the lights), scripts do not execute the way you expect them to (which you'll have to debug using a 'Developmental Build'), or assets which are not loading as you expect them to (such as AssetBundles, Third party assets, or others).
3. 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

 In progress

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 setting the Build Target, the Graphics Pipeline, and a few standard assets. 
2. 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. 
3. Put shader variants in a preset:
     Edit —> Project Settings —> Graphics —> Save to Asset. Put this asset in the Preloaded Shaders array ([https://docs.unity3d.com/2020.1/Documentation/Manual/OptimizingShaderLoadTime.html])
4. Disable “Optimize Mesh Data”
     Edit —> Project Settings —> Player —> Optimize Mesh Data (uncheck) (It’s near the bottom)
5. Use the least amount of Graphics API’s you can get away with. This means that if you have control over on which devices you’re going to build to, only use the Graphics API you know you need.
    Edit —> Project Settings —> Player —> Graphics API (choose Vulkan, or OpenGL3, or any. Try to use only one). Uncheck “Auto Graphics API” to enable changing the array. 
6. 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 the Unity Cloud Build. 

Cloud Build 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.