Aidoku: a GPLv3 manga reader for iOS, iPadOS and macOS

What Aidoku is for, and who it is not for

Aidoku is a manga reading application for iOS, iPadOS and macOS, written in Swift and released under GPLv3. It targets one job: give an Apple device a reader that handles a library, external sources and downloads without advertising. The README lists the feature set plainly: no ads, local file reading in CBZ, built-in reading service providers (Komga, Kavita, Suwayomi), a WASM external source system, downloads, tracker integration with services such as AniList and MyAnimeList, and OCR dictionary lookup.

The audience is narrower than the feature list suggests. If you already run a Komga, Kavita or Suwayomi server, Aidoku is a client for it. If you keep CBZ files on disk, it reads them. If you want a catalogue of manga baked into the app, that is not what this is: content arrives through sources, and sources are loaded separately. The README also states Aidoku is still in a beta phase with planned features and fixes, which is the single most important line for anyone deciding whether to depend on it.

How the WASM source system and the built-in providers differ

Aidoku has two distinct paths for getting content into the library. The first is the built-in reading service providers: Komga, Kavita and Suwayomi. These are self-hosted servers you run yourself, and the app connects to them as a client. The second is the WASM external source system, where a source is a WebAssembly module the app loads rather than code compiled into the binary. That split is the architectural decision worth understanding, because it explains both the app's flexibility and its fragility.

Shipping sources as WASM modules means the app binary does not have to carry every integration, and a source can be added or removed without a new release. It also means a source is an external artifact with its own lifecycle. The README does not document a bundled catalogue of sources, nor does it describe a verification or signing step for third-party modules. If a source stops working, the failure sits outside the app's release cycle. For a reader whose value partly depends on those modules, that is a real dependency to accept up front, not a detail to discover later.

Installing Aidoku on iOS: TestFlight, AltStore and manual ipa

The README does not put installation steps in the repository. It points to the website at https://aidoku.app for detailed instructions and then lists three routes. TestFlight requires joining the Aidoku Discord first. AltStore works through a repo that carries the latest release ipa; you copy the direct source URL and paste it into AltStore, and the README notes that AltStore PAL is not supported. Manual installation uses the ipa from the releases page.

The AltStore route is the one with a concrete, copyable URL in the README:

https://raw.githubusercontent.com/Aidoku/Aidoku/altstore/apps.json

Paste that into AltStore as a source. What you should then see is Aidoku listed among the apps that source provides, with the latest release ipa available to install. If nothing appears, the source URL is the first thing to check, since the README treats it as the entry point rather than a mirror.

The manual route is the fallback when AltStore is not an option:

# download the latest ipa from the releases page
https://github.com/Aidoku/Aidoku/releases

The README states the latest ipa is always available from the releases page, and that nightly ipas are built on each commit. It explicitly does not recommend the nightlies, because they may contain in-progress changes that cause issues when updating later. Take that warning at face value: if you install a nightly and later move to a release, the upgrade path is the thing most likely to break.

The beta label and the update risk it implies

The README says Aidoku is still in a beta phase. That is not a formality. Combined with the recommendation against nightly builds, it describes a project where the install path and the update path are the two places users are most likely to hit trouble. The releases listed for the project are versioned (v0.9, v0.8.4, v0.8.3), so there is a release cadence, but the beta framing means behaviour can change between them.

The practical failure mode is an update that does not carry your data or your sources forward cleanly. The README warns that nightlies may cause issues when updating later, which implies state compatibility is not guaranteed across arbitrary builds. If you install from a nightly and then a release lands, you are in exactly the configuration the README tells you to avoid.

A second limitation is platform. Aidoku is for iOS, iPadOS and macOS only. The related searches show people repeatedly asking about Aidoku for Android; nothing in the README or the repository layout indicates an Android client exists. If Android is a requirement, this project is the wrong tool regardless of how well it reads manga on an iPad.

Where Aidoku sits next to a self-hosted server plus a generic reader

The closest alternative approach is to run a self-hosted manga server and read from it in a browser or a general-purpose reader. Aidoku supports Komga, Kavita and Suwayomi as built-in providers, so it can act as the client for that setup, but the difference in approach matters. A browser client needs no installation, no AltStore, no ipa and no beta-phase update risk; it also gives you no native downloads, no tracker integration and no OCR dictionary lookup.

Aidoku's bet is the opposite one: a native Apple app with CBZ reading, downloads, tracker sync and OCR lookup, in exchange for an install path that runs outside the App Store and a source system that lives outside the release cycle. If your library is already on Komga or Kavita and you mostly read at a desk, the browser is the lower-maintenance choice. If you read on an iPhone or iPad and want local files and downloads, the native app is doing work the browser cannot. The trade is maintenance surface for reading features, and it is a genuine trade rather than a clear win either way.

Licence, CLA and what redistribution actually requires

The repository is licensed under GPLv3, excluding translations, which are licensed separately under Apache 2.0. On top of that, contributors must sign a project CLA. The README explains the intent: the CLA gives the maintainer (Skittyblock) the ability to distribute Aidoku through TestFlight and the App Store, while others must obtain an exception from the maintainer to do the same. Otherwise GPLv3 applies, and the code can be used freely as long as modified source is made available.

That combination is unusual enough to read carefully before you build on it. Forking and shipping your own build to the App Store is not simply a GPLv3 matter; the README says an exception from the maintainer is required for that specific distribution route. If you are evaluating Aidoku as a base for a product rather than as an app to use, this is the constraint that decides the question. This is a description of what the README states, not legal advice; if distribution is your plan, get the licence and CLA reviewed by someone qualified.

Maintenance cost for a user is low: install once, update through the same channel. The repository's last push was on 2026-09-17, and the most recent release listed is v0.9 on 2026-09-03.

Editorial conclusion

Adopt Aidoku if you read manga on an iPhone, iPad or Mac, already run Komga, Kavita or Suwayomi, or want CBZ files handled locally, and you are willing to install through AltStore or a manual ipa rather than the App Store. Do not adopt it if you need a stable, feature-frozen reader, an Android client, or a source catalogue that ships inside the app. Before installing, check the release page for the current ipa, confirm whether the AltStore source URL still resolves, and read the CLA and GPLv3 terms if you intend to distribute a build.

Frequently asked questions

Official sources

1. Aidoku/Aidoku on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases