Share the Brain, Keep the Face: Why KMP Beats Traditional Cross-Platform

Building separate native applications for iOS and Android forces teams to pay twice for the exact same business logic. Two engineering silos rewrite the same data models, networking stacks, offline caching logic, and state management rules. The result is feature drift, mismatched release schedules, and double the testing overhead.

Cross-platform solutions promised to eliminate this duplication. For years, the industry traded native performance for developer convenience. Kotlin Multiplatform (KMP) and Compose Multiplatform (CMP) take a different approach: split the application into logic and presentation, sharing only what makes architectural sense.

Here is how KMP and CMP compare against React Native and Flutter, how the underlying rendering pipelines work, and how to structure a cross-platform codebase without sacrificing native performance.

Deconstructing an App: The Brain and the Face

Every mobile application splits cleanly into two distinct layers:

1. The Brain (Business Logic): Data models, local SQLite databases, network clients, authentication flows, validation rules, and state holders. This code has no dependency on screen pixels or platform UI toolkits.
2. The Face (User Interface): Buttons, typography, navigation transitions, touch gestures, and accessibility hooks. This code depends entirely on platform design conventions and UI rendering pipelines.

Traditional native development duplicates both layers. React Native and Flutter attempt to unify both layers under a single external runtime. KMP gives you the choice to share the brain while keeping the native face, or share both using declarative Compose.

How the Three Cross-Platform Paradigms Work

The fundamental difference between modern cross-platform frameworks is not the programming language. It is where they draw the boundary between shared code and the host operating system.

1. React Native: Orchestrating Native Views via JavaScript

React Native runs application logic in a JavaScript engine like Hermes. In the New Architecture, it uses JavaScript Interface (JSI) to call C++ and native platform APIs synchronously.

• How UI renders: React components map to platform UI elements (such as UIView on iOS and android.view.View on Android) via the Fabric renderer.
• Code shared: Typically 85% to 95% of the codebase.
• The reality: While UI components look native, the app carries the overhead of the JavaScript engine, runtime garbage collection, and object marshaling across the C++ boundary. Under heavy animation or rapid state dispatch, this causes dropped frames.

2. Flutter: Drawing Every Pixel on a Custom Canvas

Flutter bypasses the platform UI hierarchy completely. It bundles its own rendering engine (Impeller on iOS and Android) and controls every pixel drawn to a single fullscreen canvas.

• How UI renders: Flutter handles layout calculation, hit testing, and GPU rasterization inside the Dart runtime. It does not use iOS UIKit or Android Views.
• Code shared: 95% to 99% of the codebase.
• The reality: UI rendering is consistent and runs at high frame rates (up to 120 FPS). However, the app ignores native OS styling changes, accessibility tools require manual framework mapping, and the bundled engine increases base memory consumption.

3. KMP & CMP: Native Compilation and Direct Execution

Kotlin Multiplatform does not introduce a runtime engine or a foreign bridge.

• Shared Logic Only (KMP): Shared Kotlin code compiles to JVM bytecode for Android and standalone native machine code via Kotlin/Native (LLVM) for iOS. You write business logic once in Kotlin, then write the UI natively using Jetpack Compose on Android and SwiftUI on iOS. Code sharing is typically 50% to 70%.
• Unified UI (Compose Multiplatform): CMP takes the declarative Jetpack Compose compiler and runtime and targets Android, iOS, Desktop, and Web. On Android, it renders directly through the native Android graphics pipeline. On iOS, it renders via Skiko and Skia directly onto a Metal canvas.

Hardware and Rendering Performance

Different runtime models produce measurable differences in memory and execution speed.

Idle Memory Consumption

Because Flutter bundles a full rendering engine and React Native initializes a JavaScript runtime, their baseline resource footprint is higher than pure native binaries.

• Kotlin Multiplatform (Native Logic): ~96 MB idle RAM. Compiles directly to native machine code with a minimal runtime footprint.
• Flutter: ~253 MB idle RAM. Carries the engine, Dart VM, and internal layout trees.
• React Native (Fabric): Sits between KMP and Flutter, with memory scaling based on JS bundle complexity and native bridge caches.

Execution Overhead

When shared Kotlin code runs on iOS, it executes as compiled native ARM machine instructions. A network call or cryptographic hash calculation in KMP runs at the same speed as Swift or Objective-C code, with direct memory access and zero serialization cost.

Handling Platform Specifics: The expect/actual Mechanism

When shared code needs to interact with hardware or platform-specific APIs (such as secure hardware keys, Bluetooth, or biometric prompts), KMP uses the expect/actual mechanism.

Unlike Flutter platform channels or React Native native modules, expect/actual is resolved at compile time. There is no string-based message passing, JSON serialization, or runtime dictionary lookup.

Example: Platform Identifiers and Device Information

In the shared module (commonMain), define the expected declaration:

// commonMain
expect class DeviceInfo() {
    val platformName: String
    val osVersion: String
    fun getHardwareId(): String
}

In the Android source set (androidMain), implement the actual class using standard Android SDK APIs:

// androidMain
import android.os.Build
import java.util.UUID

actual class DeviceInfo {
    actual val platformName: String = "Android"
    actual val osVersion: String = Build.VERSION.RELEASE
    actual fun getHardwareId(): String = UUID.randomUUID().toString()
}

In the iOS source set (iosMain), implement the actual class using iOS system frameworks:

// iosMain
import platform.UIKit.UIDevice
import platform.Foundation.NSUUID

actual class DeviceInfo {
    actual val platformName: String = UIDevice.currentDevice.systemName
    actual val osVersion: String = UIDevice.currentDevice.systemVersion
    actual fun getHardwareId(): String = NSUUID().UUIDString
}

During compilation, the Kotlin compiler merges the expect contract with the target’s actual implementation into a single binary.

Declarative UI in Action: Jetpack Compose and CMP

Declarative UI treats the visual layout as a direct transformation of state: UI = f(State). When state updates, the runtime recalculates only the composable functions affected by that state change.

@Composable
fun MetricCounter(initialCount: Int = 0) {
    var count by remember { mutableIntStateOf(initialCount) }

    Column(
        modifier = Modifier
            .fillMaxWidth()
            .padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(
            text = "Total Events: $count",
            style = MaterialTheme.typography.headlineSmall
        )
        Spacer(modifier = Modifier.height(12.dp))
        Button(onClick = { count++ }) {
            Text("Register Event")
        }
    }
}

In standard KMP, this composable runs on Android while an equivalent SwiftUI view runs on iOS, both observing the same Kotlin ViewModel or state flow. In Compose Multiplatform, this exact composable function runs across Android, iOS, desktop, and web without modification.

The Year-Three Maintenance Tax

The long-term cost of a cross-platform framework is determined by how it handles major operating system upgrades.

When Apple or Google releases a major OS update with new system gestures, font scaling rules, or UI components:

• Custom Engine Frameworks (Flutter): Must wait for the framework maintainers to reimplement new iOS or Android visual behaviors inside Dart.
• Bridge Frameworks (React Native): Must update bridge bindings, Fabric component wrappers, and third-party native modules.
• KMP (Shared Logic): Incurs zero UI breakage from OS updates. Because the UI is written in native SwiftUI and Jetpack Compose, the app inherits all system appearance updates, new hardware APIs, and accessibility improvements immediately.
• Shared Kotlin Code: Continues running unaffected because data structures, network requests, and database schemas do not change when the host OS updates its visual styling.

Enterprise Adoption: Who Uses What in Production

Major technology companies choose their stack based on architecture constraints rather than framework popularity:

• Kotlin Multiplatform: Used by Netflix, McDonald’s, Philips, 9GAG, and X (formerly Twitter). X migrated core client networking, data serialization, and business logic to KMP, achieving 3x developer leverage while keeping 100% native UI performance on each platform.
• React Native: Used by Shopify, Discord, and Instagram. Best suited for organizations with large JavaScript/React web teams that need fast feature rollout across mobile and web.
• Flutter: Used by BMW, Nubank, and Google Pay. Best suited for applications requiring custom 2D canvas rendering and highly stylized, brand-first interfaces that look identical on all devices.

The Framework Decision Matrix

To select the right architecture, evaluate your team and product constraints:

Constraint	Recommended Architecture	Reason
Existing Web/React team & tight release timeline	React Native	Reuses existing JavaScript expertise and component ecosystems.
Custom, branded UI & heavy graphics/canvas needs	Flutter	Delivers consistent custom rendering across platforms via Impeller.
Existing native app, critical performance & deep OS integration	KMP (Shared Logic)	Allows incremental adoption without rewriting native UI or degrading UX.
Pure Kotlin engineering team building across mobile & desktop	Compose Multiplatform	Maximizes code reuse across UI and logic using standard Jetpack Compose.

Engineering Principles

1. Build for the developers you can hire. Align technology choices with team competencies rather than chasing trends.
2. Match performance to user expectations. If an app depends on heavy native integrations or background processing, compile to native binaries.
3. Architect for long-term maintenance. Isolate business logic from UI frameworks so that presentation updates never break core domain rules.