skip to content

What is the Kotlin/Native target, and how does running a Kotlin/Native binary differ from running Kotlin on the JVM?

level: juniorimportance: must knowfreq 60%

answer

  1. LLVM backend, AOT, no JVM
  2. linuxX64 / macosArm64 / mingwX64
  3. executable, static/dynamic lib, Apple framework
  4. small runtime gives GC + stdlib
  5. iOS / CLI / C interop use cases

basics

~10 s

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.

solid answer

~40 s

Kotlin/Native is a Kotlin compiler backend that turns Kotlin into native binaries using the LLVM toolchain instead of JVM bytecode. You declare targets in the Gradle `kotlin {}` block such as `linuxX64()`, `macosArm64()`, or `mingwX64()`, and each produces platform-specific output: a standalone executable, a static (`.a`) or dynamic (`.so`/`.dll`/`.dylib`) library, or an Apple `.framework`. At runtime there is no JVM, no class loading, and no JIT — the code is already machine code, started by a small Kotlin/Native runtime that provides the garbage collector and standard library. This makes it suitable where a JVM is unavailable or undesirable: iOS apps, CLI tools, and embedding into C/Swift/Objective-C. Trade-offs include longer ahead-of-time compile times and a different memory model than the JVM.

go deeper

for a junior

Knows Kotlin/Native produces a native binary with no JVM and can name a couple of targets.

for a middle

Explains LLVM/AOT, the three output kinds, and that a small runtime supplies GC and stdlib.

for a senior

Discusses use cases (iOS, CLI, C interop) and trade-offs like build time and a distinct memory model.

for a principal

Frames target choice in a multiplatform strategy and weighs ecosystem maturity, binary size, and toolchain costs.

## What Kotlin/Native is **Kotlin/Native** is one of several compiler *backends* for the Kotlin language. The same Kotlin source can be compiled to: - **Kotlin/JVM** — Java bytecode that runs on a Java Virtual Machine. - **Kotlin/JS** — JavaScript. - **Kotlin/Wasm** — WebAssembly. - **Kotlin/Native** — native machine code, with *no JVM at runtime*. ## How it compiles Kotlin/Native uses **LLVM** as its code-generation toolchain. LLVM is a widely used compiler infrastructure (also used by Clang/Swift). The Kotlin compiler lowers Kotlin into LLVM intermediate representation (IR), and LLVM produces a native binary for a specific CPU architecture and operating system — this is **ahead-of-time (AOT)** compilation, done at build time, not at run time. ## Targets A *target* is a concrete platform you compile for. You declare them in Gradle: ```kotlin kotlin { linuxX64() // 64-bit Linux on Intel/AMD macosArm64() // Apple Silicon macOS mingwX64() // 64-bit Windows (MinGW toolchain) } ``` Each target produces output of a chosen kind: - a **standalone executable** (a runnable program); - a **static library** (`.a`) or **dynamic library** (`.so` on Linux, `.dll` on Windows, `.dylib` on macOS), callable from C; - an **Apple framework** (`.framework`), callable from Swift/Objective-C — the basis of Kotlin Multiplatform on iOS. ## What "no JVM at runtime" means On the JVM, your program needs a JVM installed; bytecode is loaded by a class loader and compiled to machine code on the fly by the JIT. With Kotlin/Native none of that happens: the binary is already machine code. A small **Kotlin/Native runtime** is linked in to provide the **garbage collector** and the standard library, but there is no separate VM process. ## Why use it - Targets where a JVM is impractical: **iOS**, embedded, or small CLI tools. - Direct **C interop** and embedding into native apps. - No JVM startup cost or runtime dependency. ## Trade-offs - **Slower builds** (AOT compilation is heavier than JVM compilation). - A **different memory model** and GC than the JVM. - Generally larger single-binary sizes and fewer mature libraries than the JVM ecosystem.

  • Does Kotlin/Native still have a garbage collector?
    Yes. A small native runtime is linked into the binary and provides a garbage collector plus the standard library; there just isn't a separate JVM process.
  • Name one output format unique to Apple platforms.
    An Apple `.framework`, which Swift/Objective-C code can import — this is how Kotlin Multiplatform shares code with iOS apps.

JVM is like shipping a recipe that the diner's kitchen cooks on demand; Kotlin/Native ships the finished meal ready to eat.

saying these in an interview costs you the question

  • Saying Kotlin/Native still runs on a hidden JVM
  • Claiming there is no garbage collector at all
  • Confusing it with Kotlin/JS or Kotlin/Wasm
  • Thinking it only produces executables, never libraries/frameworks
  • Believing compilation happens at runtime (it is ahead-of-time)

context

resolving links…