Production-Grade Kotlin Multiplatform SDKs: A Practical Guide

Last updated: October 12, 2026

Kotlin Multiplatform has matured past the "Hello World" stage for shared SDKs, and a new hands-on guide on ProAndroidDev walks through what a production-grade shared SDK actually looks like when it ships a `.aar` to Android and an `.xcframework` to iOS. Alongside it, PR Newswire reports that Embrace has donated its Kotlin and KMP implementation to OpenTelemetry, expanding vendor-neutral observability into the Kotlin world.

Together, the two pieces sketch a clearer picture of where KMP sits in 2026: not a toy, not yet a default, but a serious option for teams that own business logic across platforms.

At a glance

• ProAndroidDev guide covers SDK architecture, project layout, circuit breakers, and DI for shipping a real KMP SDK.
• PR Newswire release dated March 24, 2026: Embrace's Kotlin and KMP implementation accepted into OpenTelemetry.
• The contribution adds tracing and logging APIs at the time of donation.
• The implementation supports both JVM and non-JVM (client-side, mobile, web) modes of operation.
• Quoted framing: Andrew Tunall, President and CPO at Embrace, called it an "exciting moment for the ecosystem."

Background: why KMP for SDKs, not apps

Cross-platform has historically meant compromise: a shared UI layer paid for with bridge overhead or rendering oddities. KMP takes a different route. It shares the logic and keeps the platform UI native. For an SDK that exposes API clients, auth, and data models, that is exactly the right cut.

The architectural pattern is well established now: `commonMain` for shared business logic and models, `androidMain` and `iosMain` for platform-specific engines (OkHttp on Android, Darwin on iOS), and `expect`/`actual` declarations for the seams. The ProAndroidDev guide pushes that further with circuit breakers, Koin DI modules, and an explicit feature module structure (`facade`, `repository`, `requestbuilder`, `models`).

The OpenTelemetry donation matters because observability is one of the few SDK categories every app needs and almost nobody wants to build. A vendor-neutral Kotlin implementation lowers the cost of adding tracing and logging to KMP codebases, which is exactly where shared logic tends to hide the most interesting bugs.

Our analysis

The interesting design decision in the guide is treating the SDK as a dependency for other teams. That changes the rules. Public APIs become contracts. State has to be exposed as a sealed class so host apps can render UI without leaking internals. Caching, retries, and deduplication belong in the shared layer because host apps will not implement them consistently.

The Embrace donation is the more strategically significant story. Until now, KMP code either fell back to Java interop (with a JVM requirement) or shipped its own observability story from scratch. A donated OpenTelemetry implementation gives KMP teams a standard answer, and standards compound. The contribution supports two modes, JVM and non-JVM, which is the right call for code that may run on iOS where the JVM is not available.

Who benefits: platform teams shipping SDKs to multiple host apps, and any KMP codebase that has been hand-rolling telemetry. Who loses: vendors whose closed observability SDKs just became the more expensive option.

What to watch:

• Whether the OpenTelemetry project merges the contribution in a form that tracks upstream specs.
• Whether Google or JetBrains publishes a reference KMP project layout that converges on the patterns in the guide.
• Whether the circuit-breaker and DI patterns become standard advice in KMP SDK templates.

A practical scenario

Say you lead a mobile platform team that ships a payments SDK to four host apps across Android and iOS. Today the SDK is duplicated, the two implementations drift on retry logic, and observability is whatever the host app happens to log. You adopt the guide's layout: shared `ApiClient` with Ktor, Koin for DI, a circuit breaker around the token endpoint, and a sealed `SDKState` for host apps to render.

You also pull in the OpenTelemetry Kotlin SDK, switch on tracing for the API client, and ship a span around each retry attempt. Now the two platforms agree on what a successful payment looks like in your tracing backend, and your SDK team's on-call rotation has actual signal.

Bottom line

KMP SDKs are no longer experimental, and the ecosystem is filling in around them. Use the guide as a reference architecture for shared business logic, and treat the OpenTelemetry donation as the missing observability layer. If you are still duplicating Kotlin and Swift logic across two repositories, this is the quarter to plan the migration.

Key takeaways

• KMP works best for SDKs that share business logic, not for shared UI shells.
• A clean project layout with `commonMain`, `androidMain`, `iosMain`, and feature modules is the single biggest maintainability decision.
• Embrace's OpenTelemetry donation gives KMP teams a vendor-neutral observability option with both JVM and non-JVM support.