Índice de contenidos
Claves de la noticia
- JetBrains recomienda Kotlin Toolchain 0.13 para la mayoría de los proyectos nuevos de Kotlin Multiplatform, sin extender aún esa recomendación a todas las migraciones.
- La integración con Swift Package Manager utiliza las APIs accesibles mediante Objective-C y módulos Clang, no cualquier interfaz de Swift.
- Las cachés nativas aceleran el enlace de binarios de depuración compatibles; la compilación completa a archivos .klib permanece fuera de esa mejora.
Kotlin Toolchain 0.13 llega este 7 de octubre con una recomendación importante para quienes empiezan aplicaciones multiplataforma. JetBrains propone su herramienta como punto de entrada para la mayoría de los proyectos nuevos de KMP. El cambio incluye dependencias SwiftPM y cachés nativas, pero revisar los documentos revela límites que afectan a la distribución de bibliotecas y a cómo medir el ahorro de tiempo.
Una recomendación para empezar, con las migraciones pendientes
La herramienta reúne configuración declarativa, preparación del entorno y comandos de construcción, ejecución y publicación. La nueva versión incorpora un asistente mediante kotlin new; kotlin init conserva la creación de archivos en el directorio actual. JetBrains indica también las versiones de IDE necesarias para acceder a las novedades: IntelliJ IDEA 2026.2.3 o Android Studio Rabbit 1, 2026.2.1, o posteriores, con el complemento actualizado.
Ese respaldo para proyectos nuevos no supone que todos los repositorios Gradle deban migrar. La empresa dice que quiere cerrar carencias y comprender mejor esos proyectos antes de recomendar migraciones. La diferencia es práctica: una aplicación que parte de cero puede elegir sus convenciones alrededor de la herramienta; un repositorio existente ya tiene tareas, integraciones y procesos que necesitan equivalencias concretas.
Por tanto, la noticia no permite concluir que Gradle haya dejado de ser válido. Permite plantear una evaluación distinta para el siguiente proyecto. El equipo debe comparar los destinos que necesita y su forma de distribuir artefactos, en vez de interpretar la recomendación de JetBrains como una orden general de sustitución.
SwiftPM importa una frontera de APIs concreta
La documentación permite declarar un repositorio SwiftPM, una versión y los productos que se van a consumir en módulos con plataformas Apple. El nombre del gestor puede llevar a una conclusión demasiado amplia: resolver un paquete no implica que todas sus APIs Swift sean directamente utilizables desde Kotlin.
El mecanismo documentado importa módulos Clang mediante interoperabilidad nativa. La superficie que expone a Kotlin son APIs Objective-C procedentes de código Objective-C o Swift. Esa condición obliga a mirar la interfaz del paquete elegido, no solo que exista un archivo Package.swift. Un equipo que espera utilizar una API exclusivamente Swift debe comprobar la frontera realmente expuesta antes de adoptar la nueva configuración.
Hay una segunda condición menos visible al probar el proyecto localmente. Los paquetes Swift locales se conservan al publicar mediante su ruta absoluta en la máquina autora. Por ello, la documentación restringe la publicación de bibliotecas que dependen de ellos al repositorio Maven local y bloquea otros repositorios. No es un problema que pueda solucionarse cambiando simplemente el nombre de la biblioteca.
Una biblioteca que funciona con un paquete Swift local no queda lista para distribuirse a otros equipos. Al cruzar el formato de publicación con la resolución por rutas absolutas, la diferencia se vuelve comprobable: el consumidor no dispone necesariamente de ese mismo archivo en ese mismo lugar. Para compartir la biblioteca, la documentación pide utilizar paquetes remotos en esas dependencias.
Como antecedente técnico, el canal oficial Kotlin by JetBrains publicó el 19 de agosto una explicación de SwiftPM en Kotlin Multiplatform, por Timofey Solonin. Su descripción trata las APIs Objective-C y la publicación de bibliotecas. Es contexto sobre el mecanismo, no una demostración específica de la versión 0.13 ni una prueba realizada para este artículo.
La biblioteca publicable gana contenido respecto a 0.12
En septiembre, Kotlin Toolchain 0.12 había ampliado la publicación desde bibliotecas JVM a bibliotecas multiplataforma, con artefactos y metadatos por destino. Sin embargo, sus notas advertían que los recursos de Compose Multiplatform aún no formaban parte de la publicación.
La versión 0.13 incluye esos recursos y los metadatos de dependencias SwiftPM junto a los artefactos; también resuelve recursos Compose de bibliotecas externas. La comparación documenta un cambio de alcance que importa más que el número de versión: distribuir código y distribuir todo lo que necesita ese código son entregas distintas.
Para revisar una biblioteca compartida, resulta útil comprobar el consumo desde otro proyecto, además de su construcción en el repositorio de origen. El caso de los paquetes locales explica por qué: la máquina del autor puede ocultar dependencias que no viajan con el artefacto. Esta comprobación propuesta no es un ensayo que se haya ejecutado aquí; deriva de los límites de publicación descritos por la herramienta.
El enlace nativo mejora sin abarcar toda la compilación
La referencia de configuración precisa el alcance de settings.kotlin.compileIncrementally. En destinos nativos activa cachés de código compilado y reutilización entre construcciones, pero solo afecta al enlace de binarios y a variantes de depuración sin optimizar en destinos compatibles. La construcción de archivos .klib sigue ejecutándose como un conjunto completo.
| Trabajo | Aplicación de la mejora |
|---|---|
| Binario de depuración compatible | Reutilización de código compilado al enlazar |
| Compilación a .klib | Continúa completa |
| Binario optimizado | Fuera del alcance anunciado de esta caché |
El resultado es que una prueba de edición y ejecución de depuración no permite proyectar automáticamente su ahorro al empaquetado final. Tampoco debe confundirse la primera construcción, que necesita poblar las cachés, con una posterior que las reutiliza. No hay en este artículo una medición propia ni un porcentaje universal de aceleración.
La distinción entre etapas ya aparecía en mold 3.0 y su función de enlazador, y en los problemas de compilación incremental de Headstart. Son herramientas y entornos diferentes; el contexto útil es identificar qué trabajo se reduce antes de convertir un caso favorable en una promesa para todo el proceso.
La adopción de 0.13 tiene así dos comprobaciones especialmente valiosas: que las dependencias sean distribuibles fuera de la máquina autora y que la mejora de caché corresponda al tipo de binario que se utiliza a diario. Ambas evitan que un proyecto aparentemente funcional o un ensayo rápido escondan una condición que reaparecerá al compartirlo o publicarlo.
Imagen destacada: recreación editorial generada con IA de un entorno de desarrollo multiplataforma.
