maplibre-compose: MapLibre maps in a Compose Multiplatform UI

A Compose wrapper around the MapLibre SDKs

MapLibre Compose is a Compose Multiplatform wrapper around the MapLibre SDKs for rendering interactive maps, and the point of it is that a map becomes a composable in a Kotlin interface rather than a platform view you have to interop with. The project notes put the supported targets plainly: you can add maps to your Compose UIs across Android, iOS, Desktop and Web.

That is four quite different rendering environments behind one API. The native SDKs do the work, so the wrapper's job is to bridge the Compose component model to whichever platform implementation is underneath, and the risk in that bridge is exactly where the per platform stability levels come from later on.

The library is published to Maven Central under the org.maplibre.compose namespace, with the artifact named maplibre-compose, and it is maintained by the MapLibre organisation rather than by an individual, which is the arrangement you would expect for a wrapper that sits on top of several SDKs at once. The repository also carries the usual AI policy file, a code of conduct and a security policy, and a Slack channel is linked for questions about the wrapper itself.

The stability table is the real specification

The most useful thing in the project notes is the stability table, because it tells you exactly what risk you are taking on each platform. The library uses Kotlin's stability levels to describe update risk, and the levels are not uniform. Android is Beta and iOS is Beta. macOS native on ARM64 is Experimental. Desktop on the JVM is Alpha, and Web is Alpha.

The notes also say that the public API is still evolving and that minor releases can contain breaking changes. That sentence is the one to plan around. It means the version number alone does not tell you whether an upgrade is safe, so a project that wants predictable upgrades has to read the release notes or pin a version and move deliberately.

This is a normal way for a wrapper around multiple SDKs to behave, since each underlying platform library has its own cadence and its own breaking changes, and the wrapper has to absorb them. The stability table is the mechanism that makes that absorbable: a Beta API is one you can use with some expectation of stability, an Alpha one is where you should expect to do work when the library moves.

Why desktop and web are Alpha

The notes give the reason for the two lowest levels in one line: Desktop and Web are Alpha because their platform integrations depend on implementation details in Compose and Skia.

That is a specific and useful diagnosis. The Android and iOS paths go through native MapLibre SDKs that are themselves first class on those platforms, so the wrapper has a stable surface to sit on. Desktop and web do not, because there the integration runs through implementation details of Compose and Skia, and the sort of thing that is an implementation detail today can change shape in a release without anyone meaning to break your map view.

The practical reading is that a team targeting mobile can adopt this and expect a normal level of churn, while a team whose primary target is a desktop or browser build should treat the map as experimental code, isolate it behind their own interface, and expect to revisit it. The macOS native ARM64 entry sits in between as Experimental, which suggests a working integration with more unknowns than the mobile ones.

A release rhythm measured in days

The published versions show a fast cadence. v0.18.0 was released on 2026-09-25, v0.19.0 on 2026-10-01 and v0.20.0 on 2026-10-10, and the last push to the repository was on 2026-10-20, so the project is moving quickly and shipping as it goes.

That is good news for anyone who needs a missing platform integration, and it is a reason to be careful about automatic upgrades. A minor release that can contain breaking changes, arriving every week or two, means the default of tracking the newest version is a poor fit for a production app. Pinning a known version and updating on a schedule is the safer pattern, and the stability table tells you how much work each upgrade is likely to be.

It is also worth noticing that the version numbers have not reached 1.0, which for a Kotlin library is a signal that the API contract is still settling, in line with the notes about the public API evolving.

A polyglot build around Gradle

The repository layout shows how a multiplatform library like this is assembled. The Kotlin library itself is in the lib directory, there is a demo app in demo-app, documentation sources in docs, benchmarks in their own directory, and the build support in buildSrc, ci and tools. There is also a patches directory and a third_party directory, which are the two places where a project that wraps native dependencies keeps its local modifications.

The toolchain is similarly mixed, and this is where the JavaScript presence in the repository comes from. The package manifest is private, and its only entry is a single development dependency for the documentation tooling:

{
  "name": "maplibre-compose",
  "private": true,
  "devDependencies": { "vite-plus": "^0.2.7" }
}

So the JavaScript is not part of the shipped library, it is the tool that builds the documentation site. The rest of the tooling is spread across systems: a pnpm workspace with a lock file for the JavaScript side, a Kotlin JS store for the web target, mise lock files for environment pinning including a separate Android one, an Xcode version file, dprint for formatting, a pkl configuration for hooks, Gradle settings and a wrapper for the actual build, and several editor and agent configuration directories.

Where to look when you get stuck

Documentation is not the weakest part of this project. There is a getting started guide, an API reference, and a documentation site under the MapLibre domain, plus a demo application in the repository that you can run to see the wrapper working on each target. A Slack channel is linked from the project notes for questions in the moment.

The project notes are short, which is a function of the wrapper's scope rather than an omission. Almost everything a user needs is in the guides, because the interesting decisions are the ones MapLibre itself has already made, and the wrapper's job is to expose them through Compose.

The licence is BSD-3-Clause, and the code is published under the MapLibre organisation with the project pages hosted alongside the rest of the MapLibre documentation, which is a sensible arrangement for a library that exists to make the MapLibre SDKs usable from a multiplatform Kotlin codebase.

Editorial conclusion

maplibre-compose suits a Kotlin team shipping a shared interface across mobile and desktop who want a map view that is a Compose composable rather than a platform view embedded in a layout, and the per platform stability levels let you scope that decision honestly. It is the wrong choice if you need a stable public API on desktop or the web, where the library is at Alpha and the integrations depend on Compose and Skia implementation details, and it is the wrong choice if you cannot accept breaking changes in minor releases, which the project states plainly. Before you adopt it, check which platform you actually need, because the stability levels differ by platform rather than being uniform, and pin a version rather than tracking the branch, given a release every few days. The licence is BSD-3-Clause, the current release is v0.20.0 from 2026-10-10, and the artifact is on Maven Central under the org.maplibre.compose namespace.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. maplibre/maplibre-compose on GitHub
3. Project website
4. README
5. Releases