Meta Quest developers looking to port their Unity-based apps to Google’s newly unveiled Android XR operating system shouldn’t have a tough time of it, Unity says, as the game engine creator today released all of the tools devs need to get cracking.

Google unveiled its Android XR operating system today, which is coming first to the newly revealed Samsung mixed reality headset, “Project Moohan,” slated for consumer release in 2025. The short of it: details are still very thin, although Samsung’s prototype feels like a mashup of Quest and Apple Vision Pro, which you can read more about in our hands-on.

And Unity, maker of the most popular game engine for XR app developers, announced they’ve partnered with Google to provide official platform support for Android XR. So, starting today, app developers can both build as well as port existing games and experiences to upcoming Android XR devices.

Samsung Project Moohan | Image courtesy Google

Developers opted into the Public Experimental release of Unity 6, which is available for all versions, can start now, which includes dedicated documentation and optimizations to help create performant and comfortable experiences, Unity says.

Unity’s XR tools also feature support for a list of modern features, including hand and eye-tracking, occlusion, foveated rendering, composition layers, and more features designed to make it “easy to start fresh or expand your audience by bringing existing apps and games to Android XR,” the company says.

Apps that already integrate OpenXR will ostensibly be the easiest to port, with Unity citing studios like Owlchemy Labs and Resolution Games, which have brought their Unity apps to Android XR with “minimal effort,” the company says.

“This is as simple a port as you’re ever going to encounter. Plus, it’s not going to break your four-person studio—or your 400-person studio—to make it happen,” says Owlchemy Labs CEO Andrew Eiche.

SEE ALSO
Physics Action Puzzler ‘BONEWORKS’ is Coming to Quest 3, Pre-production for Next Game Announced

For now, Google has only shown off Android XR working on Samsung’s prototype in addition to a pair of prototype smartglasses we got to try on (re: not AR), although it and Unity making porting easy for Quest developers feels like a strong opening gambit.

While Android is generally known for its broad device support, it’s likely the company will need to keep a fairly short leash on the sort of devices it hopes to support with Android XR though. Granted, it’s the earliest of early days for Android XR—we don’t even know the specs, price, release date, name, etc for Samsung’s headset.

Still, Google ostensibly has its sights on capturing a substantial slice of the XR market in the coming years. Notably, in addition to VR content, Android XR supports the entire existing library of standard Android apps as well as “spatialized” versions of those apps, undoubtedly positioning Google as a “day-1” player in the XR space, and competitor apparent to both Meta’s Quest platform and Apple Vision Pro.

– – — – –

We’re still learning about Android XR; we haven’t heard whether other major game engines, like Epic’s Unreal Engine, are offering similar support. It is however a good bet though, considering Unreal Engine has supported OpenXR for a number of years now. Road to VR will of course be following all things Android XR, so make sure to check back soon for more.

Newsletter graphic

This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. More information.

Scott Hayden
Well before the first modern XR products hit the market, Scott recognized the potential of the technology and set out to understand and document its growth. He has been professionally reporting on the space for nearly a decade as Editor at Road to VR, authoring more than 4,000 articles on the topic. Scott brings that seasoned insight to his reporting from major industry events across the globe.
  • Christian Schildwaechter

    Unity as the most popular engine for VR games quickly supporting AndroidXR isn't surprising. It already does so for most XR platforms, made possible by OpenXR. In the early VR days each company supplied their own SDK and Unity plugins, most now switched to OpenXR, with Unity basing their plugin structure on it. UnityXR further abstracts functionality not covered by OpenXR, allowing devs to mostly implement apps once and have Unity translate them to the matching Meta/Pico etc. OS and SDK.

    This made porting XR apps very easy to port. VR didn't start that open, instead everyone tried to compete with incompatible, but very similar solution. VR being less successful than expected had everyone facing the same problem of lacking games, made worse by developers having to adapt each game to various slightly different APIs, financially unviable in an already tiny market. So early on there was a common interest to unify the API with OpenXR, now managed by Khronos Group.

    OpenXR support is almost universal, and even AVP lacking it runs the very similar WebXR on top of ARKit, making it easy for Unity to integrate. A much better situation than with Windows vs MacOS vs Linux or Android vs iOS, where porting is much harder despite cross-platform tools like Qt or virtual machines like on Java, which don't allow for the same tight integration as a native/unified API. Which leads to platform lock-in, while switching XR platforms will be easier with apps ported everywhere using OpenXR, and tools like Unity handling remaining differences.

  • It's an amazing thing, but honestly, it's not very surprising. Unity has tools like Unity.XR, Unity XR Interaction Toolkit and the new Input System which are made exactly for this purpose: building cross-platform XR apps. Every time a new runtime is added, theoretically you just check a box and you build for the new platform without changing anything of the code. In reality, there are some little things to change here and there (e.g. if you put images of the controllers in the tutorials, you have to make them dependent on the platform you are building for), but most of the codebase stays the same. This is how I also ported two pieces of content to Pico in less than one day when Pico launched his new headset in Europe years ago.