# Nekome is a Compose Android tracker that keeps its list on Kitsu, not on the phone

> Nekome is a Kotlin Android application for tracking anime and manga progress, storing everything through the Kitsu API. It ships on F-Droid and Google Play, uses MVVM with Hilt and Compose, and its releases stopped in August 2024 while the master branch kept moving.

**Chesire/Nekome** — Nekome is an Android application to manage tracked Anime and Manga lists.

- Repository: https://github.com/Chesire/Nekome
- Stars: 522 · Forks: 48
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/chesire-nekome

## The list is a Kitsu account, and that changes what the app is

Nekome is an Android application that helps with tracking your anime and manga watch lists. The important detail is in the second sentence: watch list data is handled by Kitsu, and all of it is accessed through the Kitsu API.

That single decision defines what this app is and is not. It is not a local database with a sync service bolted on. The list, the progress markers, the series metadata, all of it lives in your Kitsu account, and the app is a client for that service. The advantages follow from that. Your list follows you when you switch phones, it is shared with whatever else already talks to Kitsu, and there is no account system of Nekome's own to register for, reset, or lose.

The costs follow from it too. You need a Kitsu account. If the service disappears, your list goes with it, and unlike a local SQLite file you cannot just open the database. And Nekome's feature set is bounded by what the Kitsu API exposes, which is why the feature list is short: track anime and manga series progress, quickly update progress on series, search for new series to follow, and light and dark themes.

For most people, that is the whole job of a tracker, and the fact that a full-featured alternative already integrates with the same service makes that choice uncontroversial. The interesting question for an engineer is not whether a tracker app is useful but how this particular one is built.

## A Compose, MVVM, Hilt stack assembled from current Jetpack pieces

The tech stack list is specific enough to read like a manifest of the choices the author made, and every item is a mainstream Android library rather than something unusual.

The app supports Android 5.0 and newer, which is SDK 21 and above, and is fully Kotlin. The architecture is MVVM, the UI layer is Compose, and Material3 is supported for dynamic themes using Material 3. Dependency injection is Hilt, Retrofit aids with API communication, Moshi parses the JSON, Coroutines perform the async tasks, and Coil handles async image loading.

The choice of Retrofit plus Moshi over a single hand-rolled HTTP client is the one worth commenting on, because it is the part that has to track a third-party API. Retrofit gives typed endpoints and an OkHttp underneath, and Moshi gives Kotlin-aware JSON binding without reflection. Together they make the Kitsu integration a small, well-typed surface rather than a scattering of string keys. It also means the Kitsu API contract is expressed in code that the compiler checks, which matters when the upstream API can change without notice.

The Kitsu API is consumed through its documented HTTP API, and the README links to the API documentation, so the contract is a public, versioned interface rather than a private one. That is a meaningful difference for a client app, since a public API has a stability expectation attached to it.

Coil is worth a brief mention because it is easy to overlook. Anime trackers are image-heavy: every entry has a cover, and a list of forty entries means forty cover images. Coil handles that fetching and caching asynchronously so the list scrolls without waiting on the network, which is the difference between a tracker that feels like a native app and one that feels like a web page in a wrapper.

## The module layout says this is a multi-app project

The top-level repository entries are worth reading closely, because they reveal a structure bigger than a single app module.

There is an app/ directory, which is the Android application itself. There is a core/ directory, which in this layout is the shared foundation that the app and any other consumer would use. There is a features/ directory, which is the modern Gradle convention for splitting an app by feature rather than by layer, one Gradle module per user-facing area. There is a libraries/ directory for third-party or shared library modules, a config/ directory for Gradle configuration such as convention plugins, and a testing/ directory for shared test utilities.

That set of directories is the giveaway. A single-screen app does not need core, features, libraries, config and testing as separate top-level entries. A project that has a reusable core, a set of feature modules and a shared library set is structured to be consumed by more than one application, or to keep the build fast enough that a change in one area does not force a rebuild of everything.

There is also a fastlane/ directory, and the README's screenshot markup points into it at fastlane/metadata/android/en-GB/images/phoneScreenshots/. Fastlane is the standard toolchain for store submission automation, and keeping the store listing metadata inside fastlane rather than in a separate folder means the screenshots and the release metadata live next to the build configuration and travel together. The en-GB locale in that path tells you the app ships at least one localised store listing in British English.

The build itself is Gradle, with build.gradle.kts, settings.gradle.kts, gradle.properties, a gradle/ directory and the gradlew and gradlew.bat wrappers, so the Kotlin DSL is used and the wrapper means a checkout builds without a system Gradle installation. The .idea/ directory is committed too, which tells you the project is developed in IntelliJ IDEA.

## Continuous integration, coverage and a static analysis setup

The badge set at the top of the project describes a continuous integration setup with more than one service.

There is a GitHub Actions workflow named Master with a build badge, a Bitrise build status badge, and a codecov badge pointing at the master branch. Two CI providers running alongside each other is slightly unusual, and it is usually because one is the canonical build and the other is doing something additional, such as store submission. There is a Dangerfile at the top level, which is the Swift library used to add checks and required review steps to pull requests, so the project enforces some conventions on incoming changes.

The codecov badge and the codecov.yml configuration file mean coverage is measured and reported, and the .coveragerc-adjacent tooling in this ecosystem usually means there is a coverage threshold that the build enforces rather than a number nobody reads. Combined with the Detekt and ktlint entries in the tech stack, the project treats static analysis as a build gate: Detekt for Kotlin-specific code smells and ktlint for formatting.

That combination is the part a contributor notices first. ktlint enforces formatting rather than leaving it to taste, so a pull request with different spacing gets rewritten by the linter rather than debated in review. Detekt catches the things that are not style but are still smells, like overly complex functions or long parameter lists. For a small hobby-scale project, having both wired in is a statement that the codebase is meant to be read and modified by people other than the author.

The Gradle wrapper and the .github/ directory with a workflow named Master complete the picture, and the presence of gradlew.bat means the build is expected to work on Windows as well as on a Unix-like system.

## Where to get it, and what the release history says

Nekome is distributed the normal way for an Android app, and it carries two store badges.

The first is a F-Droid badge linking to the F-Droid package com.chesire.nekome, and the second is a Google Play badge for the same application id. The F-Droid presence is the notable one from a reviewer's point of view, because F-Droid only lists free and open source software and builds from the source in the repository, which means a user can obtain and audit the exact code that is described here. For a tracker that talks to a third-party API, having a build provenance story is worth something.

The version history is where the caveats start. The recent releases are 2.2.3 on 2024-08-15, 2.2.2 on 2024-01-23 and 2.2.1 on 2024-01-20. The last push to the repository was on 2026-10-10, on the master branch.

So the tree is being worked on, and the published versions stopped in August 2024. That gap has a practical consequence: the version you install from either store is roughly two years older than the code on master, and a user who clones the repository and reads the source may see behaviour that differs from what the shipped app does. It also means the F-Droid build, which is made from the repository, and the Play Store build may not be the same code.

The two stores also differ in one practical way worth knowing: F-Droid updates lag by its own build cycle, so even when a new tag exists it is not available the same day.

The privacy angle is handled explicitly. The repository contains a privacypolicy.md file and the top-level entries show a fastlane metadata tree, so the store listing and the policy are part of the project rather than an afterthought. For an app that sends your viewing activity to a third-party service, reading that document before you install is the sensible first step.

## Where Nekome is the wrong tool

The first wrong-tool case is a user who wants their list to live on their own device. Because the watch list data is handled by Kitsu, Nekome is not usable without a Kitsu account and the list is not stored locally in any meaningful way. A tracker that keeps its data in a local file, with optional export, behaves differently when the network is unavailable and does not tie your history to somebody else's account.

The second case is a user who needs a feature set beyond the four listed. Track progress, update progress quickly, search for new series to follow, and themes. There is no mention of statistics, recommendations, user scores, sync between devices beyond the account, import or export, or lists other than anime and manga. If you want a tracker with a dashboard of what you watched this year, this is not it, and no amount of configuration will add that.

The third case is a team that needs a maintained app with a support commitment. The 2024-to-2026 gap in releases, with the master branch still active, describes a project where a single maintainer is working but the shipping artifact has stopped moving. The Apache 2.0 licence means you can fork it, and the Kotlin and Compose stack means a fork is a realistic option for a team willing to own it, which is often the honest answer to a stalled app.

The alternative approach is the Kitsu-integrated apps that already exist in the stores. The difference in approach is that they compete on the same backend, so the difference is in the client: Nekome's is a Compose, Material 3, Hilt, Retrofit and Moshi build with a modular core and features layout, and the alternatives may be built on Views and XML, or may be the original application for the service. If you want a maintained app with a broader feature set, take one of those and accept its UI stack. If you want a small, modern, auditable client you can fork, Nekome is the better shape.

## Conclusion

Nekome suits an Android user who already has a Kitsu account and wants an open-source list app with a Compose interface, available outside the Play Store through F-Droid. It does not suit someone who wants their tracking data held locally on the device, because the list lives in the Kitsu account, and it does not suit a team that needs a maintained release cadence, since the last tagged version is 2.2.3 from 2024-08-15 while the last push to master was on 2026-10-10. Before adopting, create a Kitsu account and confirm the app version you install from F-Droid matches the release you expect, and check the privacy policy document in the repository for what the app sends to the service.

## FAQ

### Where does Nekome store my anime and manga list?

In your Kitsu account. The README states that watch list data is handled by Kitsu, with all information accessed through the Kitsu API, so you need a Kitsu account and the list follows that account rather than the device.

### How do I install Nekome?

It is published on F-Droid as com.chesire.nekome and on Google Play under the same application id. F-Droid builds from the source in the repository, so the installable code matches the project.

### What are the minimum Android version and UI toolkit for Nekome?

It supports Android 5.0 and newer, which is SDK 21 and above, is fully Kotlin, and uses Jetpack Compose for the UI layer with Material 3 support for dynamic themes.

### What libraries does Nekome use for networking and dependency injection?

Retrofit for API communication, Moshi for parsing JSON, Hilt for dependency injection, Coroutines for async tasks and Coil for async image loading. Detekt and ktlint are used for static analysis.

## Sources

- [Chesire/Nekome on GitHub](https://github.com/Chesire/Nekome)
- [Issues](https://github.com/Chesire/Nekome/issues)
- [License: Apache-2.0](https://github.com/Chesire/Nekome/blob/master/LICENSE)
- [README](https://github.com/Chesire/Nekome/blob/master/README.md)
- [Releases](https://github.com/Chesire/Nekome/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chesire-nekome