Kotlin Multiplatform in 2026: Sharing Code Between Android, iOS and Web

Why Kotlin Multiplatform Matters More Than Ever in 2026

The promise of “write once, run anywhere” has been chasing the software industry for decades. Java applets tried it. Cordova tried it. React Native and Flutter pushed it further. But none of these solutions fully resolved the tension between code reuse and native quality.

Kotlin Multiplatform (KMP) takes a different path. Instead of forcing every platform into the same rendering pipeline, it lets you share the layers that make sense—business logic, networking, data persistence, validation—while giving each platform the freedom to render its own native UI.

In 2026, this approach has moved from experimental curiosity to mainstream adoption. According to JetBrains’ annual developer survey, more than 15% of professional Kotlin developers now use KMP in at least one production project, up from roughly 6% in 2023. Google itself ships KMP modules inside several of its flagship apps.

Let’s explore what makes KMP the most pragmatic cross-platform strategy available today—and how your team can leverage it.

Understanding the KMP Architecture

The Shared Module

At the heart of every KMP project sits a shared module (often called shared or commonMain). This module contains pure Kotlin code that compiles to:

• JVM bytecode for Android (or server-side)
• Native binaries via Kotlin/Native for iOS (ARM64, x86-64 simulator)
• JavaScript or Wasm via Kotlin/JS and Kotlin/Wasm for the web

Because the Kotlin compiler handles the translation, you write business logic once and get platform-optimized output for each target.

The expect/actual Mechanism

When you do need platform-specific behavior—say, accessing the iOS Keychain or the Android SharedPreferences—KMP provides the expect/actual pattern:

// commonMain
expect class SecureStorage {
    fun save(key: String, value: String)
    fun read(key: String): String?
}

// androidMain
actual class SecureStorage(private val context: Context) {
    private val prefs = EncryptedSharedPreferences.create(
        "secure_prefs",
        MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC),
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )
    actual fun save(key: String, value: String) { prefs.edit().putString(key, value).apply() }
    actual fun read(key: String): String? = prefs.getString(key, null)
}

// iosMain
actual class SecureStorage {
    actual fun save(key: String, value: String) {
        // Keychain Services API wrapper
        KeychainWrapper.standard.set(value, forKey: key)
    }
    actual fun read(key: String): String? {
        return KeychainWrapper.standard.string(forKey: key)
    }
}

This mechanism is explicit, type-safe, and avoids the hidden bridges that often cause runtime surprises in other frameworks.

Where Compose Multiplatform Fits In

Since JetBrains marked Compose Multiplatform for iOS as stable in mid-2025, teams now have the option of sharing UI code as well. The stack looks like this:

Layer	Shared?	Technology
Business logic	✅ Yes	Kotlin common code
Data / networking	✅ Yes	Ktor, SQLDelight, Koin, Kotlinx.serialization
UI (optional)	✅ Yes	Compose Multiplatform
Platform APIs	🔀 Partial	expect/actual, platform modules
OS-level services	❌ No	Native SDK calls

You can share as little or as much as your project requires. An e-commerce app might share only the cart logic and API layer. A content-driven app might share 90% of its UI with Compose Multiplatform. The choice is yours.

KMP vs. Flutter vs. React Native: A 2026 Comparison

The cross-platform landscape is rich, and choosing the right tool depends on context. Here’s an honest comparison as of 2026:

Criteria	Kotlin Multiplatform	Flutter	React Native
Language	Kotlin	Dart	JavaScript / TypeScript
UI approach	Native or Compose Multiplatform	Skia / Impeller rendering	Native components via bridge / Fabric
Code sharing model	Logic-first, UI optional	Full stack	Full stack
iOS performance	Near-native (compiled)	Near-native (compiled)	Improving (JSI + Fabric)
Web target	Kotlin/Wasm (maturing)	Flutter Web (canvas-based)	React (DOM-based, mature)
Ecosystem maturity	Growing rapidly	Mature	Very mature
Ideal for	Teams with existing Kotlin / native skills	Greenfield apps, rapid prototyping	Teams with strong JS / React skills
Typical shared code	50–80%	90–100%	85–100%

When KMP Is the Stronger Choice

• You already have a native Android codebase and want to extend logic to iOS without a full rewrite.
• Platform-specific UX matters deeply (banking, health, luxury retail).
• You need a web target that lives as a “real” web app, not a canvas render.
• Your team knows Kotlin and you want to capitalize on that investment.

At Lueur Externe, we’ve observed this pattern repeatedly with our clients across the Alpes-Maritimes region and beyond: companies that already invested in a solid Android app find KMP the fastest and least risky path to iOS parity.

Real-World Adoption: Who Uses KMP in Production?

KMP is no longer a niche experiment. Here are notable adopters as of 2026:

• Netflix – shares logic for parts of its studio tooling and internal apps.
• McDonald’s – the global ordering app shares networking and business rules via KMP.
• Cash App (Block) – one of the earliest large-scale KMP adopters; shares the entire transaction engine.
• Forbes – rebuilt its mobile apps with KMP to unify content delivery logic.
• Philips – uses KMP for connected health device SDKs that run on Android, iOS, and cloud services.
• Google Workspace – Google Docs, Sheets, and Slides teams use KMP internally to share document-processing logic.

These companies report 30–50% reductions in feature delivery time once the shared module is established. Bug fixes in shared logic propagate to all platforms simultaneously—a massive win for QA teams.

Setting Up a KMP Project in 2026: A Practical Overview

Step 1 — Project Scaffolding

JetBrains provides an official wizard at kmp.jetbrains.com. Select your targets (Android, iOS, Web, Desktop), pick your libraries, and download a ready-to-build Gradle project.

Alternatively, in Android Studio Meerkat (2026) or JetBrains Fleet, you can create a KMP project from the New Project dialog.

Step 2 — Choose Your Shared Libraries

The KMP ecosystem has matured considerably. Key libraries include:

• Ktor – multiplatform HTTP client and server
• SQLDelight – type-safe SQL with drivers for Android (SQLite), iOS (native SQLite), JS (SQL.js), and Wasm
• Kotlinx.serialization – JSON / Protobuf / CBOR parsing without reflection
• Koin / Kodein – lightweight dependency injection
• Kotlinx.datetime – cross-platform date/time handling
• Multiplatform Settings – key-value storage abstraction
• Compose Multiplatform – shared declarative UI

Step 3 — Structure Your Shared Code

A clean architecture for KMP typically follows these layers inside the shared module:

shared/
├── commonMain/
│   ├── data/          // Repositories, DTOs
│   ├── domain/        // Use cases, business rules
│   ├── network/       // Ktor client setup, API definitions
│   └── di/            // Koin modules
├── androidMain/       // Android-specific implementations
├── iosMain/           // iOS-specific implementations
└── wasmJsMain/        // Web-specific implementations

Platform apps (the Android app module, the Xcode project, the web app) then depend on this shared module and provide their own UI layer.

Step 4 — Integrate with iOS

KMP compiles to an XCFramework that you import into Xcode. In 2026, integration is seamless:

• Direct Gradle-Xcode linking via the embedAndSignAppleFrameworkForXcode Gradle task.
• Swift-friendly APIs thanks to improved Kotlin/Native-Objective-C interop and the experimental Swift export feature.
• SPM support – you can publish your shared module as a Swift Package Manager dependency.

iOS developers interact with KMP code as if it were a native Swift framework. No bridging headers, no manual setup.

Step 5 — Target the Web with Kotlin/Wasm

Kotlin/Wasm reached beta in 2024 and is now stable for Compose Multiplatform web targets. A shared UI written in Compose can render in the browser via WebAssembly with near-native performance.

For traditional web apps, Kotlin/JS remains a solid option, integrating with existing React or vanilla JS frontends. The shared module exports JavaScript bindings that your frontend code can call directly:

// In jsMain
@JsExport
fun calculateShippingCost(cartJson: String): Double {
    val cart = Json.decodeFromString<Cart>(cartJson)
    return ShippingCalculator.compute(cart)
}

This means your web checkout page uses the exact same shipping logic as your mobile apps. No drift, no duplication.

Performance Benchmarks: Does KMP Hold Up?

Performance concerns were legitimate in KMP’s early days, particularly around Kotlin/Native garbage collection. The new concurrent, tracing GC introduced in Kotlin 2.0 resolved those issues. Benchmark highlights in 2026:

• Android: KMP shared code runs on the JVM—zero overhead compared to a pure-Kotlin Android app.
• iOS: Kotlin/Native performance is within 5–10% of equivalent Swift code for CPU-bound tasks. For I/O-bound logic (networking, database), the difference is negligible.
• Web (Wasm): Compose Multiplatform Wasm bundles are 40–60% smaller than equivalent Flutter Web builds and render through the DOM compositor, offering better accessibility and SEO.

For the vast majority of business applications, KMP introduces no perceptible performance penalty.

Common Pitfalls and How to Avoid Them

Having helped multiple clients adopt cross-platform strategies, the team at Lueur Externe has identified recurring mistakes:

• Sharing too much, too soon. Start with the data and domain layers. Prove the approach before moving UI into the shared module.
• Ignoring iOS developers. KMP succeeds when iOS engineers feel ownership. Involve them early, let them shape the expect/actual contracts.
• Overusing expect/actual. If you find yourself writing more actual implementations than common code, reconsider your abstraction. Community libraries often already solve the problem.
• Neglecting testing. commonTest lets you write tests once that run on every target. Use it extensively. Platform-specific tests should cover only actual implementations.
• Skipping CI/CD setup. Build all targets in CI from day one. A macOS runner is required for iOS compilation—plan your pipeline accordingly.

The Web Target: Still Maturing but Viable

Let’s be candid: while Android and iOS targets are battle-tested, the web target is the youngest link in the KMP chain. Kotlin/Wasm is stable, but the surrounding ecosystem (routing, SSR, hydration) is less mature than React or Next.js.

That said, for specific use cases—progressive web apps, admin dashboards, internal tools, or shared widgets embedded in an existing site—Kotlin/Wasm with Compose Multiplatform is a compelling option. You get a single codebase for mobile and web with consistent behavior and near-identical UI.

For public-facing marketing sites where SEO and time-to-first-byte are paramount, a traditional server-rendered approach (WordPress, for instance, which Lueur Externe deploys and optimizes regularly) remains the better choice. The key is using the right tool for each job.

What’s Coming Next: The 2026–2027 Roadmap

JetBrains and Google continue to invest heavily in KMP. Expected milestones include:

• Swift export stabilization – call Kotlin code from Swift with fully idiomatic syntax, no Objective-C interop layer.
• Gradle improvements – faster incremental builds for multi-target projects, improved dependency resolution.
• Compose Multiplatform for web maturity – server-side rendering support, improved bundle sizes, broader browser API access.
• Wider Google library KMP support – more Jetpack libraries (Room, DataStore, WorkManager) shipping with KMP artifacts.
• Kotlin 2.2 – further compiler performance improvements and language features like named-based overloading and union types.

The trajectory is clear: KMP is becoming the default strategy for teams that value both code reuse and native excellence.

Should You Adopt KMP for Your Next Project?

Here’s a quick decision framework:

• ✅ You have or plan an Android + iOS app with significant shared logic.
• ✅ Your team includes Kotlin developers (or developers willing to learn).
• ✅ You value native UI fidelity or want the option to go fully shared later.
• ✅ You want to extend shared logic to a web dashboard or backend.
• ⚠️ Your entire team is JavaScript-only → React Native may be a faster start.
• ⚠️ You need pixel-perfect identical UI on all platforms with minimal effort → Flutter may be more practical.

There is no universal winner in cross-platform development. But for an increasing number of teams, KMP offers the best balance of flexibility, performance, and long-term maintainability.

Conclusion: Code Sharing Without Compromise

Kotlin Multiplatform in 2026 delivers on a nuanced promise: share what should be shared, keep native what should be native. It doesn’t pretend that Android, iOS, and the web are the same—it acknowledges their differences while eliminating the redundancy that slows teams down.

Whether you’re modernizing an existing Android app, building a greenfield product for three platforms, or looking to consolidate fragmented business logic, KMP deserves serious consideration.

If you’re evaluating Kotlin Multiplatform for your mobile or cross-platform project and want experienced guidance, Lueur Externe can help. With over two decades of web and mobile expertise, certifications across Prestashop, AWS, and WordPress, and deep SEO knowledge, our team in the Alpes-Maritimes builds solutions that perform on every platform. Get in touch today and let’s turn your multiplatform vision into production-ready reality.