CPU Info: one Kotlin Multiplatform app that reports on six kinds of device

One application, six platforms

CPU Info is described as a multiplatform application which provides information about device hardware and software, and the platform table in the README is the whole scope of the project in one row.

| Android | Android TV | Wear OS | iOS | Desktop | Wasm | |---|---|---|---|---|---| | yes | yes | yes | yes | yes | yes, in preview |

The WebAssembly build is marked as in preview and is linked to a live page rather than a download, which is the usual way a web target is introduced in a project whose other targets are store applications.

The primary language is Kotlin, and the whole point of the project is that the same codebase produces all of those. The README lists the stack in full: Kotlin Multiplatform for the shared code, Compose Multiplatform for the interface, the Jetpack ViewModel and Lifecycle components for the state handling, coroutines for concurrency, Koin for dependency injection, Coil for image loading, and DataStore for storage.

Two of those entries are about reading the device rather than drawing it, and they are the heart of the application. `pytorch/cpuinfo` and OSHI are the two libraries that supply the information, one of them the CPU information library used by the PyTorch project, the other a cross-platform system information library for Java. Everything else in the stack exists to put a readable interface on top of what those two return.

The project is Apache-2.0 licensed, with the copyright held by KG Soft. The last push was on 2026-10-15, and the recent releases are android-6.7.0 from 2026-09-26, wear-6.7.0 from 2026-05-27 and android-6.6.2 from 2026-03-26, which is the versioning story of the project in three lines: the releases are tagged per platform, and the Wear OS application moves on its own schedule.

shared/ and the per-platform application modules

The repository layout is the standard Kotlin Multiplatform shape, and it is worth reading because it explains how one project supports six targets.

There is a `shared/` directory, which is where the code that every target uses lives, and beside it the per-platform application modules: `androidApp/`, `iosApp/`, `desktopApp/`, `wearOsApp/` and `webApp/`. There is also a `native-android/` directory and a `kotlin-js-store/` directory, which are where the Kotlin/Native and Kotlin/JS dependency metadata lives.

The build is a single Gradle project with `settings.gradle.kts` and `build.gradle.kts` at the root, a `buildSrc/` directory for the build logic, and the usual `gradlew` and `gradlew.bat` wrappers. The `gradle.properties` file carries the shared configuration.

Two more directories are worth naming because they tell you how the project is maintained. `fastlane/` is the Android release automation, which is what makes the per-platform tagged releases and the store uploads possible. And `spotless/` holds the formatting configuration, with the Spotless plugin keeping the Kotlin sources in a single style across every module, which matters in a project where the same file is compiled by several different toolchains.

`renovate.json` is there as well, so the dependencies are updated automatically, and `.aiexclude` at the root, together with the `CLAUDE.md` file, describes the conventions for coding assistants working in the repository.

Koin, Coil and DataStore: the parts an app needs anyway

Most of the stack is not about CPU information, and a reviewer looking for the interesting part has to look past it.

Koin is the dependency injection framework, and in a Kotlin Multiplatform project it is the piece that keeps the platform-specific implementations of the information providers behind a common interface. The `expect` and `actual` mechanism tells the compiler which implementation exists on which target, and Koin is what binds the actual one into the shared code at runtime, so the shared module never has to know whether it is talking to an Android implementation or an iOS one.

Coil is the image loading library, listed among the stack, so any image the interface shows is loaded through it on the platforms the app supports.

DataStore is the storage layer, the Kotlin Multiplatform datastore from the Android documentation, which is where the application keeps what it needs to keep between runs, such as the settings a user chooses.

Coroutines and the Jetpack ViewModel and Lifecycle components do the work that every modern application does, and in a Compose Multiplatform project the lifecycle integration is the part that decides how much of the screen survives a configuration change or a move to the background, which on a Wear OS watch and on a phone are very different problems.

The result is an application where the domain logic is small and the platform integration is large, which is the normal shape of a cross-platform information tool and the reason the project can support a platform with no real users, such as the Wasm preview, at the cost of a separate application module and a store submission for each.

Nine stores, one repository, three version lines

The distribution section of the README is nine badges, and reading them in order tells the whole story of a cross-platform application.

There is F-Droid and Google Play for Android, the HUAWEI AppGallery for the Chinese market, GitHub releases for anyone who would rather have a file than a store, the Amazon AppStore and the Apple App Store for iOS, Flathub for Linux desktops, the Microsoft Store for Windows, and a Homebrew cask for macOS.

The Homebrew cask and the Flathub entry are the interesting ones for a technical audience, because they are the two distributions that deliver a desktop build as a package rather than as a signed store application, and both of them are the normal way a developer installs a desktop tool on macOS or Linux.

The release history shows how that translates into version numbers. The three recent releases are `android-6.7.0` from 2026-09-26, `wear-6.7.0` from 2026-05-27 and `android-6.6.2` from 2026-03-26. The tag is prefixed with the platform, and the number after the prefix is shared within a platform, so the Android application and the Wear OS application version independently of each other even though they come out of the same repository and carry the same number.

That is the practical consequence of a multiplatform project with separate store submissions: the same source tree produces artefacts that are released, reviewed and updated on different schedules, and the version in the about screen of the Android application tells you nothing about the Wear OS one. A support engineer comparing a screenshot from a watch with a screenshot from a phone is comparing two different builds.

The `fastlane/` directory in the repository is the automation behind the Android releases, and the workflow badge at the top of the README is for a shared test workflow, which suggests the platforms are covered by one test run.

Where CPU Info is the wrong tool

Three limits are worth naming, and none of them is a criticism of the project.

The first is that it is an application and not a library. A team that needs the hardware information inside its own tooling cannot depend on this repository, because what it publishes is an app with a user interface, not a module with an API. The alternative for that case is to call the same two libraries directly, `pytorch/cpuinfo` and OSHI, from a script or a service, which is a few lines and gives machine-readable output.

The second is what the readings actually are. The information comes from the operating system and from the JVM, not from the hardware. The CPU model, the core count and the instruction set come from what the platform reports, the memory figures are what the process sees, and the storage and network details are similarly filtered by permissions and by what the platform is willing to disclose. On a phone, the most interesting hardware is often behind an API that only a privileged application can call, and no amount of interface polish changes what the numbers are.

The third is the cost of the multiplatform commitment. Every target needs its own application module, its own build configuration, its own store submission and its own release, and the Wear OS release being four months behind the Android release is the visible price of that. For a project whose whole purpose is to show information, a smaller footprint of two or three targets would cover most of the demand for a fraction of the maintenance.

There is also the WebAssembly preview, which is honest about its status but worth watching, because a build that runs in a browser without an install is a genuinely different way to ship this kind of tool.

The alternative for a developer who wants the numbers on a workstation is a command line tool, and the one that comes closest to what this application does is a small script that prints the same fields from the same libraries. The difference in approach is that the application is built for a phone, a watch and a browser, where the value is in the presentation and in the fact that it runs on the device you are holding, and the script is built for a terminal, where the value is in the output being pipeable.

Editorial conclusion

CPU Info fits a developer or support engineer who wants a single application that tells them what a device is, and who wants it on the platform they happen to be holding, which is a real problem when the interesting device is the one in your hand and the tooling is on your laptop. It is the wrong tool as a library, because it is an application and not something you embed, and it is the wrong tool on a server, where a script calling the same two underlying libraries gives the numbers without the interface. Before depending on the readings, check which platform produced them, since the data comes from the JVM and the operating system rather than from the hardware itself, and remember that the WebAssembly build is still marked as a preview.

Frequently asked questions

Official sources

1. Issues
2. kamgurgul/cpu-info on GitHub
3. License: Apache-2.0
4. README
5. Releases