Bug 240117 – USDZ AR QuickLook support in WKWebView inconsistencies

• Status: NEW
• Component: WebXR

[Miles]

When viewing a webpage in WKWebView that has links to USDZ files for viewing 3D models in AR QuickLook, in some apps, this breaks or is not supported, and in others it works. 

Repro:

Open Apple AR Gallery in a WKWebView:
https://developer.apple.com/augmented-reality/quick-look/
Click on any 3D model example.

Observed results:

iSO Facebook (WebView): shows a network error screen
iOS LinkedIn (WebView): shows a page of text
iOS Instagram (WebView): does nothing
iOS Twitter (SFSafariViewController): correctly displays USDZ in AR QuickLook
iOS Chrome (WebView?): correctly displays USDZ in AR QuickLook
iOS Firefox (WebView?): correctly displays USDZ in AR QuickLook
iOS Edge (WebView): correctly displays USDZ in AR QuickLook
iOS Opera (WebView?): invokes the file download dialog

Is WKWebView automatically / inherently compatible with opening USDZ models in AR QuickLook?

Or do app developers have to specifically implement additional support for opening USDZ models in AR QuickLook?

Could WKWebView be made automatically / inherently compatible with opening USDZ models in AR QuickLook?

[Radar WebKit Bug Importer]

<rdar://problem/93166954>

[Dean Jackson]

Yeah, AR Quick Look isn't yet supported in WKWebView :(

We'll fix it when we can.

[Miles]

(In reply to Dean Jackson from comment #2)
> Yeah, AR Quick Look isn't yet supported in WKWebView :(
> 
> We'll fix it when we can.

Thanks for looking at this Dean. It's very much appreciated. 

Just to provide context; we do a lot of work with brands creating USDZ AR product previews for their website and ecommerce platforms. AR QuickLook has been awesome for this and our clients see huge benefit. An AR product preview page can boost conversion rates by 30% or more. Which is a huge deal for many brands! 

This all works flawlessly when viewing websites in Safari.

However, many of our clients drive large amounts of their traffic via social (paid, owned and earned), and a lot of this comes from apps like Facebook and Instagram.

Sadly, all of this traffic misses out on an AR experience - or even worse, gets a broken experience. 

Compounding the issue is that there's no way for a website to easily 1-click transition the user out of the WKWebView and over to their proper browser, as mentioned here:
https://bugs.webkit.org/show_bug.cgi?id=240025

AR QuickLook support in WKWebKit would be a MASSIVE benefit to many brands and users alike. 

Thanks for listening ;)

[Miles]

I didn't see anything at WWDC2022 that might resolve this matter (I was hoping for more news on <model> or WebXR). 

Any chance the original request to bring AR QuickLook support to WKWebView can be taken under consideration?

I am weighing in +1 for this request, as another business owner/lifetime Apple customer/Apple ecosystem developer that would benefit tremendously from the ability to have AR QuickLook support in WKWebView. From my perspective:
- All in-app browsers are built on WebKit (most with WKWebView)
- Apple sells devices with USDZ / AR Quicklook support as a major selling point, specifically showcasing in-browser and in-app support 
- Webkit (WKWebView) doesn't support USDZ / AR Quicklook

...which in sum means that there really isn't true support for Apple's own USDZ format/experience for the vast majority of the iOS app ecosystem (at least not outside of explicitly "AR" apps). 

The friction of having to tell every single user to copy the link and re-open in Safari is way too high - it really destroys the user experience and kills any momentum of the excitement of AR (especially in the social media apps). The ability to have a link break out of WebKit would potentially be another solution. I'm aware that is a separate request already filed here, but I've misplaced the link. (Somehow my guess is that Apple does not want people doing that.)

I certainly understand that there are many complicated moving pieces in web dev and mobile dev, probably many new privacy considerations with AR, and all of this is high stakes when you are maintaining code that is relied on by billions of people. At the same time, it doesn't seem like a ridiculous thing to request that the Apple AR default tool be supported by the Apple web browser default tool. (Especially after so many years have gone by since the USDZ / AR Quicklook announcements.) 

I hope you will strongly consider prioritizing this request.

[Brent Fulgham]

This is actually tracked by:
rdar://39544702

[Miles]

(In reply to Brent Fulgham from comment #6)
> This is actually tracked by:
> rdar://39544702

Thanks. Is there an associated bug listing for that I can cc myself on to (I can't see rdars)?