The observability landscape just expanded in a significant direction. OpenTelemetry, the Cloud Native Computing Foundation's framework for collecting and exporting telemetry data, has accepted a Kotlin implementation into its ecosystem. This marks a pivotal shift for teams building mobile and multiplatform applications, addressing a gap that has quietly frustrated developers for years.

The contribution comes from Embrace, a user-focused observability platform company and CNCF member. Their Kotlin API and SDK implementation was formally accepted in 2025, following a proposal that recognized a fundamental mismatch: while Kotlin has become the default language for modern Android development and increasingly powers backend services, developers have been forced to rely on Java-based tooling that doesn't align with how Kotlin applications actually work.

The Java Interoperability Problem

Until now, Kotlin developers have used OpenTelemetry through the Java SDK, leveraging Kotlin's interoperability with Java. On paper, this sounds reasonable. In practice, it creates friction that compounds across large codebases.

The Java SDK works well for JVM-based services, but it carries three critical limitations. First, it cannot support non-JVM targets used in Kotlin Multiplatform (KMP) projects, which allow developers to share business logic across iOS, Android, and web platforms. Second, the API reflects Java design patterns rather than Kotlin idioms, forcing developers to write code that feels unnatural in a Kotlin context. Third, it makes backend-oriented assumptions about execution models and lifecycle management that don't match mobile and client-side realities.

These aren't minor inconveniences. When your observability tooling doesn't match your application's runtime characteristics, you end up with telemetry that misses critical context or, worse, degrades performance in resource-constrained environments. For teams building production mobile applications, this gap has meant choosing between comprehensive observability and optimal user experience.

Why Mobile Observability Demands Different Thinking

Backend observability and mobile observability operate under fundamentally different constraints. Server environments assume stable network connectivity, predictable resource availability, and long-running processes. Mobile applications face intermittent connectivity, frequent process termination by the operating system, limited CPU and memory budgets, and highly asynchronous execution models.

Hanson Ho, an Android architect at Embrace, addressed these differences at the CNCF's first Open Observability Summit in his talk "Beyond Good Enough: Why We Want a Kotlin API and SDK." His central argument: observability isn't just about collecting more data anymore. It's about understanding user workflows, context, and outcomes in environments where performance, connectivity, and lifecycle constraints are fundamentally different.

Consider a typical mobile scenario. A user opens your app on a subway with spotty cellular service, performs several actions, backgrounds the app, and returns hours later. During that time, the operating system may have terminated your process to reclaim memory. Your telemetry system needs to buffer data intelligently, correlate events across sessions, and export efficiently when connectivity returns—all without draining battery or consuming excessive storage.

Backend-focused SDKs aren't optimized for these conditions. They assume you can export telemetry immediately, that processes run continuously, and that resource constraints are relatively generous. A native Kotlin implementation provides the opportunity to design APIs and runtime behavior that match mobile realities while still conforming to the OpenTelemetry specification.

How the Kotlin SDK Works

The contributed project is a Kotlin Multiplatform implementation of the OpenTelemetry specification, designed to support both JVM and non-JVM environments. It currently operates in two modes, each serving different use cases.

Compatibility Mode allows the Kotlin API to interoperate with the existing OpenTelemetry Java SDK. This provides Android and JVM users with an idiomatic Kotlin interface while continuing to rely on the mature opentelemetry-java SDK underneath. For teams with existing OpenTelemetry instrumentation, this offers a low-friction migration path—you can adopt Kotlin-friendly APIs without rearchitecting your entire observability stack.

Regular Mode runs on a Kotlin-native implementation of the specification. This enables support for non-JVM targets such as iOS and JavaScript, and provides greater flexibility for client-focused optimizations. Both modes follow the OpenTelemetry specification closely and remain interoperable with the broader ecosystem.

Currently, the project includes implementations of the Tracing and Logging APIs, which are being refined based on community feedback. According to Jamie Lynch, senior software engineer at Embrace, both modes are designed to participate in OpenTelemetry's compliance review process, ensuring they meet the same standards as other language implementations.

What This Means for Kotlin Developers

The practical implications are substantial. Teams building Kotlin Multiplatform applications can now capture telemetry using one API across Android, iOS, and web targets. This eliminates the need to maintain separate observability implementations for each platform, reducing code duplication and ensuring consistent telemetry semantics.

For Android developers specifically, the Kotlin SDK provides APIs that feel natural in a Kotlin context. Instead of working around Java patterns, you can use coroutines, extension functions, and other Kotlin idioms directly in your instrumentation code. This reduces cognitive overhead and makes observability code easier to maintain alongside your application logic.

Backend teams using Kotlin for server-side development also benefit. While the Java SDK remains a solid choice for pure JVM deployments, the Kotlin SDK offers an alternative that aligns better with Kotlin's language features and can share code with client-side implementations when building full-stack Kotlin applications.

The Broader Observability Evolution

This contribution reflects a larger shift in how the industry thinks about observability. As organizations adopt OpenTelemetry for end-to-end visibility, the need for consistent telemetry across frontend, mobile, and backend systems becomes critical. Users don't experience your backend services in isolation—they interact with applications that span multiple tiers and platforms.

Understanding user experience requires correlating telemetry from the mobile app that initiated a request, through the API gateway that routed it, to the microservices that processed it, and back. When each layer uses different observability frameworks with incompatible data models, this correlation becomes difficult or impossible. OpenTelemetry's vendor-neutral approach solves this problem, but only if it supports the languages and platforms where applications actually run.

Kotlin's growth beyond Android into backend, desktop, and web environments makes native OpenTelemetry support increasingly important. JetBrains created Kotlin in 2011, reaching stable release in 2016, and it has since become one of the fastest-growing languages in the JVM ecosystem. With Kotlin Multiplatform enabling code sharing across platforms, the language is positioned to play a larger role in cross-platform development strategies.

What Comes Next

The Kotlin SDK is now part of the OpenTelemetry ecosystem, but the work is far from complete. Community feedback and real-world usage will shape its evolution. The Embrace team has committed to long-term development within the OpenTelemetry community, and they're actively seeking input from developers using the SDK in production environments.

Future development will likely focus on expanding API coverage, optimizing performance for resource-constrained environments, and refining the developer experience based on practical usage patterns. The Metrics API, which isn't yet implemented, represents an obvious next step. Integration with popular Kotlin frameworks and libraries will also be important for driving adoption.

For organizations evaluating their observability strategies, the Kotlin SDK represents an opportunity to standardize on OpenTelemetry across their entire stack, including mobile and multiplatform applications. Teams already using OpenTelemetry for backend services can now extend the same framework to their client-side code, simplifying their tooling and improving end-to-end visibility. The acceptance of this contribution signals that OpenTelemetry is maturing beyond its server-side origins into a truly comprehensive observability standard.