# ComposeCharts: charting composables for Jetpack Compose across four platforms

> ComposeCharts is a Kotlin charting library built for Jetpack Compose and published as a Kotlin Multiplatform artefact covering Android, desktop, iOS and WasmJS. It reached 1.0.0 in July 2026 after a long 0.x line, and its in-repository documentation is thin next to the hosted guide.

**ehsannarmani/ComposeCharts** — Animated & Flexible Practical Charts For Jetpack Compose

- Repository: https://github.com/ehsannarmani/ComposeCharts
- Website: https://ehsannarmani.github.io/ComposeCharts/
- Stars: 914 · Forks: 73
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/ehsannarmani-composecharts

## Charts as composables rather than a view you drop in

ComposeCharts describes itself as animated and flexible practical charts for Jetpack Compose. The words carry more weight than they look.

In the Android view system, a chart was historically a View or a custom Drawable that you added to a layout, and the only way to style it was whatever the library exposed. The Compose model changes that: a chart becomes a composable function, so it participates in the same layout and theming rules as everything else on the screen, and it is written in Kotlin with the same modifier and state patterns as the surrounding code.

That is the whole reason to reach for a library like this rather than drawing with a Canvas by hand. Drawing a bar chart yourself is a few primitives. Drawing an animated chart with axes, labels, tooltips and a data model that reacts to state changes is a project, and every team ends up writing a slightly different one.

The repository topics give the position clearly: compose-charts, compose-multiplatform, jetpack-compose-charts, android-chart and chart-library. So it sits in the same category as the charting libraries that have grown up alongside Compose, and its differentiator is stated in the same place.

The audience is Kotlin developers building applications with Compose who need data visualisation and would rather not maintain a charting library themselves. That includes product teams whose dashboards live in the app, and teams shipping the same UI to phone and desktop.

## One artefact covering Android, desktop, iOS and WasmJS

The platform badges on the project page are the clearest statement of scope: Android, Desktop, iOS and WasmJS.

WasmJS is the one that usually turns heads, because it means the charts can run in a browser through WebAssembly, which puts the same visualisation code in a web frontend without a separate JavaScript charting implementation. That is a genuine engineering saving for a team that already has a Kotlin Multiplatform codebase, because the alternative is maintaining a second charting stack in the web target.

The Kotlin Multiplatform badge confirms the project is built as a multiplatform library rather than an Android library with a desktop port. That distinction matters for the artefact you consume: a multiplatform library publishes platform specific variants and resolves the right one per target, so a single dependency declaration works across all of them.

The Kotlin version badge reads 2.0.0, which is the language and compiler generation the project targets. For an evaluator, the practical questions are whether your own project is on that generation and whether your targets are covered by the four listed platforms. The repository layout supports the multiplatform claim, with an iosApp/ directory at the root alongside the library module and the sample app, which is the conventional shape for a KMP project that wants to demonstrate its iOS target.

## Adding the dependency, and picking a version

The library is published on Maven Central under the group io.github.ehsannarmani with the artefact compose-charts, and the install is one Gradle dependency.

```gradle
dependencies {
    implementation ("io.github.ehsannarmani:compose-charts:latest_version")
}
```

That snippet is the entire installation section of the project documentation, and the placeholder version tells you something important: the project expects you to look up which version you want rather than taking whatever is newest. For a published library that is a reasonable stance, but in practice you want a fixed version in a real build, because a chart library that changes its composable signatures between releases will break your screen code at a dependency bump rather than at a deliberate upgrade.

The dependency coordinates follow the same pattern as other GitHub-hosted Kotlin projects, where the group id is io.github.<username>. That means the artefact is tied to the author's GitHub account namespace rather than a company domain, which is normal for an individual open source project and is the kind of thing to check if your organisation has policies about where dependencies come from.

After the dependency resolves, the real learning is in the guide. The project documentation points to a full guide and document hosted at ehsannarmani.github.io/ComposeCharts, and the repository itself carries a document/ directory that is the source of that site. The repository layout also includes an app/ directory, which is the sample application, alongside the compose-charts/ module that holds the library code, the Gradle build files and settings.gradle.kts, and an assets/ directory with the banner and mockup images.

## A long 0.x line that ended at 1.0.0

The release history explains the shape of the project better than the short readme does.

There is 1.0.0, published on 2026-07-21. Before it there is 0.2.5 from 2026-02-12 and 0.2.0 from 2025-10-03. The last push was on 2026-07-30, about a week after the 1.0.0 tag, so the tree has continued to move since that release.

A version number reaching 1.0 is a statement about the library's public API, and it arrives after roughly nine months of 0.x releases. That is a normal pace for a Compose component library, and the fact that the API was considered stable enough to tag at 1.0 suggests the composable surface had settled before that point.

For an adopter, the practical advice follows from the numbers. If you adopted this library in its 0.x period, you may have absorbed API churn that the 1.0 tag now promises is over. If you are starting fresh, 1.0.0 is the version to read the guide for, and anything written about 0.2.x in a blog post or an old commit is out of date.

The licence field on the repository says Apache-2.0, and the badge on the project page shows the same, pointing at the Apache licence text. That is a permissive licence with an explicit patent grant and no copyleft obligations, which is the conventional choice for a library that companies embed in their applications. This is not legal advice, and for anything beyond internal use you would still read the LICENSE file in the repository root rather than the badge.

## What the repository does not tell you, and the gap that creates

The most notable thing about this repository is how little is in it. The README is a heading, a banner image, a mockup, a row of badges for Kotlin, licence, multiplatform and the four platforms, an installation section with one Gradle snippet, and a link to the hosted guide.

There is no API reference, no list of chart types, no sample code, no configuration documentation. For a chart library that is a real gap, because the entire value of the library is in the shape of its API: which chart types exist, how data is passed in, how axes are configured, how animation is triggered, how theming works.

The practical consequence is that you cannot evaluate this library from the repository alone. You have to read the hosted guide, and if the guide is thin too, you have to read the source in the compose-charts/ module or build the sample app and try it. The app/ directory presumably contains the demonstration, which is the fastest way to see what the library actually produces.

There is a second, quieter consideration. The project sits at version 1.0.0 as a single maintainer's library, with the group id under a personal GitHub namespace and the documentation hosted on GitHub Pages from a document/ directory in the same repository. If the maintainer stops, the artefact stays on Maven Central and the source stays on GitHub, so nothing disappears. But there is no roadmap in the repository, no indication of what comes after 1.0.0, and no indication of who else reviews the pull requests. The Apache-2.0 licence means you can fork and maintain it yourself if that becomes necessary.

For a chart library specifically, the risk profile is lower than for something infrastructural. A chart is a leaf in your dependency tree, easy to replace, and easy to lift into your own codebase if the licence permits. That is the argument for adopting it despite the thin documentation, and the argument against is simply the cost of reading the guide instead of the docs.

## Conclusion

ComposeCharts suits a Kotlin team that wants charts drawn with the same composable model as the rest of its UI and needs the same chart code to run on Android, desktop and iOS from one artefact. It does not suit a project that has to ship today on a JVM only, because the library's value is the shared multiplatform code path rather than any particular chart style, and it does not suit a team that expects an in-repository manual, since the README is a banner, an install snippet and a link. Before adopting it, read the hosted guide at ehsannarmani.github.io/ComposeCharts, since the repository itself does not document the API, and pin a version rather than using latest_version, because the 1.0.0 tag from 2026-07-21 marks the end of a long 0.x series where the shape of the composables could still change.

## FAQ

### What platforms does ComposeCharts support?

The project lists Android, Desktop, iOS and WasmJS, and carries a Kotlin Multiplatform badge. It is published on Maven Central as io.github.ehsannarmani:compose-charts and targets Kotlin 2.0.0.

### How do I add ComposeCharts to an Android project?

Add the Gradle dependency implementation ("io.github.ehsannarmani:compose-charts:latest_version") to your dependencies block. The project ships the library as a Kotlin Multiplatform artefact, and the repository includes an app/ sample and an iosApp/ directory.

### Where is the ComposeCharts documentation?

The full guide and documentation are hosted at ehsannarmani.github.io/ComposeCharts, and the repository carries a document/ directory that is the source of that site. The README itself only contains the install snippet and a link.

### Is ComposeCharts stable enough to depend on?

Version 1.0.0 was published on 2026-07-21, following 0.2.5 from 2026-02-12 and 0.2.0 from 2025-10-03. The last push was on 2026-07-30, and the licence field on the repository says Apache-2.0.

## Sources

- [ehsannarmani/ComposeCharts on GitHub](https://github.com/ehsannarmani/ComposeCharts)
- [License: Apache-2.0](https://github.com/ehsannarmani/ComposeCharts/blob/master/LICENSE)
- [Project website](https://ehsannarmani.github.io/ComposeCharts/)
- [README](https://github.com/ehsannarmani/ComposeCharts/blob/master/README.md)
- [Releases](https://github.com/ehsannarmani/ComposeCharts/releases)

---

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