After I have written my post on how to handle unwanted permissions in Unity, many Oculus Quest developers asked me to make another tutorial to solve another common problem: Facebook showing a warning for 32-bit builds submitted to App Lab.
This happens because if you build your Unity application leaving the default settings, the Android build may be a 32-bit one, but actually all the modern stores now require 64-bit builds. For instance, when some months ago I published an application for a customer on Google Play, it got rejected because Google Play doesn’t even allow uploading 32-bit apps anymore. Facebook still allows 32-bit apps on the Oculus Quest store, but it warns you that this is going to change soon, so you had better learn how to work with 64-bit applications. And guess what? Your Ghost is here to tell you how!
How to make 64-bit builds for App Lab – Video
Here you are my video tutorial with an in-depth explanation of the problem and the solution. I have shot everything inside the project of my famous The Unity Cube app… don’t forget to download it on App Lab and give it 5 stars!
Watching it, you can learn how to build in 64-bit for the Quest like a boss!
How to make 64-bit builds for App Lab – Textual Instructions
I’ll give you two very easy methods to get rid of the 32-bit nasty warning.
Method 1 – The Unity Way
If you have not imported the Oculus plugin, or you are a true Unity purist and want to do this operation in the classical way, this is how you do it:
- Go to Edit -> Project Settings…
- Select the Player Tab on the left panel of the windows that opens
- Make sure that you are changing the settings for the Android build (select the Android Tab on the right panel)
- Scroll until you reach “Other Settings” and expand the section
- In the “Configuration” section, change Scripting Backend to “IL2CPP” and as Target Architectures unselect ARM v7 and select ARM64
Method 2 – The Oculus Way
In case you have installed the Oculus Integration from the Unity Asset Store, you have a set of facilities to make this even easier:
- Go to Oculus -> Tools -> OVR Performance Lint Tool
- In the popup that opens, if there is a line that says “Optimize Scripting Backend. For CPU performance, please use IL2CPP”, click on the Fix button that there is next to it
- if there is a line that says “Set Target Architecture to ARM64. 32-bit Quest apps are no longer being accepted on the Oculus Store”, click on the Fix button that there is next to it.
IL2CPP
In both methods, you have to convert your scripting backend to IL2CPP from Mono. Speaking roughly, this means that the code that you write in C# gets converted to CPP before performing the final build, and this lets Unity create more optimized builds. IL2CPP is the new standard for building Unity apps.
Most of the time, you can switch between one backend to the other safely, and nothing changes for you. But in my career there have been two cases when IL2CPP has created some trouble for me:
- An old version of the Vuforia plugin didn’t work properly with IL2CPP: I had to update Unity and the Vuforia plugin to a newer version to make the app build. Some libraries may work with Mono and not IL2CPP or vice versa. They are infrequent cases, but they may happen;
- In some projects where there are intermediate solutions to build (e.g. UWP apps), Mono is sometimes easier to debug. At least, in a HoloLens 1 project that I had to manage some years ago, IL2CPP was a mess to debug in Visual Studio, while Mono was just the same plain C# that I had written inside Unity. I know things are better now, but since I don’t have a HoloLens with me, I can’t tell you for sure.
If you want to read more about IL2CPP you can refer to the official Unity manual: https://docs.unity3d.com/Manual/IL2CPP.html
And that’s it! I hope this tutorial has been useful for you, and if it is the case, share it on your social media channels to help other VR developers!
(Header image using material from Facebook and from Unity Technologies)