Feature Opportunity: IPC via SharedArrayBuffer and Async atomic waits coming to WKWebView

[franz-fletcher]

I'm sure this is likely already on your radar as a potential strategy for Tauri's IPC reimplementation hopefully shipping in v2.
WebKit-7615.1.18.100.1, released about 2 weeks ago includes exciting support for shared memory data operations between spawned threads on the UI layer (WebAssembly and Worker contexts) as well as the Main thread FINALLY 🥳.

This functionality is exposed through the implementation of Atomics.waitAsync spec and SharedArrayBuffer Objects spec API proposals through TC39.

WebKit/WebKit#8578 (comment) describes the implementation and platform support surface attached to the merged changes that enable access to SharedArrayBuffer Objects docs using Atomics.waitAsync() docs on the main thread running JavaScriptCore.

Safari and WKWebView support on Apple platforms is currently available in the Technology Preview release for version 16.3. It will likely be released along with the next minor updates to MacOS Ventura and iOS. Parity with Linux, Windows and Android seems to be a possibility with WebKit browsers on these platforms already supporting compatibility for the API specs in their latest versions.

Im sure there are potential limitations and bugs that will make implementing an IPC rearchitecture initiative challenging and time consuming regardless of the direction you decide is suitable to address the v2 solution.
This is less of on RFC proposal or feature request, the community seems interested in collaborating on this subject so I hope this can encourage meaningful dialogue and potential prototypes to determine feasibility.

[FabianLars]

Sooo without actually looking to much into the new apis, this will most likely not be used for the new IPC (or if it will, it will be behind version checks) because wkwebview is only updated on new macos releases, meaning this would only work on macos 13.X (or even 14 if we're unlucky) and above 😭

So imho this is not a solution we should invest much time into until it's more broadly available (as-in, until tauri raises the min mac version accordingly)

[franz-fletcher]

Sooo without actually looking to much into the new apis, this will most likely not be used for the new IPC (or if it will, it will be behind version checks) because WKWebView is only updated on new MacOS releases, meaning this would only work on MacOS 13.X (or even 14 if we're unlucky) and above 😭

The most recent minor update release for MacOS Ventura 13.2 includes a new feature addition to the SwiftUI framework tagged as an incremental version update to the developer SDK.
(...actually looks like they just pushed a security update as 13.2.1 to address some spooky vulnerabilities that have surfaced 👻 )
In this WWDC2022 WebKit Presentation, I believe the intention is clearly communicated that these new WebKit features will be available in a Safari 16 release this year.

You are right to be concerned that the probability of WKWebView API updates being bundled with Safari's incremental releases is very low. With that said, there are promising workarounds and common low level patterns that can leverage the private WebKit API to enable Safari features in WKWebView assuming the target device has installed the latest version of Safari.

It's messy but I think it is an acceptable workaround for developing and testing prototypes in the spirit of empowering the community to buy into the IPC reachitecture initiative, which should hopefully encourage contributions that can help expedite the proposed architectures definition and feasibility.

[JonasKruckenberg]

I have a bit of a different take here, currently all IPC solutions provided to us by webviews (especially webkit) are incredibly underwhelming and there is no way for us to workaround except for shipping an http server shich ofc is a no-go.

So this news (which I wasn't aware of actually) has me more excited than anything else and I would vote for adopting this as soon as possible (with a fallback to the current impl where shared memory ipc isn't supported) and also actively engage with the people implementing this, maybe we can help out, do testing, etc.

Again to me this is the most exciting news for Tauri in ages!

Edit: I agree though getting it in v2 would be tricky time-wise, but this should be a transparent upgrade anyway

[brandonros]

It would be no small lift to extend WebKit's JavaScriptCore WASM runtime to support something like this, right? https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/export_native_api.md

[oganator]

Has there been any update on this? I am currently struggling with this (slow IPC) as well...

[FabianLars]

No. This whole thread ended up being basically off-topic, or rather, a misinterpretation of the changes in WebKit.

This SharedArrayBuffer implementation does not allow communication between frontend (js/wasm) and backend (rust) but only between different frontend contexts (the "main" frontend thread and worker threads) which really doesn't help us at all.

[nothingismagick]

Well, this is amazing news - and will come with security implications but is really exciting and I agree that looking into this will have exciting implications for a number of projects. Webkit taking this on could also have a benefit for the rest of the ecosystem.