Koin: dependency injection for Kotlin and Kotlin Multiplatform, now with compile-time checking

The problem Koin solves for Kotlin codebases

Koin exists for teams writing Kotlin who want dependency injection without the ceremony that annotation-driven frameworks carry. The README describes it as "a pragmatic, lightweight dependency injection framework for Kotlin developers", developed by Kotzilla together with open-source contributors. That positioning matters: the project targets the moment when manual constructor wiring in a growing Kotlin codebase stops being manageable, but a full annotation processor or code generator still feels like too much machinery.

The audience is broader than Android. The repository topics list android, kotlin-multiplatform and kotlin-multiplatform-library, and the examples directory contains android-perfs, jvm-perfs, hello-ktor, ktor-di-sample, multimodule-ktor, sample-android-compose and sample-desktop-compose. So the intended user is a Kotlin developer on any of those targets, not only an Android developer. If you are writing a shared module that has to run on JVM and Android from one source set, Koin's multi-target support is the reason it appears in the dependency list.

The trade-off is visible in the name of the DSL itself. A container you configure in code is flexible and easy to read, but nothing stops a definition from referencing a binding that was never declared. Koin's answer to that is the compiler plugin, which the README says makes the framework compile-safe. That is the most consequential change described in the project's own documentation, and it reframes Koin from a runtime-only container into something closer to a checked one.

How Koin's DSL, modules and compiler plugin fit together

Koin's mechanism is a runtime container populated by declarations. You describe bindings inside modules, and the container resolves them when the application starts or when a component asks for a dependency. The README keeps the pitch short: "Keep Koin's concise, idiomatic DSL, no extra boilerplate". There is no generated factory class to inspect, and no annotation processor step in the build, unless you opt into the compiler plugin.

The compiler plugin changes the failure point rather than the programming model. According to the README, "Your dependency graph is verified at compile time, missing bindings, broken definitions, and misconfigured modules are caught by the compiler instead of crashing at runtime." The same paragraph states it "Works across Kotlin & Kotlin Multiplatform targets". So the data flow stays the same: modules declare bindings, the container resolves them. What changes is when an unresolved reference surfaces.

That distinction is the whole argument for adopting the plugin. Runtime resolution failures tend to appear on a code path that a test suite may not cover, often the first time a screen or a background job runs. Compile-time verification moves that class of error into the build. The plugin lives in a separate repository, InsertKoinIO/koin-compiler-plugin, which the README links to for getting started. That separation is worth noting: the core framework and the verification tooling are versioned and documented independently, so a team can adopt one without the other, and a team that adopts both has two things to keep in step.

The repository layout reflects a multi-target project rather than a single artifact. Top-level entries include docs/, examples/, projects/ and license_header.txt, with a Gradle wrapper under examples/. The examples folder is where a new user is most likely to find a working configuration for their target, since the README itself defers setup to a dedicated page on insert-koin.io rather than listing coordinates.

Installing Koin and resolving your first dependency

The README does not list Gradle coordinates. It says to follow the dedicated setup page at insert-koin.io/docs/setup/koin for your project, and it points at Maven Central for the current version of the core artifact. The artifact identifiers appear in the project's search traffic as io.insert-koin:koin-core, io.insert-koin:koin-android, io.insert-koin:koin-bom and io.insert-koin:koin-annotations, which is consistent with a multi-artifact project split by target. Because the README does not pin a version, take the version from Maven Central rather than from any example you copy.

A minimal JVM setup adds the core artifact to your build. The module names below are the ones the repository's examples use, and the version comes from Maven Central:

// build.gradle.kts
dependencies {
    implementation("io.insert-koin:koin-core")
}

For an Android app, the README's ecosystem points at a separate artifact, and the search data shows io.insert-koin:koin-android as the name people look for. The shape of the declaration is the same, only the artifact changes:

// build.gradle.kts (Android module)
dependencies {
    implementation("io.insert-koin:koin-android")
}

The README does not print a full usage example, so the only runnable references are the projects under examples/, which include hello-ktor, ktor-di-sample, multimodule-ktor, sample-android-compose and sample-desktop-compose. Open the one closest to your target, read its settings.gradle and build.gradle, and start the sample with the Gradle wrapper the repository ships:

cd examples
./gradlew build

What you should see is the example project compiling and running with its Koin modules registered. If you have added the Koin Compiler Plugin from the koin-compiler-plugin repository, a binding that references something the module never declares should fail the build rather than the run. The README does not document the plugin's own Gradle configuration, so check that repository for the exact plugin id and version.

Where Koin is the wrong choice

The clearest limitation is the one the README itself concedes by announcing a compiler plugin: without it, Koin's graph is a runtime construct. Missing bindings and misconfigured modules are runtime errors. If your team's constraint is that dependency wiring must be verified by the type system with no additional build plugin, Koin's default mode does not give you that, and adding the plugin means another component in the build to version alongside Kotlin and your targets.

A second boundary is the artifact split. Koin is not one dependency. The search data shows people looking for koin-core, koin-android, koin-bom and koin-annotations, and the compiler plugin lives in a different repository from the framework. Teams that expect a single coordinate to cover every target will need to assemble the right set, and the README does not enumerate them, deferring instead to the setup page. If you are evaluating Koin for an offline or air-gapped build, that dispersion is something to plan for rather than discover.

A third case is organisational rather than technical. The README separates community support (Kotlin Slack, Stack Overflow with the koin tag, GitHub issues, the Koin blog) from Koin LTS, a paid offering from Kotzilla with SLA-backed updates, long-term maintenance on stabilised versions such as Koin 3.5 LTS, security and compliance patches, and priority bug fixes. If your process requires a contractual support path, the free channels are not that, and the paid tier is a separate decision from adopting the library. Nothing in the README suggests the open-source framework is gated behind it, but the support expectations differ.

Finally, Koin is Kotlin-specific. The README frames it entirely around Kotlin and Kotlin Multiplatform. A mixed Java and Kotlin codebase, or a JVM service written mostly in Java, gets no benefit from the DSL and would be better served by a container that treats Java as a first-class consumer.

Koin compared with annotation-processing DI

The natural alternative for a Kotlin or Android project is an annotation-processing framework, where you annotate constructors and fields and a processor generates the wiring at build time. The difference in approach is where the graph lives. With annotation processing, the graph is derived from your source annotations and the generated code is inspectable. With Koin, the graph is written explicitly in modules using the DSL, and the README's stated advantage is that you "Keep Koin's concise, idiomatic DSL, no extra boilerplate".

That difference cuts both ways. Explicit modules are easy to read and easy to change without regenerating anything, and they do not require an annotation processor in the build. Against that, the graph is code you maintain by hand, and its correctness is not enforced by the type system in the default configuration. The Koin Compiler Plugin narrows that gap by verifying the graph at compile time, but it is a plugin you add, from a separate repository, not a property of the core library.

The second real difference is target coverage. Koin's README states that compile-safe verification "Works across Kotlin & Kotlin Multiplatform targets", and the repository topics include kotlin-multiplatform. For a project sharing code across Android and iOS or JVM, that multi-target story is the reason to look at Koin specifically. A framework whose tooling assumes a single platform will not map cleanly onto a shared module, no matter how good its generated code is.

A third option worth naming is doing nothing: passing dependencies through constructors by hand. Koin's own framing is that it is lightweight, so if your object graph is small and shallow, manual wiring has no dependency to upgrade and no container to start. Koin earns its place when the graph grows enough that the wiring code becomes the thing you are maintaining.

Licence, maintenance and upgrade cost

Koin is licensed under Apache-2.0, with the LICENSE file at the repository root and license_header.txt alongside it. Apache-2.0 is a permissive licence that permits commercial use and modification, and it includes an explicit patent grant and a notice requirement. That last point is the practical obligation: if you redistribute the library or a derivative, you carry the notice. This is a description of the licence text, not legal advice, and organisations with compliance review processes should route the LICENSE file through them.

The maintenance picture is straightforward from the repository facts. The repository is not archived, and the last push was on 2026-09-20, one day before this review. The most recent release listed is 4.2.2 from 2026-06-15, preceded by 4.2.1 on 2026-04-10 and 4.2.1-RC1 on 2026-04-03. The release cadence shown here is a minor patch line with release candidates ahead of it, which tells you what to expect on upgrades: patch releases arrive between feature versions, and RCs are published before the stable tag, so a team that pins versions has a window to test.

Upgrade cost has two axes. The first is the core library, where the version is whatever Maven Central currently serves and the README does not commit to a compatibility policy. The second is the Koin Compiler Plugin. Because it lives in its own repository and verifies the graph against your Kotlin version and targets, it is the component most likely to constrain when you can move to a new Kotlin release. For teams that need stability over currency, the README points to Koin LTS and names Koin 3.5 LTS as an example of a stabilised version held under long-term maintenance, which is a different upgrade model: you stay on a maintained line rather than tracking the newest release.

Editorial conclusion

Adopt Koin if you want a Kotlin-first DI layer that works across JVM, Android and Kotlin Multiplatform targets without annotation processing, and if you are willing to add the Koin Compiler Plugin so missing bindings fail the build instead of the app. Skip it if you need compile-time wiring without any plugin, or if you already rely on an annotation processor and do not want to migrate. Before committing, verify the current Koin version on Maven Central, check that the Compiler Plugin supports your Kotlin and target combination, and decide whether the free community channels or a paid Koin LTS agreement matches your support expectations.

Frequently asked questions

Official sources

1. InsertKoinIO/koin on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases