What is the state of augmented reality (AR) on the web in 2019? Well, it is a complex story for now because the underlying technology for AR on the web is not yet mature.
The short answer is that the best AR experiences on the web are actually mobile app based. But it is very difficult to get customers to install a mobile app just to enable an AR experience if they were otherwise already browsing a website. The reliance on mobile apps is ubiquitous because the official standard to enable AR on the web, WebXR, is not yet finished nor are its draft forms widely supported by mainstream browsers. To make things more interesting, Apple has released a proprietary web extension called AR Quick Look which enables easy but very limited AR functionality on the web. Of course, this proprietary Apple extension only works on Apple devices.
Let’s look at the details of what is going on with AR on the Web in 2019.
WebXR for Browser-Based AR
The AR trend really took off when Apple introduced their markerless ARKit technology in the summer of 2017. ARKit allowed developers of native iOS applications to deploy AR relatively easily.
The overwhelmingly positive response to ARKit motivated Google to sketch out what an AR API would look like for the Web. Google released its WebAR prototypes for Android and iOS in late 2017. While the WebAR API that Google sketched out wasn’t a standard; however, it did motivate others on the web to push towards the standardization of this functionality in the web browser.
The resulting effort eventually became the WebXR API. The WebXR API is really an evolution of the WebVR API. In fact, WebVR 2.0 API was discontinued or merged into the WebXR API effort. Microsoft, Google and Firefox support the WebXR API. Apple unfortunately has not yet shared an opinion on whether they will support it.
The WebXR API has not yet been released. It is currently a draft specification. This means that the API itself is still undergoing changes at lightning speed, the last of which happened just two months ago. The hope is that by the end of 2019 the WebXR API will be officially released and incorporated into most of the major browsers: Chrome, Edge, and Firefox.
Unfortunately, until the WebXR API stops changing, is formally finished and then integrated into the web browsers, it is difficult to make use of it. One can install special versions of some of the browsers that support a preliminary version of the WebXR API, but getting customers to install these browsers is out of the question.
Thus native AR on the web is coming (to most browsers), but it isn’t ready just yet.
Apple’s AR Quick Look
After the great reception to Apple’s ARKit release, Apple released the means by which ARKit can be utilized on the web via the proprietary AR Quick Look extension. The extension is very simple. It requires specifying a USDZ file (USDZ is a 3D model file format) in the webpage in a very specific way. If done correctly, Apple will display an AR icon on the screen. Once the user clicks that icon, the browser will load the USDZ file into a full screen Apple AR viewer application.
The great thing about Apple’s AR Quick Look feature is that it was a quick way to get AR accessible from the web. It is much easier to trigger an AR experience in one click from a website rather than having to install a mobile application to get access to ARKit’s functionality.
There are two major limitations with Apple’s AR Quick Look: the USDZ file format and the use of a native AR viewer application.
The USDZ file format was likely chosen for the AR Quick Look functionality because it was already adopted as the 3D model file format used to embed 3D data in iOS applications. But it was a weird choice for the web. The USDZ file is not particularly efficient at storing 3D data compared to alternatives like the glTF 3D format. This is because USDZ was designed by Pixar Animation studios to transfer data inside of its studio where storage space and bandwidth are not issues. The other issue with USDZ is that Apple’s implementation of the standard is partial and limited. This is likely because USDZ was intended for film quality graphics and not the real-time graphics needed for AR. Thus Apple didn’t feel the need to fully implement the USDZ specification. The end result is that it is tricky to create USDZ that look good in AR Quick Look as one has to be very aware of which features were implemented by Apple and which were not.
The second limitation of AR Quick Look is its reliance on a native AR viewing experience. This experience is completely separate from the web browser once it is triggered and there is no connection back to the web. This means that the website cannot influence how the user interacts with the AR content. It also means that the website cannot modify the AR experience in any way. This is very limiting as a result. Developers cannot make a configurable AR experience where the user can modify colors or finishes of objects. It also limits the AR experience to where multiple separate objects cannot be placed in the same space, AR Quick Look only supports a single object.
Mobile Application AR
Now that we have looked at the future of AR standards for the web and the easy to use but limited Apple AR Quick Look feature, let’s look at the most powerful means to do AR one the web. The most powerful method is to not use the web browser at all, but instead to create a mobile application. That is, unfortunately, the current answer to rich AR experience at least for now.
Mobile applications, both on iOS and Android, have direct access to powerful AR APIs exposed by hardware devices. These native AR APIs allow for modification of the AR experience in many powerful ways including real-time configuration and multi-object placement. In addition, one of many open source specialized AR toolkits open up the ability for virtual try-ons of wearable items like jewelry and hats. Some tool sets even allow for virtual makeup filters.
The main downside of mobile applications is that they require the user to take the time to install the application. This is not a problem if the mobile application is from a major company that already has a large install base, such as Amazon or Walmart or Wish. However, it can be a problematic for smaller niche players or even a large player whose customers don't have a need for repeatedly using the app. The statistics on mobile application installations have shown a clear trend towards less niche application installs. In fact, by 2017 the average number of app installs per month per user in the US fell to zero.
The second issue with mobile apps is that they are generally expensive to create compared to a website. Also, apps require a fairly regular commitment to maintenance and updates so that they remain viable.
In response to this second issue, some people have suggested only investing in creating AR functionality in the mobile app and not replicating the rest of the website’s functionality in the mobile app. But while this is cheaper, it can even further reduce the ROI on the mobile app if you need to create it from scratch. First off, there is even less of a chance of repeat usage by your users. Second, once the user opens the app for an AR experience, configures their products, how does that configuration get to a checkout? Well, it can be done, but it is cumbersome to achieve from scratch both from an app development standpoint as well as a confusing user experience.
Thus while mobile applications are powerful, it is a real challenge to get users to install these apps and to continue to use them. Realistically for the majority of websites, it should be expected that such apps will not get any meaningful percentage of installs.
The end result of all this mess is that executing an effective AR strategy on the web is challenging at best at this time. There are options, but each option has its tradeoffs. Hopefully, WebXR is coming and it should solve most of these issues for those who can not invest in a successful mobile app strategy, thus developers are eagerly awaiting its arrival.