The state of WebXR on iOS, and beyond

​

Introduction

As the world of augmented reality (AR) and virtual reality (VR) continues to grow, so does the importance of WebXR—a crucial technology that enables immersive experiences on the web. In this article, we will explore the history of WebXR support on iOS, shedding light on the developments that have taken place, and what the future may hold for this innovative technology.

​

tl;dr update as of WWDC 2023

• WebXR is not supported on iOS, at least up to iOS 17
• Support for WebXR has been built into Safari for Apple Vision Pro (Vision OS)
• This support is limited to VR experiences (immersive-vr sessions), and does not include AR (immersive-ar sessions)
• There are fundamental UX limitations on the device - users cannot move more than 1.5m in any direction without the experience disappearing and a guardian boundary appearing - that demonstrates Apple sees Vision as primarily a seated/stationary platform.
• You can build WebXR on iOS today using Variant Launch, our WebAR SDK.

​

The Web in XR

The ‘WebXR API’ refers to a group of features available in web browsers, focusing on immersive experiences on the web.

The WebXR API allows for “immersive-AR” sessions that layers an AR experience onto the users real-world environment. The spec also supports both dedicated HMDs like the Oculus Quest, and handheld devices like phones and tablets.

The future of WebXR is an internet where physical and digital realms meet and merge, allowing objects and environments of each to interact. The WebXR API allows developers to easily create these experiences and objects in a way thats integrated with the rest of the web, privacy-protecting, and without the need for app store approval.

​

A Cambrian Explosion

By 2017/2018, Google and Apple had already began discussing the importance of augmented reality to their future plans, and introduced competing AR features to their operating systems — ARCore and ARKit. This brought OS-level AR tracking to billions of users by default, accessible via native apps.

Both of the platform-holders also provided solutions for jumping quickly into AR from the web - AR Quicklooks on iOS, and Scene Viewer on Android. However, Google went a step further, supporting the early WebAR spec (later merged with WebVR to become WebXR). This gave developers access to AR via Chrome on Android by default.

​

Apple’s Absence

Despite keeping pace with ARCore features in ARKit (and outperforming in some areas), Apple’s response to Googles web experimentation was… silence.

This likely stemmed from how seriously Apple took AR as a strategic space: Rather than enabling a cross-platform, freeform developer ecosystem, iOS would seek to control the quality of the end-user UX and guide developers to their preferred formats and methods, creating a cohesive, OS-integrated approach to AR (making AR part of the OS experience that defines Apple products).

To this end we, as developers, received USDZ over the more popular GLTF, AR quicklooks over browser-based AR experiences, and no WebXR API in Safari.

​

Proof of Life

In time, evidence began to emerge of WebXR being worked on within WebKit, Apple’s Safari browser engine. Clues included mentions in bug trackers, and the hiring of immersive-web working-group members.

In iOS16, WebXR feature flags even appeared in the Safari browser settings, but toggling them on did nothing. Some data-miners found mentions of a mysterious external device - a headset - that seemed to be the intended hardware for this additional XR support.

​

A Big, Big, Bet.

It has become clear that WebXR’s fate on iOS will be determined by the broader release-plans for this new headset. This will be Apple’s biggest gamble on a new category for a while (bigger than even Apple Watch or Airpods) as the device will live or die based on its software, and hence its developer ecosystem.

WebXR then, presents both a source of much-needed content, but also a threat to rich, native software that utilises the power and depth of OS APIs to create the Apple Experience.

Immersive computing is a new field, developing novel UX & interactions. It’s understandable that Apple would want to be able to introduce users to the most refined, interconnected version of the experience, and tune it over time based on feedback.

Immersive native apps will likely be aware of your environment, and aware of other apps placed within the same space. Things like pinning spatially-aware apps & widgets in your home, and moving 3D content between apps are not possible via WebXR, so if developers flocked to the browser over the OS, it could harm the success of the headset platform.

Apple might choose to handle this tension similarly to their approach with the App Store back when it first launched; by limiting web functionality at launch to drive developers and users toward native apps.

WebXR will likely be supported fully in VR experiences (head and controller tracking), but have some limitations in immersive-AR. For example, given Apple’s focus on privacy it’s unlikely they will allow camera access from day-one, and may even block sub-features like image-tracking.

In all this headset talk, iPhones and iPads are conspicuously absent. It’s hard to say whether WebXR will be backported to handheld iOS devices. Certainly there wasn’t enough interest to do so between 2018-23, but it might be part of making the case for the importance & utility of AR to iPhone owners (the core target market for the headset).

Apple’s WWDC (Worldwide Developers Conference) is scheduled for June 2023, so these questions will likely all be answered then. It’s my hope that WebXR will be supported to the fullest as an open standard, enabling the kind of permissionless, free-form experimentation that bore much of the web’s now well-established utility.

That outcome may present challenges to Variant Launch itself, but I believe no matter what the future holds, Variant will do better in a healthy immersive-web ecosystem than an artificially limited one.

​

You can build WebXR on iOS today

At Variant we’ve built Launch - our WebAR SDK. that lets you write and publish WebXR experiences on iOS and Android, today. We don’t charge per-view, and don’t lock you into an online code/3d editor. Instead, you get rock-solid native tracking at a much lower cost than leading competitors. You can learn more here.

Should Apple release WebXR on iphones, you’ll be able to just remove one line of code (that adds Variant Launch) and your experience will keep running using Safari’s WebXR API.