Kotlin Multiplatform Mobile — ano ito, mga pangunahing konsepto at arkitektura ng KMM

Ano ang Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) — ay isang teknolohiya na nagpapahintulot sa pagsulat ng shared business logic ng isang mobile application sa Kotlin at paggamit nito sa iOS at Android nang walang pagdodoble ng code. Hindi tulad ng Ionic o Cordova, hindi nire-render ng KMM ang interface sa WebView — ang UI ay nananatiling ganap na native at isinusulat sa SwiftUI (iOS) at Jetpack Compose (Android).

Ang KMM ay inanunsyo ng JetBrains noong 2019 bilang bahagi ng Kotlin Multiplatform strategy. Ang pangunahing pagkakaiba sa iba pang cross-platform na solusyon — ang framework ay hindi sumusubok na pag-isahin ang UI, sa halip ay nakatuon sa pagbabahagi ng mismong code na talagang pareho para sa parehong platform: mga network request, modelo ng data, validation ng form, mga panuntunan ng negosyo at pagtatrabaho sa mga database.

Ayon sa JetBrains Developer Survey (2025), ang KMM ay ginagamit ng 14% ng mga mobile developer, at ang bilang na ito ay lumalaki ng 5% taun-taon. Ang teknolohiya ay pinipili ng mga kumpanyang may mataas na pangangailangan sa performance at native na karanasan ng user, kung saan ang mga hybrid na solusyon ay hindi katanggap-tanggap.

Arkitektura ng KMM: shared module at mga implementasyon ng platform

Ang arkitektura ng KMM ay binubuo ng tatlong module: shared (shared code sa Kotlin), iosApp (native iOS application sa Swift) at androidApp (native Android application sa Kotlin). Ang shared module ay kino-compile sa JAR para sa Android at sa isang unibersal na framework (Apple Framework) para sa iOS.

Shared module: ano ang isinasama sa shared code

Sa shared module pumapasok ang lahat ng layer na hindi nakadepende sa platform: network layer sa Ktor Client, mga modelo ng data na may serialization sa pamamagitan ng kotlinx.serialization, mga repository para sa pamamahala ng data, validation ng form at mga panuntunan ng negosyo (halimbawa, pagkalkula ng halaga ng pagpapadala o pagsuri ng mga karapatan sa pag-access).

Ang shared module ay gumagamit ng Gradle Multiplatform Plugin at naglalaman ng tatlong set ng source: commonMain (shared code), androidMain (mga implementasyong spesipiko sa Android) at iosMain (mga implementasyong spesipiko sa iOS). Ang Kotlin/Native compiler ay ginagawang native library para sa iOS ang shared code, na kumokonekta sa Swift project sa pamamagitan ng XCFramework.

Mga module ng platform

Android module — ay isang standard na Android application sa Kotlin na may Jetpack Compose o ViewBinding. Ang shared module ay kumokonekta bilang isang ordinaryong Gradle dependency, at lahat ng klase mula sa commonMain ay direktang maa-access.

iOS module — ay isang Xcode project sa Swift o Objective-C. Ang shared module ay kumokonekta sa pamamagitan ng CocoaPods, Swift Package Manager o XCFramework. Ang Kotlin/Native ay gumagawa ng Objective-C headers para sa pag-export ng mga Kotlin type, ginagawa itong maa-access mula sa Swift.

Mekanismo ng expect/actual sa KMM

expect/actual — ay isang Kotlin Multiplatform na mekanismo na nagpapahintulot sa pagdeklara ng API sa shared code (expect declaration) at pagbibigay ng implementasyon nito nang hiwalay para sa bawat platform (actual declaration). Tinitiyak ng compiler na mayroong actual para sa bawat target na platform.

Mga tipikal na senaryo ng paggamit ng expect/actual: pagkuha ng kasalukuyang oras na isinasaalang-alang ang time zone, pagtatrabaho sa SharedPreferences (Android) / UserDefaults (iOS), mga cryptographic function at pagbuo ng UUID. Sa bawat platform, ginagamit ang sariling system API.

Kung walang expect/actual, imposibleng magkaroon ng pare-parehong code ng lohika ng negosyo, dahil ang mga API para sa pagtatrabaho sa file system, network at storage ay nagkakaiba sa pagitan ng iOS at Android sa antas ng system calls. Ginagarantiya ng mekanismo na hindi makakalimutan ng developer na i-implement ang bahagi ng platform.

Para sa mga platform call tulad ng pagtatrabaho sa camera o biometry, nag-aalok ang KMM ng expect/actual library kasama ng mga plugin na katulad ng Cordova, ngunit sa Kotlin/Native. Ang JetBrains ay naglabas din ng library na kotlinx-datetime na nag-aabstrak ng pagtatrabaho sa mga petsa.

Mga halimbawa ng code sa KMM

Tingnan natin ang pangunahing istraktura ng isang KMM project na may deklarasyon ng expect function para sa pagbuo ng UUID at implementasyon nito para sa iOS at Android.

// commonMain — shared declaration
expect fun generateUUID(): String

// androidMain — implementasyon para sa Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — implementasyon para sa iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

Sa shared code, idineklara ang expect fun generateUUID(). Para sa Android, ginagamit ang java.util.UUID, para sa iOS — NSUUID mula sa Foundation framework. Sa natitirang code ng shared module, ang function na ito ay tinatawag nang hindi isinasaalang-alang ang platform.

Halimbawa ng network request gamit ang Ktor Client sa shared code:

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

Ang code na ito ay gumagana sa parehong platform nang walang pagbabago. Ang Ktor Client ay awtomatikong gumagamit ng OkHttp sa Android at NSURLSession sa iOS, nang walang karagdagang configuration. Ang JSON serialization sa pamamagitan ng kotlinx.serialization ay cross-platform din.

Paghahambing ng KMM sa Flutter at React Native

Ang KMM ay may natatanging posisyon sa mga cross-platform na teknolohiya, dahil hindi nito sinusubukang palitan ang native na UI hindi tulad ng Flutter at React Native. KMM — ay isang solusyon para sa pagbabahagi ng lohika, hindi para sa pag-iisa ng interface.

Ang pangunahing bentahe ng KMM — ganap na kontrol sa UI. Kung ang application ay dapat magmukha at kumilos nang native sa bawat platform (halimbawa, gumamit ng iOS TabBar at Android BottomNavigation na may mga platform animation), ang KMM ay ang tanging cross-platform na solusyon na nagbibigay nito nang walang workaround.

Ang kahinaan — ang koponan ay dapat marunong ng Kotlin, Swift, Jetpack Compose at SwiftUI nang sabay-sabay, na nagpapahirap sa pag-hire. Ang Flutter at React Native ay nangangailangan ng kaalaman sa isang wika at isang framework.

Mga benepisyo at hamon ng pagpapatupad ng KMM

Kotlin Multiplatform Mobile — ay isang makapangyarihang teknolohiya, ngunit ang pagpapatupad nito ay nangangailangan ng balanseng diskarte. Tingnan natin ang mga pangunahing benepisyo at karaniwang hamon na kinakaharap ng mga koponan.

Mga benepisyo ng KMM

Ang una at pinakamahalagang benepisyo — pagbawas ng pagdodoble ng code. Ayon sa JetBrains Case Studies (2024), ang mga koponan na nagpatupad ng KMM ay nagbawas ng dami ng nadobleng code ng 60–80% para sa network layer at 40–50% para sa lohika ng negosyo sa kabuuan. Ito ay direktang nakakaapekto sa bilis ng pag-develop at bilang ng mga bug.

Ang pangalawang benepisyo — performance sa antas ng native na mga application. Hindi tulad ng hybrid frameworks, hindi nagdadagdag ang KMM ng mga abstraction layer sa pagitan ng UI at system. Ang code ng lohika ng negosyo ay pumapatakbo nang kasingbilis kung ito ay isinulat sa Swift o Kotlin para sa bawat platform nang hiwalay.

Mga hamon ng pagpapatupad

Ang pangunahing hamon — kwalipikasyon ng koponan. Ang mga developer ay dapat marunong ng Kotlin (para sa shared module), pati na rin ang Swift at Jetpack Compose (para sa UI). Ang paghahanap ng unibersal na espesyalista ay mahirap, kaya karaniwang nabubuo ang isang koponan mula sa Android at iOS developer na sama-samang namamahala sa shared module.

Ang pangalawang hamon — mga tool. Ang KMM ay nangangailangan ng configuration ng Gradle, CocoaPods o Swift Package Manager, pati na rin ang integration sa Xcode. Sa mga unang yugto ng proyekto, karaniwan ang mga problema sa configuration ng build, lalo na kapag nagtatrabaho sa C libraries.

Ang pangatlong hamon — debugging. Kapag lumitaw ang bug sa intersection ng Kotlin/Native at Swift, mas mahirap matukoy ang dahilan nito kaysa sa isang monolithic application. Patuloy na pinapabuti ng JetBrains ang mga debugging tool, ngunit sa praktika ang mga koponan ay kailangang gumugol ng hanggang 20% ng oras sa mga gawaing pang-imprastraktura.