QUICK START:HTMLCSSJavaScriptTypeScriptPythonSQLReactNext.jsNode.jsLinux & UbuntuKotlinSwiftC# / .NETJavaGoRustC++DSASystem DesignDevOpsCybersecurityAI / ML
Advanced 24 min readModule: Module 9: Kotlin Multiplatform (KMP) & Cross-Platform Architecture

Kotlin Multiplatform (KMP) Shared Architecture

Architect cross-platform applications by sharing data models, networking, database repositories, and business logic across Android, iOS, and Web with KMP.

What You Will Learn in This Lesson

  • The KMP philosophy: Share core business logic while keeping native UI (Jetpack Compose / SwiftUI)
  • Common source sets (`commonMain`) vs Platform-specific source sets (`androidMain`, `iosMain`)
  • The `expect` / `actual` declaration mechanism for platform-specific capabilities
  • Multiplatform networking with Ktor Client and database persistence with SQLDelight

Introduction & Core Concept

Kotlin Multiplatform (KMP) is JetBrains' modern technology for sharing code across platforms without the limitations of traditional cross-platform frameworks. Unlike React Native or Flutter which abstract the UI layer and introduce heavy runtimes, KMP compiles directly to native binaries (JVM bytecode for Android, Objective-C/Swift frameworks via LLVM for iOS, WebAssembly for Web) while preserving 100% native UI performance.
WHY DOES THIS MATTER IN THE REAL WORLD?

Engineering teams at Netflix, McDonald's, VMware, and Philips use KMP to write their data layers, networking, and validation logic once, cutting codebase duplication in half while maintaining fully native user experiences.

Syntax & Structure

kotlin
// commonMain
expect class PlatformUUID() {
fun generate(): String
}
// iosMain
actual class PlatformUUID actual constructor() {
actual fun generate(): String = NSUUID().UUIDString
}

Expect/Actual Declaration for Cross-Platform Platform Information

kotlin
kotlin
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// KMP: commonMain (Shared Business Logic)
package com.kwasacademy.kmp
// 1. Declare expected platform capability in commonMain
expect class PlatformInfo() {
val platformName: String
}
// 2. Shared business logic utilizing the expect declaration
class WelcomeService(private val platformInfo: PlatformInfo) {
fun getGreeting(): String {
return "Welcome to KWAS Academy running natively on ${platformInfo.platformName}!"
}
}
// Simulated JVM / Android actual implementation (in androidMain)
class JVMPlatformInfo : PlatformInfo {
override val platformName: String = "JVM / Android 14"
}
fun main() {
val service = WelcomeService(JVMPlatformInfo())
println(service.getGreeting())
}

Line-by-Line Technical Breakdown

1Binary Output: For iOS targets, Kotlin/Native compiles the shared code into a native `.xcframework` that iOS developers import directly into Xcode and consume with standard Swift types.

Try It Yourself (Interactive Editor)

Modify the code in real-time and click Run to test live browser output and console logs.

Intelligent Code Runner & Live Sandbox[KOTLIN]
KOTLIN SOURCE EDITOR
Interactive Live Code

Common Mistakes & How to Avoid Them

#1: Attempting to share platform-specific UI code in commonMain instead of keeping UI native.

KMP's primary strength is sharing business logic, networking, and data layers, leaving UI native for maximum responsiveness.

Incorrect / Antipattern
import android.widget.TextView // In commonMain
Correct / Professional Solution
class SharedViewModel // Share logic only; render with Jetpack Compose on Android & SwiftUI on iOS

Industry Best Practices & Professional Standards

  • Keep `commonMain` free of platform-specific SDK dependencies.
  • Use Ktor Client for multiplatform HTTP networking and kotlinx.serialization for JSON parsing.
  • Use `expect` / `actual` sparingly; prefer dependency injection interfaces when possible.

Lesson Summary & Core Takeaways

  • KMP shares business logic while allowing 100% native UI rendering on iOS and Android.
  • `commonMain` contains shared code; platform sets provide `actual` implementations.
  • Compiles to native iOS frameworks without bridge overhead or virtual DOMs.