What is the state of augmented reality (AR) on the web in 2019? It's a complex story 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. That said, it's very difficult to get customers to install a mobile app just to enable an AR experience. 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 take a closer look at the state of 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,, it did motivate others on the web to push towards the standardization of this functionality.
The resulting effort eventually became the WebXR API. The WebXR API is essentially 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 has unfortunately not yet shared an opinion on whether or not they will support it.
The WebXR API has not yet been released and is currently a draft specification. This means that the API itself is still undergoing changes at lightning speed, the last of which happened in early 2019. 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 is formally finished and integrated into the web browsers, it will be 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 ( 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 is a quick way to access AR from the web. It is much easier to trigger an AR experience in one click from a website 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 an unusual choice for the web because 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's triggered and there is no connection back to the web. This means that not only can the website not influence how the user interacts with the AR content, but 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 so that multiple separate objects cannot be placed in the same space, as AR Quick Look only supports a single object.
Mobile Application AR
Now that we've looked at the future of AR standards for the web and the Apple AR Quick Look feature, let’s look at the most powerful means to do AR , which is to create a mobile application. That is, unfortunately, the current answer to rich AR experiences –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. 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 mobile apps and not replicating the rest of the website’s functionality in the mobile app. While this is cheaper, it can even further reduce the ROI on the mobile app if you need to create it from scratch. For starters, there is even less of a chance of repeat usage by your users. Second, once the user opens the app for an AR experience and configures their products, how does that configuration get to a checkout? It can be done, but it it's cumbersome to achieve from scratch from an app development standpoint and leads to a confusing user experience.
Thus., while mobile applications are powerful, it's a real challenge to get users to install these apps and to continue to use them. For the majority of websites, it should be expected that such apps will not get any meaningful percentage of installs.
The reality for now is that executing an effective AR strategy on the web is challenging at best. 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, which is why developers are eagerly awaiting its arrival.