AniHyou ships an AniList client as a Compose app with a separate beta channel

An unofficial client, and what that word commits the project to

AniHyou describes itself in one line as another unofficial Android AniList client. The word unofficial is doing real work in that sentence. AniList is the tracking service the app talks to, and AniHyou is a community-built front end for it rather than a product shipped by the service operator.

That positioning shapes everything else. There is no company behind the app and no support contract, though a project board does track coming features. The README lists Google Play and F-Droid badges, a Crowdin badge for localization, a donation link, and a Discord invite. What it does not contain is a feature list, a section on how the app talks to AniList, or any note about accounts, caching or offline behaviour.

For a reader deciding whether to install it, that absence is the central fact. You can see what the app looks like from the screenshots image and the Google Play and F-Droid listings, but the repository itself does not narrate what the app does for you. The maintainer points at a GitHub project board for coming features and at a separate AniHyou-iOS repository for the iOS sibling, which tells you the project is a multi-platform effort rather than a one-off Android build.

So the audience is two groups. Android users who want a native tracker and accept a community app, and developers who want to read a Kotlin and Compose codebase for an AniList front end.

The Gradle layout says more than the README does

Since the prose is thin, the repository structure carries the argument. The build is Gradle based with Kotlin DSL: settings.gradle.kts and build.gradle.kts at the root, a gradlew and gradlew.bat wrapper, and a gradle/ directory. A build-logic/ directory holds the convention plugins, which is the modern way to share build configuration across modules rather than copy it.

The application code is split into three source sets that map directly to the top level directories. app/ holds the application module, core/ holds shared code, and feature/ holds feature modules. That layout is the standard answer to a problem Compose applications hit early: a single monolithic module that any change to can rebuild entirely.

Two other directories are worth naming because they change what you can expect from the app. There is a wearos/ module, which indicates a Wear OS target alongside the phone app, and a baselineprofile/ directory, which holds baseline profile work for startup performance. The README does not describe either one, so treat them as signs of work in progress rather than as promises.

Supporting files round out the picture. There is a crowdin.yml for the translation pipeline, a fastlane/ directory for store automation, version.properties and gradle.properties for build configuration, stability_config.conf, and a Gemfile, which suggests some tooling in the release process is Ruby based. A .idea/ directory is checked in as well, which is unusual but harmless.

Releases live in the MoeList repository, not here

The most surprising line in the README is the downloads badge. It points at the releases page of axiel7/MoeList, not at the AniHyou-android repository, even though the tags on this repository are named beta-137, beta-136 and beta-135. The project therefore maintains two related repositories, and the one a user downloads from is MoeList.

That arrangement has a practical consequence. If you follow the badge, you land on a different project's release list, and the artifact you install may have been produced by that project's workflow rather than by the code in the repository you cloned. For anyone pinning a build or writing a script that fetches a specific version, that distinction matters.

The regular distribution channels are the conventional ones for an Android app. The Google Play badge points at the listing for com.axiel7.anihyou, and the F-Droid badge points at the same package identifier in the F-Droid catalogue, which means F-Droid builds the app from source rather than shipping a proprietary artifact.

There is no command line install step in this project, so a new user opens one of these destinations instead:

https://play.google.com/store/apps/details?id=com.axiel7.anihyou
https://f-droid.org/packages/com.axiel7.anihyou

The Play listing gives you the store install. The F-Droid page covers the same package identifier built from source by the F-Droid project, which is the route to take if you would rather not depend on a store account.

For testers, the README gives a third path: latest beta version from nightly.link, pointing at a workflow run on the develop branch. Nightly builds are the fastest way to see unreleased behaviour, and also the least predictable, since they are rebuilt from a branch that changes without a release note.

Beta numbering instead of semantic versions

The recent tags are beta-137 on 2026-10-11, beta-136 on 2026-10-07 and beta-135 on 2026-09-27. There is no stable version in that list, and the numbering has no relationship to a semantic version scheme, which is a deliberate choice for an app that ships to stores continuously.

The dates are more informative than the numbers. Three beta builds over roughly two weeks says the project is moving at a fast clip, and the repository's last push was on 2026-10-20, days after beta-137 was tagged. The app is not archived and it is being worked on.

What the numbering does not tell you is what changed. There is no changelog in the repository listing, no release notes file and no upgrade section in the README, so a user moving from beta-135 to beta-137 has no documented way to learn what was fixed. For an app that can read and write to a tracking account, that is a genuine gap rather than a cosmetic one.

The practical reading is that AniHyou is a rolling beta application. If you want a predictable artifact, take the F-Droid or Play build and accept its cadence. If you want to see the newest work, use the nightly.link build and expect the behaviour to shift under you.

Localization runs through Crowdin, not through pull requests

The Crowdin badge and the crowdin.yml file at the repository root show that translations are managed on the Crowdin platform rather than as a folder of locale resources edited in the repository. That is the common arrangement for open source apps with more than a handful of languages, since Crowdin gives non-technical contributors a place to translate strings without learning the build.

The consequence for a user is that the set of available languages and the freshness of a translation depend on what has been merged on Crowdin, not on what was tagged in the app. A string can change in the Kotlin source and reach a user only after the translation round trip completes. Some strings fall back to the source language in the meantime.

For a developer who wants to contribute a language, the entry point is the Crowdin project linked from the badge rather than the repository itself, which also means a fork cannot easily ship its own translations without carrying its own Crowdin project or hard-coding strings.

The README does not list the supported languages, the default fallback behaviour, or who maintains the Crowdin project. If translation coverage matters to you, that is a question for the Discord server rather than something the repository answers.

Where the documentation stops and the project board takes over

There is an honest limit to what can be said about this project from its own files. The README has no feature documentation, no architecture notes, no network or caching description, and no statement of which AniList API version the app targets. The only forward-looking pointer is a line headed coming features that links to a project board on GitHub.

That is a legitimate way to run a small community app, but it shifts the cost of evaluation to the reader. To judge the app you have to look at the screenshots, at the store listings, and at the board, and to infer from the source layout that the code is organised per feature with shared code in core. Nothing in the repository states which parts of AniList the app covers, so you cannot check a requirement list against a documented capability list.

A second limitation follows from the distribution model. Because Play and F-Droid builds and the nightly.link builds all come from different pipelines, the version you have may not match the tag whose name you remember. A third is the licence and update channel combined: the GPL-3.0 grant and the beta cadence mean a fork is possible, and so is an app that diverges from the official listings.

None of that makes the project unusable. It makes it a project where the documentation is one of the things you will be asking the community about.

Two alternatives, and the difference in how each one ships

The first alternative is the platform sibling. The README links an iOS version at axiel7/AniHyou-iOS, which is the same project aimed at a different platform. The difference in approach is not in the tracking service or the data, which are shared, but in what a user gets on each platform: the Android repository is the one with a published beta channel, a nightly.link workflow and a project board, and the README attaches no equivalent release arrangement to the iOS link. For an Android user the practical comparison is therefore between this app and something else entirely.

The second alternative is the stable build of this same app. If you do not need unreleased features, the Play or F-Droid listing of com.axiel7.anihyou is the better choice, and the difference from a nightly.link build is the entire point of having both channels. The nightly build tracks the develop branch and changes without notice, while the store build is a reviewed artifact.

A third option worth naming is using AniList through the web interface instead of a native app. The trade is straightforward and cuts both ways. The browser needs no installation and no store, and it stays in step with the service by definition. What a native client adds is offline reading of cached lists, platform notifications and a UI built for a phone rather than a desktop viewport, though the README does not document which of those AniHyou actually implements.

GPL-3.0, the maintainer, and what an upgrade costs you

The project is released under GPL-3.0. For an end user the practical effect is that you receive the app under that licence and may inspect and modify its source, and if you redistribute a modified build you must publish your changes under the same terms. It does not restrict ordinary installation, and it places no obligation on you to contribute back.

The project is a single maintainer effort with community help around it. The README carries a donation link through Ko-Fi and lists cryptocurrency addresses for BTC, ETH and LTC, alongside a Discord server for development discussion and a Crowdin project for translation. The iOS repository, the MoeList repository and the Play and F-Droid listings all sit under the same owner, which makes the app easy to follow and equally dependent on one person.

Upgrading is where the beta cadence costs something. There is no changelog to read and no upgrade note to check, so moving between beta numbers means re-testing whatever you relied on. The F-Droid route has an advantage here, since a catalogue build is rebuilt from a tagged source rather than from a shifting branch.

The repository was last pushed on 2026-10-20 and is not archived, and the recent beta tags fall in September and October 2026. That tells you the pace of the work, but it does not tell you what any given build changes, which is the piece the project still owes its users.

Editorial conclusion

AniHyou suits Android users who want a native client for AniList and who are comfortable tracking a community-maintained app whose releases move in beta numbers rather than stable versions. It is the wrong choice if you need documented feature coverage, if you want a release cadence you can plan around, or if you cannot accept an app distributed under GPL-3.0 with translation pulled from a hosted service. Verify first which artifact you are actually installing, since the download badge points at the axiel7/MoeList releases while the app itself is also listed on Google Play and F-Droid, then read the project board linked as coming features to see what the maintainer is planning next.

Frequently asked questions

Official sources

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