Here at Variant, we recently switched Android users from Scene Viewer to WebXR for AR experiences. In this article, we lay out some of the reasons why, the benefits to our customers and users, and why we’re excited for the future of WebXR.
Here at Variant, we recently switched Android users from Scene Viewer to WebXR for AR experiences. In this article, we lay out some of the reasons why, the benefits to our customers and users, and why we’re excited for the future of WebXR.
Scene Viewer is a standalone 3D/Augmented Reality viewer that launches as its own app. Arriving soon after Google’s ARCore position-tracking, it was placed as a universal tool for opening 3D content from the web, with the intention of deep integration into Google Search results and Google Shopping.
Its position as a first-class, search-friendly, OS-level viewer made it the clear initial choice for Variant: WebXR support was still patchy in non-chrome browsers, and Scene Viewer had the bonus of launching instantly when called, without user input.
Unfortunately, over time some of the original goals didn’t materialise - most notably for Variant, the integration into Google Shopping - and the march of WebXR support and tooling seems to have swayed even Google, as development on their model-viewer rapidly outpaced Scene Viewer.
With WebXR we have greater control over every aspect of the GLTF loading and rendering process. This allows us to support features like:
We were already using Google’s excellent model-viewer project to provide easy 3D embeds for our customers’ dev teams, so it was natural to use model-viewer’s AR support (with some added Variant magic). This reduced the burden on dev & UX teams to learn the quirks of Scene Viewer in addition to model-viewer.
Also, since the WebXR viewer is just a web page, the customisation opportunities are near-limitless. This includes embedding variant options directly into the AR experience for real-time changes and adjusting lighting to more closely match colours between iOS AR Quicklooks and Android WebXR.
Using the customisability of WebXR, we’re working to unify the experience between Android and iOS users, matching the appearance and UX of iOS Quicklook. This makes it easier to know what users will see & when they will see it, via the numerous routes to viewing a variant (QR codes, FB Lens ads, webviews, social shares etc.).
Our decision to move to WebXR was sealed when an Android update broke Scene Viewer, stopping users from launching AR, with the fix only due to arrive weeks later.
Thankfully we had been testing a WebXR integration and were able to swap all our users to WebXR within a matter of hours. This was our only downtime to date, and it stung that it was due to something outside of our control.
Now, with WebXR, we can react within minutes to issues, and have much greater insight into upcoming browser changes and issues in our JS SDK. This translates directly into increased uptime for our users.
In the future, Apple may change their position of not supporting WebXR on handheld devices. There has been some recent movement, with Webkit developers beginning to support some WebVR-like features, (although this may be focused only on their upcoming HMD).
Universal WebXR support would pave the way for more real-time interactions with variants - reloading meshes and textures without having to generate entire models via the API.
WebXR on Android alone still enables some additional interactivity, as USDZ supports limited script-like functions (see their Augmented Reality examples)
Here’s what we've been up to recently.
