Kodein — Kotlin Multiplatform Dependency Injection

Introduction

Kodein-DI is a dependency injection container for Kotlin that uses a type-safe DSL to define bindings. It is designed to be idiomatic Kotlin, working across all Kotlin Multiplatform targets (JVM, Android, iOS/Native, JavaScript, WASM) without code generation or annotation processing.

What Kodein Does

• Defines dependency bindings using a Kotlin DSL with singleton, provider, factory, and multiton scopes
• Resolves dependencies at runtime using reified type information, avoiding annotation processing or code generation
• Supports Kotlin Multiplatform projects with the same DI code shared across JVM, Native, JS, and WASM targets
• Provides scoped bindings that tie object lifecycle to Android Activities, Fragments, or custom scopes
• Allows modular DI configuration through importable DI modules that can be composed and overridden

Architecture Overview

Kodein-DI maintains a container of typed bindings defined in a DI builder block. Each binding maps a type key (optionally with a tag string) to a factory function. When a dependency is requested via instance(), provider(), or factory(), Kodein looks up the binding by its type key at runtime using Kotlin's reified generics. Dependencies are resolved lazily by default and can be injected via property delegation (by di.instance()). The container is immutable after construction, ensuring thread safety. Modules allow splitting bindings across files and composing them via the import() function in the DI builder.

Self-Hosting & Configuration

• Add the kodein-di dependency to your Gradle build file, choosing the artifact matching your platform (kodein-di for common, kodein-di-framework-android-x for Android)
• Define a DI container at the application level and pass it through your dependency graph or use DIAware interface
• Use bindSingleton for single-instance bindings, bindProvider for new instances on each retrieval, and bindFactory for parameterized construction
• For Android, implement DIAware in your Application class and use closestDI() in Activities and Fragments
• Organize bindings into DI.Module objects for separation of concerns and reuse across features

Key Features

• Kotlin-idiomatic DSL with no annotations, no code generation, and no reflection on most targets
• Full Kotlin Multiplatform support (JVM, Android, iOS, JS, WASM) from a single dependency
• Thread-safe immutable container with lazy resolution and property delegation
• Scoped bindings for lifecycle-aware dependency management on Android
• Module system for composable, reusable binding definitions across features and libraries

Comparison with Similar Tools

• Koin — another Kotlin DI framework with a similar DSL; slightly simpler API but less strict type safety at compile time
• Dagger/Hilt — compile-time DI via annotation processing; faster runtime performance but Android/JVM only and more verbose setup
• Spring DI — enterprise Java DI container; comprehensive but heavy and not suitable for Kotlin Multiplatform
• Manual DI — constructor injection without a framework; no library dependency but becomes unwieldy in large projects

FAQ

Q: How does Kodein compare to Koin? A: Both use Kotlin DSLs without code generation. Kodein has stronger type safety with reified generics and supports more Kotlin Multiplatform targets. Koin has a simpler API and slightly larger Android community. Both are valid choices for Kotlin DI.

Q: Does Kodein work with Kotlin Multiplatform (KMP)? A: Yes. Kodein-DI is fully multiplatform. You can define bindings in commonMain and resolve them on JVM, Android, iOS, JS, and WASM targets with the same API.

Q: Is Kodein suitable for Android apps? A: Yes. The kodein-di-framework-android-x module provides Android-specific features like lifecycle-scoped bindings, closest DI resolution in the Activity/Fragment hierarchy, and integration with ViewModel.

Q: Does Kodein use reflection or code generation? A: On the JVM, Kodein uses minimal reflection for type checking. On Kotlin/Native and Kotlin/JS, it uses no reflection. It never requires code generation or annotation processing on any platform.

Sources

• https://github.com/kosi-libs/Kodein
• https://kosi-libs.org/kodein/7.22/getting-started.html