skip to content

Kotlin/Native Target

3 roadmaps5 questions

Kotlin/Native compiles through LLVM to a standalone binary, a library, or an Apple framework, with no JVM anywhere at runtime. That absence is what makes its memory model and interop story different enough to be its own topic.

part ofKotlinoverview, primer and where to startread it →
on this pageshow

explore

questions

5

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…

open as a page

Describe the Kotlin/Native memory model and garbage collector. What changed from the original (legacy) model, and what does it mean for sharing objects across threads?

level: middleimportance: should knowfreq 40%

basics

~10 s

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.

open as a page

How do you choose what a Kotlin/Native target produces — an executable, a shared library, or an Apple framework — using the Gradle binaries DSL?

level: middleimportance: should knowfreq 45%

basics

~10 s

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.

open as a page

How does Kotlin/Native interoperate with C libraries? Walk through cinterop, .def files, and how C types map into Kotlin.

level: seniorimportance: should knowfreq 35%

basics

~20 s

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.

open as a page

You ship a Kotlin/Native CLI and an iOS framework. What toolchain and build-performance characteristics of Kotlin/Native should drive your engineering decisions, and how do you mitigate the rough edges?

level: principalimportance: nice to knowfreq 22%

basics

~10 s

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.

open as a page