Kotlin Multiplatform Roadmap 2026: o que acompanhar e como planejar seu projeto

Resposta rápida: o Kotlin Multiplatform roadmap em 2026 deve ser lido como uma direção de evolução, não como uma promessa de datas para cada recurso. Para planejar um produto, acompanhe cinco frentes: estabilidade do toolchain, interoperabilidade com Swift e Objective-C, bibliotecas disponíveis em commonMain, maturidade do Compose Multiplatform e experiência de build, teste e distribuição. Um time não precisa esperar o ecossistema inteiro ficar “pronto”: comece compartilhando modelos, regras de negócio, rede e persistência; amplie para ViewModels ou UI somente depois de medir os benefícios e validar os requisitos de cada plataforma.

Essa interpretação é mais útil do que procurar uma lista fechada de funcionalidades. Roadmaps oficiais mudam conforme feedback, prioridades e resultados técnicos. Antes de tomar uma decisão de arquitetura, consulte o roadmap público do Kotlin, a documentação oficial do Kotlin Multiplatform e os canais de releases das bibliotecas usadas pelo projeto.

Este guia organiza o que realmente deve entrar no planejamento de uma equipe Android, iOS, desktop, web ou backend que considera KMP.

O que significa “roadmap” no Kotlin Multiplatform?

Um roadmap de tecnologia descreve áreas de investimento. Ele ajuda a entender para onde ferramentas e APIs caminham, mas não substitui uma matriz de risco do seu produto.

Há três níveis que precisam ser separados:

Uma funcionalidade aparecer no roadmap não significa que ela estará disponível na próxima sprint. Da mesma forma, uma tecnologia não precisa aparecer como novidade para ser útil: coroutines, serialização, Ktor Client e código de domínio em commonMain já resolvem problemas concretos.

A primeira regra é simples: planeje com o que está disponível e validado hoje; trate o roadmap como sinal para os próximos ciclos.

As cinco frentes que merecem acompanhamento

1. Toolchain, compilador e Gradle

A produtividade de KMP depende de várias peças funcionando juntas: versão do Kotlin, Gradle, plugins, Android Gradle Plugin, Xcode, targets nativos e IDE. Por isso, melhorias no toolchain têm impacto direto no custo de adoção.

Ao acompanhar releases, observe:

• tempo de importação e sincronização do projeto;
• velocidade de compilação incremental;
• mensagens de erro entre source sets;
• compatibilidade entre plugins;
• suporte da IDE para código compartilhado;
• previsibilidade do build em CI;
• tamanho e estabilidade dos artefatos gerados para iOS.

Evite atualizar todas as peças no mesmo pull request. Uma estratégia segura é manter uma matriz testada no repositório:

Kotlin: versão homologada pelo time
Gradle: versão compatível
AGP: versão compatível
Xcode: versão usada no CI e pelos desenvolvedores iOS
JDK: versão definida no projeto
Targets: Android, iosArm64, iosSimulatorArm64

Version Catalog e Gradle Wrapper ajudam a tornar essa matriz explícita. O guia de Gradle Version Catalog com Kotlin mostra como centralizar dependências sem espalhar números por vários módulos.

2. Interoperabilidade com Swift e Objective-C

Para equipes mobile, o sucesso de KMP não depende apenas de “compilar para iOS”. A API exportada precisa parecer utilizável para quem escreve Swift.

Os principais pontos de avaliação são:

• nomes gerados para classes, métodos e propriedades;
• representação de erros;
• consumo de funções suspend no Swift;
• observação de Flow e estado assíncrono;
• tipos nulos e coleções;
• integração com Swift Package Manager ou frameworks;
• depuração quando uma falha cruza a fronteira Kotlin/Swift.

Não exporte todo o domínio interno. Crie uma fachada pequena e estável para o app iOS:

class ProfileSdk(
    private val repository: ProfileRepository,
) {
    suspend fun loadProfile(userId: String): ProfileResult =
        runCatching { repository.getProfile(userId) }
            .fold(
                onSuccess = { ProfileResult.Success(it.toPublicModel()) },
                onFailure = { ProfileResult.Failure(it.toPublicError()) },
            )
}

sealed interface ProfileResult {
    data class Success(val profile: PublicProfile) : ProfileResult
    data class Failure(val error: PublicError) : ProfileResult
}

A camada pública protege o consumidor de mudanças internas e deixa o contrato mais fácil de documentar. Se a distribuição para iOS é central no projeto, veja também o guia de Swift Package Manager com Kotlin Multiplatform.

3. Bibliotecas realmente multiplataforma

A pergunta “KMP está pronto?” é ampla demais. A pergunta útil é: as dependências do meu caso de uso estão prontas para os targets escolhidos?

Faça um inventário antes de criar o módulo compartilhado:

Não escolha uma biblioteca apenas por ter a etiqueta “multiplatform”. Confira frequência de releases, documentação, issues abertas, política de compatibilidade e capacidade do time de substituir a dependência.

Para persistência, compare os requisitos do projeto com os guias de SQLDelight para Android e iOS e Room com Kotlin Multiplatform.

4. Compose Multiplatform e compartilhamento de UI

Kotlin Multiplatform e Compose Multiplatform não são a mesma decisão. KMP pode compartilhar lógica com SwiftUI no iOS; Compose Multiplatform permite compartilhar também partes da interface.

Há três estratégias honestas:

1. domínio compartilhado, UI nativa: Compose no Android e SwiftUI no iOS;
2. UI parcialmente compartilhada: design system ou fluxos específicos em Compose Multiplatform;
3. UI amplamente compartilhada: maior parte das telas em Compose, com integrações nativas quando necessário.

A escolha depende de produto, equipe e requisitos. Uma ferramenta interna com interface padronizada pode ganhar muito com UI compartilhada. Um aplicativo que depende intensamente de experiências específicas do iOS talvez prefira SwiftUI sobre um domínio KMP.

Antes de ampliar o compartilhamento, faça uma prova de conceito com uma tela difícil, não apenas login e lista. Inclua:

• navegação e restauração de estado;
• acessibilidade;
• teclado, foco e formulários;
• imagens e scroll;
• mapas, câmera ou web view, se usados;
• analytics e crash reporting;
• testes de UI;
• tempo de inicialização e uso de memória.

A comparação Kotlin Multiplatform vs Flutter ajuda quando a decisão envolve uma stack cross-platform completa. Para compartilhamento de UI, leia também o guia de Compose Multiplatform entre Android, iOS e desktop.

5. Build, testes, observabilidade e entrega

Um protótipo local não representa o custo de produção. O roadmap interno do time precisa incluir tudo que acontece depois do primeiro Hello World.

Avalie desde cedo:

• cache de dependências e outputs no CI;
• testes de commonTest e testes por target;
• simuladores e devices necessários;
• publicação de frameworks ou pacotes;
• versionamento do módulo compartilhado;
• símbolos e stack traces para crashes nativos;
• monitoramento de regressões de tamanho e performance;
• processo de rollback para Android e iOS.

Um pipeline mínimo pode separar validações rápidas de jobs específicos de plataforma:

pull request
├── lint e testes de commonMain
├── testes JVM/Android
├── compilação dos targets iOS
└── verificação de API pública

main
├── build Android de homologação
├── framework/pacote iOS de homologação
└── testes de integração e distribuição interna

Essa divisão evita obrigar cada mudança de domínio a esperar um pipeline mobile completo, sem deixar a compilação iOS para o fim do projeto.

O que compartilhar primeiro em um projeto KMP?

Para a maioria das equipes, a ordem mais segura é:

1. modelos e validações;
2. regras de negócio e casos de uso;
3. serialização;
4. cliente HTTP e tratamento de erros;
5. repositórios e cache;
6. estado de apresentação;
7. UI, quando houver benefício comprovado.

O exemplo abaixo mantém regra e resultado em commonMain, sem impor uma interface específica:

class CalculateShippingUseCase(
    private val repository: ShippingRepository,
) {
    suspend operator fun invoke(
        postalCode: String,
        items: List<CartItem>,
    ): ShippingResult {
        if (postalCode.filter(Char::isDigit).length != 8) {
            return ShippingResult.InvalidPostalCode
        }

        if (items.isEmpty()) {
            return ShippingResult.EmptyCart
        }

        return repository.quote(postalCode, items)
    }
}

sealed interface ShippingResult {
    data class Available(
        val priceInCents: Long,
        val estimatedDays: Int,
    ) : ShippingResult

    data object InvalidPostalCode : ShippingResult
    data object EmptyCart : ShippingResult
    data object Unavailable : ShippingResult
}

Android e iOS podem apresentar esses resultados de formas diferentes. O ganho já existe: validação, cálculo, erros e testes são compartilhados.

Matriz de decisão: KMP faz sentido para seu time?

Use a tabela como ponto de partida:

Nenhuma linha decide sozinha. Considere contratação, suporte, prazo, dependências, experiência da equipe e custo de operação.

Um roadmap de adoção em quatro fases

Fase 1: descoberta

Duração sugerida: uma ou duas semanas, conforme o produto.

• mapeie código duplicado;
• liste SDKs específicas;
• escolha um fluxo representativo;
• defina métricas de sucesso;
• monte a matriz de versões;
• valide build Android e iOS no CI.

Métricas úteis incluem porcentagem de lógica compartilhada, tempo de build, defeitos de paridade, esforço para adicionar uma regra e satisfação dos desenvolvedores das duas plataformas.

Fase 2: piloto vertical

Implemente um fluxo de ponta a ponta: rede, regra, cache, estado e integração com as duas UIs. Evite um módulo “utils” cheio de funções desconectadas, pois ele não testa os desafios reais.

Um bom piloto tem valor de produto, mas baixo risco operacional. Favoritos, preferências, catálogo ou perfil costumam ser melhores que pagamentos, biometria ou câmera como primeiro passo.

Fase 3: padronização

Depois do piloto:

• documente fronteiras de source sets;
• crie convenções de erros e resultados;
• padronize logging e analytics;
• defina revisão de API exportada para Swift;
• automatize testes e publicação;
• estabeleça responsáveis pelo módulo compartilhado.

Sem ownership, commonMain pode virar uma área onde nenhuma equipe se sente responsável por compatibilidade.

Fase 4: expansão baseada em evidência

Amplie apenas quando o piloto demonstrar ganho. Compartilhar mais código não é, por si só, uma métrica de sucesso. Às vezes, 40% bem escolhidos reduzem mais custo que 90% com abstrações frágeis.

A cada nova feature, pergunte:

1. a regra precisa ser idêntica nas plataformas?
2. as dependências funcionam nos targets?
3. o contrato pode permanecer pequeno?
4. a equipe consegue testar e observar a implementação?
5. o compartilhamento reduz tempo total, não apenas linhas de código?

Sinais do roadmap que devem acionar uma reavaliação

Reavalie sua arquitetura quando houver:

• mudança de nível de estabilidade de uma tecnologia importante;
• melhoria relevante na exportação de APIs para Swift;
• nova versão maior do Kotlin, Gradle, AGP ou Xcode;
• biblioteca essencial adicionando ou removendo suporte a um target;
• redução mensurável no tempo de build;
• amadurecimento de uma solução de navegação, persistência ou UI;
• depreciação que afete o pipeline atual.

Não migre imediatamente por causa de um anúncio. Crie uma branch de atualização, rode os testes, compare métricas e documente incompatibilidades. O guia geral de Kotlin Multiplatform oferece a base para quem ainda precisa entender source sets e expect/actual.

Erros comuns ao seguir um roadmap público

Tratar item planejado como API disponível

Uma intenção pública pode mudar. Não desenhe um prazo comercial supondo que uma funcionalidade futura resolverá um bloqueio crítico.

Acompanhar apenas anúncios de UI

Interoperabilidade, compilação, testes e distribuição costumam determinar mais o custo de produção que uma demonstração visual.

Confundir compatibilidade com qualidade de integração

Uma biblioteca pode compilar em todos os targets e ainda oferecer documentação fraca, tratamento de erro inconsistente ou manutenção insuficiente.

Forçar tudo para commonMain

APIs específicas não são fracasso. expect/actual, interfaces e adapters existem justamente para preservar diferenças legítimas.

Ignorar a equipe iOS

KMP não transforma automaticamente uma API Kotlin em uma boa API Swift. Desenvolvedores iOS devem participar do desenho, da revisão e da observabilidade.

Checklist antes de aprovar KMP para produção

• Targets e versões estão explícitos no repositório.
• O projeto compila para Android e iOS no CI.
• Dependências críticas foram avaliadas individualmente.
• Há testes em commonTest e nos pontos de integração.
• A API consumida pelo Swift é pequena e documentada.
• Erros, cancelamento e concorrência têm comportamento definido.
• Persistência possui estratégia de migração.
• Logs e crashes podem ser investigados por plataforma.
• O time conhece o processo de release e rollback.
• A prova de conceito inclui um fluxo difícil e representativo.
• Métricas de produtividade e qualidade foram definidas.
• Recursos do roadmap não são dependências obrigatórias do cronograma.

Perguntas frequentes

Existe uma data em que Kotlin Multiplatform estará “100% pronto”?

Não existe uma única data aplicável a todos os projetos. Linguagem, targets, bibliotecas, UI e ferramentas evoluem em ritmos diferentes. A prontidão deve ser avaliada para o caso de uso e as dependências da equipe.

KMP exige Compose Multiplatform?

Não. É possível compartilhar domínio, rede, persistência e estado com KMP, usando Jetpack Compose no Android e SwiftUI no iOS. Compose Multiplatform é uma decisão adicional sobre compartilhamento de UI.

Vale esperar o próximo item do roadmap antes de começar?

Somente se o projeto estiver bloqueado por uma capacidade que ainda não existe ou não atende aos requisitos. Caso contrário, um piloto pequeno com recursos atuais produz evidência melhor que esperar indefinidamente.

Kotlin Multiplatform substitui desenvolvedores iOS?

Não. Mesmo com UI compartilhada, o produto continua precisando de conhecimento sobre distribuição, permissões, ciclo de vida, performance, acessibilidade e integrações do iOS.

Qual é o melhor primeiro módulo para compartilhar?

Escolha um fluxo de negócio relevante, com poucas SDKs específicas e testes claros. Modelos, validações, chamadas de rede e regras de domínio costumam oferecer uma boa relação entre benefício e risco.

Conclusão

O melhor uso do Kotlin Multiplatform roadmap não é tentar adivinhar uma data mágica de maturidade. É identificar as frentes que podem reduzir risco ou ampliar o compartilhamento no seu produto: toolchain, Swift interop, bibliotecas, Compose Multiplatform e operação em produção.

Comece pelo domínio, valide um fluxo vertical nas duas plataformas e meça o resultado. Mantenha UI e integrações específicas onde isso melhora o produto. Acompanhe os documentos oficiais, mas baseie cada decisão de release em versões disponíveis, testes reproduzíveis e capacidade real da equipe. Assim, o roadmap deixa de ser uma coleção de anúncios e vira uma ferramenta prática de planejamento técnico.