From Unity to the immersive web.

Why the default answer changed.

For years, if a company wanted to build a serious VR or mixed-reality application, the default answer was often straightforward: build it in Unity.

That still makes sense for many applications. Unity remains excellent for games, simulations, complex physics, advanced animation and deeply native XR experiences. But the decision is no longer automatic.

The immersive web stack has changed considerably. WebXR, Three.js, React Three Fiber, WebGPU, modern media APIs and newer higher-level frameworks such as Meta’s immersive-web tooling are making it possible to build experiences that previously would have required a full Unity application. More importantly, those experiences inherit one of the web’s biggest advantages: you build an application, publish a URL, and progressively enhance it for XR-capable devices.

Consider a typical enterprise XR application. You might end up maintaining several products at once:

Unity app         Web dashboard     Mobile app
    |                   |               |
Quest build         React app     Separate app
    |
Android APK
    |
Device deployment

An immersive-web architecture can instead look like one application that adapts:

           ONE APPLICATION
                  |
         React / TypeScript
                  |
         3D + Spatial Layer
                  |
        Capability Detection
                  |
      +-----------+-----------+
      |           |           |
   Desktop      Mobile        XR
                              |
                    +---------+----------+
                    |         |          |
                  Quest    Vision Pro   Android XR

The user doesn’t necessarily download anything. They open the application. On a laptop they get a high-quality 3D application. On a phone they get a touch-optimised experience. On a compatible headset they can enter immersive mode. That can fundamentally change the economics of an XR project.

What the modern stack looks like.

WebXR itself isn’t particularly new. What has changed is everything around it. A production immersive-web project in 2026 can draw on React or Next.js and TypeScript for the application, Three.js and React Three Fiber for the scene, WebXR for sessions and spatial input, WebGL2 and WebGPU for rendering, WebCodecs, WebRTC, HLS and DASH for media, WebSockets for live data, modern cloud and CDN infrastructure for delivery, and AI coding agents and spatial AI on top of all of it.

Higher-level frameworks then abstract away much of the repetitive XR infrastructure, so developers increasingly don’t need to build everything directly against low-level WebXR APIs.

This is similar to what happened with normal web development. Nobody wants to manually manipulate the DOM for every application anymore; React and similar frameworks created better abstractions. We’re beginning to see the same thing happen with spatial applications.

Distribution is the business argument.

This is probably the strongest commercial case. A traditional XR deployment involves a build, an APK, a store or MDM or sideload step, an install, an update, and then maintaining device versions. A web deployment is a push, a CI/CD run, a CDN invalidation, and a URL that is now current.

Your customer doesn’t necessarily need another application installed. For enterprise projects, exhibitions, sales demonstrations and temporary experiences, that matters enormously.

Imagine sending a prospective customer immersive.simamdigital.com rather than “here’s an APK, enable developer mode, install this tool, connect your headset…”. That friction can be the difference between someone experiencing your work and never opening it.

WebXR does not mean “VR website”.

This distinction is important. A good immersive-web application should be a full web application with spatial capabilities, rather than a 3D world attempting to recreate everything a normal website already does well.

Consider an automotive configurator. Each technology handles what it is good at:

The same rule applies to interface work later in this guide: information is usually web UI, objects are usually spatial UI.

How the Unity architecture translates.

A typical Unity XR architecture runs from a bootstrap scene through managers and remote config into a main scene, with Addressables or AssetBundles feeding runtime content. A modern web architecture runs from an application shell through authentication and configuration into React UI, with lazily loaded 3D, a spatial session and remote content. The architectural concepts don’t disappear. They move into technologies designed specifically for those jobs.

Stop thinking in scenes

This can be one of the harder adjustments for experienced Unity developers. Suppose a Unity application contains MainMenu.unity, Showroom.unity, ProductViewer.unity and Checkout.unity. You don’t need four Three.js scenes. You need routes: /showroom, /product/123, /cart, /checkout.

Your product page might contain product information, a gallery, a 3D viewer, recommendations, an AI assistant and an add-to-cart control. Only the 3D viewer needs the renderer. That can dramatically reduce complexity.

Remote assets become easier

Unity developers are familiar with Addressables and AssetBundles. They solve a real problem, but the web already has native remote-content infrastructure: HTTP, object storage and CDNs. Instead of packaging vehicle_bundle_android.bundle, you request vehicle.glb, vehicle_low.glb, vehicle_high.glb or vehicle.ktx2 from a CDN, and a small manifest describes what is available:

{
  "vehicle": {
    "preview": "/vehicle.webp",
    "low":     "/vehicle-low.glb",
    "high":    "/vehicle-high.glb",
    "version": 7
  }
}

The application decides what to download. This is extremely powerful for retail catalogues, digital twins, exhibitions, vehicles, Gaussian splats, museums and training content, because content can change independently of application releases.

Don’t download everything

This is one of the first mistakes teams make when migrating from Unity. Web users expect applications to become usable quickly. Load the application shell in the first half second, then UI and navigation, then metadata, then preview imagery, then low-resolution 3D, then the required experience, and stream high-resolution content in the background. Don’t make someone download a 300 MB environment before they can see the menu.

Asset optimisation becomes critical

The browser is less forgiving of enormous game-development assets. A raw CAD model that “worked on my PC in Unity” isn’t a production web asset. A sensible pipeline cleans the geometry, removes invisible faces, generates LODs, optimises meshes, bakes where appropriate, compresses geometry and textures, and exports GLB to a CDN.

• glTF/GLB for runtime models.
• Meshopt or Draco for geometry compression.
• KTX2/Basis for GPU-friendly texture compression.
• LOD systems for large environments.
• Gaussian splats where photoreal captured environments are more valuable than conventional meshes.

Rendering, React and performance.

WebGL2 and WebGPU are not competitors

Three.js sits above the renderer, and the renderer sits above WebGL2 or WebGPU. WebGL2 remains an important compatibility baseline; WebGPU provides a much more modern graphics and compute architecture where available. For production applications, progressive enhancement is the sensible approach — use WebGPU when it is there, fall back to WebGL2 when it isn’t, and never make the whole experience unusable because one advanced rendering feature is missing.

React is not Unity

This causes performance problems surprisingly quickly. A Unity developer might instinctively calculate a position in Update() and push it into application state. Don’t make React rerender your application 72 or 90 times per second. Separate application state from real-time rendering state.

React manages application state. The renderer manages frame state. That is one of the most important architectural rules for high-performance React XR.

Establish budgets before building

“Runs on my headset” isn’t a performance strategy. Define a frame-rate target of 72 or 90 FPS, then set limits per scene class for draw calls, triangles, texture memory, active video decoders, dynamic lights, transparent surfaces, concurrent splats, network payload and initial download. Measure them continuously.

Don’t keep rendering what nobody can see

WebXR performance requires aggressive lifecycle management. When a user leaves a showroom, unmount it: dispose geometry and textures, stop video, remove listeners, close unused sockets and release references. Three.js will not magically protect you from leaking GPU resources, and a long-running XR session with leaked textures can eventually fall apart even if the initial performance was excellent.

Be careful with transparency and post-processing

Beautiful glass UI becomes expensive very quickly. Passthrough plus transparent panels plus transparent particles plus transparent product materials plus video plus post-processing generates serious overdraw. Bloom, SSAO and depth-of-field look excellent and cost GPU time. For standalone XR, good lighting with excellent materials and good assets usually beats mediocre assets with five post-processing effects. The fact that something looks great on a desktop RTX GPU doesn’t mean it belongs on a standalone headset.

Test on the weakest real target

Do not optimise on a desktop browser and assume Quest will be fine. Your development loop should include desktop development, device testing, profiling, network throttling, thermal and load testing, and a long-session test — repeatedly, throughout the project, on the real headset.

Media, timelines and AI.

For immersive video applications, migrating away from Unity can unlock an extremely mature media ecosystem. Instead of depending heavily on one Unity video plugin, you can put a playback service in front of native video, HLS, DASH, WebRTC, WebCodecs and whatever comes next, then feed a video texture into Three.js for VR180, VR360 or a spatial screen. The same underlying media can simultaneously power conventional browser playback.

Adaptive streaming

A headset on perfect Wi-Fi shouldn’t necessarily receive the same stream as a mobile device on 4G. HLS and DASH can expose 1080p through to 8K variants, and the playback system selects quality based on bandwidth, buffer health, device capability, decoder capability and the current presentation mode. For high-resolution immersive video, this matters enormously.

Live experiences combine several protocols

A sports application might use HLS for broadcast video, WebRTC for an ultra-low-latency camera, WebSockets for telemetry, REST or GraphQL for event information, and WebXR for immersive presentation. That separation is healthy. Don’t force every data type through one system.

Build around a master timeline

For sports, training and synchronised digital twins, create one authoritative timeline:

                 MASTER CLOCK
                      |
      +---------------+---------------+
      |               |               |
    Video         Telemetry           3D
      |               |               |
  Commentary       GPS/CAN         Objects
      |               |               |
    Events        Statistics      Animation

Seeking to 13:42 should update everything, not only the video. This architecture also enables AI: “take me to the final overtake” becomes an agent resolving an event to a timestamp and telling the timeline controller to seek.

AI should control tools, not just chat

Weak integration sends a user question to a model and returns a text answer. Better integration gives the agent tools that act on the application — searchProducts(), openProduct(), seekVideo(), changeCamera(), highlightMachine(), loadTelemetry(), enterImmersiveMode(), placeObject().

Then “show me where machine 14 is” can physically move the user to the machine, and “show me this sofa against that wall” can manipulate the spatial scene. This is where AI plus immersive web becomes far more interesting than adding a chatbot to an XR application.

Capability detection, input and spatial UI.

Don’t assume every device supports the same functionality. At startup, build a capability profile: WebXR, WebGPU, WebGL2, hand tracking, controllers, touch, spatial audio, AR and MR, WebRTC, codec support, GPU class. Then adapt — mouse and keyboard on desktop, touch and device orientation on mobile, immersive XR with hands or controllers on Quest, natural input on Vision Pro, and whatever spatial capabilities Android XR exposes. The goal isn’t to make every device identical. It is to deliver the best version the current device supports.

Input abstraction is essential

Don’t write application logic that says “Quest trigger pressed, therefore buy product”. Write “select, therefore buy product”, and map inputs into it:

Mouse click  ---+
Touch        ---+
Controller   ---+--->  SELECT
Hand pinch   ---+
Gaze/select  ---+

Your business logic should not know what headset produced the interaction. That dramatically improves portability.

Spatial UI is a common migration trap

A Unity developer can be tempted to recreate every Canvas as geometry. Don’t. Use normal HTML and CSS for forms, text, tables, dashboards, accessibility, responsive layouts, checkout, search and account management. Use spatial UI where spatial positioning genuinely adds value. A good rule: information is usually web UI, objects are usually spatial UI.

Where Unity is still the right answer.

This is not a one-way argument, and pretending otherwise would waste your budget.

Browser compatibility is a real caveat

A native build gives you a known runtime. The web gives you different browsers, different WebXR implementations, different codecs, different GPU APIs, different input systems and different device capabilities. The solution isn’t dozens of platform-specific code paths — it is adapters. Define interfaces for XR input, media playback, the render backend, storage and spatial capabilities, select implementations based on capability detection, and keep your application above them.

Fully offline deployments are harder

If a customer requires an application to run in a remote facility with absolutely no internet, Unity can still be the simpler solution. Web applications support caching, service workers and local storage, but fully offline immersive deployments require more planning. Don’t pretend this caveat doesn’t exist.

Native hardware integration can favour Unity

Proprietary peripherals, unusual Bluetooth devices, low-level hardware APIs, special native SDKs, advanced haptics and platform-exclusive capabilities may still make a native engine preferable. WebXR is not automatically the answer to every XR project.

Games remain a different category

If you’re building complex physics, large numbers of animated characters, deep game systems, advanced animation graphs, heavy VFX, console deployment or large authored worlds, Unity or Unreal may remain the better choice. If you’re building product visualisation, digital twins, immersive video, tourism, events, education, retail, architecture, sports visualisation, collaboration, data visualisation or brand experiences, the immersive web deserves serious consideration. If the question for you is really about engines rather than migration, we compared them directly in Unity vs WebGL for browser-based 3D.

A sensible migration strategy.

Don’t begin by rewriting your biggest production application. Choose one representative experience.

1. Technical spike. Recreate one environment, an XR session, basic UI, one interaction, one streamed asset and one media source. Measure performance on the real target.
2. Vertical slice. Add production assets, the backend, real interactions, analytics, streaming, AI and device testing. Now compare it against the existing Unity experience.
3. Architecture. Only after proving it, establish the shared XR core, asset pipeline, media abstraction, input abstraction, design system, backend contracts, analytics and deployment pipeline.
4. Migration. Move reusable application features incrementally.

Don’t blindly translate MonoBehaviours into TypeScript classes. Use web-native architecture.

What not to migrate directly

That table is really one question asked six times: what is the web-native solution to this problem?

Example production architecture

                        CLIENT
             Next.js / React / TypeScript
                          |
        +-----------------+-----------------+
        |                 |                 |
        UI                XR                3D
    HTML / CSS          WebXR            Three.js
        |                 |                 |
        +-----------------+-----------------+
                          |
                     Shared State
                          |
      +---------+---------+---------+----------+
      |         |         |         |          |
    Media      Data       AI      Social   Analytics
  HLS/WebRTC  API/WS    Agent     WebRTC
      |
      +-------------------+
                          |
                        CLOUD
                          |
        +-----------------+-----------------+
        |                 |                 |
       CDN               APIs               DB
    GLB / KTX2    Serverless / .NET      Postgres
      Splats
      Video
      Images

Notice what isn’t there: one enormous engine owning everything. That’s the architectural change.

What a company actually gains.

If executed properly, moving suitable XR workloads to the web can provide:

• Faster iteration. Deploy continuously instead of producing application builds.
• Lower distribution friction. Send a URL.
• Cross-device reach. Desktop, mobile and spatial devices can share one product.
• Better cloud integration. APIs, databases, authentication, analytics and CMS platforms are native territory for web development.
• Better commerce integration. Existing payment and e-commerce infrastructure plugs directly into the application.
• Mature media infrastructure. HLS, DASH, WebRTC and browser media technologies give you real options.
• AI-native architecture. Modern agent frameworks and model APIs integrate naturally with web backends.
• A larger developer ecosystem. React and TypeScript developers can contribute without becoming Unity developers.
• Smaller updates. Content and application logic can evolve independently.
• Better discoverability. A spatial experience can be part of the ordinary web rather than living entirely inside an app store.

But migration isn’t the goal

This is the most important conclusion. Companies shouldn’t migrate from Unity because WebXR is fashionable. They should migrate when the architecture solves a business problem. If your application needs advanced physics, native hardware integration or sophisticated game-engine systems, Unity may still be the right tool. But if you’re building a connected, data-driven, content-driven immersive application, the calculation has changed substantially.

The question used to be “can the web actually deliver our XR experience?” Increasingly, the more useful question is “which parts of this experience still require a native game engine?”

For a surprising number of enterprise XR, immersive media, commerce, visualisation and digital-twin projects, the answer is becoming: far fewer than before.

See it running.

Everything above is easier to judge with a headset or a laptop in front of you. These are live, in the browser, with nothing to install:

• Product configurator — the configurator pattern described above, with web UI around a 3D viewer.
• Virtual walkthrough — spatial navigation of a captured environment.
• Immersive showcase — the WebXR entry point we send to clients instead of an APK.

Common questions.

Should we migrate our Unity XR application to WebXR?

Migrate when the architecture solves a business problem. If distribution friction, cross-device reach, cloud and data integration, or content that changes faster than your release cycle are hurting the project, the immersive web is a strong candidate. If the application depends on advanced physics, native hardware SDKs or deep game-engine systems, Unity is still the better tool.

Can WebXR match Unity for visual quality?

For product visualisation, digital twins, configurators and immersive media the gap is small, and Gaussian splats can exceed conventional meshes for captured environments. The web is less forgiving of unoptimised assets, so quality depends far more on the asset pipeline — glTF compression, texture compression, LODs — than on the renderer itself.

Does WebXR work on Meta Quest, Vision Pro and Android XR?

Yes, though implementations differ by browser and device. The practical approach is capability detection at startup plus adapter interfaces for input, media, rendering and storage, so one application delivers the best version each device supports rather than requiring a separate code path per headset.

How do you replace Addressables and AssetBundles on the web?

With HTTP, object storage and a CDN. Publish glTF/GLB models at several quality levels alongside KTX2 textures, describe what is available in a small JSON manifest, and let the application decide what to download. Content can then change independently of application releases.

What does a migration cost?

Start with a technical spike rather than a full rewrite: one environment, one XR session, one interaction, one streamed asset and one media source, measured on the weakest real target. At Simam Digital that scale of prototype starts from £2,800, and only after it proves out is it worth committing to a shared XR core and asset pipeline. Our pricing page sets out the rest.

What this means for a buyer.

Start with the business decision, the audience, and the evidence the project has to produce. Simam Digital can turn that into a focused discovery, prototype, MVP or production roadmap across AI applications, SaaS platforms, digital twins, real-time 3D, XR and interactive systems — and can tell you honestly when Unity is still the right home for the work.

Sources and further reading

• W3C WebXR Device API
• Three.js
• Khronos glTF
• W3C WebGPU

A version of this article was first published in Tech Alchemy, the Simam Digital newsletter on LinkedIn.