# Grit: a todo and habit tracker for Android that also builds for desktop and the web

> Grit is a Kotlin and Jetpack Compose todo list and habit tracker that is published on Google Play, built from a shared module with Android, desktop and web targets, and the web build uses Compose Multiplatform with Kotlin wasm. It is GPL-3.0 licensed, crowdsourced for translation through Weblate, and its roadmap still points at social features rather than at the core tracker.

**shub39/Grit** — 🔨 A Simple todo list and habit tracker for Android 

- Repository: https://github.com/shub39/Grit
- Stars: 1,207 · Forks: 83
- Language: Kotlin
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/shub39-grit

## One app, three targets, one shared module

The repository layout is the clearest description of what Grit is, and it is a modern Android project structure rather than a single-module app.

There is an androidApp/ directory, a desktopApp/ directory and a shared/ directory at the root, alongside the Gradle files. The shared module holds the code the three targets have in common, and the app modules are thin shells around it.

The build files are Kotlin DSL, build.gradle.kts and settings.gradle.kts, with a gradle.properties, a gradle/ directory, and the gradlew and gradlew.bat wrappers. There is also a spotless/ directory, so the code formatting is enforced by Spotless rather than left to individual contributors.

The web target is the part that is unusual for an Android app. The README lists Compose Multiplatform and Kotlin wasm for the Web Demo among the technologies used, and the screenshots section is split between Phone and Tablets and Desktop, with the latter showing four more images.

That combination has a real consequence. A pure Android app can be built and run with nothing but the Android SDK and a JDK. A Compose Multiplatform project with a Kotlin wasm target needs a toolchain that can compile to WebAssembly, and that toolchain moves faster than the Android SDK does. The multiplatform reach is the most valuable thing about the project and also the most likely thing to break under you, because the web build depends on parts of the Kotlin ecosystem that are still settling.

The Android side is the primary target, with the fastlane/ directory holding the Play Store metadata and the screenshots used in the listings.

## A habit tracker and a todo list in one app

The project description is a simple todo list and habit tracker for Android, and the topic list names the feature areas: android-application, habit-tracking, todolist, notifications, material-ui.

The motivation section explains the choice in the author's own terms. There are plenty of todo list and habit tracker apps for Android. Some have the features the author loves while some have good UI design. While learning Android the author made this app for themselves, bringing together all the features that are liked while keeping everything simple. The stated long-term goal is to turn it into a productivity hub with many social features like progress sharing in the form of beautiful cards.

That motivation is worth reading carefully as a signal about the project. It is a personal app built while learning Android, with a social vision attached. That explains a lot about the shape: the feature set is deliberately the union of what the author liked in other apps, the design is first, and the social features are the growth plan rather than the current state.

It also sets expectations about the data model. Nothing in the README describes accounts, sync or a server. The screenshots come from the fastlane metadata, phoneScreenshots and featureGraphic, and the Play Store listing is at the package name com.shub39.grit. So the app as it stands is a local-first, single-device tracker, and the social ambition is something to be built rather than something to import.

The inspiration list is specific and worth reading for anyone choosing a habit tracker: Loop Habit Tracker, uhabits, is named first, followed by Compose Reorderable, MaterialKolor, ColorPicker Compose, Compose Calendar and the RevenueCat Android SDK.

## The library list is the design brief

The README's inspiration and technology section names the projects Grit is built on, and together they describe what the app does.

Kotlin and Jetpack Compose are the base. Compose Multiplatform and Kotlin wasm for the Web Demo is what produces the browser build. Compose Reorderable from Calvin-LL handles drag-to-reorder, which is the obvious interaction for a habit list where the order of your habits is a ranking you care about. MaterialKolor from jordond provides the Material You colour scheme, and ColorPicker Compose from skydoves is the colour picker. Compose Calendar from boguszpawlowski is the calendar component, and the RevenueCat Android SDK handles purchases, which is what lets a paid app distribute without handling payment itself.

Three things stand out about that list.

First, every UI dependency is a Compose component library rather than a design system Grit wrote itself. For a project that lists Material Design in its topics and shows material-ui in its badges, that is consistent and it means the app inherits Material You dynamic colour rather than inventing a palette.

Second, the RevenueCat SDK is the only non-UI dependency, and it is the only one that has a commercial dimension. It means Grit is distributed through Google Play with a purchase flow, and that the RevenueCat SDK is the piece that has to keep working with Play's billing policies.

Third, nothing in the list is a sync backend, a database library, or an analytics SDK. There is no Room, no Firebase, no Crashlytics mentioned. Combined with the absence of any account or server description in the README, that strongly suggests the storage is local and the dependency set is deliberately small.

The consequence for a user is that the data lives on the device. That is a feature for a privacy-minded user and a limitation for anyone who switches phones, and the project does not claim otherwise.

## Distribution through Play and fastlane, with a verified signature

The release side of the project is unusually well documented for a small app, and the README says two things that matter for anyone installing the build.

First, there is a Get it on Google Play badge pointing at the listing for com.shub39.grit, and a Get it on github badge pointing at the GitHub releases. So both distribution channels exist, and the fastlane/ directory at the root holds the metadata, the featureGraphic and the phoneScreenshots, which is the standard layout for an app that publishes through fastlane.

Second, and more unusually, the README publishes the SHA-256 fingerprint of the signing certificate used for the GitHub releases.

```text
0F:E1:B9:F4:4A:4D:B9:7E:C5:09:48:F5:18:9F:6B:43:00:71:6C:C6:D4:84:3F:56:98:D6:14:A2:15:2E:21:88
```

Publishing a signing fingerprint is what lets a user verify that an APK downloaded from the releases page was signed by the same key as the previous one. For a project distributed outside the Play Store, where the install flow is a download and a sideload, that is the only meaningful integrity check available, since the Play Store provides its own. It is a small thing in the README and a serious one in practice, and it is the kind of detail you look for when deciding whether a sideloaded build can be trusted.

The release history is recent and busy: 6.2.1 on 2026-10-14, 6.2.0 on 2026-10-13 and 6.1.1 on 2026-10-10, with the last push on 2026-10-15. Three releases in five days around a 6.2 minor indicates an active development cycle rather than a maintenance mode, which is a good sign for an app in this category, and it also means the app will keep moving under you.

## Translations through Weblate, and a roadmap kept in a discussion

Two things show how the project is run as a community project rather than a closed-source effort.

Translations are done via Weblate, with a contribution link and a translation status widget showing the project on hosted.weblate.org under the name grit. Weblate is a translation platform, so a contributor who wants to add a language does not need to know Kotlin, only the language, and the platform handles the string extraction and the merge back into the source.

The planned changes are kept in a discussion rather than a file. The README points at a RoadMap link, which is a GitHub Discussions thread numbered 66. Keeping the roadmap in Discussions is a choice with consequences: anyone can see it and comment, but it is not versioned with the code, so it does not tell you what version a feature landed in.

Contributing follows the same pattern. Please read CONTRIBUTING.md for details of the code of conduct, and the process for submitting pull requests. There is a CODE_OF_CONDUCT.md at the root, an AGENTS.md, a CHANGELOG.md and a .github/ directory with the workflows.

The hacktoberfest topic in the list is worth a note. It means the project has participated in the seasonal contribution event, which is a reasonable way for a solo-maintained app to attract first-time contributors, and it also means the issue tracker sees a periodic influx of drive-by pull requests that a maintainer has to triage.

The licence is GPL-3.0, with the LICENSE file at the root. For an application rather than a library, the copyleft term applies to the distributed work, and the fastlane metadata in the repository means the store listings are part of the project as well.

## What the README does not tell you

This is a short README, and for a project with a working Google Play listing that leaves several questions open that an adopter would want answered.

The README does not describe the data model. There is no statement of what is stored, whether there is a backup or export path, or how a habit's streak and history are represented. The screenshots show a tracker, and the topic list names habit tracking and notifications, but the mechanics of the scoring are not written down.

It does not describe the notification system either, beyond notifications appearing in the topic list. Since notifications are how a habit tracker reaches you when a day is missed, the absence of any description of reminder times, quiet hours or notification permissions is a real documentation gap.

There is no migration or upgrade note, and the README does not say how data survives an app update. For a local-storage app that is the question a user should most want answered, and it is not addressed here.

Nor does the README state a minimum Android version, which for an app built on recent Compose versions is a meaningful constraint rather than a detail.

None of this makes the project unsuitable, and the CHANGELOG.md and the Roadmap discussion are the places to look. But the honest summary is that Grit is a well-presented app with a transparent development process and an open roadmap, whose internals you will be reading from the source rather than from the documentation.

## Conclusion

Grit suits an Android user who wants a todo list and a habit tracker in one app without an account, and a developer who wants a readable Jetpack Compose codebase to learn from, since the shared, androidApp and desktopApp split is a clear example of modern Android project structure. It is the wrong tool if you need your data to sync across devices, and it is the wrong choice if you want a maintained habit tracker with a community, since the project is one author's app and the social features are still on the roadmap. Before you build on it, read the CHANGELOG.md and the Roadmap discussion linked from the README, and check the JDK and Gradle setup in build.gradle.kts, because the multiplatform targets are what determine whether the web and desktop builds still work with your toolchain.

## FAQ

### What is Grit and what does it do?

It is a simple todo list and habit tracker for Android, written in Kotlin with Jetpack Compose, published on Google Play under the package name com.shub39.grit and also available as a GitHub release.

### Does Grit have a web or desktop version?

Yes. The repository has androidApp/, desktopApp/ and shared/ modules, and the README lists Compose Multiplatform and Kotlin wasm for the Web Demo, with separate screenshots for phone, tablet and desktop.

### How do I help translate Grit?

Translations are done via Weblate, and the README links to the project on hosted.weblate.org where you can contribute a language without needing to know Kotlin.

### How can I verify a Grit APK downloaded from GitHub releases?

The README publishes the SHA-256 fingerprint of the signing certificate used for the GitHub releases, so you can compare it against the certificate of the build you downloaded.

### What licence is Grit released under?

GPL-3.0, with the LICENSE file in the repository root and a CODE_OF_CONDUCT.md describing how contributions are handled.

## Sources

- [Issues](https://github.com/shub39/Grit/issues)
- [License: GPL-3.0](https://github.com/shub39/Grit/blob/master/LICENSE)
- [README](https://github.com/shub39/Grit/blob/master/README.md)
- [Releases](https://github.com/shub39/Grit/releases)
- [shub39/Grit on GitHub](https://github.com/shub39/Grit)

---

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