Jerboa is the native Android client for Lemmy, and its README promises very little

A native client for a federated aggregator

Jerboa is described as an Android client for Lemmy, a federated reddit alternative. Both halves of that sentence matter.

Lemmy is a federated link aggregator, which means an instance is not a single database you sign up for. Your account lives on an instance, and the instance exchanges posts and comments with other instances over the ActivityPub protocol, and the repository topics list activitypub and link-aggregator alongside android and mobile-app. A client for such a service is not talking to one server with one schema; it is talking to a server whose peers each have their own state, and the protocol vocabulary is visible in the app's own domain model.

The other half is native. Jerboa is built using the native Android toolkit and Jetpack Compose, which is a deliberate choice over a web wrapper. The built-with list names Android Jetpack Compose, Kotlin and Retrofit, and the repository has a compose_compiler_config.conf at the root and a Compose-era application under app/, along with a benchmarks/ directory and fastlane/ metadata with phone screenshots for the stores.

Retrofit as the HTTP layer is the part that connects the client to the API, and it is the same API a browser client would call, which is why the app can be replaced or supplemented without losing anything except the native interface.

The project is organised under the LemmyNet organisation, and the README describes it as made by Lemmy's developers, with the promise that it is free, open-source software meaning no advertising, no monetising and no venture capital, ever. Jerboa and Lemmy are made possible by a generous grant from the NLnet foundation, and donations are accepted through Liberapay, Ko-fi, OpenCollective and Patreon, with cryptocurrency addresses listed for bitcoin, ethereum and monero.

The feature list is one line, which is its own kind of information

Under Features, the README lists exactly one thing.

Open-source, AGPL License.

That is not an oversight in the sense of a neglected section, and it is not a marketing decision either. It is the honest state of a project whose documentation lives elsewhere and whose scope is a client for an API that another project defines. The interesting material is not in the feature list, it is in the surrounding infrastructure, and in what the README says about who has time to work on it.

The note under the About section is the sentence that should shape any evaluation.

You can submit issues, but between Lemmy and lemmy-ui, the developers probably won't have too much time to work on them. You can learn Jetpack Compose and contribute if you want to help make this app better.

That is a maintainer-capacity warning delivered plainly. The same people are responsible for the server, the web client and this app, so issue response time is bounded by that, and the route the README offers is contribution rather than support. It also tells you what the project wants from outside contributors, which is Compose experience, since the entire UI is declarative.

For a reader, the sensible interpretation is that Jerboa is a well-scoped native client maintained alongside a larger stack, not a product with a support organisation behind it. The screenshots show the interface, the docs site is not linked from the README, and the code is the documentation.

Four distribution channels and a version number that has not reached 1.0

Installation is offered through four channels, which is generous coverage for a client of this size.

The Releases page on GitHub is listed first, and the README also links RELEASES.md in the repository. Then there is IzzyOnDroid, the F-Droid index entry and the F-Droid listing, both under the package id com.jerboa, then Google Play under the same id, and finally a badge pointing at the latest GitHub release for a direct APK download.

The version numbers tell their own story. The recent releases are 0.0.88 on 2026-07-21, 0.0.87 on 2026-05-01 and 0.0.86 on 2026-04-23. Every recent release is still below 0.1, and the gaps between them range from days to a couple of months. That is a project that ships continuously and has not yet declared its API stable, which is a normal position for an Android client and also means you should expect behavioural changes between versions.

The build is a standard Gradle project, with build.gradle.kts at the root, settings.gradle.kts, gradle.properties, the gradlew and gradlew.bat wrappers and a gradle/ directory. The repository also has an app/ module, a.run/ directory for IDE run configurations, and a scripts/ directory.

Two files are worth a reader's attention for the release process rather than the code. cliff.toml is a configuration file for release tooling, and the README also links RELEASES.md in the repository. And fastlane/ holds the store metadata, including the android/en-US images that appear as the screenshots in the README's own comparison table.

Woodpecker, Weblate and Renovate do the boring work

The badge row at the top of the README shows a project with its infrastructure in place.

The build status badge points at Woodpecker, hosted at join-lemmy.org, so the CI is self-hosted on the project's own infrastructure rather than on a commercial service. The translation status badge points at Weblate, also under join-lemmy.org, with a project page for lemmy/jerboa. And there is a renovate.json in the repository root, which is the configuration for Renovate, the dependency update bot.

That trio is the standard shape for a federated, community-run project. The instance runs its own CI so that a build depends on the community's own infrastructure, translations are handled by a dedicated tool rather than by pull requests, and dependency updates arrive as automated pull requests that a maintainer merges.

The self-hosting is a design choice with consequences. It means the project controls its own build pipeline and is not exposed to a commercial CI provider's pricing or policies, and it also means the pipeline's availability is the community's problem to solve. The Weblate arrangement matters for a client whose users are, by definition, distributed across instances and languages, since a translation platform with a web interface is a better fit than editing YAML files by hand.

The .github/ directory and the .woodpecker.yml file at the root cover the rest of the workflow, and CONTRIBUTING.md is the entry point for a new contributor, which matters given the README's invitation to learn Compose and help.

AGPL-3.0 is the licence to read carefully before you redistribute it

The licence is AGPL-3.0, with the LICENSE file at the repository root and the README stating it under Features as well. The repository metadata agrees.

For a client application, the AGPL is a stronger obligation than the MIT that many client projects use, and it is worth being precise about what that means for the people who might redistribute it. The AGPL's network clause is the part that usually raises questions, and the practical effect for anyone shipping a modified build as a service is that the source of the modified version has to be offered to the users of that service. This is a licensing fact rather than legal advice, and the details depend on how a given distribution is offered.

The distribution channels listed in the README are therefore worth a look by anyone thinking of shipping a fork inside a product or a service: F-Droid, IzzyOnDroid, Google Play and the GitHub release assets are four different distribution contexts, and each has its own expectations about what a licence permits. The question that matters in practice is whether your use is personal or whether you are offering the app, or a modified version of it, to users as part of something you operate.

The project itself is unambiguous about the intent. It is made by Lemmy's developers and is described as free, open-source software, meaning no advertising, no monetising and no venture capital, ever, with donations going directly to full-time development. The NLnet grant is named as the thing that makes both Jerboa and Lemmy possible, and the funding links are the README's main ask.

The icons are credited separately, made by Freepik from flaticon.com, which is the kind of detail worth checking if you plan to reuse the assets rather than the app.

The alternative is the web client, and it explains the project's own limits

The realistic alternative to Jerboa is lemmy-ui in a browser, and that comparison is not hypothetical because the same developers work on both, which the README says outright when it explains why there is little time for issues.

The difference in approach is the interface. A browser client needs no installation, updates itself, and runs on any device with a browser, and it can be bookmarked or added to a home screen. A native Compose app gives you the platform's own widgets, the system's gestures, the notification shade and the accessibility services, and it can be faster and more responsive in a scrolling feed, at the cost of a download, a store listing and an update cycle you do not control.

The counter-argument is the one this project itself makes. The team that maintains the client is the team that maintains the server and the web front end, and their time is finite. A native client that competes for the same attention as the web client can only be as good as the spare capacity behind it, and the README is unusually candid about that rather than pretending otherwise.

For a reader, the practical comparison is short. If you want Lemmy on your phone today with no friction, the web client is the path of least resistance. If you want a native app and are willing to install from F-Droid, IzzyOnDroid or a GitHub release, Jerboa is the open-source option, licensed AGPL, built with Compose and Retrofit, and shipping roughly every few weeks under a 0.0.x version number.

What you give up by choosing the native client is the immediacy of the web path. What you gain is an application that talks to the same API with the platform's own conventions, and a codebase you can read and, if you learn Compose, contribute to.

Editorial conclusion

Jerboa fits a Lemmy user on Android who wants a native application with the platform's own look and feel rather than a browser tab, and who is comfortable with a pre-1.0 version number. It does not fit someone who needs the maintainers to respond quickly to an issue, since the README states plainly that time is limited and points new contributors at learning Jetpack Compose. Before adopting it, install from F-Droid or the GitHub releases rather than relying on the Play build, and check the app's behaviour on your instance, because the client is versioned independently of the server it talks to.

Frequently asked questions

Official sources

1. Issues
2. LemmyNet/jerboa on GitHub
3. License: AGPL-3.0
4. README
5. Releases