Todometer brings a meter to-do list to five platforms with one Compose codebase

The repository layout is the actual documentation of this project

Todometer is small, so the interesting content is not the feature list but the way the project is cut up. The top level shows app/, app-common/, app-feature/, common/, common-android/ and wearapp/, plus macrobenchmark/, resources/, config/, spotless/, docs/ and the Gradle files. That arrangement is the answer to the question a multiplatform project is usually judged on, which is where platform code stops and shared code begins. app-feature/ holding features and common/ holding shared code is a deliberate separation, and common-android/ exists to hold the parts that genuinely need Android. The wearapp/ module is a separate application rather than a flavour inside app/, which is a common way to keep the watch build from pulling in phone dependencies. For an engineer learning Kotlin Multiplatform, that tree is worth more than any tutorial, because it shows one author making the same decisions you would have to make.

One shared Compose codebase covers Android, desktop, iOS and a watch

The technologies section lists Compose UI Multiplatform, Compose ViewModel Multiplatform, Compose Navigation Multiplatform and Compose Vectorize as the common layer, with Compose ViewModel Multiplatform and Compose Navigation Multiplatform linking JetBrains documentation for the lifecycle and the routing. On top of that sit two platform specific layers. Android uses Android Jetpack with Android KTX and the Glance App Widget, and Wear OS uses Wear Compose with Wear Compose Navigation. The screenshots confirm that all four targets are real rather than aspirational: there are Android screens for the home view and the add task flow, a Glance widget screen, desktop screens, iOS screens in both dark and light variants, and a full set of Wear OS screens covering the task list, a single task view and both delete flows. The Glance widget and the Wear Compose build are the two pieces most often missing from multiplatform samples, and both are present here.

The desktop build runs from a single Gradle command

The documentation for the desktop target is a single line, which is the point: the desktop app is an ordinary Gradle module. Running the app module on the JVM needs no emulator and no platform SDK setup.

`./gradlew :app:run`

The Android app is distributed on Google Play under the package id dev.sergiobelda.todometer. For iOS, the instruction is different in kind: open app-ios/Todometer.xcodeproj in XCode, or run it in Android Studio using the Kotlin Multiplatform Mobile plugin. That is worth noting as a boundary. The iOS path is not a Gradle invocation but an Xcode project, so an engineer who expects every target to build from the same command line will not get that here, and the caveat is not spelled out further in the documentation. A useful detail for anyone who asks where the data lives: the project carries a PRIVACY_POLICY.md at the top level, and the presence of that file next to a local-first to-do list tells you the storage story is on device rather than on a server.

Storage runs through SQLDelight and dependency injection through Koin

SQLDelight is the persistence layer, and picking a typed SQL library for a to-do app says something about the author's priorities. Instead of an ORM with runtime reflection, the queries are compiled, so the schema and the generated Kotlin are checked at build time and a malformed query fails the build rather than the app. Koin Multiplatform handles dependency injection, and the technologies list also includes Kotlin and Coroutines with Flow, which is the mechanism through which the UI observes data changes across every target. Two libraries in that list are the author's own work, compose-vectorize and navigation-compose-extended, both hosted on the same account as the project. That detail matters for anyone considering reuse, because those are separate repositories with their own release cycles, and the app depends on them. It also means the multiplatform stack here is not only a set of JetBrains and Google libraries but a small personal ecosystem of extractions from a production app.

A meter, not a productivity system

The project describes itself as a meter to-do list, and the project description calls it a meter to-do list built with Compose UI Multiplatform, Wear Compose, SQLDelight, Koin Multiplatform and Glance. The README makes the origin explicit: it is based on the web todometer at cassidoo.github.io/todometer. What that means for an adopter is that this is a demonstration of platform reach rather than a serious task manager. The feature set visible in the screenshots is a task list, a screen for adding a task, and deletion gestures, presented with a meter on the home screen. There is no sign of subtasks, due dates, reminders, projects, search, or attachments, and the technologies list mentions no networking or sync library even though ktor appears among the repository topics. For an engineer who wants to learn how to build a multiplatform Compose app, the toy scope is an advantage, since the code stays readable. For anyone looking for a to-do app to install, it is the wrong artefact entirely.

Formatting is enforced with spotless and dependencies are kept current by renovate

Two pieces of automation stand out in the top level tree. spotless/ has its own directory, and spotless is listed among the technologies, so code formatting is a build-time concern handled by the diffplug tool rather than a habit maintained by hand. Renovate is configured through renovate.json, which is how the project keeps its many dependencies current: with a stack this wide, spanning Compose Multiplatform, Koin, SQLDelight, Glance, Wear Compose and the author's own libraries, a manual update pass would be a chore. The macrobenchmark/ module is the other one. A macrobenchmark module exists to measure and check real device behaviour, typically cold start and frame timing, which places this repository among the multiplatform samples that treat performance as something to verify on hardware rather than assume from a build passing. The .github/ directory holds the workflows, including the build workflow that the badge in the README points at.

The last push is recent, but the release tags are not

The repository is not archived and the last push was on 2026-10-20, so the code is being worked on. The published releases tell a different story. The most recent tag is dated 2025-04-03, followed by 2024-04-22 and 2024-03-09, and each is named after its date rather than a version number. Those tag names are typical of an automated release pipeline, and they also mean there is no semantic version to depend on. Anyone pinning a dependency has to pin a commit or a date tag instead, and a date tag tells them nothing about compatibility. The licence is Apache-2.0, and the LICENSE file in the repository carries the standard Apache 2.0 text with the copyright line for Sergio Belda, so the terms are standard and the redistribution obligations that come with Apache 2.0, such as passing on the licence and noting changes, apply to a fork. Nothing in the documentation describes a rollback procedure or a support policy, so treat the project as a sample with a permissive licence rather than a dependency with a maintenance commitment.

Where Todometer is the wrong starting point

Three cases stand out. The first is anyone who wants a capable to-do app, because the feature set is a meter, a list and an add screen, and the absence of any sync or notification layer means it will not survive a change of device. The second is anyone who needs a supported dependency rather than a reference implementation, because the release tags are dated, there is no semantic versioning, and the two companion libraries the app relies on live in separate repositories that would need their own evaluation. The third is a team that wants a shared codebase across every target including iOS, because the iOS build path is an Xcode project rather than a Gradle task, and that decision has consequences for how the iOS code is generated and how the build is run in CI. The more productive framing is to treat the project as a well-organised sample. The module split, the shared and platform layers, the use of a compiled SQL layer and the presence of macrobenchmarks are all patterns worth copying, and the small feature set means every file in the repository is one you can read without wading through unrelated business logic.

Editorial conclusion

Adopt Todometer as a reference codebase when you need to see how one Compose Multiplatform project is split across app, app-feature, app-common, common and wearapp modules, and skip it if you were expecting a task app to adopt wholesale, because the feature set is that of a to-do list with a meter and the project ships no releases beyond dated tags. Verify first that the iOS target still opens in XCode, since the documented path is app-ios/Todometer.xcodeproj rather than a Gradle task, and check the PRIVACY_POLICY.md in the repository before shipping any fork.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. serbelga/Todometer-KMP on GitHub