OtakuWorld: three Android media readers sharing one Compose codebase

One repository, several apps: how the OtakuWorld modules fit together

OtakuWorld started as a consolidation. The README describes it as a combined version of the MangaWorld and AnimeWorld apps, created because there were a ton of shared elements between the two, so they were combined into two separate apps that share a lot of the same base logic. A third reader, NovelWorld, followed the same pattern, and the repository's own description summarises the goal as an anime watcher, a manga reader and a novel reader delivered as three separate apps with the same user interface.

The directory listing shows how that consolidation is expressed in code. Each product owns a top level module, with animeworld/, mangaworld/, novelworld/ and animeworldtv/ alongside otakumanager/, which is the cross-app favourites viewer. Underneath sit the pieces that the products share: sharedcomponents/, sharedtools/ and sharedutils/, plus kmpmodels/ and kmpuiviews/ for the multiplatform model and view layers, and a UIViews/ directory that looks like the older view layer kept alongside the Compose one. There is also datastore/, favoritesdatabase/, imageloader/, Models/, misc/ and source_utilities/, which is a reasonable sketch of the architecture of a media app of this size.

The consequence for a user is concrete. Because the same components back all of them, a fix to the favourites list or the image loader shows up in every app, and a setting you learn in the manga reader behaves the same way in the novel reader. The repository also carries a Multiplatform Roadmap.md and separate baseline profile modules per app, which indicates that the shared code is expected to keep widening beyond Android.

Compose Multiplatform as the shared layer, with desktop builds emerging

The implementation is Kotlin, and the topics list Jetpack Compose, Compose Multiplatform, Kotlin Multiplatform and Android TV support. Otaku Manager is described as made using pure Jetpack Compose with no XML for any views, which is the clearest statement of direction in the README: the older XML view layer is being replaced rather than extended.

The README also documents desktop builds that reuse the Android interface through shared modules. A JVM and Desktop Compose build of MangaWorld shares its UI with the Android app via :mangaworld:shared, and the same pattern applies to AnimeWorld and NovelWorld:

./gradlew :mangaworld:desktop:run

./gradlew :animeworld:desktop:run

./gradlew :novelworld:desktop:run

What each desktop build supports is listed honestly in the README, and the lists differ. The MangaWorld desktop build works for browsing, search, favourites, manga lists and details, reading chapters in the built-in reader, downloads with a configurable download directory in Platform Settings, and custom lists. The AnimeWorld desktop build covers browsing, search, favourites, episode lists and details, and basic downloads that save the episode stream to disk with a configurable download folder. The NovelWorld desktop build is documented for browsing, search and favourites.

The AnimeWorld desktop build is where the limits show. The README states that in-app video playback is not yet supported, so clicking an episode shows a placeholder screen, and that Chromecast and casting are not supported because both are Android-only for now. A desktop build that can list episodes but not play them is useful for organising and browsing, and it is not a replacement for the phone or TV app.

Sources as pluggable providers: the Mihon and Aniyomi bridges

The apps are clients. The README is explicit that these apps do not contain any sources themselves, while noting that in order to pull sources, the apps do contain some default sources. The practical model is that a source describes where content comes from and how it is parsed, and the app supplies the browsing, reading and playback around it. The repository keeps anime_sources/, manga_sources/ and novel_sources/ directories for this purpose, with source_utilities/ alongside them.

Two integrations matter most. For MangaWorld, installed Mihon extensions are loaded natively: you add a Mihon repo URL in Extensions, and its signing key marks that repo's extensions as trusted. In-app browsing and installing supports both repos that publish the legacy index.min.json format and repos that publish Mihon's newer index_v2 format. That format support is the practical difference between an extension list that loads and one that silently shows nothing.

For AnimeWorld the README says that any sources that work with Aniyomi will work with AnimeWorld, after the bridge is installed. The phrase after the bridge is installed is the important qualifier, since the compatibility is delivered by that bridge rather than by the app itself.

Two cautions belong here. The first is that compatibility with a source ecosystem is a moving target, because a source repository can change its index format or its parsing rules without any change on the app side. The second is the one that matters most for anyone deciding to adopt this: the sources point at third-party content sites, and what those sites are is not something this repository controls. The project ships the reader; the responsibility for what a configured source returns sits with whoever adds it.

Firebase sync, the coming replacement, and a server that only works on a LAN

The shared feature list starts with login to save favourites and watched episodes from device to device, and the favourite mechanism adds alerting when a tracked series updates. Otaku Manager exists to view all favourites across every OtakuWorld application, and it requires a login.

That login currently points at Firebase. The README states plainly that cloud syncing via Firebase is supported right now, but that this will be going away soon, and that an alternative way is being built which requires some manual configuration. The manual configuration path is described in app/readme.md: a server is required, and a basic one has been made that will only work on a local network. The README then asks for help to set up a more solid solution, which is an honest signal about where the project is in this respect.

For a user on a single device or a single household, that is a minor issue. For someone whose library of favourites spans a phone, a TV box and a desktop build, it is a significant one: the sync story is documented as temporary, and the replacement is described as basic and LAN-only. Anyone adopting this now should assume the sync behaviour will change, and should keep local exports or backups of their library if that data has value.

Building locally, the noFirebase variant, and installing the TV app

The README's local build instruction is short. Be sure to change the build variant to a noFirebase variant, and other than that nothing needs to change to run or build locally. That single switch matters because the Firebase dependency is baked into the default variants, and the manual sync path does not use it. The repository also carries local.defaults.properties, buildtypes.gradle and buildSrc/, which is the usual scaffolding for per-build-type configuration.

Installing the TV app is a separate procedure with two branches. The instruction is to download animeworldtv-release.apk, and then either use adb:

adb install animeworldtv-release.apk

or, without adb, follow the steps published by Android Authority. There is no store listing mentioned in the README for this app, so the download is the distribution channel. AnimeWorldTV is available only on Android TV devices, and its feature list adds a built-in video player, favourites synchronised with AnimeWorld, and an opening skipper that the README describes plainly as skipping ahead 90 seconds.

For a developer, the practical entry points are the gradlew tasks for the three desktop modules, the noFirebase variant for local work, and the separate app modules for the Android builds. The repository carries a CHANGELOG.md, a CONTRIBUTING.md, a renovate.json for dependency updates and per-app baseline profile modules, which together describe a project with a real continuous integration setup rather than a hobby script.

Nightly releases on a develop branch, and what that means for stability

The recent releases tell the story. They are nightly builds, tagged nightly_2026_10_16, nightly_2026_10_01 and nightly_2026_09_10, and the README points to a rolling nightly tag for the latest one rather than to a versioned release series. The default branch is develop, not main, and the last push to the repository was on 2026-10-20. The repository is not archived.

That combination is a deliberate choice for an app whose users tolerate rougher edges in exchange for new features, but it changes what a release means. There is no numbered release to pin, no compatibility statement against a particular version, and no changelog entry per build in the way a tagged release would have. What you install is a snapshot of a moving branch, so a bug reported yesterday may already be gone and a bug reported today may be in tomorrow's nightly.

For a user who wants a stable reading app, this argues for installing a nightly and keeping it, rather than reinstalling after every build. For a developer tracking source compatibility, it means any script that pins a version has nothing to pin to. The separation of apps also means the nightly artefacts are per app, so an update to AnimeWorld does not necessarily move MangaWorld, and a user with a mix of apps across devices can find them at different points in the cycle.

Where OtakuWorld is the wrong choice

The clearest wrong-tool case is a single format. If you read manga and nothing else, MangaWorld carries MangaWorld's feature set and not the rest; the shared codebase does not translate into a single binary for everyone. The repository's structure makes this explicit, with separate app modules and separate launcher icons for each product.

The second case is the desktop user who expects to watch. The AnimeWorld desktop build lists in-app video playback as not yet supported and casting as Android-only, so a desktop install covers browsing and downloads but not viewing.

The third case is a sync-dependent setup. Firebase cloud syncing is on its way out and the manual alternative requires a server that only works on a local network, which is workable inside one home network and useless across sites.

The fourth is legal risk in the source configuration, and it deserves to be named rather than glossed over. The apps are source-driven: content comes from sites configured by the user or by a default source the project ships. The project is licensed under Apache-2.0, which covers the code, not the content that a configured source may deliver. Anyone deploying these apps for others, or in a workplace, should check the terms of the sources they point at themselves, since the README does not make any statement about that and the project does not control what those sites serve.

A fifth limit is the ecosystem dependency. MangaWorld relies on Mihon extensions and their repo formats, and AnimeWorld relies on the Aniyomi bridge, so a change in either upstream project can break your setup without anything changing in OtakuWorld itself. That is a real operational cost of choosing a client built on top of other people's extension systems.

Editorial conclusion

OtakuWorld earns a place for Android users who read across manga, anime and novels and want one interface, one favourites store and a desktop build for browsing, provided you are willing to manage sources and accept that Firebase sync is on its way out. It does not fit a single-format reader, a desktop user who expects video playback, or anyone who needs a stable, documented release process, since the published artefacts are nightly builds cut from a develop branch. Verify first that the source repositories you intend to use are reachable and still in the format your app expects, and that the noFirebase build variant runs on your machine before you rely on the manual sync server.

Frequently asked questions

Official sources

1. Issues
2. jakepurple13/OtakuWorld on GitHub
3. License: Apache-2.0
4. README
5. Releases