The State of AR on the Web

We know that in today's visual economy, consumers are hungry for AR technology. In fact, 71.5% say that AR is the “future technology they are most eager to use.”  But the truth is, augmented reality (AR) on the web may not be as far into the future as some think.  It's a complex story because the underlying technology for AR on the web is not yet mature.

AR with finger


Right now, 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.

We started on this subject in April 2019, but as with everything AR, things are moving fast. Let’s take an updated 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.

While the WebXR API has not officially “launched,” Google Chrome 79 is currently on the Beta Channel. It enables WebXR by default, allowing anyone to try out demos and games. This is the first step to broader integration and adoption.

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.


47% of all Apple ARkit app downloads are games. 


In 2017, spending on Pokémon GO accounted for 84 percent of the entire mobile AR consumer spending.


32 % of consumers use augmented reality, and 73% of mobile AR users reported either high or very high satisfaction with mobile AR experiences. 

Thus, native AR on the web is coming (to most browsers), but it isn’t ready just yet.

It should be noted that there are some JavaScript libraries, such as AR.js, that do enable a fully native marker-based AR experience on the web. However, the term “marker-based” is key, as it means the user must have a marker upon which the AR object is placed. Compared to the markerless approach of Apple’s ARKit and Google’s ARCore, marker-based approach is very consumer unfriendly. Therefore, it is our opinion that a marker-based approach is not a real AR solution for the web at this time.


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. 

But Apple’s true intention for investing in ARKit may have more to do with laying the groundwork for its own set of augmented reality glasses.  By launching ARKit several years in advance of the glasses, they are hoping third-party developers create applications that will make the smart glasses a must-have among consumers.  As of this writing, rumors have the AR headset coming out as early as 2020, with the glasses slated for 2023. Considering the failure of Google Glass, many consider this is a bold investment. Will consumers finally be ready to adopt this technology?


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.


EDITOR'S NOTE: This post has been updated with additional data and details. 

Threekit is product visualization software that creates photorealistic imagesinteractive 3D and augmented reality experiences that help businesses sell more. To learn more, please schedule some time with one of our teammates. 


Article Categories: Insider, Industry Trends, Augmented Reality, usdz, obj, gltf

Share this article