10ten Japanese Reader for WebViews

[shirakaba]

For years, I've wanted to use 10ten Japanese Reader from inside a WebView, rather than using it as a Web Extension in a full-blown web browser. This would allow me to create offline-first apps like ebook readers and be free of the constraints of PWAs on iOS.

Back in 2024, I spent a couple of weeks reverse-engineering how to polyfill the Web Extension APIs for a WebView by hand. I made some good progress, filling in many of the APIs successfully, but still couldn't quite get the end-to-end of goal of puck + popup dictionary working. I revisited it this year and still couldn't get it working.

So, on a whim, I pointed an LLM at it last night, basically telling it to pick up where I left off. It required a lot of hand-holding and frustration, and I had to pay for more tokens to keep going (it has cost me ¥6,000 to get this far 😵), but I'm happy to report that there are now signs of life:

webview_demo.mp4

webview_demo_macos.mp4

I designed it to use the 10ten-ja-reader code as-is. The short-term goal is for iOS + macOS app developers to be able to just install a Swift Package and integrate it into a WebKit WebView by installing it as a Swift Package and just pointing it at their existing WebView. But as there's nothing WebKit-specific about this logic, in theory it could be adapted for use in Gecko or Chromium on Android or Windows.

So, I'm very pleased. It's still early days, and I need to clean up a lot of slop before I can turn this into a library and bother making the repo public, but happy to report the scientific progress so far. Does this sound of use to anyone?

[birtles]

Well done! Please let me know if there's anything we can do to make it more easily embeddable. I wonder if being able to ship a more complete snapshot of the database with your app and disabling the automatic download could be useful.

[shirakaba]

Please let me know if there's anything we can do to make it more easily embeddable.

I think I'm not clear yet myself what the best path to easier embeddability would be, as I don't want to hold back 10ten Japanese Reader from freely using Web Extension APIs, and there's no point creating a one-off environment-agnostic abstraction for just the subset of the Web Extension APIs it's using.

It might be easier to ask, "if we were to re-implement 10ten Japanese Reader as a script that could just be dropped into a page as-is, how could that be achieved?" Because if it can be turned into a script, it can be trivially injected into a WebView. For any performance-sensitive aspects, build-time flags could be provided to allow the embedder to choose between either a best-of-a-bad-job default implementation, or to let 10ten delegate to a more optimised implementation provided by the embedder.

For example:

• the best-of-a-bad-job implementation could be that the dictionary is just bundled along with the JS code as a big multi-megabyte series of store.put() statements into IndexedDB. It's clearly hideously heavy for an injected script, but the point is that it'd be zero-setup.
• whereas the embedder could choose to manage an SQLite database on the native side of their iOS app.

I wonder if being able to ship a more complete snapshot of the database with your app and disabling the automatic download could be useful.

I think that would be good, yes. I'm sure any reasonably up-to-date dictionary dump would be plenty fine for most use-cases. And in fact, it'd be perfectly acceptable for iOS or macOS apps embedding 10ten to just provide dictionary updates as part of the usual App Store update process rather than automatically downloading patches to the database.

[shirakaba]

I wonder if being able to ship a more complete snapshot of the database with your app and disabling the automatic download could be useful.

The WKWebExtension API (that I mentioned in the other comment) works a treat! The 10ten Web Extension, associated with my WKWebView, is downloading dictionaries before my very eyes.

[birtles]

Awesome. For what it's worth, I think we probably will get to a SQLite backed version in time. I've had a bit of success recently with getting AI to very slowly migrate things, piece by piece, day by day and I have a rough plan for very carefully migrating from IndexedDB to SQLite. No timeframe yet, though.

[shirakaba]

Update: Something that completely slipped me by was this relatively new WKWebExtension API that came out in iOS 18.4 (in March 2025 – a year after I'd started the polyfill approach). I tried it out, and it allowed me to substantially simplify my approach:

As you'd guess, it's a first-class API for using Web Extensions with WKWebView. It seems you don't need to be a browser vendor or to have any particular entitlements to use it, and I think it's available to use regardless of region with no particular App Store considerations to worry about.

So, I'll pivot to this approach instead. I'll keep the code around for the old polyfill-based approach, as it's WebKit-independent. But it does sound like Android might have options for using Web Extensions as first-class citizens with GeckoView anyway, so just because we couple to Apple here doesn't necessarily mean we rule out cross-platform support down the line.

(As for the repo, I'll share it once ready).