Kotlin Multiplatform Mobile — o que é, conceitos-chave e arquitetura do KMM

O que é Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) é uma tecnologia que permite escrever a lógica de negócio compartilhada de uma aplicação móvel em Kotlin e usá-la no iOS e Android sem duplicação de código. Ao contrário do Ionic ou Cordova, o KMM não renderiza a interface em um WebView — a IU permanece completamente nativa e é escrita em SwiftUI (iOS) e Jetpack Compose (Android).

O KMM foi anunciado pela JetBrains em 2019 como parte da estratégia Kotlin Multiplatform. A principal diferença de outras soluções multiplataforma é que o framework não tenta unificar a IU, mas foca em compartilhar exatamente o código que é realmente idêntico para ambas as plataformas: requisições de rede, modelos de dados, validação de formulários, regras de negócio e operações de banco de dados.

De acordo com a Pesquisa de Desenvolvedores JetBrains (2025), o KMM é usado por 14% dos desenvolvedores móveis, e esse número cresce 5% ao ano. A tecnologia é escolhida por empresas com altas exigências de desempenho e experiência de usuário nativa, para as quais soluções híbridas são inaceitáveis.

Arquitetura do KMM: módulo compartilhado e implementações de plataforma

A arquitetura do KMM consiste em três módulos: shared (código comum em Kotlin), iosApp (aplicação iOS nativa em Swift) e androidApp (aplicação Android nativa em Kotlin). O módulo compartilhado é compilado em um JAR para Android e em um framework universal (Apple Framework) para iOS.

Módulo compartilhado: o que vai no código comum

O módulo compartilhado contém todas as camadas independentes de plataforma: a camada de rede usando Ktor Client, modelos de dados com serialização via kotlinx.serialization, repositórios para gerenciamento de dados, validação de formulários e regras de negócio (por exemplo, calcular custo de entrega ou verificar permissões de acesso).

O módulo compartilhado usa o Plugin Gradle Multiplatform e contém três conjuntos de código-fonte: commonMain (código comum), androidMain (implementações específicas do Android) e iosMain (implementações específicas do iOS). O compilador Kotlin/Native transforma o código comum em uma biblioteca nativa para iOS, que é vinculada ao projeto Swift via XCFramework.

Módulos de plataforma

Módulo Android — é uma aplicação Android padrão em Kotlin com Jetpack Compose ou ViewBinding. O módulo compartilhado é conectado como uma dependência Gradle comum, e todas as classes do commonMain são diretamente acessíveis.

O módulo iOS é um projeto Xcode em Swift ou Objective-C. O módulo compartilhado é conectado via CocoaPods, Swift Package Manager ou XCFramework. O Kotlin/Native gera cabeçalhos Objective-C para exportar tipos Kotlin, tornando-os acessíveis a partir do Swift.

O mecanismo expect/actual no KMM

expect/actual é um mecanismo do Kotlin Multiplatform que permite declarar uma API em código compartilhado (declaração expect) e fornecer sua implementação separadamente para cada plataforma (declaração actual). O compilador garante que exista uma declaração actual para cada plataforma alvo.

Casos de uso típicos do expect/actual: obter a hora atual com fuso horário, trabalhar com SharedPreferences (Android) / UserDefaults (iOS), funções criptográficas e geração de UUID. Cada plataforma usa sua própria API do sistema.

Sem o expect/actual, seria impossível ter um código unificado de lógica de negócio, pois as APIs para trabalhar com sistema de arquivos, rede e armazenamento diferem entre iOS e Android no nível de chamadas de sistema. O mecanismo garante que o desenvolvedor não se esqueça de implementar a parte específica da plataforma.

Para chamadas de plataforma como trabalhar com câmera ou biometria, o KMM oferece o mecanismo expect/actual combinado com plugins similares ao Cordova, mas em Kotlin/Native. A JetBrains também lançou a biblioteca kotlinx-datetime, que abstrai o manuseio de datas e horas.

Exemplos de código no KMM

Vejamos a estrutura básica de um projeto KMM com a declaração de uma função expect para geração de UUID e sua implementação para iOS e Android.

// commonMain — declaração comum
expect fun generateUUID(): String

// androidMain — implementação para Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — implementação para iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

No código compartilhado, declara-se expect fun generateUUID(). O Android usa java.util.UUID, enquanto o iOS usa NSUUID do framework Foundation. No restante do código do módulo compartilhado, esta função é chamada independentemente da plataforma.

Um exemplo de requisição de rede usando Ktor Client em código compartilhado:

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

Este código funciona em ambas as plataformas sem alterações. O Ktor Client usa OkHttp no Android e NSURLSession no iOS automaticamente, sem configuração adicional. A serialização JSON via kotlinx.serialization também é multiplataforma.

Comparação do KMM com Flutter e React Native

O KMM ocupa uma posição única entre as tecnologias multiplataforma, pois não tenta substituir a IU nativa ao contrário do Flutter e React Native. KMM é uma solução para compartilhar lógica, não para unificar a interface.

A principal vantagem do KMM é o controle total sobre a IU. Se uma aplicação precisa parecer e se comportar de forma nativa em cada plataforma (por exemplo, usando a TabBar do iOS e a BottomNavigation do Android com animações de plataforma), o KMM é a única solução multiplataforma que proporciona isso sem gambiarras.

A desvantagem é que a equipe precisa conhecer Kotlin, Swift, Jetpack Compose e SwiftUI simultaneamente, o que dificulta a contratação. Flutter e React Native exigem conhecimento de uma linguagem e um framework.

Vantagens e desafios da adoção do KMM

Kotlin Multiplatform Mobile é uma tecnologia poderosa, mas sua adoção requer uma abordagem equilibrada. Vamos examinar as principais vantagens e os desafios típicos que as equipes enfrentam.

Vantagens do KMM

A primeira e principal vantagem é a redução da duplicação de código. De acordo com os Estudos de Caso da JetBrains (2024), equipes que adotaram o KMM reduzem o código duplicado em 60–80% para a camada de rede e em 40–50% para a lógica de negócio em geral. Isso impacta diretamente a velocidade de desenvolvimento e o número de bugs.

A segunda vantagem é o desempenho no nível de aplicações nativas. Ao contrário dos frameworks híbridos, o KMM não adiciona camadas de abstração entre a IU e o sistema. O código da lógica de negócio é executado tão rápido quanto se fosse escrito em Swift ou Kotlin para cada plataforma separadamente.

Desafios da adoção

O principal desafio é a qualificação da equipe. Os desenvolvedores precisam conhecer Kotlin (para o módulo compartilhado), além de Swift e Jetpack Compose (para a IU). Encontrar um especialista universal é difícil, então as equipes geralmente consistem em desenvolvedores Android e iOS que mantêm conjuntamente o módulo compartilhado.

O segundo desafio são as ferramentas. O KMM requer configurar Gradle, CocoaPods ou Swift Package Manager, bem como a integração com o Xcode. Nos estágios iniciais de um projeto, problemas de configuração de build são comuns, especialmente ao trabalhar com bibliotecas C.

O terceiro desafio é a depuração. Quando um bug ocorre na interseção do Kotlin/Native e Swift, determinar sua causa é mais difícil do que em uma aplicação monolítica. A JetBrains melhora continuamente as ferramentas de depuração, mas na prática, as equipes gastam até 20% do tempo em tarefas de infraestrutura.