Kotlin Toolchain 0.13: reduza o custo do projeto novo sem transformar isso em migração obrigatória

A JetBrains passou a recomendar Kotlin Toolchain 0.13 para a maioria dos novos projetos Kotlin Multiplatform.[17] A ferramenta reúne configuração de ambiente, criação de projetos, compilação, testes e publicação em uma entrada por CLI, com configuração declarativa e provisionamento automatizado.[17] A recomendação não é uma orientação para migrar indiscriminadamente projetos Gradle existentes.[17] Esse limite importa mais do que a novidade do comando.

O que muda para quem desenvolve

O novo kotlin new oferece criação interativa por tipo de aplicação e plataformas; kotlin init continua disponível para gerar arquivos no diretório atual.[17] No iOS, o onboarding melhora diagnósticos de licença e primeira execução do Xcode, baixa runtimes e cria simulador quando necessário.[17] No Android, a importação pela IDE provisiona componentes de SDK ausentes e reforça a validação de namespace e application ID.[17]

Minha leitura é que o ganho potencial está em reduzir decisões ambientais repetidas. Um agente ou uma pessoa consegue produzir código mais útil quando o projeto oferece comandos previsíveis e erros acionáveis. Isso não dispensa conferir o que foi instalado e quais plataformas o ambiente consegue atender.

A versão acrescenta integração com dependências Swift Package Manager, incluindo pacotes locais, e permite importar APIs Objective-C provenientes de código Objective-C e Swift com swiftPMImport.[17] Isso não representa suporte irrestrito a qualquer API Swift.[17]

O Kotlin/Native reutiliza dependências compiladas e usa caches por arquivo para código do projeto em binários debug não otimizados e alvos compatíveis; a geração de arquivos .klib continua completa.[17] Não transforme uma melhoria específica de incrementalidade em promessa sobre todo build.

Como aplicar

Para um projeto novo, proponha um teste de onboarding com as plataformas que o produto realmente pretende entregar. Registre o tempo até compilar, executar e testar uma aplicação mínima. Anote intervenções manuais, downloads e erros, sem confundir ausência de código de negócio com prontidão de produção.

Depois, faça uma mudança pequena e compare o ciclo com cache aquecido. Inclua uma dependência representativa do produto, especialmente se houver integração Apple. O objetivo é descobrir cedo se o fluxo reduz atrito sem bloquear uma necessidade real.

Para uma base existente, faça primeiro uma lista de plugins, customizações e etapas de publicação. Crie uma avaliação isolada, não substitua o build principal para experimentar. Critérios de aceitação devem incluir testes e artefatos equivalentes, além da velocidade.

O anúncio apresenta um servidor MCP de Hot Reload e skills oficiais instaláveis separadamente, com distribuição integrada prevista para depois.[17] Se usar agentes, mantenha explícitos os comandos permitidos e as condições para publicar artefatos.

Cuidados e limites

A equipe pretende fechar lacunas, especialmente em projetos Gradle existentes, antes de recomendar migrações.[17] Isso reforça uma adoção por necessidade, não por atualização automática da stack.

Benchmarks da equipe indicam maior confiabilidade e menor uso de tokens em fluxos com agentes.[17] São resultados do fornecedor. O teste decisivo é completar o ciclo do seu projeto com as dependências e plataformas reais, sem pressupor que a mesma melhora aparecerá em todos os ambientes.

Fonte

[17] Fonte: JetBrains Blog. Data/hora no feed: 07/10/2026 às 07:21:46.