Kotlin Multiplatform for shared logic — Monitoring & Observability — Practical Guide (Mar 29, 2026)
Kotlin Multiplatform for Shared Logic — Monitoring & Observability
Level: Intermediate
Date: March 29, 2026
Target Kotlin Multiplatform version range: 1.9.x – 1.10.x
Introduction
Kotlin Multiplatform (KMP) continues to mature as a powerful approach for sharing business logic across Android, iOS, desktop, and backend platforms. In 2026, stable KMP tooling now solidly supports complex use cases, including monitoring and observability of shared components. Observability — encompassing logging, metrics, tracing, and error reporting — is crucial for reliable and performant systems, particularly when the same logic runs cross-platform.
This article guides you through practical strategies to implement monitoring and observability in KMP shared modules. We focus on current best practices with Kotlin 1.9.x and upcoming 1.10.x, highlighting cross-platform concerns, appropriate libraries, and typical pitfalls.
Prerequisites
- Intermediate Kotlin and Kotlin Multiplatform experience, including basic project setup.
- Familiarity with multi-platform build configurations (Gradle Kotlin DSL typically).
- A clear use case involving shared business logic that requires runtime observability.
- Android Studio or IntelliJ IDEA updated for latest Kotlin plugin (compatible with Kotlin 1.9.x+).
- Basic understanding of concepts such as logging, metrics, distributed tracing, and error reporting.
Hands-on Steps
1. Defining Cross-platform Observability Interfaces
Start by defining common interfaces for logging, metrics, and tracing in the shared module. Keep APIs minimal and idiomatic. Use expect/actual declarations to provide platform-specific implementations as needed.
// Shared module
interface Logger {
fun debug(message: String)
fun info(message: String)
fun warn(message: String)
fun error(message: String, throwable: Throwable? = null)
}
expect object Metrics {
fun incrementCounter(name: String, tags: Map = emptyMap())
fun recordGauge(name: String, value: Double, tags: Map = emptyMap())
}
interface Tracer {
fun startSpan(name: String): Span
}
interface Span {
fun end()
fun setTag(key: String, value: String)
}
This approach ensures your shared logic depends only on abstract observability contracts, avoiding direct platform APIs.
2. Providing Platform-specific Implementations
Implement these interfaces using platform-specific logging and monitoring libraries.
Android Example
// Android actual implementation in androidMain
actual object Metrics {
private val registry = io.micrometer.core.instrument.Metrics.globalRegistry // Assuming Micrometer JVM
actual fun incrementCounter(name: String, tags: Map) {
val counter = registry.counter(name, tags.flatMap { listOf(it.key, it.value) })
counter.increment()
}
actual fun recordGauge(name: String, value: Double, tags: Map) {
val gauge = registry.gauge(name, tags.flatMap { listOf(it.key, it.value) }, value)
}
}
actual object Logger : Logger {
override fun debug(message: String) = android.util.Log.d("SharedLogger", message)
override fun info(message: String) = android.util.Log.i("SharedLogger", message)
override fun warn(message: String) = android.util.Log.w("SharedLogger", message)
override fun error(message: String, throwable: Throwable?) =
android.util.Log.e("SharedLogger", message, throwable)
}
iOS Example
// iosMain actual implementation using OSLog & Prometheus client (or custom lightweight)
// Use kotlin-native interop for accessing iOS frameworks
import platform.os.log.*
actual object Logger : Logger {
private val log = osl_create("SharedLogger", OS_LOG_TYPE_DEFAULT)
override fun debug(message: String) = osl_log(log, OS_LOG_TYPE_DEBUG, message)
override fun info(message: String) = osl_log(log, OS_LOG_TYPE_INFO, message)
override fun warn(message: String) = osl_log(log, OS_LOG_TYPE_DEFAULT, message)
override fun error(message: String, throwable: Throwable?) {
osl_log(log, OS_LOG_TYPE_ERROR, message)
// throwable handled via error reporting services often
}
}
When native libraries are unavailable or too heavyweight, implement custom minimal logging or metrics using text files, user preferences, or simple data structures transferred to your backend.
3. Integrating Third-party Observability Services
For distributed tracing and comprehensive monitoring, consider mature open-source or commercial SDKs that support Kotlin or native platforms:
- OpenTelemetry (Kotlin support is maturing; stable JVM implementations are recommended for Android and backend)
- CocoaLumberjack or OSLog for iOS logs
- Micrometer for metrics on JVM platforms
- Sentry, Bugsnag or Firebase Crashlytics for error reporting
Use KMP-compatible wrappers or common APIs to unify usage in your shared module. Keep an eye on Kotlin 1.10+ for new official multiplatform libraries like kotlinx-logging preview for standardised logging API.
4. Threading and Concurrency Awareness
Shared logic code often runs on different threads or dispatchers per platform. Ensure observability calls are thread-safe. Use Kotlin coroutines carefully: call logging/metrics in safe contexts to avoid lifecycle or deadlock issues.
Common Pitfalls
- Platform API leakage: Avoid using platform-specific logging or metrics APIs directly in common code. Always abstract with expect/actual or multiplatform libraries.
- Heavy dependencies: Some JVM or iOS libraries add binary size and complexity. Evaluate runtime costs, especially on mobile or embedded devices.
- Inconsistent data: Metrics tags or log formats must be consistent across platforms to allow aggregated analysis.
- Concurrency bugs: Observability code that is not thread-safe can cause crashes or data loss.
- Preview APIs caution: Avoid relying on preview features in production unless fully understood and tested.
Validation
- Unit-test your abstractions in the shared module to confirm correct API usage.
- Run platform-specific integration tests validating your actual implementations.
- Use observability backends or dashboards to verify actual data arrives as expected.
- Employ runtime assertions and debug logs initially to trace instrumented code paths.
Checklist / TL;DR
- Define common observability interfaces in shared code using
expect/actual. - Implement platform-specific versions using native or JVM libraries consistent with your stack.
- Choose stable libraries; approach preview multiplatform logging cautiously.
- Keep metric names and tags unified for multi-platform aggregation.
- Ensure thread safety and suspend function compatibility for observability calls.
- Integrate distributed tracing and error reporting via wrappers when possible.
- Test thoroughly on each target platform.
When to Choose Kotlin Multiplatform Observability vs Platform-only
If your core logic is shared and must report consistent monitoring data, centralising observability interfaces in KMP is beneficial. However, platform-unique UI or OS-layer events might still be best handled separately in platform-native code to leverage richer APIs.
For backend-heavy projects or JVM-only targets, standard JVM libraries offer more mature and feature-rich tooling. For maximum control and minimal dependencies, writing minimal adapters on each platform can also be a practical solution.