Tasks publishes release-signature fingerprints for four channels, and still ships a Pebble app

The largest section is a set of hashes with no version attached

Most of this README is about verifying that what you downloaded is what was published, which is the most useful thing a small Android project can put in its front page.

Four channels are covered. The Google Play channel is identified by its package name and by a release artefact on the repository, and it carries two digests, a SHA-256 and a SHA-1. The F-Droid channel carries the same pair. The macOS channel is identified by a zip artefact and by an Apple team identifier, and it carries one digest, a SHA-256. The Linux repository is verified differently again, with an OpenPGP key fingerprint and a URL to fetch the public key from.

None of these values carries a version number; the README presents them under the heading Verifying release signatures, and the most recent release is 15.13.

Two things are called F-Droid and only one of them is

The header links to a listing on the F-Droid repository, and the release verification section names a different artefact with F-Droid in its filename.

The section heading is explicit about the distinction. The F-Droid artefact is a package on the project's own releases, and the text italicises the words not official F-Droid release. So the APK named for F-Droid in the release list is built by the project, signed by the project, and verified against the project's own digest.

That is not a criticism. Building your own package for a distribution channel you do not control is a normal thing to do, and a project that publishes a digest for it is doing the right thing. The confusion is entirely in the naming, because a reader who sees F-Droid in a filename next to an F-Droid badge in the header has no way to know there are two supply chains without reading the italic.

The naming convention otherwise is consistent and worth noting, because it is what makes the section usable. Each channel has a filename pattern: one pattern for the Google Play builds, one for the self-built F-Droid packages, and a third with both a project prefix and a mac segment in it. The same pattern style is used in the tree, where six dependency snapshot files are named after the variant they describe.

Two archived changelogs named for version ranges

The change history in this repository is three files, and two of them are named after the versions they cover rather than after their own contents.

There is a current change log, and beside it are two files whose names end in a change log suffix and begin with a version and a joining character: one covering a 06 to 09 range and one covering 10 to 12. Those look like major version ranges rather than dates.

Which is which is a reasonable guess rather than a stated fact. What is clear is the shape: one rolling file for what is current, and two frozen files for history that has been closed out. That is a better arrangement than one enormous log nobody reads, and it means the current file stays a size a person will actually open.

The release numbers support the same reading. The recent releases are 15.13-beta02 on 2026-10-08, 15.13-beta03 on 2026-10-13 and 15.13 on 2026-10-14, so the project is on a two-number version scheme with beta builds ahead of a release.

The second number does not track the calendar month: the current release is 15.13, published in October 2026.

Six dependency snapshot files, one per distribution variant

The root of this repository contains a set of plain text files whose names are all of one shape, and there are six of them.

Each is named for a variant rather than for a package, and each variant appears to be a distribution channel. There is one for a desktop build of the shared application module and one each for the two Android channels, then separate files for the two Android variants and one for the watch module. Beside them sits a file for tracking dependency differences between them.

That is a specific engineering choice. A single codebase that ships five or six differently-configured builds needs to know what each build actually pulls in, and a committed snapshot per variant is the cheap way to do it: a diff in continuous integration shows a dependency that appeared in the desktop build and not in the store build, which is the kind of thing that silently changes what you ship.

It also means the dependency surface of the project is legible without running anything. Six files, each a list, and the fact that the desktop and the two Android channels differ is the interesting part.

Dependency updates are automated separately, through a configuration file at the root, and the Gradle setup is described by a wrapper script with its Windows counterpart, a properties file for versions, and two build scripts in the Kotlin DSL. The other generator at the root is a shell script for a compose metrics module, and there is a Python script for generating material symbols, which is the icon set.

The project began as a product that was bought and switched off

The project's origin is stated in the first paragraph, and it is the reason the repository exists in its current form.

Astrid was a cross-platform productivity service. It was acquired, and then discontinued in 2013, and both facts are supported by links: one to an archived copy of the company's own announcement and one to a technology news article about the service going dark. The repository description says the same thing more bluntly, describing the project as bringing Astrid Tasks back from the dead.

What was actually inherited is narrower than the original service. The source that forms the basis of this project is the open-source Android app, not a client for a hosted service. So the modern Tasks descends from a component of a discontinued hosted product.

That distinction is the most useful thing in the origin story. The tree holds an app/ module, a composeApp/ module with desktop dependency snapshots, an iosApp/ directory, and wear/ and pebble/ directories.

The desktop build is the one piece of that list the project itself qualifies, labelling the download link as alpha.

A watch app is still shipped for hardware whose original store closed

One of the distribution links in the README is for a watch, and the two stores it points at are community replacements.

There is a Rebble store and a Repebble store, and both are listed as the way to get the Pebble build. The original store for that hardware is not among the links, which is the point: the project maintains a target for a device whose first-party distribution channel no longer exists, and it does so through two separate community efforts rather than one.

The tree has a separate pebble/ directory for this build, alongside wear/ and wear-datalayer/ directories for a second watch target.

There is also a Ruby version file and a locked Ruby dependency set at the root, next to a fastlane/ directory, in a project whose application code is in Kotlin.

Translation is handled off the repository, through a hosted localisation service, and the project carries a mail map file for contributor names, which is a small signal about the size of the contributor base.

Three donation processors and a support split across three places

The closing part of the README is about money and about where to ask questions, and both are more thorough than most projects of this size manage.

Three donation routes are listed. There is a donation page on the project's own domain, a direct payment link handled by a well-known online payment processor with the author's own address as the payee, and a third processor with a per-project page.

Support is split by kind rather than funnelled into one place. End-user questions go to the project's site, which also carries the support promise. Questions go to the repository's discussions area. Bug reports and feature suggestions go through the contributing guide instead, which is a deliberate separation between a user and a potential contributor.

The project domain is written as a plain http address in the recorded homepage, while every internal link in the README uses https. That is a small inconsistency, and it is the kind that matters more than it looks: a user who types the domain from memory gets an unencrypted first request before any redirect.

The licence is GPL version 3, with a code of conduct and a contributing guide at the root, and the history of the project is documented rather than implied.

Editorial conclusion

Tasks is worth a look if you want a to-do list with apps for Android, desktop and watches, and it comes from a project that publishes verification material for every channel it ships on, which is rarer than it should be. Three things to check first. The release-signature values in the README carry no version number. The package labelled for F-Droid in the release list is built by the project and is explicitly not the official F-Droid build, so there are two artefacts under one name. And the desktop build is described as alpha in the project's own link text, while the Android app is the one with a stable release cadence.

Frequently asked questions

Official sources

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