Kotlin Multiplatform Mobile — cos'è, concetti chiave e architettura di KMM

Cos'è Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) è una tecnologia che consente di scrivere la logica di business condivisa di un'applicazione mobile in Kotlin e utilizzarla su iOS e Android senza duplicazione di codice. A differenza di Ionic o Cordova, KMM non renderizza l'interfaccia in un WebView — l'interfaccia utente rimane completamente nativa e viene scritta in SwiftUI (iOS) e Jetpack Compose (Android).

KMM è stato annunciato da JetBrains nel 2019 come parte della strategia Kotlin Multiplatform. La differenza principale rispetto ad altre soluzioni cross-platform è che il framework non tenta di unificare l'interfaccia utente, ma si concentra sulla condivisione esatta del codice che è realmente identico per entrambe le piattaforme: richieste di rete, modelli dati, validazione dei moduli, regole di business e operazioni sui database.

Secondo il JetBrains Developer Survey (2025), KMM è utilizzato dal 14% degli sviluppatori mobile, e questo dato cresce del 5% ogni anno. La tecnologia è scelta da aziende con elevate esigenze di prestazioni ed esperienza utente nativa, per le quali le soluzioni ibride non sono accettabili.

Architettura di KMM: modulo condiviso e implementazioni di piattaforma

L'architettura di KMM è composta da tre moduli: shared (codice comune in Kotlin), iosApp (applicazione iOS nativa in Swift) e androidApp (applicazione Android nativa in Kotlin). Il modulo condiviso viene compilato in un JAR per Android e in un framework universale (Apple Framework) per iOS.

Modulo condiviso: cosa va nel codice comune

Il modulo condiviso contiene tutti i livelli indipendenti dalla piattaforma: il livello di rete con Ktor Client, modelli dati con serializzazione tramite kotlinx.serialization, repository per la gestione dei dati, validazione dei moduli e regole di business (ad esempio, calcolo del costo di consegna o verifica dei permessi di accesso).

Il modulo condiviso utilizza il plugin Gradle Multiplatform e contiene tre insiemi di sorgenti: commonMain (codice comune), androidMain (implementazioni specifiche per Android) e iosMain (implementazioni specifiche per iOS). Il compilatore Kotlin/Native trasforma il codice comune in una libreria nativa per iOS, che viene collegata al progetto Swift tramite XCFramework.

Moduli di piattaforma

Modulo Android — un'applicazione Android standard in Kotlin con Jetpack Compose o ViewBinding. Il modulo condiviso viene collegato come una normale dipendenza Gradle e tutte le classi da commonMain sono direttamente accessibili.

Il modulo iOS è un progetto Xcode in Swift o Objective-C. Il modulo condiviso viene collegato tramite CocoaPods, Swift Package Manager o XCFramework. Kotlin/Native genera intestazioni Objective-C per esportare i tipi Kotlin, rendendoli accessibili da Swift.

Il meccanismo expect/actual in KMM

expect/actual è un meccanismo di Kotlin Multiplatform che consente di dichiarare un'API nel codice condiviso (dichiarazione expect) e fornire la sua implementazione separatamente per ciascuna piattaforma (dichiarazione actual). Il compilatore garantisce che esista una dichiarazione actual per ogni piattaforma target.

Casi d'uso tipici di expect/actual: ottenere l'ora corrente con fuso orario, lavorare con SharedPreferences (Android) / UserDefaults (iOS), funzioni crittografiche e generazione di UUID. Ogni piattaforma utilizza la propria API di sistema.

Senza expect/actual, sarebbe impossibile avere un codice unificato di logica di business, poiché le API per lavorare con file system, rete e archiviazione differiscono tra iOS e Android a livello di chiamate di sistema. Il meccanismo garantisce che lo sviluppatore non dimentichi di implementare la parte specifica della piattaforma.

Per chiamate di piattaforma come lavorare con la fotocamera o la biometria, KMM offre il meccanismo expect/actual combinato con plugin simili a Cordova, ma su Kotlin/Native. JetBrains ha anche rilasciato la libreria kotlinx-datetime, che astrae la gestione di date e ore.

Esempi di codice KMM

Osserviamo la struttura di base di un progetto KMM con una dichiarazione di funzione expect per la generazione di UUID e la sua implementazione per iOS e Android.

// commonMain — dichiarazione comune
expect fun generateUUID(): String

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

// iosMain — implementazione per iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

Nel codice condiviso, viene dichiarata expect fun generateUUID(). Android utilizza java.util.UUID, mentre iOS utilizza NSUUID dal framework Foundation. Nel resto del codice del modulo condiviso, questa funzione viene chiamata indipendentemente dalla piattaforma.

Un esempio di richiesta di rete utilizzando Ktor Client nel codice condiviso:

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())
    }
}

Questo codice funziona su entrambe le piattaforme senza modifiche. Ktor Client utilizza automaticamente OkHttp su Android e NSURLSession su iOS, senza configurazione aggiuntiva. La serializzazione JSON tramite kotlinx.serialization è anch'essa cross-platform.

Confronto tra KMM e Flutter e React Native

KMM occupa una posizione unica tra le tecnologie cross-platform, poiché non tenta di sostituire l'interfaccia nativa a differenza di Flutter e React Native. KMM è una soluzione per condividere la logica, non per unificare l'interfaccia.

Il principale vantaggio di KMM è il controllo completo sull'interfaccia utente. Se un'applicazione deve apparire e comportarsi in modo nativo su ciascuna piattaforma (ad esempio, utilizzando la TabBar di iOS e la BottomNavigation di Android con animazioni di piattaforma), KMM è l'unica soluzione cross-platform che fornisce questo senza soluzioni alternative.

Lo svantaggio è che il team deve conoscere simultaneamente Kotlin, Swift, Jetpack Compose e SwiftUI, il che complica l'assunzione. Flutter e React Native richiedono la conoscenza di un solo linguaggio e un solo framework.

Vantaggi e sfide dell'adozione di KMM

Kotlin Multiplatform Mobile è una tecnologia potente, ma la sua adozione richiede un approccio equilibrato. Esaminiamo i principali vantaggi e le sfide tipiche che i team affrontano.

Vantaggi di KMM

Il primo e principale vantaggio è la riduzione della duplicazione del codice. Secondo i casi studio di JetBrains (2024), i team che hanno adottato KMM riducono il codice duplicato del 60–80% per il livello di rete e del 40–50% per la logica di business complessiva. Questo influisce direttamente sulla velocità di sviluppo e sul numero di bug.

Il secondo vantaggio sono le prestazioni al livello delle applicazioni native. A differenza dei framework ibridi, KMM non aggiunge livelli di astrazione tra l'interfaccia utente e il sistema. Il codice della logica di business viene eseguito velocemente come se fosse scritto in Swift o Kotlin per ciascuna piattaforma separatamente.

Sfide dell'adozione

La sfida principale è la qualificazione del team. Gli sviluppatori devono conoscere Kotlin (per il modulo condiviso), così come Swift e Jetpack Compose (per l'interfaccia utente). Trovare uno specialista universale è difficile, quindi i team sono solitamente composti da sviluppatori Android e iOS che mantengono congiuntamente il modulo condiviso.

La seconda sfida sono gli strumenti. KMM richiede la configurazione di Gradle, CocoaPods o Swift Package Manager, oltre all'integrazione con Xcode. Nelle fasi iniziali di un progetto, i problemi di configurazione del build sono comuni, soprattutto quando si lavora con librerie C.

La terza sfida è il debug. Quando si verifica un bug all'intersezione tra Kotlin/Native e Swift, determinarne la causa è più difficile che in un'applicazione monolitica. JetBrains migliora continuamente gli strumenti di debug, ma nella pratica, i team dedicano fino al 20% del tempo a attività infrastrutturali.