# koin Koin is a lightweight dependency injection framework designed for Kotlin. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How to use Koin Compiler in a Multimodule Project? DevFeed: [How to use Koin Compiler in a Multimodule Project?]() Original publisher: [Read original article]() Author: Gabriel Bronzatti Moro Published: 2026-06-11T08:47:55Z Content type: tutorial Language: en Sources: [Koin developers - Medium]() Topics: [koin](), [compose-multiplatform](), [multiplatform](), [Gradle](), [Kotlin](), [implementation]() Tags: [build](), [compose](), [compose-multiplatform](), [gradle](), [how-to](), [implementation](), [koin](), [kotlin](), [migrate](), [multi-module-project](), [plugin]() ### AI overview A tutorial on migrating a Compose Multiplatform multi-module project to the Koin Compiler. It covers the required Kotlin and Koin versions, configuring the compiler dependency through Gradle, creating a convention plugin, applying it to modules, and updating module initialization. The article reports replacing an approximately 80-line custom Gradle plugin with a simpler approximately 30-line setup while retaining compile-time safety through the K2 compiler. ### Source excerpt Hey everyone! Today we're diving into how to use the Koin Compiler in a Compose Multiplatform multi-module project. In the previous article, we explored how to migrate a multimodule setup to Koin Annotations, using a convention Gradle plugin to move forward in small, safe steps. We'll follow that same approach diving deep into a project called MovieDB-App👋 A sticky note attached to a wall with the words "how to" written on it - Unsplash by walls_ioFirst step: Update your project, if necessary 🚀 Your project is eligible to support the Koin Compiler if it meets at least the following requirements: ✅ Kotlin 2.3.x or higher (K2 is required) ✅ Koin 4.2.x or higher Our sample project is using the following stack overview: 🤖 AGP: 9.1.0 🧩 Kotlin: 2.3.20 💉 Koin: 4.2.1 🏷 Koin Annotations: 2.3.1 Second step: Configure Koin compiler dependency Let's add our Koin Compiler dependency into the libs.versions.toml : #gradle/libs.versions.toml [versions] koin-compiler-plugin = "1.0.0" ... [libraries] koin-compiler-plugin = { group = "io.insert-koin", name = "koin-compiler-gradle-plugin", version.ref = "koin-compiler-plugin" } Now, let's run Gradle Sync 🐘 Our mission is to create a conventional plugin in our build-logic so we can migrate the project module by module, taking small and safe steps along the way. To achieve that let's add the koin compiler dependency as a depency of our build-logic: // build-logic/build.gradle.kts ... dependencies { implementation(libs.koin.compiler.plugin) } After syncing Gradle, it's time to create our conventional plugin: // build-logic/src/main/kotlin/plugins/KoinCompilerSetupPlugin.kt package plugins import org.gradle.accessors.dm.LibrariesForLibs import org.gradle.api.Plugin import org.gradle.api.Project import org.gradle.kotlin.dsl.configure import org.gradle.kotlin.dsl.dependencies import org.gradle.kotlin.dsl.the import org.koin.compiler.plugin.KoinGradleExtension // Ref: https://github.com/InsertKoinIO/koin-compiler-plugin/blob/main/docs/CASE_S ## Unlocking Koin Compile Safety -- Koin Compiler Plugin 1.0.0-RC1 DevFeed: [Unlocking Koin Compile Safety -- Koin Compiler Plugin 1.0.0-RC1]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-04-14T08:08:36Z Content type: release Language: en Sources: [Koin developers - Medium]() Topics: [koin](), [Compiler](), [Dependency injection](), [Kotlin](), [Code generation]() Tags: [compilation](), [compiler](), [dependency](), [dependency-injection](), [generation](), [koin](), [kotlin](), [kotlin-multiplatform](), [plugin](), [release](), [safety]() ### AI overview Koin announces Compiler Plugin 1.0.0-RC1 for Kotlin and KMP. The release candidate validates dependency graphs during compilation and adds constructor auto-wiring across DSL and annotations. ### Source excerpt Koin Compiler Plugin 1.0.0-RC1 -- Unlocking Compile-Safe Dependency Injection for Kotlin & KMP Hello Koin Community 👋 Compile-time safety has been one of the most requested features by the community. For years, verifying your Koin dependency graph required runtime tools with checkModules()and verify()in your test suite. They run after compilation. If something is missing, you find out in test results, not at build time. It's now time for new generation of tools for Koin. My Linkedin post for AndroidMakers Last week at Android Makers (Paris, France), we announced Koin Compiler Plugin 1.0.0-RC1! This release candidate brings compile-time safety, constructor auto-wiring, and a unified developer experience for both DSL and Annotations, all powered by a native Kotlin Compiler Plugin. Aligned with Koin 4.2.1 and Kotlin 2.3.20. Check out the roadmap and documentation to get started. Dependency graph validation is done in the Koin Compiler Plugin itself: your graph is verified as part of the build (no need to run tests). DSL, annotations, and even individual call sites are checked. The Kotlin compiler plugin ecosystem has matured, and new DI approaches are emerging. Koin's answer is straightforward: lighter Compiler codegen, an existing runtime container, and validation by design of the compilation. Koin Compiler Plugin -- 1.0.0-RC1Check the online Koin documentation for further information: https://insert-koin.io/docs/intro/koin-compiler-plugin We are also gathering some "playground apps" to showcase different scenarios of Koin Compiler Usages (https://github.com/InsertKoinIO/playground-apps) Koin Compiler Plugin Setup 🔎 Below, you will find the minimum versions of Koin & Koin Compiler Plugin that are allowed to enable compile safety (note that you need Kotlin 2.3.20): [versions] kotlin = "2.3.20" koin = "4.2.1" koin-plugin = "1.0.0-RC1" [libraries] koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" } # if using annotations koin-annotations = { module = ## 51 Detekt Rules for Koin: Catch Anti-Patterns Your Compiler Misses DevFeed: [51 Detekt Rules for Koin: Catch Anti-Patterns Your Compiler Misses]() Original publisher: [Read original article]() Author: Kirill Rozov Published: 2026-03-02T08:17:18Z Content type: tutorial Language: en Sources: [Stories by Kirill Rozov on Medium]() Topics: [koin](), [Android](), [ci]() Tags: [analysis](), [android](), [best-practices](), [ci](), [dependencies](), [detekt](), [errors](), [koin](), [kotlin](), [kotlin-multiplatform](), [tests]() ### AI overview This article explains how the detekt-rules-koin Detekt extension identifies Koin dependency-injection anti-patterns that compile successfully but can fail at runtime. It covers misuse of get(), service-locator access through KoinComponent, singleton registration for mutable use cases, and installation in an existing Detekt setup. ### Source excerpt Your Koin module compiles. Unit tests pass. CI is green. Then production crashes with NoBeanDefFoundException on first launch -- and the offending line has been sitting in your codebase for weeks. Koin's runtime graph resolution means the compiler never sees these bugs; it only surfaces them when Koin tries to wire everything together. No red underlines, no warnings, no build failures -- just a crash on a user's device. This is the fundamental tension with Koin: its DSL is concise and readable, but none of the structure it creates is visible to the type system. The three examples below compile without errors on any Android project. All three will cause real problems at runtime. Static analysis is the standard answer to this class of problem -- but generic Detekt rules were not written with Koin's semantics in mind. A rule that flags unused variables or improper nullability checks has no concept of a Koin scope, a module definition block, or the difference between single and factory. What you need is a rule set that understands Koin. That's exactly what detekt-rules-koin provides. Problem 1 -- `NoGetOutsideModuleDefinition`// ❌ get() called outside a Koin module - compiles, crashes at runtime class UserRepositoryImpl : UserRepository { // KoinComponent not implemented, no scope active private val db: AppDatabase = get() private val api: UserApi = get() } get() is only valid inside a Koin module definition block, where the Koin container is active and providing dependencies. Calling it here triggers IllegalStateException: KoinApplication has not been started -- or silently resolves to the wrong scope -- depending on how your app is wired. Problem 2 -- NoKoinComponentInterface// ❌ Repository using Service Locator via KoinComponent class UserRepository : KoinComponent { private val db: AppDatabase by inject() private val api: UserApi by inject() fun getUser(id: String) = api.fetchUser(id) }// ✅ Constructor injection - dependencies are explicit and testable class UserRepository ## Re: Dependency Injection vs. Service Locators DevFeed: [Re: Dependency Injection vs. Service Locators]() Original publisher: [Read original article]() Author: Zac Sweers Published: 2026-02-20T05:10:16Z Content type: opinion Language: en Sources: [Zac Sweers]() Topics: [Dependency injection](), [Dagger](), [koin](), [Kotlin](), [service](), [multiplatform]() Tags: [dagger](), [dependency-injection](), [koin](), [kotlin](), [metro](), [service]() ### AI overview The article compares dependency injection frameworks with service locators, focusing on compile-time validation, testing, isolation, generated performance, and the tradeoff of requiring more explicit code. It discusses Metro, Dagger, Hilt, Anvil, kotlin-inject, Koin, and manual dependency injection. ### Source excerpt This is a port of a write-up I did in the Kotlin Lang slack here in response to the question "Dagger vs. Hilt vs. Koin vs. Metro vs. . Serious question: Are there any compelling reasons to switch from Koin to Metro in a ## Going Fully Multiplatform #1: Migrating your Android Project to Kotlin Multiplatform DevFeed: [Going Fully Multiplatform #1: Migrating your Android Project to Kotlin Multiplatform]() Original publisher: [Read original article]() Author: Isuru Rajapakse Published: 2021-10-21T13:24:07Z Content type: tutorial Language: en Sources: [Stories by Isuru Rajapakse on Medium]() Topics: [Kotlin Multiplatform](), [multiplatform](), [Kotlin](), [Android](), [iOS](), [Ktor](), [Web](), [Jetpack Compose](), [koin](), [RxJava](), [navigation]() Tags: [android](), [caching](), [dependency-injection](), [kotlin](), [kotlin-multiplatform](), [ktor](), [libraries](), [moshi](), [multiplatform](), [navigation](), [okhttp](), [retrofit](), [rxjava]() ### AI overview The article describes migrating an Android-only application to Kotlin Multiplatform. It compares the existing Android stack with a planned multiplatform stack targeting Android, JVM, iOS, and Web, including changes to networking, serialization, caching, dependency injection, asynchronous plumbing, navigation, and UI. ### Source excerpt Earlier this year I started a mission to start migrating one of our long-lasting Android-only apps to Kotlin Multiplatform to go beyond just Android. This is the story of how that went. Migration from Only-Android to Kotlin Multiplatform!The Android stack This is our current "stack" our android app was set up as follows Targeting Android SDK API 23 or above, we had a few libraries to help us out. The Android-only stack OkHttp for Networking Retrofit for.. also Networking Moshi for serialisation Okio for caching Koin for Dependency Injection/ Service Locator Plumbing with RxJava Navigation with Conductor Imperative UI with Android Views written in XML The Multiplatform stack To go beyond just Android, I had to make some hard decisions to step outside of the comfort zone that we've been so fond of To target Android, JVM, iOS and Web -- we will be making use of The Multiplatform stack Ktor for Networking Kotlin Serialisation for.. serialisation Caching with SQLDelight Koin for Dependency Injection (that one can stay) Plumbing with Coroutine Flows Navigation with Decompose Declarative UI powered with Jetpack/Jetbrains Compose That's the plan! In the next few articles, we'll take a look at each step in more detail. Before jumping on to that -- I want to take a close look at how we can fully modularise a Kotlin Multiplatform project with Going Fully Multiplatform #2 Modularising your Kotlin Multiplatform Project! ## Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem DevFeed: [Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem]() Original publisher: [Read original article]() Author: Danny Preussler Published: 2020-06-22T17:39:16Z Content type: opinion Language: en Sources: [Stories by Danny Preussler on Medium]() Topics: [Code](), [clean-code](), [Dagger](), [koin]() Tags: [android](), [clean-code](), [code](), [code-smells](), [constructor](), [dagger](), [dependencies](), [dependency-injection](), [koin](), [kotlin]() ### AI overview The article argues that dependency-injection tools can hide overly large constructors. It presents large constructors as a code smell that may indicate a violation of the Single Responsibility Principle, and notes that they make classes harder to test. ### Source excerpt How tools made us forget how to write sane constructors https://unsplash.com/photos/qvBYnMuNJ9A In an ideal world, developers get smarter every day. The code we write this year should be better than the code we wrote 10 years ago, which in turn should be better than the code 20 years ago. Today we have better tools, more modern languages, and better practices. But as often in life, we realize we are not living in that ideal world. In nearly every codebase I see today, there are things that would shock a developer two decades ago. I am speaking of what Mark Seemann called "Constructor Over Injection". We've all learned to inject our dependencies into constructors. And ideally use a tool for that like Spring or Dagger. If you look at some random classes from your codebase, how many fields are you injecting? Three? Five? More? I'm pretty sure you easily can find classes with even more, like this one: class ProfilePresenter @Inject constructor( @MainThreadScheduler private val mainScheduler: Scheduler, @IOScheduler private val ioScheduler: Scheduler, private val profileApi: ProfileApi, private val userRepository: UserRepository, private val analytics: Analytics, private val errorReporter: ErrorReporter private val referrerTracker: ReferrerTracker, private val shareTracker: ShareTracker, private val tracksRepository: TracksRepository, private val playlistRepository: PlaylistRepository ) If you would show this constructor to a developer from 20 years ago they would probably look at you as if you would be crazy. No one would want to call this constructor and provide all these parameters. But these days we don't care. We don't have to. We have a tool that will provide us with all those parameters, right? This does not make it right though! The proof If you would use some manual injection code or a service locator like Koin, you would notice more what's going on because you would need to write code like this: ProfilePresenter(get(), get(), get(), get(), get(), get(), get(), ## Koin and Dagger for dependency injection on Android DevFeed: [Koin and Dagger for dependency injection on Android]() Original publisher: [Read original article]() Published: 2019-06-13T00:00:00Z Content type: tutorial Language: en Sources: [Antonio Leiva]() Topics: [koin](), [Dependency injection](), [Dagger](), [Android](), [Kotlin]() Tags: [android](), [architecture](), [dagger](), [dependency-injection](), [how-to](), [koin](), [kotlin]() ### AI overview A video explains why dependency injection is useful on Android, compares Dagger with Koin, and demonstrates how to start using Koin in a complete example. ### Source excerpt Everything Android, Kotlin and other random topics