Tasks (tasks/tasks): the Astrid successor, rebuilt for Android and Compose

What Tasks is, and the Astrid history behind it

Tasks exists because Astrid was shut down. The README states that Astrid was a cross-platform productivity service that was acquired and discontinued in 2013, and that the source code from Astrid's open source Android app serves as the basis of Tasks. That sentence is the whole origin story the repository gives. The project is not a rewrite of Astrid's backend; it is a continuation of the client codebase, which is why the package name is org.tasks and why the app still carries the Astrid lineage.

The audience is narrower than the Astrid pitch was. This is an Android-first task manager, distributed through Google Play and F-Droid, with a desktop build explicitly marked alpha and a Pebble companion app listed through the Rebble and Repebble stores. The repository is written in Kotlin, uses Compose Multiplatform as a topic, and the top level contains separate source sets for composeApp, wear, pebble, iosApp and kmp. If you are looking for a web service or a hosted sync product, nothing here describes one. The README sends end users to tasks.org for documentation and support.

How the repository is laid out and what that implies

The top level is a multi-target Gradle build, not a single Android module. There is app/ for the Android application, composeApp/ for the Compose Multiplatform side, wear/ and wear-datalayer/ for Wear OS, pebble/ for the Pebble companion, iosApp/ for an iOS target, and kmp/ for shared Kotlin Multiplatform code. Alongside those sit cert4android/, data/, libs/, graphics/ and compose-metrics/, plus a generate_compose_metrics.sh script and a generate_material_symbols.py script that suggest the UI layer is partially generated or measured rather than entirely hand written.

The dependency story is split by distribution channel. The repository root carries deps_composeApp_desktop.txt, deps_composeApp_fdroid.txt, deps_composeApp_googleplay.txt, deps_fdroid.txt, deps_googleplay.txt and deps_wear.txt. That is six dependency manifests, which tells you the project treats each build flavor as a distinct artifact with its own dependency surface. It also means a bug report is only useful if it names the flavor. A build problem on the googleplay variant and the same problem on fdroid are not the same bug, and the repository layout makes that explicit.

CONTENT_PROVIDER.md at the root is worth noting for anyone integrating with the app rather than using it. The project documents a content provider, which is the Android mechanism other apps use to read and write data. The README does not summarize that document, so the file itself is the source to read.

Installing Tasks and a first real use

The README offers the Play and F-Droid badges as the primary install paths, with the desktop build at tasks.org/download marked alpha. It gives no source build tutorial and no build commands; it points to CONTRIBUTING.md for suggestions and bug reports, and to tasks.org for end user documentation and support. So the only install instructions the README actually publishes are the distribution channels and the signing material.

For Linux desktop users, the README lists an apt repository at update.tasks.org and publishes the public key at https://update.tasks.org/keys.asc. It gives the fingerprint rather than an import command, so the check is a manual one:

The published fingerprint is 224F A88A 5A19 A03B 0682 7A1B F60C E212 7D6B BBDE. Compare it against the key you fetched from keys.asc. If it does not match, stop. The README also publishes SHA-256 and SHA-1 values for the Google Play APK, the F-Droid APK on GitHub Releases and the macOS zip, which is the check to run on any artifact you download from GitHub Releases rather than from a store.

A first real use is unremarkable by design: install the app, create a task list, add a task, and set a due date. The interesting part is not the first task, it is the account and sync configuration, which the README does not document and defers to tasks.org.

Release signing is the most concrete thing in the README

Most project READMEs list features. This one lists fingerprints. There are four signing blocks: the Google Play APK, the F-Droid APK, the macOS zip, and the Linux apt repository. Each carries SHA-256 values, and the macOS entry adds a Team ID of 447244PVXH.

The detail that matters is a parenthetical in the F-Droid heading. The F-Droid APK published on GitHub Releases is, in the README's own words, not the official F-Droid release. So there are two distinct F-Droid artifacts in circulation: the one built and signed by the F-Droid infrastructure, and the one attached to GitHub Releases with the fingerprint 5E:FD:4E:D0:BA:CC:BF:D3:C1:17:98:7E:BE:AC:34:CF:60:1D:08:31:EC:4B:B3:E5:97:46:77:42:13:05:69:FD. If you install through the F-Droid client, you get the first. If you sideload from GitHub, you get the second. They will not share a signature, so switching between them is not a normal upgrade path.

This is a genuinely useful piece of documentation and it is also a maintenance burden. Four signing identities across four distribution channels means four places to rotate keys and four fingerprint blocks to update. The README does not describe a key rotation policy, and it does not say what happens if a key is compromised. That silence is the gap.

Where Tasks is the wrong tool

The desktop build is labelled alpha in the README's own text. If your workflow depends on a desktop client, that label is the answer to whether you should plan around it. An alpha designation on the download page means the project is not making a stability commitment, and nothing in the repository contradicts that.

The bigger gap is sync. Astrid was a service; Tasks is a client. The README describes installation, distribution, signing and communication channels, and it points to tasks.org for end user documentation and support. It does not describe a sync backend the project operates, and it does not describe account setup. If you need a task manager where the vendor hosts your data, this repository does not present itself as that, and you should read tasks.org before assuming otherwise.

The third case is iOS. There is an iosApp/ directory in the repository, but the README lists only Play, F-Droid, the desktop alpha and Pebble as distribution. A directory in a repository is not a shipped product, and the README does not claim one. Treat the iOS target as source code that exists, not as an app you can install.

Comparing Tasks with a plain calendar-based task list

The obvious alternative for many people is the task list built into whatever calendar or mail suite they already use. The difference is architectural rather than cosmetic. A calendar-integrated task list lives inside another product's data model, and its features are bounded by that product's release cycle. Tasks is a standalone GPL-3.0 application with its own content provider, documented in CONTENT_PROVIDER.md, which means other Android apps can integrate with it directly rather than through a vendor API.

The trade-off runs the other way too. A standalone client gives you control over the client and nothing else. If the sync service you point it at disappears, the client survives but your data does not, which is precisely the failure mode Astrid users experienced in 2013. That history is in the README, and it is the reason the GPL-3.0 licence and the published source matter here: the code outlived the service once already.

A second alternative is a plain text task file managed by an editor plugin. That gives you portability and no vendor at all, at the cost of the Android integration, the Wear OS and Pebble companions, and the multi-flavor build structure that makes this project useful on a phone. The two approaches solve different problems.

Licence, maintenance and upgrade cost

Tasks is GPL-3.0. The practical consequence is that anyone distributing a modified binary has to make the corresponding source available under the same terms. For an end user installing from Play or F-Droid, the licence changes nothing about daily use. For someone forking the app for internal distribution, it shapes what you can ship and what you must publish. This is a description of the licence, not legal advice; read LICENSE for the actual terms.

The last push to the repository was on 2026-09-22, and the most recent release listed is 15.12 from 2026-09-15, preceded by 15.11 on 2026-09-10 and 15.10 on 2026-08-29. Three releases in roughly a month is a fast cadence, and it has a cost: upgrade churn. The repository carries version.properties and a CHANGELOG.md, plus archived changelogs V06_09_CHANGELOG.md and V10_12_CHANGELOG.md, so the project does keep a written record across major eras.

There is also a renovate.json at the root, which indicates automated dependency updates. Combined with the six per-flavor dependency manifests, that means dependency bumps arrive frequently and have to be validated against each flavor separately. If you build from source, budget for that. If you install from a store, the cost lands on the maintainers instead.

Editorial conclusion

Adopt Tasks if you want a GPL-3.0 Android task client with a working F-Droid or Play build and a desktop alpha you can tolerate, and if you are willing to verify the release signature before installing. Do not adopt it if you need a stable desktop product or a hosted sync service the project itself operates; the README points to tasks.org for end user documentation and the desktop track is labelled alpha. Before installing, check the SHA-256 fingerprint for the artifact you downloaded against the value in the README, and confirm which repository the package came from, because the F-Droid APK on GitHub Releases is not the official F-Droid release.

Frequently asked questions

Official sources

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