Get Started with Kotlin Multiplatform

Apa Itu Kotlin Multiplatform?

Kotlin Multiplatform (KMP) adalah teknologi dari JetBrains yang memungkinkan business logic dibagi (shared) antar platform berbeda — Android, iOS, desktop, web, bahkan backend — menggunakan bahasa Kotlin yang sama. Ini bukan framework UI, dan bukan juga sekadar tool transpiler. KMP bekerja di level compiler: kode Kotlin yang ditulis di commonMain dikompilasi ke target yang berbeda-beda sesuai platform — ke JVM bytecode untuk Android, ke native binary (lewat Kotlin/Native) untuk iOS, ke JavaScript atau Wasm untuk web.

Konsekuensinya, kode yang di-share bukan "dijalankan lewat interpreter" seperti pendekatan cross-platform lain, melainkan benar-benar dikompilasi jadi kode native di masing-masing platform. Ini yang membuat performanya sebanding dengan kode native murni, karena secara teknis memang itu yang terjadi.

Bagian yang di-share biasanya:

Model data (data class)
Business logic / use case
Networking (HTTP client, parsing response)
Local database / caching
Validasi, kalkulasi, dan logic lain yang tidak bergantung ke UI

Bagian yang tidak di-share:

UI rendering
Navigasi antar layar
Akses ke API platform-spesifik tingkat rendah (kalau belum ada library KMP-nya)

KMP vs Flutter vs React Native

Ketiganya sering disebut dalam kategori yang sama ("cross-platform"), tapi pendekatannya beda secara fundamental.

Flutter merender UI-nya sendiri lewat Skia (custom rendering engine), tidak memakai widget native platform sama sekali. Konsekuensinya, tampilan Flutter konsisten di semua platform, tapi butuh effort ekstra kalau mau benar-benar terasa "native" — misalnya animasi transisi khas iOS atau ripple effect khas Material Design harus ditiru manual.

React Native memakai jembatan (bridge) ke komponen native, jadi secara teori UI-nya "native", tapi logic aplikasi tetap jalan di JavaScript engine, dan komunikasi lewat bridge ini historically jadi sumber bottleneck performa (meski arsitektur baru, New Architecture/Fabric, sudah memperbaiki ini).

Kotlin Multiplatform berbeda pendekatan: developer yang menentukan sendiri bagian mana yang di-share dan mana yang tidak. Skenario paling umum — dan yang dipakai di tutorial ini — adalah share logic saja, UI ditulis native penuh: Jetpack Compose untuk Android, SwiftUI untuk iOS. Artinya dua tim UI (atau satu developer yang mengerjakan dua-duanya) tetap menulis UI dengan tool dan konvensi masing-masing platform, tapi logic di baliknya satu sumber kebenaran.

Ada juga opsi Compose Multiplatform, yaitu Compose yang bisa di-share juga ke iOS, desktop, dan web. Tutorial ini sengaja tidak memakai itu. Alasannya: pendekatan native UI terpisah lebih merepresentasikan kondisi tim di lapangan yang biasanya sudah punya developer Android dan developer iOS masing-masing, dengan skill set dan preferensi tooling yang berbeda. Belajar pendekatan ini juga lebih transferable — begitu paham cara kerja expect/actual dan bagaimana shared module dikonsumsi dari dua sisi, konsep yang sama berlaku untuk proyek KMP jenis apa pun, termasuk yang nanti memutuskan pakai Compose Multiplatform.

Kenapa Bukan Native Terpisah Penuh (Tanpa KMP Sama Sekali)

Pertanyaan yang wajar muncul: kalau UI tetap ditulis dua kali (native), apa untungnya dibanding bikin dua project terpisah dari awal — satu Android murni, satu iOS murni?

Jawabannya ada di bagian yang biasanya paling rawan bug dan paling banyak menyita waktu maintenance: business logic dan networking. Kalau ditulis dua kali di Kotlin dan Swift, ada risiko:

Logic parsing response API bisa beda perilaku antara dua implementasi
Bug fix harus diterapkan dua kali, dan gampang lupa satu sisi
Perubahan aturan bisnis (misalnya rumus konversi suhu, threshold cuaca ekstrem) harus disinkronkan manual

Dengan shared module, semua itu hanya ditulis dan ditest sekali. Yang beda hanya lapisan presentasi.

Arsitektur yang Dipakai

flowchart TB subgraph Shared["shared (commonMain)"] DOMAIN["Domain Layer - Model and Use Case"] DATA["Data Layer - Repository"] NET["Ktor Client - WeatherApiClient"] DOMAIN --> DATA DATA --> NET end subgraph AndroidApp["androidApp"] AVM["ViewModel (StateFlow)"] ACOMPOSE["Jetpack Compose UI"] ACOMPOSE --> AVM end subgraph IosApp["iosApp"] IOBS["ObservableObject (@Published)"] ISWIFT["SwiftUI View"] ISWIFT --> IOBS end NET -->|"Open-Meteo API"| API[("Open-Meteo REST API")] AVM --> DOMAIN IOBS --> DOMAIN

Tiga bagian utama:

1. shared module — berisi tiga layer: domain (model dan use case), data (repository), dan networking (Ktor client untuk memanggil Open-Meteo). Dipakai bersama oleh Android dan iOS, dikompilasi ke masing-masing target.

2. androidApp — UI native Jetpack Compose, mengonsumsi shared module lewat ViewModel yang mengekspos state dalam bentuk StateFlow.

3. iosApp — UI native SwiftUI, mengonsumsi shared module lewat ObservableObject yang berfungsi sebagai jembatan antara StateFlow Kotlin dan @Published Swift.

Pola ini — domain di tengah, dikonsumsi dari dua arah UI berbeda — akan berulang terus sepanjang series. Setiap kali ada fitur baru, urutannya selalu: logic dulu di shared module, baru UI Android, baru UI iOS.

Requirement

Android Studio versi Koala atau lebih baru (untuk dukungan KMP plugin yang stabil)
Xcode versi terbaru yang tersedia di Mac App Store
Kotlin Multiplatform plugin, diinstall di Android Studio
Kotlin Multiplatform Mobile plugin, untuk integrasi build ke Xcode
macOS, wajib untuk build dan run target iOS — ini keterbatasan dari Apple sendiri, bukan dari KMP, karena kompilasi ke iOS binary butuh toolchain Xcode yang hanya jalan di macOS

Tanpa akses macOS, bagian shared module dan Android tetap bisa diikuti penuh sampai selesai. Bagian iOS (Fase 3) membutuhkan akses ke Mac, baik fisik maupun lewat layanan cloud Mac seperti MacStadium atau sejenisnya.

TAGS: