Apple has confirmed that Safari on Vision Pro will support WebXR, a web-standard that allows immersive experiences to be delivered through the browser.

In a somewhat surprising move, Apple confirmed that Safari on Vision Pro will support WebXR. Prior to the reveal of the headset, it was an open question whether the company would entertain the idea of XR experiences through the browser, and even more so if the company would adopt the relatively new WebXR standard. But now Apple has confirmed that Safari on Vision Pro will indeed support WebXR.

The company confirmed as much in its WWDC 2023 developer talk titled Meet Safari for Spatial Computing, in which the Apple explained the version of Safari running on Vision Pro is “truly is Safari with the same WebKit engine underneath, plus some thoughtful additions for [Vision Pro].”

Thanks to Safari on visionOS being a fully-featured version of the browser, existing websites should work exactly as expected, the company says. But to go beyond flat web pages, Safari on visionOS includes support for WebXR for immersive experriences and the new <model> tag for 3D models.

For the time being, WebXR capabilities on Safari for visionOS are still hidden through a developer toggle, but once enabled it will support the ‘immersive-vr’ session type, and the ‘hand-tracking’ feature for user input.

An example of a fully immersive WebXR environment | Image courtesy WebKit

WebXR allows developers to build fully immersive content that can be delivered through a web browser. It’s possible to create fully interactive VR games and experiences, like this Beat Saber clone, which can run across various headsets and browsers using the same code, just like a web page can render the same way between different devices and browsers.

Apple plans to make WebXR a mainline feature in visionOS Safari after more time collaborating with the rest of the industry on the WebXR standard.

With Apple now officially supporting WebXR, the standard can claim truly widespread support; WebXR is now supported, at least in some capacity, by Chrome, Firefox, Opera, Edge, and Safari, as well as the Quest browser, Pico browser, Magic Leap Browser, Chrome for Android, Samsung Internet, Opera Mobile, and Firefox for Android. Though like visionOS Safari, some of these browsers have kept the feature as a developer preview for now.

In addition to WebXR, Apple is also adding support for the in-development <model> specification, a standardized approach to adding 3D models to web pages for things like previewing clothing, furniture, and other products.

Image courtesy WebKit

The goal is to make embedding 3D models into web pages as easy as embedding photos or videos. For the time being the feature will remain behind a developer toggle.

Newsletter graphic

This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. More information.

Ben is the world's most senior professional analyst solely dedicated to the XR industry, having founded Road to VR in 2011—a year before the Oculus Kickstarter sparked a resurgence that led to the modern XR landscape. He has authored more than 3,000 articles chronicling the evolution of the XR industry over more than a decade. With that unique perspective, Ben has been consistently recognized as one of the most influential voices in XR, giving keynotes and joining panel and podcast discussions at key industry events. He is a self-described "journalist and analyst, not evangelist."
  • g-man

    And of course it will support third party browsers with their own engines, right?


  • xyzs

    What about OpenXR ?
    (OpenXR is not only about controller input)

    • Anonymous

      Yes. This is indeed the most pressing enigma.

      No OpenXR and with this price tag they are essentially asking for a death sentence for AVP.

    • Christian Schildwaechter


      It’s very likely we’ll see support, indicated by:
      – Unity support for Immersive apps, with Unity basing XR on OpenXR and being the main XR development platform.
      – Safari support for WebXR, with WebXR sharing large parts of the core functionality with OpenXR and often being implemented on top of it.
      – Everybody else is converging towards OpenXR, and Apple has to reduce friction for existing XR developers, as the AVP user base will remain very small for years due to price and technical limitations. Meaning revenue from software sales will be way worse than on existing VR platforms, so Apple requiring extensive code rewrites would cut them of from many interesting ports.
      – Apple supports existing standards if they fit their needs, and collaborate on new standards if existing ones aren’t powerful enough, though they usually stick to what they picked for a long time, even if a newer, open standard with the desired features appears later (Lightning USB-C, Metal Vulkan).
      – One of the main sales arguments for the initial iPhone was its fully desktop compatible browser, compared to at that time limited browsers that required special HTML subsets and web design, making most websites barely usable.
      – Before they even allowed native apps, they pushed web apps based on existing, open standards, also running in browsers for other vendors, which developed into the progressive web apps we use today.
      – Apple usually doesn’t try to re-invent the wheel, they try to improve the existing technology and embed it in a very smooth and intuitive user interface.

      (Very) Long:

      I of course don’t know, but I’d expect them to support OpenXR, simply because it makes sense. They obviously haven’t announced any support yet, but if they are looking for developers to support the Immersive/VR mode on AVP, they will have to make it somewhat easy to port existing apps. Apple’s own sales predictions for the AVP are less than 1mn devices sold in 2024, partly due to Sony being the only source for the microOLED displays, and Sony’s production facilities currently not being able to manufacture more than 900K per year.

      And with Apple pushing integration into the existing iOS market, using iPad Apps and media consumption as major use cases, XR developers will quickly come to the conclusion that for the first few years, the number of VR app/games they can sell on the platform will be miniscule. Apple never mentioned existing VR games directly, but emphasized the cooperation with Unity to give full access to all the spatial data necessary to create (or port) apps, with Unity being the main development tool for most VR apps. Unity itself switched all their vendors specific XR interfaces to a unified, OpenXR based plugin architecture.

      Basically everything XR is converging from proprietary, but similar APIs covering mostly the same function set, towards OpenXR, providing an open standard that allows for vendor specific extensions to implement either advanced or backward compatibility features. WebXR and OpenXR themselves are different standards for different purposes (e.g. WebXR has to also deal with sessions and requesting data from servers), but they cover many of the same basic compatibilities, and OpenXR can be used as a native backend for WebXR, similar to how it is (one) native backend to Unity’s own XR Core Utilities and XR Interaction Toolkit, with ARKit and ARCore being others. I’m pretty sure that most WebXR implementations will switch their rendering from the OpenGL ES based WebGL1/2 to WebGPU, a standard based on suggestions by Apple to replace the aging OpenGL ES with an architecture fitting to modern GPU architectures, now supported by all mayor browsers and providing both a significant performance and feature boost, getting web based XR performance closer to native apps.

      Apple may be the big fish in mobile and even mobile AR, but it is a tiny fish in XR in general and will remain that for some time, with interest for AVP driven mostly by future prospects, not short term user growth. Meta already has a lot more users, and by the time an affordable Apple HMD will reach the marked in large numbers, Samsung/Google will have released their own. That’s quite a different situation to Apple introducing their own APIs for the (MacOS based) iOS, both of which relied for years on OpenGL for 3D graphics, because at that time there basically were no smartphones besides the failed WindowsCE devices. They had to create most of it themselves, and reused as much as possible from their existing OS, which itself has a Unix-like architecture based on tons of standards and open source software.

      The advanced Metal API, which is always dug up when pointing out Apple going proprietary ways, that replaced the no longer competitive OpenGL after a couple of years, preceded Vulkan by several years, even more years before Android 7 introduced Vulkan, and many, many years before Vulkan was widespread enough for developers to use it. Apple later never switched their platform to Vulkan, nor added Vulkan support for cross platform compatibility, but neither did Microsoft. They continue to use DX12, Vulkan support comes from the GPU drivers by Nvdia, AMD and Intel. All GPU drivers on MacOS come from Apple, since Nvidia dropped support after Apple required new drivers to also support Metal, while Nvidia wanted to push their proprietary CUDA.

      Apple tends to use existing open standards, if they are (still) competitive, and push for replacement if they are not, though they are willing to break things. They removed serial and parallel ports and forced everyone to use the USB port before anyone else, they killed floppy drives and force everyone to switch to network transfers or USB sticks. They removed keyboards and buttons, forcing developers to come up with multitouch interfaces. All of which turned out to be good designs decisions, despite the outcry from users about breaking compatibility. I’m pretty sure that forcing developers onto modern graphics APIs and web APIs using these will turn out to be a good decision in the long run too, even if it now requires more work from developers.

      They surely lock down their platforms, but usually by EULAs and developer agreements, not by artificially duplicating existing APIs just to make porting harder, which doesn’t work anyway with games, where developers use tools like Unity that hide most of the differences between iOS and Android. So they would only benefit from using (extending) OpenXR, with their IP still being protected by the heavy reliance on existing Apple services and apparently 5000 patents for AVP.

      • g-man

        Oh right, like how everyone’s converging towards Vulkan so that’s what Apple’s doing

    • It’ll come, don’t you worry …. lol

  • This is very good news