WebXR experiments

WebXR is a web standard allowing AR and VR experiences to run right in the browser: immersive 3D scenes, AR over the camera, VR on headsets — without installing a native app, via a link. The appeal is accessibility 'via a link' and cross-platform in theory. WebXR experiments are prototypes and experiences on this technology: interactive 3D/AR/VR demos, capability research. Honestly about immaturity, this is key and it is in the name: WebXR is a developing standard, and the word 'experiments' here is not marketing but the essence. Support in browsers and on devices is incomplete, uneven and changing: something works in one browser and not in another, AR/VR capabilities depend on the device, behavior is unstable. So WebXR suits experiments, prototypes, demos and learning, but not functionality on which the business depends and which must work for everyone guaranteed. We honestly warn about this. Honestly about the limited audience: a full WebXR experience (especially VR) is available only on supporting devices — a minority. AR in WebXR is more accessible but also depends on the device and browser. So reach is limited, and this must be honestly built into expectations. Honestly about 'not for critical functionality': due to immaturity and instability, you cannot build on WebXR what must work reliably for everyone (payment, the key user path). It is reasonable to use it as an additional, enriching layer with a mandatory ordinary fallback for those for whom XR does not work. Honestly about performance: 3D/XR in the browser is demanding of the device; on weak ones it will lag or not launch. Honestly about 'a bet on the future': WebXR is interesting as an early groundwork and experiment — to try, learn, be ready. But positioning it as a mature mass solution now is dishonest. Honestly about the effect: it gives 'via a link' AR/VR experiences for experiments, prototypes and differentiation, but with immaturity, a limited audience and no guarantee of working for everyone. Honestly about access: an understanding of the experimental nature and an ordinary fallback are needed. An important boundary: this is WebXR (browser AR/VR); VR showrooms (native/headsets) — 1108; AR try-on — 1106; 3D viewers (no XR) — 1109; spatial-web — 1111. The base price starts from 120,000 ₽ (depends on experience complexity).

• An AR/VR experience 'via a link' in the browser without installing an app is needed.
• It is interesting to try immersive formats as a prototype/differentiation.
• An expectation that WebXR is a mature solution working for everyone (it is not).
• Standard immaturity, a limited audience and unstable support are not accounted for.

• WebXR experience/prototype development (3D/AR/VR in the browser via WebXR)
• An honest assessment: does WebXR fit (an experiment) or is a mature format needed (1108/1109)
• A mandatory ordinary fallback for devices without XR support
• Testing on available browsers/devices accounting for uneven support
• Accounting for performance and device limitations
• Honest boundaries (immaturity — 'experiments'; limited audience; unstable support; not for critical functionality)
• Documentation and handover
• Review with you

• An AR/VR experience 'via a link' in the browser for experiments/prototypes
• An enriching immersive layer with an ordinary fallback
• An honest assessment: where WebXR is appropriate as an experiment and where a mature format is needed
• Honest boundaries (immaturity; limited audience; not for critical functionality)

• We assess the task: experiment/prototype (WebXR) or a mature format is needed
• We develop the WebXR experience with a mandatory ordinary fallback
• We honestly set boundaries (immaturity, audience, stability) and hand over to you

• Does WebXR work the same for everyone in the browser?

  No, honestly, and this is the essence: WebXR is a developing standard with incomplete and uneven support. Something works in one browser and not in another, AR/VR capabilities depend on the device, behavior is unstable. The word 'experiments' in the name is not marketing but an honest description. A full experience (especially VR) is available to a minority of devices. We honestly build in an ordinary fallback rather than promise 'works the same for everyone'.

• Can key business functionality be built on WebXR?

  It should not, honestly: due to immaturity and instability WebXR is unsuitable for functionality that must work reliably for everyone (payment, the key user path). It is reasonable to use it as an additional, enriching layer with a mandatory ordinary fallback. Building the critical on an experimental technology is risky. We honestly warn and do not put business-critical things on WebXR.

• WebXR is the future, so should we do it seriously now?

  As a bet and experiment — yes, as a mature mass solution — no, honestly: WebXR is interesting to try, learn and be ready for the future. But now it is an immature standard with a limited audience and unstable support. Positioning it as a ready mass solution is dishonest. We take on WebXR precisely as an experiment/prototype with clear risks rather than pass it off as a production-ready channel.