Antes de sumergirte de lleno en los pipelines de compilación y la creación de tu primer monorepo (como detallamos en nuestra Guía Completa de Kotlin Multiplatform), es fundamental dominar los cimientos estables del lenguaje.

Si vienes del desarrollo nativo en Android, probablemente ya des por sentado el Null Safety (la seguridad contra nulos) de Kotlin. Es como el cinturón de seguridad: te olvidas de que está ahí hasta que te salva de un choque con el famoso NullPointerException.

Pero cuando entramos en el terreno de Kotlin Multiplatform (KMP), ocurre la verdadera magia: este escudo no solo te protege dentro de Kotlin, sino que también se proyecta hacia las plataformas de destino. En Swift el mapeo es muy sólido; en Java, en cambio, se traduce sobre todo en anotaciones de nulabilidad y no en una garantía absoluta de compilador.

¿Cómo interactúan estos mundos tan diferentes? Vamos a verlo.

1. El breve recordatorio: La navaja suiza de Kotlin

En Kotlin, la distinción entre un tipo que puede ser nulo y uno que no, se define desde el sistema de tipos en tiempo de compilación. No es un parche, es parte del ADN del lenguaje.

var nombre: String = "Kotlin"  // No puede ser nulo jamás
// nombre = null // Esto ni siquiera compila ❌

var apellido: String? = null  // Puede ser nulo

Hasta aquí, todo bajo control. Pero, ¿qué pasa cuando compilamos este código y el equipo de iOS o de Backend lo consume en sus respectivos lenguajes?

2. El puente de interoperabilidad: De Kotlin al resto del mundo

Cuando compilas un proyecto KMP, el compilador traduce tu código Kotlin a un framework de Objective-C (para iOS) y a Bytecode (para Java/Android). Es aquí donde el sistema de tipos de Kotlin tiene que «negociar» con las reglas de los demás.

El mapa de traducción de tipos:

El caso de Swift: Un matrimonio casi perfecto

Swift y Kotlin comparten una filosofía muy similar respecto a los nulos (en Swift se llaman Optionals). Gracias a esto, la traducción es limpísima. Si defines un String? en tu código compartido de KMP, Swift lo recibirá como un String? (u Optional<String>). El desarrollador de iOS estará obligado por su propio compilador a desenvolver (unwrap) esa variable.

El caso de Java: El peso de la historia

Java nació en una época donde todo objeto podía ser null. Para comunicar la intención de Kotlin, KMP inyecta anotaciones de JetBrains (@NonNull y @Nullable). Las herramientas modernas como Android Studio o IntelliJ leerán estas anotaciones y avisarán al desarrollador con un warning en el IDE si intenta pasar un nulo donde no debe, aunque técnicamente la JVM lo siga permitiendo en tiempo de ejecución. Además, en cuanto Kotlin consume APIs escritas en Java, aparecen los platform types, una zona gris donde el compilador ya no puede garantizar la nulidad con la misma fuerza.

3. El «choque cultural»: Detalles que debes cuidar

Aunque la traducción es automática, existen un par de situaciones donde el escudo puede agrietarse si no prestas atención:

⚠️ Los tipos primitivos nulos en iOS: Los tipos como Int, Boolean o Double en Kotlin son primitivos eficientes. Pero si los marcas como opcionales (Int?), Swift no puede convertirlos directamente en sus opcionales nativos de la misma manera porque los primitivos en Objective-C no manejan la nulidad igual. Kotlin los envuelve en clases especiales como KotlinInt. En el lado de Swift, te tocará lidiar con contenedores en lugar del tipo limpio.

Ejemplo práctico en Swift:

Si en Kotlin compartes esto:

data class Usuario(val id: Int, val edad: Int?)

En Swift se consumirá de una forma similar a esta:

let usuario = ObtenerUsuario()
print(usuario.id) // Un Int nativo normal y corriente
print(usuario.edad) // Ojo: Aquí es un objeto de tipo KotlinInt?, requiere un trato especial

4. Enfoque Sénior: Diseño de APIs y la mitigación de wrappers opcionales en iOS

En proyectos de gran envergadura, forzar a los desarrolladores de iOS a desenvolver wrappers artificiales como KotlinInt? o KotlinBoolean? genera frustración y un código Swift poco natural. Un arquitecto de software sénior en KMP debe aplicar una de las siguientes dos estrategias para garantizar una API limpia en la capa común:

• Exposición de nulos a través de tipos de referencia nativos: En lugar de declarar tipos primitivos anulables en el data class común, se pueden utilizar fachadas o modelos dedicados para la UI que expongan tipos no primitivos o encapsulados directamente en una estructura de datos nativa que Objective-C y Swift interpreten con mayor fluidez.
• Implementación anticipada de SKIE o Swift Export: Integrar herramientas de compilación como SKIE permite que el compilador intercepte estos wrappers y los transforme automáticamente en opcionales puros de Swift durante la generación del framework, eliminando la fricción de raíz.

Para profundizar

Si quieres ver los detalles técnicos de cómo el compilador de Kotlin gestiona la nulidad y exporta estos componentes bajo el capó, te recomiendo revisar la documentación oficial de JetBrains:

• Null Safety en Kotlin: La guía oficial sobre cómo funciona el sistema de tipos y la seguridad contra nulos en el lenguaje base.
• Interoperabilidad de Kotlin/Native con Swift y Objective-C: Documentación técnica sobre cómo se mapean los tipos de Kotlin cuando compilas para plataformas Apple.
• El futuro con Swift Export: Una mirada a la nueva herramienta en desarrollo que mejorará aún más el mapeo directo de tipos (incluyendo los primitivos opcionales) sin pasar por Objective-C.

Conclusión

El sistema de tipos de Kotlin es el pilar invisible de KMP. Al escribir tu lógica de negocio una sola vez, no solo compartes algoritmos; estás exportando contratos de estabilidad. En Swift esos contratos se traducen con enorme fidelidad; en Java reducen ambigüedad gracias a las anotaciones, aunque la frontera con APIs heredadas y platform types siga requiriendo criterio adicional.

¡Tu código, tus reglas, en cualquier plataforma!

Una vez asentados los tipos y la seguridad contra nulos, el siguiente reto es aprender a representar estructuras complejas y flujos de estados finitos en KMP. En el próximo artículo, Unidad 0 — Tema 2: Modelando datos sin errores: El poder de las Sealed Interfaces en Kotlin, descubriremos cómo blindar nuestra UI contra estados contradictorios o imposibles de forma estricta y nativa.