Bug 294381 – Add WebViewAssetLoader‐style API to WKWebView for virtual HTTPS asset hosting

• Status: NEW
• Component: WebCore Misc.

**Background**  
On Android’s Chromium‐based WebView, the WebViewAssetLoader API lets apps serve bundled assets (from `assets/` or `res/`) under a virtual HTTPS domain (e.g. `https://appassets.androidplatform.net/`) without needing real TLS certificates. JavaScript in the page sees a proper HTTPS origin, so `fetch()`/XHR and CORS behave as if loading from a remote server.

WKWebView today lacks an equivalent. Developers must either run a local HTTP server or use custom URL schemes, neither of which fully emulates an HTTPS origin.

**Feature Request**  
Introduce a WebKit API—analogous to Android’s WebViewAssetLoader—that allows configuration of a virtual HTTPS hostname for serving app‐bundled resources.

[Radar WebKit Bug Importer]

<rdar://problem/153812992>

Hi WebKit team—could you share the current status or triage outcome for this request?
I can’t access the linked Radar (rdar://problem/153812992), so any public note here would help.
If it’s tracked elsewhere, please feel free to mark this as a duplicate or close with a public pointer. Thank you!

It doesn't look like anyone is actively working on this issue at the moment, so I'd like to take a shot at it.

[Brady Eidson]

> It doesn't look like anyone is actively working on this issue at the moment, so I'd like to take a shot at it.

While you're quite free to work on a patch, please note that changes to the public API that a particular vendor ships are entirely up to that vendor.
And if that vendor does not want a particular API exposed, they are under no obligation to expose it.

i.e. If your goal is to add WKWebView API and have it end up in an actual macOS/iOS/visionOS SDK, that's not actually up to the WebKit open source project.