I'm not using it yet, but I've been considering using it for my maplibre-compose library. Specifically, I intend to
someday build a KMP wrapper around the Maplibre Native core C++ library instead of around their existing iOS and Android SDKs, and then build my Compose integration on top of that.
One potential architecture would look like:
• maplibre-native-kotlin, a thin Kotlin wrapper of MapLibre Native Core built for all Kotlin native targets
• maplibre-js-kotlin, a thin Kotlin wrapper of MapLibre GL JS built for all Kotlin browser targets
• maplibre-compose, adapting the above two into a Compose library for all supported Compose targets.
This architecture would involve an Android target somehow depending on an androidNative target, and I'm not sure if that's a path I can or should go down (Kotlin to Kotlin JNI?)
An alternative architecture avoiding the Kotlin androidNative target would make maplibre-native-kotlin a thin Kotlin wrapper of MapLibre Native Core built for all Kotlin Apple Native targets, plus JNI adapters to build for Android and JVM targets.