Compartilhado no CAMP Platform
De Java para 100% Kotlin: como o iShape foi reconstruído do zero
Link Curado10 de maio de 2026

De Java para 100% Kotlin: como o iShape foi reconstruído do zero

A equipe do iShape começou com Java no Android, adotou Kotlin e tomou uma decisão radical: demolir tudo e reconstruir. O resultado é um produto completo — mobile, backend e IA — em uma única linguagem - Kotlin!

#kotlin-multiplatform#compose-multiplatform#ktor#kmp#kotlin

Comentário do autor

Fala dev, esse artigo é bem interessante e mostra como dois devs resolveram apostar em Kotlin full-stack ao refatorar um projeto Android com Java para uma stack 100% em Kotlin, em todas as camadas, inclusive a camada de UI com Compose Multiplatform. Vale a pena conferir a fonte oficial mas deixo aqui um resumo pra você não precisar sair da plataforma.

A decisão de recomeçar

iShape nasceu em Java, Android-only. Quando o time (apenas duas pessoas) conheceu Kotlin a fundo, a conclusão foi direta: não vale adaptar o que existe. Melhor demolir e reconstruir certo.

Essa escolha definiu toda a arquitetura que veio depois.

KMP + Compose Multiplatform: uma base, dois apps reais

Desde o início de 2024, o projeto adotou Kotlin Multiplatform com Compose Multiplatform. iOS deixou de ser plano futuro e virou cidadão de primeira classe desde o dia um.

O resultado em linhas de código fala por si:

commonMain:  61.125 linhas
androidMain:  3.197 linhas
iosMain:      1.409 linhas

~93% do código mobile vive em commonMain — telas, ViewModels, navegação, networking, schemas de banco, injeção de dependência. As pastas de plataforma só carregam pontes para SDKs nativos (câmera, billing, health).

O time chegou a lançar o iOS em agosto de 2024, meses antes do Compose Multiplatform 1.8 declarar iOS estável (maio de 2025). O custo foi real: uma camada expect/actual espessa e uma surpresa no dia do lançamento estável — todos os Icons.Default.* quebraram e precisaram ser substituídos por vector drawables manuais. Mas para um time pequeno, o ganho de velocidade foi enorme.

Ktor no backend, não Spring

A escolha "segura" era Spring Boot. Eles escolheram Ktor.

Por quê?

  • Coroutines como cidadão de primeira classe — sem @Async, sem Mono<T>, só suspend fun
  • Plugins opt-in, sem autoconfiguração surpresa
  • kotlinx.serialization ponta a ponta, do banco à resposta HTTP
  • Compatível com GraalVM native-image — cold start cai de segundos para milissegundos

Stack atual: Ktor 3.3.2 + PostgreSQL + SQLDelight + Koin com KSP.

Koog: apostando cedo no framework de IA da JetBrains

O JetBrains open-sourceou o Koog (framework de agentes de IA para Kotlin) em maio de 2025. Em 6 semanas, o time já rodava o primeiro grafo de agentes em produção na versão 0.2.1.

O diferencial que justificou a aposta:

  • Suporte nativo a coroutines
  • DSL de grafo idiomático em Kotlin
  • kotlinx.serialization para structured outputs
  • Observabilidade via OpenTelemetry

Foi turbulento — bugs reportados, horas no canal #koog do Kotlin Slack — mas cada nova release pagou o investimento.

O argumento central

Um tipo definido em uma row do Postgres flui pelo handler do Ktor, passa pelo grafo de IA do Koog e chega numa tela Compose no iPhone de alguém.

Uma linguagem. Um modelo mental. Zero custo de troca de contexto entre plataformas.

🚀

Esse conteúdo faz parte do CAMP Platform

Cursos práticos de Android Moderno com Kotlin e Jetpack Compose, arquitetura limpa, assistente IA e uma comunidade de devs profissionais.

© 2026 CAMP Platform — Todos os direitos reservados
De Java para 100% Kotlin: como o iShape foi reconstruído do zero — CAMP Platform | CAMP