Skip to content
All case studies

Nyora for Aidoku

A source list of ~959 WebAssembly (.aix) extensions — one per Nyora source — that run inside completely stock Aidoku on iOS, each a small Rust/aidoku-rs proxy that calls the Nyora cloud helper's REST endpoints, installed with a single aidoku://addSourceList deep link.

Stack

  • Rust (aidoku-rs)
  • WebAssembly (.aix Aidoku sources)
  • Aidoku iOS source-list format (index.min.json)
  • Nyora cloud helper REST API (api.nyora.xyz)
  • kotatsu-parsers-redo engine (server-side)
  • aidoku://addSourceList deep link install
  • GitHub Pages (list hosting)

Overview

Nyora for Aidoku brings the Nyora catalog to Aidoku, the open-source manga reader for iOS, as roughly 959 WebAssembly source extensions — one .aix per Nyora source. They run inside completely stock Aidoku: there is no forked app and no patch. The user installs the whole set with a single Aidoku deep link and the sources appear in the app's normal source browser.

Why a proxy, not a scraper

Aidoku extensions are WebAssembly modules, and there is no way to run Nyora's kotatsu-parsers-redo JVM engine on-device inside stock Aidoku on iOS. The alternative — hand-writing 959 native Rust scrapers and keeping them working as sites change — would be an unmanageable maintenance load. So each Aidoku source here is a thin proxy rather than a scraper. Instead of parsing the target website itself, every .aix calls the Nyora cloud helper's REST endpoints — the kotatsu-parsers-redo engine hosted at api.nyora.xyz — which parses server-side and returns clean, normalized manga, chapter, and page data. The WASM module's only job is to map Aidoku's listing, search, details, and pages calls onto those endpoints and reshape the responses into Aidoku's own model.

959 binaries from one template

Aidoku requires each source to be a compiled WebAssembly binary with its own identity, configuration, and icon. Producing that correctly 959 times by hand would be error-prone, so a single parameterized Rust / aidoku-rs template implements the proxy logic once and is then built per source, baking in that source's id, endpoint parameters, metadata, and icon. The proxy body is identical everywhere, so correctness is established a single time and replicated mechanically across the whole catalog.

One-tap install into stock Aidoku

Everything is published as a standard Aidoku source list — an index.min.json describing every .aix with its metadata and icon, split into SFW and 18+ variants and grouped by language. Installation is a single deep link, aidoku://addSourceList?url=<list>, which registers the entire list in Aidoku's normal source browser. This is Aidoku's own supported mechanism, so nothing about the app is modified.

What this demonstrates

This is a pragmatic platform bridge: where an on-device engine is impossible, a uniform WASM proxy over the Nyora cloud helper delivers the same ~959-source catalog to iOS. It shows comfort compiling Rust to WebAssembly against a third-party plugin ABI, mechanically generating a large, consistent artifact set from one template, and shipping it through the host app's native distribution path so users get the whole catalog with a single tap.