Compilation Targets

Kotlin/JS lets you compile Kotlin code into JavaScript. The IR target is the modern compiler backend. In Gradle you add js(IR) and pick browser() or nodejs() depending on where the code runs.

Adding jvm() tells the compiler to build a JVM version of your code. It produces Java bytecode (.class files, usually packaged in a .jar) that runs on any Java Virtual Machine.

Kotlin/Native compiles Kotlin straight to a native machine-code program. There is no Java Virtual Machine running it; you get a standalone executable or library that runs directly on the operating system.

They are two Kotlin Multiplatform targets that compile code to WebAssembly. wasmJs() runs in the browser and can talk to JavaScript; wasmWasi() runs in standalone runtimes outside the browser using the WASI system interface.

jvmToolchain picks which JDK version actually compiles and runs your code. jvmTarget sets the bytecode version the compiler emits. The toolchain is the tool; jvmTarget is the output format.

Both let Kotlin call JavaScript, but Kotlin/Wasm runs as a real Wasm module, so values crossing the boundary are limited and use a special JsAny type family. Kotlin/JS compiles to JavaScript directly, so its interop is looser and supports dynamic.

It is an annotation that marks the Wasm parts of the Gradle build DSL as experimental. You add an opt-in (like @OptIn) when calling wasmJs() or wasmWasi(), acknowledging that this configuration API may still change.

The CocoaPods plugin makes your shared module a Pod the iOS app pulls via a Podfile. The SwiftPM route publishes the framework as an XCFramework referenced by a Package.swift. Pick CocoaPods if the app already uses Pods; SwiftPM for a Pod-free, native Apple toolchain.

Each iOS target has a binaries.framework {} block where you set the framework name, choose static or dynamic linking, and export other KMP libraries so their public API also shows up in the Swift-facing framework.

Dead Code Elimination removes Kotlin code your app never uses from the final JavaScript. That keeps the bundle small, so you don't ship the whole standard library when you only call a few functions.

jvm() adds jvmMain and jvmTest source sets that build on top of commonMain/commonTest. Any code touching java.* APIs must go in jvmMain because common code has to compile for every target.

Modern Kotlin/Native uses a tracing garbage collector and lets you share regular objects freely across threads, like the JVM. The old model that froze objects and forbade sharing is gone.

Inside the target's binaries {} block you call executable(), sharedLib(), staticLib(), or framework(). Each tells the compiler what kind of output to build for that platform.

iosArm64 is for real devices only. The simulator on an Apple-silicon Mac needs iosSimulatorArm64. A plain .framework holds one slice, so the simulator can't link it. Build both targets and bundle them in an XCFramework, which carries multiple slices.

You tell the compiler to output ES modules instead of the default UMD format. Then the generated JavaScript uses import/export statements, so modern browsers and tools can load and tree-shake it natively.

@JsExport marks Kotlin declarations so they keep readable names and become callable from JavaScript. The IR backend can also generate TypeScript type files for them, but only certain Kotlin types map cleanly.

Pin jvmTarget to JVM_17 so the bytecode loads on JVM 17, while using a newer JDK toolchain to compile. If bytecode is too new, production throws UnsupportedClassVersionError at load time.

Kotlin compiles to ordinary JVM bytecode, so Java can call it. Annotations like @JvmStatic, @JvmName, @JvmOverloads, and @JvmField adjust how Kotlin constructs appear to Java callers.

Kotlin/Native ships a tool called cinterop. You give it a small .def file pointing at a C header and library, and it generates a Kotlin package whose functions and types call straight into the C code.

Put shared logic in commonMain and Wasm-specific JS interop code in wasmJsMain. Choose wasmJs for a Wasm browser app with JS interop, Kotlin/JS if you need broad runtime support today, and Kotlin/Native is not a web-frontend option.

Kotlin objects need garbage collection and Kotlin code throws exceptions. Instead of bundling those features, Kotlin/Wasm uses new WebAssembly proposals so the runtime provides GC and exception handling. The cost is that only recent runtimes can run the output.

You apply the Android library Gradle plugin, set compileSdk/minSdk and a namespace in the android {} block, and put Android-only code in androidMain. androidTarget() then builds an AAR that an Android app can depend on. You can pick which build variants get published.

Check that you measured a production build, look for broad @JsExport that blocks code removal, confirm the right module format, and verify your JS interop and npm dependencies still tree-shake. The IR backend usually shrinks bundles, so growth signals a misconfiguration.

Kotlin/Native compiles ahead-of-time with LLVM, which is slow and per-platform. Plan for long release builds, keep debug builds fast, cache aggressively, and don't expect the huge JVM library ecosystem.