Belajar Mobile Developer - Kotlin Multiplatform & Compose Multiplatform

#Pendahuluan

Di episode 5 dan 6 kita melihat dua pendekatan cross-platform dari sisi UI. Kini ada pendekatan ketiga yang sedang naik daun: Kotlin Multiplatform (KMP). Kalau RN/Flutter berbagi seluruh aplikasi (UI + logika), KMP menawarkan strategi berbeda: bagikan logika bisnisnya, biarkan UI tiap platform native. Adopsinya naik dari 7% ke 18% di 2026 — dan bersama Compose Multiplatform (CMP), kini UI pun bisa dibagi.

Mengapa ini penting? Karena banyak tim menemukan bahwa kompleksitas sebenarnya aplikasi mobile ada di business logic: validasi, networking, storage, domain model. Membaginya sekali untuk dua platform menghemat separuh pekerjaan, sementara UI tetap native dan terasa "asli" di tiap platform.

#Konsep Inti KMP

#Shared Module

Proyek KMP terdiri dari module shared yang berisi business logic lintas platform, plus aplikasi Android dan iOS yang mengonsumsinya:

FitkuKMP/
├── shared/
│   ├── src/commonMain/kotlin/   → logika yang dibagi
│   ├── src/androidMain/kotlin/  → implementasi khusus Android
│   └── src/iosMain/kotlin/      → implementasi khusus iOS
├── androidApp/                  → aplikasi Android (Kotlin/Compose)
└── iosApp/                      → aplikasi iOS (Swift/SwiftUI)

commonMain berisi logika yang tidak bergantung platform — domain model, repository, use case. Untuk bagian yang bergantung platform (misal membaca tanggal sistem), KMP memakai mekanisme expect/actual.

#expect/actual

expect mendeklarasikan "kontrak" di commonMain; actual memberikan implementasi nyata di tiap platform:

expect/actual di KMP

// commonMain: kontrak
expect fun platformName(): String
 
// androidMain: implementasi Android
actual fun platformName(): String = "Android ${Build.VERSION.SDK_INT}"
 
// iosMain: implementasi iOS
actual fun platformName(): String = "iOS ${UIDevice.currentDevice.systemVersion}"

Dengan pola ini, kalian menulis logika bisnis sekali dan memanggilnya dari kedua platform.

#Praktik: Shared Module Fitku

Mari kita bagikan domain Workout dan kalkulasi kalori ke shared module:

shared/src/commonMain: domain & logic

package com.fitku.shared
 
data class Workout(
    val name: String,
    val durationMinutes: Int,
    val intensity: Intensity,
)
 
enum class Intensity { LOW, MEDIUM, HIGH }
 
fun Workout.caloriesBurned(weightKg: Double): Double {
    val met = when (intensity) {
        Intensity.LOW -> 3.5
        Intensity.MEDIUM -> 6.0
        Intensity.HIGH -> 9.0
    }
    return met * weightKg * durationMinutes / 60.0
}
 
class WorkoutRepository(private val api: FitkuApi) {
    suspend fun sync(userId: String): List<Workout> =
        api.fetchWorkouts(userId)
}

Kemudian konsumsi dari Android:

Konsumsi shared dari Android

class WorkoutViewModel : ViewModel() {
    private val repository = WorkoutRepository(FitkuApi())
 
    fun caloriesFor(workout: Workout): Double =
        workout.caloriesBurned(weightKg = 65.0)
}

Dan dari iOS — karena shared dikompilasi ke framework, Swift bisa memanggilnya langsung:

import FitkuShared
 
let workout = Workout(name: "Lari pagi", durationMinutes: 30, intensity: .high)
let calories = workout.caloriesBurned(weightKg: 65.0)

Satu implementasi logika, dua platform memakainya — ini jantung KMP.

#Compose Multiplatform (CMP)

Jika business logic sudah dibagi, langkah berikutnya adalah berbagi UI lewat Compose Multiplatform — Compose berjalan di Android, iOS, desktop, dan web:

UI bersama dengan Compose Multiplatform

@Composable
fun HomeScreen(weightKg: Double) {
    val workouts = remember { sampleWorkouts() }
    Column(Modifier.padding(16.dp)) {
        Text("Halo, Fitku!", style = MaterialTheme.typography.headlineMedium)
        LazyColumn {
            items(workouts) { workout ->
                WorkoutRow(
                    workout = workout,
                    calories = workout.caloriesBurned(weightKg)
                )
            }
        }
    }
}

Kode UI ini berjalan di Android dan iOS dengan satu codebase. Strategi yang umum: shared UI untuk layar utama, native UI untuk detail yang butuh kedalaman platform.

#KMP vs RN vs Flutter

Pilihan bergantung konteks tim: kalian dari web → RN; ingin performa pixel-perfect → Flutter; ingin investasi di native + Android (dan tim sudah Kotlin) → KMP/CMP.

#Common Pitfalls KMP

• Ekspektasi "zero native": KMP tetap menuntut memahami Android & iOS native — bukan pengganti, tapi pelengkap.
• Menaruh kode spesifik platform di commonMain: memakai expect/actual dengan disiplin; jangan curang dengan reflection.
• Serialization antar layer: pakai kotlinx.serialization agar model JSON aman di kedua platform.
• Ignore iOS memory model: pastikan memakai konfigurasi yang benar untuk performa Swift interop.

#Penutup

Pada episode 7 ini, kalian telah menguasai pendekatan ketiga:

• KMP membagi business logic antar platform dengan expect/actual dan shared module.
• Compose Multiplatform membagi UI — strategi shared UI + native UI untuk fitur dalam.
• Perbandingan KMP vs RN vs Flutter memberi kalian kerangka memilih sesuai konteks.
• Adopsi KMP yang naik ke 18% di 2026 menjadikannya skill bernilai tinggi.

Di episode 8 selanjutnya kita beralih dari "bahasa & platform" ke cara mengorganisasi kode: Architecture Patterns (MVVM/MVI) — memisahkan UI, logika, dan data lewat Repository pattern dan dependency injection. Sampai jumpa!