Changing Unity’s build target is a compiler operation. Porting is a product operation. A browser session and a headset differ in input, attention, screen geometry, lifecycle, memory, rendering cost, service access and the physical comfort of the user.
The difficult ports are rarely blocked by one unsupported API. They are slowed by platform assumptions that have no clear owner: a UI component reads mouse position directly, gameplay asks a headset singleton for pose, a loader assumes unrestricted threads, or authentication depends on a browser callback embedded deep inside product logic.
1. Inventory the platform assumptions
Before changing code, trace a complete representative flow on the source platform. Mark every point where the application touches the environment:
- Input devices, focus, pointer lock and interaction range.
- Camera, tracking origin, locomotion and recentering.
- Screen-space, world-space and spatial UI presentation.
- Authentication, browser JavaScript, native SDKs and deep links.
- Networking, streaming, local storage and file access.
- Audio routing, autoplay rules and device changes.
- Application pause, tab visibility, headset removal and resume.
- Rendering, memory, download size and thermal constraints.
This inventory becomes the port’s scope and test matrix. It also reveals which assumptions are business rules that should remain shared and which belong behind a platform boundary.
2. Model input as product intent
Mouse clicks and controller trigger presses are mechanisms. “Select,” “grab,” “confirm,” “move” and “open menu” are intentions. Product code should depend on the latter.
A useful input boundary converts platform-specific signals into shared commands with enough context for the product: target, pose or pointer position, phase, source and interaction mode. The browser implementation may use mouse, keyboard or touch; the VR implementation may use tracked controllers, hands, gaze or a ray interactor.
This does not mean forcing all interactions into their lowest common denominator. Spatial grabbing may exist only in VR and text entry may be richer on desktop. The boundary makes those differences explicit while preserving shared rules such as validation, inventory state or command authorization.
3. Share the model, adapt the presentation
A flat UI cannot always be moved into world space and remain usable. Viewing distance, angular size, head movement, ray stability, occlusion and reach all change the interaction. Conversely, a spatial panel designed for a headset may waste space and precision in a browser.
Share state and actions where possible: menu data, validation, progress, selection and navigation rules. Let each platform own layout, interaction affordances and feedback. This keeps product behavior aligned without pretending the two experiences are visually interchangeable.
Test uncomfortable paths early: long text, error recovery, permissions, loading, account selection and confirmation dialogs. Happy-path prototypes often hide the UI work that dominates the final port.
4. Treat lifecycle and services as architecture
WebGL lives inside a browser. A tab can lose focus, the page can resize, persistent storage is constrained and JavaScript may mediate authentication or host communication. Threads and networking APIs also behave differently from desktop and device builds.
VR introduces its own lifecycle: tracking can be lost, the headset can sleep, controllers can disconnect, the tracking origin can change and platform SDKs may own identity, entitlements or overlays. The application must know which transitions pause simulation, preserve state, reconnect services or return the user to a safe location.
I isolate service contracts from their platform adapters: authentication, storage, telemetry, content delivery, voice and external navigation. Shared code receives domain results rather than browser callbacks or native SDK types. This makes failure states testable without the target device and prevents service changes from leaking across the product.
Audio, networking and streaming deserve separate tests
Browser autoplay restrictions, device routing and headset focus can all affect audio startup. Network transport or browser security policies may rule out APIs that work elsewhere. Asset streaming strategies must account for WebGL download and memory pressure as well as headset storage and decode cost. These systems should be validated in vertical slices, not left until the final build.
5. Set budgets per platform
One shared quality setting rarely serves both targets. VR has a strict, continuous frame-time budget and often renders at high effective resolution. Missed frames affect comfort, not just polish. WebGL must manage browser memory, initial download, decompression, shader variants and a wide range of host hardware.
Define separate budgets for frame time, memory, texture and mesh quality, active content, loading and startup. Keep the decision system shared where useful, but allow platform configuration to select render features, content variants, pool sizes and concurrency limits.
Profile representative builds on representative hardware throughout the port. The editor cannot reproduce the browser’s runtime constraints or the headset’s thermal and stereo-rendering behavior.
6. Stage the port around risk
A low-risk sequence proves the platform boundary before migrating the entire product:
- Choose one vertical slice that includes input, UI, content, services and a meaningful user outcome.
- Build the platform composition point and the smallest required adapters.
- Validate the slice on the target hardware, including failure and resume paths.
- Measure frame time, memory, loading and build size against explicit budgets.
- Expand feature by feature, keeping a transition matrix for both platforms.
- Remove accidental assumptions as they are found instead of accumulating platform directives.
The result is not just a second build. It is one product with explicit platform contracts, shared behavior where sharing is valuable, and distinct experiences where the user needs them.