Kotlin Multiplatform deixou de ser curiosidade de conferência no ecossistema brasileiro. Em 2026, encontramos produção ativa em fintechs de Curitiba, marketplaces de Belo Horizonte e startups de SaaS em São Paulo que compartilham camada de domínio entre Android e iOS. O entusiasmo, porém, ainda corre à frente da maturidade operacional — e alguns times pagaram o preço de adotar cedo demais, no lugar errado do stack.
O que KMP resolve de verdade
KMP não elimina duas interfaces. Compartilha lógica: regras de negócio, validações, modelos de dados, clientes de API, cache offline. Para apps cujo diferencial está na experiência nativa de cada plataforma, isso é exatamente o que se quer preservar nas camadas de UI — Compose Multiplatform e SwiftUI continuam em territórios separados na maioria dos projetos que analisamos.
O ganho aparece quando o mesmo time mantém regras complexas sincronizadas manualmente entre Kotlin e Swift. Exemplo recorrente: cálculo de taxas, elegibilidade de produtos financeiros, sincronização de carrinho com regras promocionais regionais. Duplicar essa lógica gerava bugs assimétricos; centralizar em módulo compartilhado reduziu divergência, segundo relato de um time de seis desenvolvedores em BH.
Onde a adoção falhou
Projetos que tentaram compartilhar UI cedo demais enfrentaram atrito de tooling e tempo de build. Gradle com targets iOS, cache de compilação e integração com Xcode exigem disciplina de infraestrutura que startups enxutas nem sempre têm. Um estúdio em Recife reverteu parte do compartilhamento após três meses: o custo de debug cross-platform superou a economia em features de baixa complexidade.
Outro padrão de fracasso: escolher KMP sem necessidade real de iOS. Times Android-first que adotaram KMP "para o futuro" carregaram complexidade sem benefício imediato. A decisão deveria partir de roadmap confirmado para duas plataformas, não de antecipação especulativa.
Compose Multiplatform e o mercado local
Compose Multiplatform amadureceu, mas no Brasil ainda é minoria em produção iOS comparado a UI nativa ou híbrida pontual. Desenvolvedores Android que dominam Compose tendem a experimentar; equipes com forte legado Swift raramente migram interface compartilhada sem resistência. O ponto de equilíbrio atual: compartilhar domínio, manter UI nativa em cada lado.
KMP é ferramenta de alinhamento de regras, não atalho para dois apps com um clique.
Contratação e capacitação
O mercado brasileiro de trabalho ainda lista mais vagas Android Kotlin do que KMP explícito. Times que adotam o modelo precisam investir em documentação interna e convenções de módulo — expectativa de que qualquer dev Android contribua no shared sem ramp-up é otimista. Empresas que deram certo criaram guildas internas e limitaram superfície do módulo compartilhado com APIs estáveis.
Checklist antes de adotar
Quatro perguntas que recomendamos: existe app iOS no roadmap em 12 meses? A lógica duplicada já causou incidente em produção? O time tem alguém confortável com build iOS a partir do mesmo repositório? A liderança aceita curva de aprendizado de três a seis meses? Se duas respostas forem negativas, adiar KMP provavelmente é a decisão racional.
Para quem responde sim: começar pelo módulo de rede ou domínio, não pela tela. Medir tempo de build e taxa de bug cross-platform por sprint. KMP recompensa paciência incremental — o oposto da reescrita big-bang que alguns vendors ainda vendem em eventos.