WebXR or native first? Choose the prototype around the question

A spatial prototype needs a question before it needs a platform. Are you testing whether a task makes sense in a wearable display? Whether a particular input can support it? Whether an organization can deploy the experience to its equipment? The best first implementation is the one that can answer the most important question with the fewest unresolved dependencies. That choice may be a browser prototype, a native application or a smaller experiment that precedes both.

WebXR and native XR approaches are not interchangeable labels for the same delivery process. They give a team different routes to a working session, with different constraints around access, capabilities and distribution. Compare those routes against a written task and target device. A broad platform argument rarely helps as much as a short feasibility test on the equipment the participant will actually use.

Start with the participant’s path

Write down how someone reaches the experience. A browser route might begin with a link on a device where the required browser and XR support are available. A native route may begin with an installed build managed through the organization’s chosen distribution process. Neither path is automatically simpler in every setting. The relevant question is what the intended participant or facilitator must do before the task can begin.

Walk through that path with the person who will run the trial. Ask who controls the device, who can install or update software and whether the session depends on a network. In a supervised pilot, one prepared device can be a reasonable starting point. In a distributed test, the setup burden may become part of the research question. Make that distinction before writing a large amount of application code.

Understand what the standards describe

The W3C WebXR Device API specification describes support for accessing XR devices through the web. Its model includes sessions, views, spaces and input. It is a primary source for understanding the interface a web application uses. The publication is a work in progress, so a team should consult the current document and test the relevant browser implementation rather than relying on a remembered compatibility claim.

The Khronos OpenXR overview describes a common API for native XR applications across supporting platforms. That gives a team a useful starting point for evaluating portability. The actual runtime, enabled extensions and device behavior remain part of the implementation work. Treat a standards reference as a map of the interface, then verify the exact features your prototype needs.

List capabilities in task language

Avoid beginning with a long list of platform features. Write what the task requires in ordinary language: the user selects an object, the application keeps an instruction in a useful position, or the facilitator can restart the session. Then map each requirement to the technical capability that supports it. This keeps the prototype focused and makes it easier to explain a platform decision to a client or collaborator.

For each required capability, record whether it is essential for the first trial or can be simulated. A product concept may not need production-quality asset loading to test a short interaction. It may absolutely need the intended input method to answer the research question. Mark that difference explicitly. A prototype can simplify the surrounding system while preserving the part of the experience you need to learn about.

Build a vertical slice before the application

A useful feasibility test opens a session, shows one relevant object or instruction, accepts the required input and exits or resets cleanly. Run it on the target hardware. The slice should exercise the riskiest assumption, not merely prove that a familiar tutorial runs. Keep its source and configuration small enough that another developer can inspect what it actually tested.

Record the result in a short compatibility note. Include device, operating software, browser or runtime, build date and observed behavior. If a feature fails, preserve the error and the conditions before changing the configuration. A later success is easier to trust when the team can see which assumption changed. This also prevents an accidental switch of equipment from being mistaken for a platform improvement.

Compare the development loop

Consider how the team will edit, test and share builds during the pilot. A browser workflow can be convenient when the intended environment supports the needed experience and the team can distribute a link. A native workflow can be appropriate when its tooling or device integration better serves the task. Test the whole loop once: make a small change, deliver it to the trial device and verify it there.

The time required to repeat that loop matters during a short project. If every update requires a person who is rarely available, the team needs to plan around that dependency. If a browser update changes the working configuration, it needs a retest. Write down the steps rather than assuming the delivery method will remain effortless after the first demonstration. A predictable loop lets the team spend more of the pilot on the actual experience.

Keep performance questions measurable

When responsiveness matters, define what the task needs and how you will observe problems. Use the target device with representative content. An empty scene may establish that a session can start, but it does not establish how the intended application behaves. Add enough of the real task to expose the relevant constraint, while avoiding a full production build before the platform question is answered.

If the experience feels unreliable, isolate the variables. Test a simpler scene, then the required input, then the content path. Keep notes about each change. Do not turn a single poor run into a universal claim about browser or native development. The useful conclusion is narrower: this configuration did or did not support this task under the conditions tested, and the next experiment will address the remaining uncertainty.

Plan for the facilitator and handover

The prototype has to be usable by the person running the session. Provide clear startup and reset instructions, a known working build and a description of the environment it expects. If the developer needs to be present for every restart, record that as a pilot constraint. It may be acceptable for an early experiment, but it should be visible in the scope and schedule.

A handover rehearsal is a useful final check. Ask another team member to prepare the device and run the short task using only the written instructions. Observe where they need help. This can reveal a missing deployment step or an unclear state before the real participants arrive. It also gives the team a practical basis for deciding which delivery route is easier to maintain for the next phase.

Make a decision that can be revisited

Choose the first route with a brief written reason: the question being tested, the target configuration, the capabilities verified and the constraints accepted. Add a trigger for reconsidering it. A later requirement for a different device capability, distribution model or session scale may justify another implementation. That does not make the first choice a mistake if it answered the question it was built to test.

The prototype should leave the team with a clearer product decision, a reproducible build and a useful record of what happened. Start with the task, test the uncertain capability on real equipment and choose the route that lets the team run the next session with confidence in its preparation.