[mbzi]

Apple forbids other web engines explicitly (or only allows the WebKit respectively) in § 2.5.6 of App Store Review Guidelines: https://developer.apple.com/app-store/review/guidelines/

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

This means they cannot add a new API standard on iOS. This is why WebRTC was hamstrung until November last year.

https://bugs.webkit.org/show_bug.cgi?id=208667 https://bugs.chromium.org/p/chromium/issues/detail?id=752458

If the browser uses WKWebView or UIWebView, you're right, you can "mock" an API by injecting JS, and through tunnelling you can recreate native functionality. Not if its SFSafariViewController. As someone who has done a lot of fiddling with JS to Obj-C/Java tunnelling for iOS and Android in production, it can be prone to errors and/or get your app rejected. Browser makers probably do not see the commercial value in going down this bespoke path.

[wayneftw]

> If the browser uses WKWebView or UIWebView, you're right, you can "mock" an API by injecting JS, and through tunnelling you can recreate native functionality.

So, technically it can be done.

What's stopping them? Do you think Apple would count that sort of feature as "implementing your own web engine"?