Should we build our XR app in Unity or Unreal?

Start from what the experience is for, because that settles it faster than any feature comparison. Unity is the reasonable default for standalone headset work, phone AR and anything that has to run across more than one device class: it supports OpenXR, headset vendors ship maintained plugins for it because that is where their developers are, AR Foundation covers ARKit and ARCore from one codebase, and the XR hiring pool is larger than any alternative by a wide margin. Unreal earns its place when photoreal fidelity is the value rather than a nice-to-have, an architectural walkthrough, a high-end product review, a simulation where visual realism is the training content, and when you have the hardware to drive it. Its higher visual baseline is easiest to reach with a workstation behind the headset and needs deliberate reduction to fit the thermal and power budget of a standalone device, and plugin coverage for enterprise headsets and phone AR is thinner, so confirm support for your exact device before committing. Most enterprise and training XR needs a fidelity floor rather than a ceiling, which is why most enterprise XR is built in Unity.

When is WebXR the right choice instead of a native XR app?

When the install is the obstacle. A link that opens an experience removes the single largest drop-off in consumer XR, which makes the browser the right answer for campaigns, product visualization, anything aimed at the public, and anything that has to survive a locked-down corporate device. The trade is real: a lower performance ceiling, uneven browser support across devices, and no access to device capabilities the browser does not expose, so anything depending on eye tracking, a peripheral or a vendor-specific feature is out of reach. Phone-based web AR often leans on a commercial framework doing its own tracking because native browser support for AR sessions has been inconsistent, especially on iOS. The clean test is who the users are. If they are members of the public or staff on devices you do not control, the distribution advantage usually outweighs the ceiling. If they are trained staff on managed headsets, installation is not a real cost and you should choose on capability instead.

How much does it cost to switch XR engines mid-project?

Treat it as a second build rather than a port. Art assets, 3D content and design work survive a switch; interaction code, tooling, integrations, build configuration and platform-specific glue do not, and those are usually where the engineering time went. The way to avoid the question is to spend the first week proving the riskiest thing on the chosen stack: the eye-tracking read, the live data feed, the multi-user session, whatever it is, running at frame rate on the actual hardware rather than in the editor. That prototype is the cheapest insurance in an XR project, because it resolves the unknown that could invalidate the plan while the plan is still cheap to change. It also tends to answer the engine question honestly, since the constraint that decides it, a missing vendor plugin, an unreachable device API, a performance budget that does not close, shows up in the prototype and nowhere in the comparison chart.

Unity, Unreal or WebXR? Choosing the Engine for an XR Build

TL;DR: Unity, Unreal and WebXR are not three answers to the same question. Unity is the sensible default for standalone headset work and for anything that has to talk to device SDKs. Unreal earns its place when photoreal fidelity is the product and you have the hardware to drive it. WebXR wins when the experience must open from a link with nothing installed, and pays for that with a lower ceiling on fidelity and device access. The decision is made by the device you already picked, how much of the value sits in the visuals, which SDKs you have to reach, and who maintains the thing in two years. In that order.

Engine choice is the argument that arrives earliest in an XR project and deserves to arrive fourth. It gets framed as a preference, sometimes a tribal one, and the discussion runs on rendering demos rather than requirements, while the questions that actually constrain the answer, which device, what fidelity, which hardware APIs, who owns it afterwards, are still open.

The engine matters. It sets your hiring pool, your build pipeline, your per-frame budget and how easily you reach a headset's own features. But it is a downstream decision, and treating it as the first one is how teams end up fighting their stack for a year.

Here is the way we work through it, built from shipping public-safety XR, clinical VR, location-based AR and shared mixed reality.

The four real options

Unity

Unity is the default in XR for unglamorous reasons: coverage. It runs on phones, standalone headsets, tethered PC VR and desktop from one project, it supports OpenXR, and headset vendors ship maintained plugins for it because that is where their developers are. AR Foundation gives you one API over ARKit and ARCore, which matters the moment a phone build has to exist on both. The asset and plugin ecosystem is deep, and most XR engineers you can hire have shipped in it.

Rendering is good rather than spectacular out of the box, and it takes real work to get a Unity scene looking cinematic. For most enterprise and training work that is a fair trade, because the value sits in the procedure rather than in whether the reflections are physically accurate.

Unreal Engine

Unreal starts from a much higher visual baseline. If the point of the experience is that a space or an object looks genuinely real, an architectural walkthrough, a high-fidelity vehicle or product review, a simulation where visual realism is the training value, Unreal gets you there faster and further. Blueprints also let non-engineers assemble logic, which suits studios with strong technical artists.

The costs are honest ones. That fidelity is easiest to reach with a workstation behind the headset, and it needs deliberate reduction to run inside the thermal and power budget of a standalone device. Vendor plugin coverage for enterprise headsets and for phone AR is thinner than Unity's, so check support for your exact device before committing rather than assuming parity.

WebXR in the browser

WebXR removes the single largest drop-off in consumer XR, which is asking someone to install something. A link opens an experience. For campaigns, product visualization, anything aimed at the public, and anything that has to survive a locked-down corporate device, that is not a small advantage, it is often the whole reason the project works at all. We wrote about that trade in detail in web AR without an app.

What you give up: a lower performance ceiling, uneven browser support, and limited access to device-specific capabilities. Anything the headset does that the browser does not expose is out of reach. Phone-based web AR in particular often leans on a commercial framework doing its own tracking, because native browser support for AR sessions has been inconsistent, especially on iOS.

Native platform SDKs

Sometimes the right answer is not a cross-platform engine at all. Building directly against a platform's own stack gets you first-class access to new OS features and the most native-feeling interface, and costs you portability entirely. Reasonable for a single-platform product whose interface is mostly 2D panels with some 3D content, and a poor choice the moment a second device class appears on the roadmap.

The five questions that decide it

1. Does it have to open from a link?

If yes, and it genuinely is yes for public-facing and one-off experiences, WebXR moves to the front and the question becomes whether the concept survives inside that ceiling. If no, because the users are staff on managed devices, the browser's distribution advantage disappears and you choose on capability instead.

2. Which device class did you already choose?

Engine follows hardware, never the reverse. Phones, standalone headsets, enterprise headsets, tethered PC VR and see-through glasses have different rendering budgets, input models and plugin ecosystems. If you have not settled this yet, settle it first, using the framework in which XR device should you build for. Picking an engine before a device means you are choosing with the constraint missing.

3. How much of the value is in the visuals?

Ask what the experience is for. A firefighter pre-planning a building needs a legible, accurate model of that building and instant responsiveness. A luxury product review needs materials that hold up under scrutiny. The first is a fidelity floor, the second is a fidelity ceiling, and only the second is an argument for Unreal. Most enterprise XR is the first case, which is why most enterprise XR is built in Unity.

4. What hardware or data do you have to reach?

This one quietly eliminates options. Eye tracking, hand tracking, depth sensors, medical or industrial peripherals, live telemetry, a mapping service, an IoT device on the same network. Each dependency needs a maintained path in the engine you choose, and vendor support tends to be strongest in the engine that vendor's customers already use. Nystag, our VR eye-tracking diagnostics build on the Vive Focus 3, is a good example of the pattern: when the measurement is the product, engine choice narrows to whatever gives you defensible, first-class access to the device's tracking. Planes XR, which we built for ARCortex to run plane simulations in the real world from live OpenSky data, is the same test in a different direction, since it lives or dies on phone AR tracking and geolocation rather than on rendering.

5. Who maintains it in two years?

The stack you pick is a hiring commitment. Unity has the largest XR talent pool by a wide margin. Unreal's pool is strong but concentrated in games and visualization. WebXR draws on web developers who understand 3D, which is a smaller intersection than either. If the plan is for your own team to take the build over, choose what they can actually staff, and make the handover explicit rather than assumed. We covered what that involves in software ownership and handover.

What the engine does not decide

A surprising amount of what makes an XR build good or bad is engine-independent, and blaming the engine for these is a common way to spend a rewrite and end up in the same place.

Your 3D content pipeline is its own discipline. Source models arrive far too heavy, and the work of reducing, retopologizing, baking and budgeting them is the same job whichever engine consumes the result. It is also where most of the schedule risk in an XR project actually sits.

Interaction design is engine-independent too. Whether a grab feels right, whether a first-time user can complete the task, whether typing has been designed out of the product: no engine gives you any of that.

So is the performance budget. Comfortable XR means holding a high, stable frame rate, and on standalone hardware that is a discipline of draw calls, overdraw, texture memory and thermals. Unreal makes it easier to build something beautiful and easier to blow the budget doing it. Unity makes the budget more visible and the beauty more effortful. Neither one hands it to you.

Deployment, device management and update logistics sit outside the engine entirely, and decide more pilots than rendering ever will. That is the subject of rolling XR out past the pilot.

The switching penalty is real

Changing engine mid-project is not a port, it is a rebuild. Art assets and design work survive. Interaction code, tooling, integrations, build configuration and platform glue do not. Treat any mid-flight switch as a second build, and spend a week up front proving the risky part on the chosen stack instead.

That prototype is the cheapest insurance available. Build the single hardest thing, the eye-tracking read, the live data feed, the multi-user session, running at frame rate on the actual headset, before the content pipeline spins up. It is the same reasoning behind the way we scope what an XR app costs: resolve the unknown that could invalidate the plan while the plan is cheap to change.

Questions worth asking before you commission a build

Which device class is this for, and was it chosen before the engine? If the engine came first, the decision was made backwards.
Does this have to run without an install? A yes points at the browser and reshapes the concept.
Which device features or external systems does it depend on, and is each one supported in this engine today? Ask for the specific plugin and who maintains it.
What frame rate are we targeting on the real hardware, and when will we first measure it?
Who maintains this in two years, and can they hire for this stack?
What gets prototyped in week one to prove the choice? If nothing does, the risk has been deferred rather than managed.

The bottom line

There is no best XR engine, only the one that fits the device, the fidelity requirement, the integrations and the team that inherits it. Unity is the reasonable default for headset and multi-device work and needs no special justification. Unreal is the right call when photoreal fidelity carries the value and the hardware can drive it. WebXR is the right call when installation is the thing standing between you and your users. Choose the device first, prove the risky part on real hardware in week one, and treat the engine as the consequence of those answers rather than the starting argument.

Weighing an engine for an XR build and want a straight answer rather than a preference? Book a demo and we'll work through the device, the integrations and the fidelity you actually need, including telling you when a phone or a plain web app gets you there faster. See our XR work: ERIS XR and Planes XR for ARCortex, Nystag clinical VR eye-tracking on the Vive Focus 3, and MR Camera shared mixed reality.