XR Game Engines Compared: Unity, Unreal, and Godot

Which XR engine should you use?

There is no single winner, and any article that names one is describing its own project. The useful split is this: Unity is the default for teams that want the widest middleware and platform coverage, including Apple Vision Pro through PolySpatial on paid plans. Unreal Engine is the choice when rendering fidelity is the constraint and the target hardware can feed it. Godot is the choice when license cost and source access matter more than the largest asset market, and since version 4.7 it can build and publish standalone Android titles without a custom toolchain.

All three now speak OpenXR, so the runtime API no longer decides the project. The engine decides the renderer, the interaction layer, the platform packaging, the license, and how fast your team can iterate inside a headset.

OpenXR changed what the choice is about

OpenXR is the Khronos standard that abstracts headset poses, actions, and swapchains, and every engine here consumes it. Unity’s OpenXR Plugin, at version 1.14.0, describes itself as working with any device that supports conformant OpenXR runtimes and ships a table of known runtimes with their build targets and preferred graphics APIs. Godot goes further and treats OpenXR as a core module with its own settings page, action map, form factor and view configuration. Unreal splits the difference: Meta documents installing the Meta XR plugin and then choosing an OpenXR backend for the project. If you want the underlying concepts, What Is OpenXR? covers the API and its extension model.

The consequence is that session creation, pose polling, and action bindings are portable. Vendor extensions are not. Passthrough composition layers, hand tracking details, body tracking, and eye tracking all run through extensions, and each engine wraps them differently. So “we use OpenXR” is true for all three engines and still leaves you with engine-specific code for the features that make mixed reality worth building.

Unity: breadth, paid for in version bookkeeping

Unity’s XR story is a stack of packages rather than a single feature. The XR Interaction Toolkit is at version 3.0.11 and requires Unity 6000.0 or later, which means the Unity 6 editor line. It provides a component-based interaction system: interactors and interactables for hovering, grabbing and selecting, locomotion components, canvas UI interaction through controllers, and an XR Device Simulator so you can test interactions without putting a headset on. Controller input covers Meta Quest, OpenXR and Windows Mixed Reality.

On top of that sit the OpenXR Plugin for runtime access and vendor packages for device-specific features. Meta maintains its own Unity integration, and Google’s Android XR documentation lists Unity among the supported engines, with Job Simulator cited as an example of a Unity title ported to the platform. If your requirement is “ship on Quest, Android XR, and PC VR from one codebase”, Unity has the most travelled path.

Vision Pro is the sharp edge. Unity supports it through PolySpatial, now at version 2.3.1, and Unity’s own documentation states that PolySpatial and visionOS support are only available to Unity Pro, Unity Enterprise and Unity Industry subscribers. That is a licensing gate, not a technical one, and it belongs in the budget conversation before anyone writes code.

The cost of the breadth is version bookkeeping. Unity’s XR stack spans the editor version, the interaction toolkit, the OpenXR plugin, the render pipeline, and one vendor package per platform, and those versions have to agree with each other. Upgrading one usually means checking all of them.

Unreal Engine: the highest rendering ceiling, and the highest floor

Unreal’s pitch to XR is visual quality, and the engine keeps earning it. Unreal Engine 5.8 was planned as the last major release before Unreal Engine 6, and Epic has since shipped a 5.9 preview in November 2026 that 80 Level reports was built primarily through agentic workflows, with engineers directing agents to port AI tooling and to reintroduce Web as a target platform. That release also brings Lumen World Cache and improved Nanite culling, and it explicitly warns that preview builds are unstable and still being cleaned up 80 Level: Unreal Engine 5.9 Preview Is Out.

The browser target is the interesting part for anyone building XR adjacent tooling, because Epic says projects will run in browsers through WebAssembly and WebGPU. That is the same compute surface the web graphics stack has been converging on, which WebGPU vs WebGL explains, and it lines up with the single-renderer, multi-target approach covered in the briefing on one renderer for four targets.

Inside a headset the calculus changes. A standalone device runs on a mobile chipset inside a thermal budget set by the headset, which What Is Inside a VR Headset? breaks down: the display, optics, cameras and tracking all draw from the same power and heat envelope as the SoC. Unreal’s deferred renderer with Lumen and Nanite is built for hardware with far more headroom than that, so standalone XR work in Unreal tends to mean deliberate renderer choices and careful profiling rather than defaults.

Licensing is straightforward: Epic charges a 5 percent royalty on lifetime gross revenue above 1 million US dollars per product, and royalty-based licensees do not buy seats Epic Games: Unreal Engine license.

Godot: MIT, OpenXR in core, and a real Android export path

Godot 4.7 is the current stable release, published on 18 June 2026. The headline for XR developers is not a rendering feature, it is packaging: the release notes state that developing on Android and XR has been possible for a while, and that with the stable release of the Godot Android Build Environment (GABE), developers can now export and publish their games as well. In practice that removes the custom Gradle and SDK assembly step that used to sit between a working Godot XR prototype and a store submission.

OpenXR is part of the engine rather than a plugin. The settings expose an action map, a form factor choice between head mounted and handheld devices, and a view configuration choice between mono and stereo, and Godot is candid about the gaps: the documentation notes that some OpenXR view configurations are not supported yet, naming Varjo’s quad view as an example. Rendering matters here too. Godot’s Forward+ renderer is described as suited for desktop platforms only, while the Mobile renderer is the default on mobile platforms, so standalone headset work lands on the Mobile renderer with its reduced feature set.

Vendor features come from the Godot OpenXR Vendors plugin, a GDExtension that adds vendor OpenXR extensions which cannot live in the engine itself because they are specific to one vendor. It targets Android XR, Meta and Pico runtimes, is MIT licensed, and installs from the Godot Asset Library GitHub: Godot OpenXR Vendors plugin. The engine itself is MIT licensed Godot: License, which means no royalties and no seat fees.

Google lists Godot alongside Unity and Unreal on its Android XR developer pages Android Developers: Android XR, so the platform is not a hypothetical target, and What Is Android XR? covers what that platform expects from an engine. What Godot lacks is the depth of high-end rendering features and the commercial middleware market that Unity and Unreal have accumulated, plus a smaller pool of engineers who already know the engine.

The comparison that actually decides projects

• Platform coverage. Unity has the widest set of vendor packages, including visionOS. Unreal covers PC VR and standalone through OpenXR and vendor plugins, and is named by Google for Android XR. Godot covers standalone Android and PC VR through core OpenXR plus the vendors plugin, and is named by Google as well.
• Renderer ceiling. Unreal is highest, Godot’s Forward+ is desktop-only and its Mobile renderer trades features for speed, and Unity sits in between depending on whether you use the Built-in pipeline or URP.
• Interaction layer. Unity’s XR Interaction Toolkit gives you grab, poke, ray, locomotion and UI out of the box. Unreal leans on Blueprints plus the Meta XR plugin’s interaction framework. Godot gives you OpenXR actions and expects you to build interactions, often on top of community XR Tools.
• Iteration speed. Godot’s editor and C#/GDScript workflow restart fastest, Unity’s domain reloads cost time, and Unreal’s C++ compile and shader cooking are the heaviest of the three for small changes.
• Licensing. Godot is MIT and free. Unreal is 5 percent royalty above 1 million US dollars per product with no seats. Unity is subscription-based, and visionOS support requires a paid plan.
• Ecosystem. Unity has the largest XR asset and middleware market, Unreal has the strongest content pipeline for high-fidelity art, and Godot’s is growing but thinner, especially for vendor-specific XR features.

Which one to pick

• Quest or Android XR first, small team, no license budget. Godot 4.7 is now a defensible answer, because GABE closes the export gap and the vendors plugin covers Meta and Pico extensions.
• Quest first, complex interaction requirements, mixed team with C# experience. Unity, with the XR Interaction Toolkit and the OpenXR plugin, and vendor packages added only for platforms you actually ship.
• PC-tethered VR or location-based installations where the visuals are the product. Unreal. The renderer is the reason, and the royalty only starts to matter at revenue that most XR projects never reach.
• Apple Vision Pro. Unity with PolySpatial, on a Pro, Enterprise or Industry plan. There is no free path.
• A codebase that must also run in a browser. Unreal’s returning Web target and the wider WebGPU toolchain are converging, but the web build path is still less proven than shipping a native standalone build.

Limitations and caveats

• Versions move. The numbers above are the ones shipping as of November 2026: Unity 6 with XR Interaction Toolkit 3.0.11 and OpenXR Plugin 1.14.0, Godot 4.7, Unreal Engine 5.8 with a 5.9 preview. Check the current docs before you commit a project to a version.
• Previews are not shippable. Unreal 5.9 is a preview with prototype parts in its web renderer, and Epic says so directly.
• OpenXR portability is partial. Core session and input code moves between engines; passthrough, hand tracking and composition layers do not, because they live in vendor extensions with engine-specific wrappers.
• The engine is rarely the bottleneck. Frame time, comfort and content quality decide whether an XR build succeeds. Switching engines to solve a performance problem usually moves the problem rather than fixing it.

---

Sources

• Unity: XR Interaction Toolkit 3.0.11 (interaction components, Unity 6000.0 requirement, supported controller inputs, device simulator)
• Unity: OpenXR Plugin 1.14.0 (conformant OpenXR runtimes, supported build targets, graphics APIs)
• Unity: PolySpatial 2.3.1 (visionOS support restricted to Pro, Enterprise and Industry plans)
• Unity 6 manual: XR (Unity’s XR, MR and AR scope, sample projects)
• Godot Engine 4.7 release (Android and XR development, stable GABE export and publishing, editor features)
• Godot: 4.7-stable release metadata (release date, 18 June 2026)
• Godot docs: OpenXR settings (action map, form factor, view configuration, unsupported Varjo quad view)
• Godot docs: Overview of renderers (Forward+ desktop only, Mobile default on mobile, Compatibility for web)
• GitHub: Godot OpenXR Vendors plugin (vendor extensions for Android XR, Meta and Pico, MIT license, Asset Library distribution)
• Godot: License (MIT license terms)
• Meta: Unreal Engine integration (Meta XR plugin install, OpenXR backend choice, packaging)
• 80 Level: Unreal Engine 5.9 Preview Is Out (5.8 as planned final UE5 release, agentic build workflow, Lumen World Cache, Nanite culling, Web target via WebAssembly and WebGPU, preview stability warning)
• Epic Games: Unreal Engine license (5 percent royalty above 1 million US dollars, no seat purchase under royalty licensing)
• Android Developers: Android XR (Unity, Godot and Unreal named as supported engines, OpenXR and WebXR)