OpenTelemetry has become the de facto standard for collecting and exporting telemetry data across cloud native systems. Its success has been driven by strong community collaboration, a clear specification, and a growing ecosystem of language-specific SDKs and platform integrations.
In recent years, client-side and mobile observability has become an area of increasing focus within the OpenTelemetry community, particularly for teams building applications in Kotlin and Kotlin Multiplatform (KMP). In 2025, Embrace, a user-focused observability platform and active OpenTelemetry contributor, opened a proposal to contribute a Kotlin implementation of the OpenTelemetry specification to the community.
We’re pleased to announce that the contribution of Embrace’s Kotlin API and SDK to OpenTelemetry has been accepted. The project expands vendor-neutral observability support across client- and server-side applications written in Kotlin. It establishes a foundation for a community-owned Kotlin SDK and allows KMP and Kotlin projects to capture telemetry using one API for many different platforms.
This post discusses how the Kotlin SDK fits into the OpenTelemetry ecosystem and outlines its current and future direction.
Why Kotlin Matters in the OpenTelemetry Ecosystem
Kotlin has become the default language for modern Android development and is increasingly used across backend, desktop, and web environments. With the growth of KMP, teams can now share significant portions of application logic across Android, iOS, and other targets using a single codebase.
For observability, this shift creates both an opportunity and a challenge.
Historically, most Kotlin applications have relied on the OpenTelemetry Java SDK through language interoperability. While this approach works well for JVM-based services, it has several limitations:
- It does not support non-JVM targets used in KMP
- The API reflects Java design patterns rather than Kotlin idioms
- It makes backend-oriented assumptions about execution models and lifecycle
As Kotlin adoption continues to expand beyond the JVM, these limitations become more significant. A native Kotlin implementation allows OpenTelemetry to support this ecosystem directly, rather than indirectly through Java.
Mobile and Client-Side Observability Have Different Constraints than Backend Systems
Client and mobile runtimes operate under very different performance, lifecycle, and reliability constraints than traditional server environments.
My colleague, Hanson Ho, Android Architect at Embrace, spoke about this at the CNCF’s first Open Observability Summit, where he presented the talk, “Beyond Good Enough: Why We Want a Kotlin API and SDK.” The session addressed the constraints of mobile environments, like battery, network, and storage, and how OpenTelemetry can be adapted accordingly.
Hanson stated, “…observability isn’t just about collecting more data. It’s about understanding user workflows, context, and outcomes in environments where performance, connectivity, and lifecycle constraints are fundamentally different.”
Applications in these environments must account for:
- Intermittent connectivity
- Frequent process termination by the operating system
- Limited CPU and memory budgets
- Highly asynchronous execution models
- User-driven workflows that may span multiple sessions
These realities affect how telemetry is generated, buffered, correlated, and exported. Backend-focused SDKs are not always optimized for these conditions.
A Kotlin implementation provides an opportunity to design APIs and runtime behavior that better match these environments while still conforming to the OpenTelemetry specification. This becomes increasingly important as organizations adopt OpenTelemetry for end-to-end observability across frontend, mobile, and backend systems.
The Kotlin SDK Contribution
The contributed project is a KMP implementation of the OpenTelemetry specification, designed to support both JVM and non-JVM environments.
The project participates in OpenTelemetry’s compliance review process, and it currently supports two primary modes of operation:
- Compatibility Mode: In this mode, the Kotlin API interoperates with the OpenTelemetry Java SDK. This allows Android and JVM users to adopt an idiomatic Kotlin interface while continuing to rely on the mature opentelemetry-java SDK. It provides a low-friction migration path for teams with existing OpenTelemetry instrumentation.
- Regular Mode: In this mode, the SDK 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 are designed to follow the OpenTelemetry specification closely and remain interoperable with the broader ecosystem.
At present, the project includes implementations of the Tracing and Logging APIs, which are being refined based on community feedback.
Current State of the Project
The OpenTelemetry Kotlin Special Interest Group (SIG) meets regularly and provides a forum for design discussion, roadmap planning, and community collaboration. There are scheduled meetings as well as ongoing discussions in the CNCF Slack in the #otel-kotlin channel.
Key characteristics of the project today include:
- Support for Android, JVM, iOS, and JavaScript targets
- Production usage on Android
- Experimental status for core APIs
- Ongoing work on various APIs
- Active community feedback and iteration
As with other OpenTelemetry language SDKs, stability and long-term support are central priorities. The project follows established governance, security, and review processes under CNCF stewardship.
Why This Matters for the OpenTelemetry and Cloud Native Ecosystems
A Kotlin SDK expands OpenTelemetry’s coverage into modern client and multiplatform runtimes, strengthening its role as a unified observability standard across the cloud native stack.
More specifically, it contributes to several ongoing shifts in how observability is adopted and implemented across the ecosystem, including:
- Expanding end-to-end observability: Organizations increasingly seek unified visibility across frontend, mobile, and backend systems. KMP support enables consistent instrumentation of shared application logic across these layers.
- Supporting purpose-built language SDKs: The community is moving toward SDKs designed for specific runtimes and execution environments. This mirrors recent work in browser, mobile, and edge observability.
- Lowering barriers to adoption: Providing idiomatic, well-supported Kotlin APIs reduces friction for developers and helps bring new contributors into CNCF projects.
- Strengthening vendor-neutral foundations: Placing the Kotlin SDK under OpenTelemetry governance ensures development remains transparent, community-driven, and aligned with open standards. This governance model is a critical step, ensuring that organizations adopting the Kotlin SDK can rely on transparent development and a long-term roadmap free from single-vendor constraints.
Where the Project Is Going
Looking ahead, the Kotlin SIG is evaluating several additions and improvements, including:
- Stabilizing the Tracing and Logging APIs
- Improving exporter and processor support
- Expanding platform coverage
- Enhancing documentation and onboarding materials
- Attracting additional maintainers and contributors
- Refining mobile and client-specific runtime behavior
A long-term goal is to make OpenTelemetry feel natural and accessible to Kotlin developers, regardless of where their applications run.
Toward End-to-End Observability Across Platforms
OpenTelemetry’s growth has been driven by a commitment to interoperability, openness, and practical engineering needs. Community feedback and real-world usage will remain central to shaping these efforts.
The team at Embrace is honored that the contribution of the Kotlin SDK has been accepted and remains committed to its long-term development within the OpenTelemetry community. We look forward to continuing this work in collaboration with maintainers and contributors across the ecosystem. More information about Embrace’s open source work is available at https://embrace.io.
How To Get Involved
Community participation is essential to the success of this project. Developers interested in contributing or providing feedback can:
- Explore the repository: https://github.com/open-telemetry/opentelemetry-kotlin
- Join the Kotlin SIG meetings
- Participate in the #otel-kotlin channel on CNCF Slack: https://slack.cncf.io
- Open issues and proposals on GitHub: https://github.com/open-telemetry/opentelemetry-kotlin
Early feedback is especially valuable as the project continues to mature.