# koin

Published articles for koin.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Koin Compiler 1.2: Compile-Time Safety for ALL Koin DSL

DevFeed: [Koin Compiler 1.2: Compile-Time Safety for ALL Koin DSL](<https://devfeed.tech/articles/koin-compiler-1-2-compile-time-safety-for-all-koin-dsl-22973.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/koin-compiler-1-2-compile-time-safety-for-all-koin-dsl-4603787b9921?source=rss----925561f2ecdf---4>)

Author: Arnaud Giuliani

Published: 2026-09-10T12:01:01Z

Content type: release

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [Compiler](<https://devfeed.tech/topics/compiler.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>)

### AI overview

Koin Compiler Plugin 1.2, with 1.2.1 as the latest patch, extends compile-time validation to Koin's reified, constructor, and classic lambda DSLs. It also adds visibility across Gradle modules, supports additional entry points, and provides one artifact for Kotlin 2.3.20 through 2.4.20 without requiring a DSL migration.

### Source excerpt

Hello, dear Koin community 👋 I'm happy to share that Koin Compiler Plugin 1.2 is out, with 1.2.1 already available as the latest patch. Developer mascott unboxing new Koin Features!TL;DR Compile-time validation now works on the Koin application you already have, where before 1.2 it only covered code written specifically for the compiler plugin. Koin DSL -- All now covered! All Koin DSL: the plugin's reified DSL, Koin's constructor DSL (singleOf(::T)), and the classic lambda DSL (single { Foo(get()) }). Across Gradle modules: definitions are now visible two or more implementation hops away. More entry points: Ktor's install(Koin) and KoinApplication.withConfiguration<T>(). One artifact for Kotlin 2.3.20 through 2.4.20. You get there with no migration to a new DSL, and nothing to rewrite. Let's go through what shipped. Covering now all Koin DSL Until now, compile-time safety only covered the plugin's own reified DSL, which means the two DSL styles you have most likely already written were invisible to it. val appModule = module { single<UserService>() // checked singleOf(::UserRepository) // not checked before 1.2 single { AnalyticsHelper(get()) } // not checked before 1.2 } Three ways to declare a definition, and only the first was validated. If your UserRepository needed a Database that no module provided, your build passed and Koin threw at runtime. In 1.2, all three are validated. The two DSL styles get there differently. For the constructor DSL, the referenced constructor's parameters become real requirements, exactly like single<T>(), and any named() qualifier you put on the registration is matched against the consumers that ask for it. The classic lambda DSL works differently. The plugin doesn't try to work out dependencies from free-form lambda code. What it validates instead are the get() calls you wrote inside the lambda, treated as ordinary resolution call sites. Before 1.2 those calls were skipped on purpose, because a hand-written get() is difficult to dis

## Setting Up Koin in a Real Kotlin Multiplatform Project: A Step-by-Step Guide

DevFeed: [Setting Up Koin in a Real Kotlin Multiplatform Project: A Step-by-Step Guide](<https://devfeed.tech/articles/setting-up-koin-in-real-project-a-step-by-step-guide-22976.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/setting-up-koin-in-real-project-a-step-by-step-guide-1575e2357239?source=rss----925561f2ecdf---4>)

Author: Gabriel Bronzatti Moro

Published: 2026-09-07T12:01:03Z

Content type: tutorial

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [compose-multiplatform](<https://devfeed.tech/topics/compose-multiplatform.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android](<https://devfeed.tech/topics/android.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [ui](<https://devfeed.tech/topics/ui.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [compose-multiplatform](<https://devfeed.tech/tags/compose-multiplatform.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [guide](<https://devfeed.tech/tags/guide.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [ios](<https://devfeed.tech/tags/ios.md>), [kmp](<https://devfeed.tech/tags/kmp.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>), [module](<https://devfeed.tech/tags/module.md>), [viewmodel](<https://devfeed.tech/tags/viewmodel.md>)

### AI overview

A step-by-step tutorial for setting up Koin in a Kotlin Multiplatform project targeting Android and iOS. It covers dependencies, data, domain, and UI modules, a platform bridge, platform entry points, and dependency injection in Composables.

### Source excerpt

Hi everyone! 👋 In this article, we'll take a practical, step-by-step approach to setting up Koin in a real-world Kotlin Multiplatform (KMP) project. Instead of starting with an isolated example or a simple Hello World, we'll work with a project created by the CodandoTV community: the World Cup Best Team Simulator. The app allows users to browse football players by country and build their own dream team. It runs on both Android and iOS, using Kotlin Multiplatform for sharing business and data logic, and Compose Multiplatform to share the UI across platforms. Step 1: Add Koin Dependencies Add the Koin libraries to your version catalog: # gradle/libs.versions.toml [versions] koin = "4.2.2" [libraries] koin_core = { group = "io.insert-koin", name = "koin-core", version.ref = "koin" } koin_android = { group = "io.insert-koin", name = "koin-android", version.ref = "koin" } koin_compose = { module = "io.insert-koin:koin-compose", version.ref = "koin" } koin_compose_viewmodel = { module = "io.insert-koin:koin-compose-viewmodel", version.ref = "koin" } In the shared module shared/build.gradle.kts, split the dependencies by source set -- commonMain gets the shared Koin libraries, androidMain gets the Android-specific one: // shared/build.gradle.kts sourceSets { commonMain.dependencies { implementation(libs.koin.core) implementation(libs.koin.compose) implementation(libs.koin.compose.viewmodel) } androidMain.dependencies { implementation(libs.koin.android) } } In the Android app module androidApp/build.gradle.kts , add the Android Koin dependency: // androidApp/build.gradle.kts dependencies { implementation(libs.koin.android) implementation(libs.koin.core) }Step 2: Create the Data Module Create shared/src/commonMain/.../data/DataModule.kt . This module provides singleton instances -- repositories, and data sources that live for the entire app lifecycle. val dataModule = module { single<WorldCupRepository> { WorldCupRepositoryImpl(ioDispatcher = Dispatchers.IO) } }Step 3: Create

## Let Koin Shape your Application Architecture

DevFeed: [Let Koin Shape your Application Architecture](<https://devfeed.tech/articles/let-koin-shape-your-application-architecture-22974.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/let-koin-shape-your-application-architecture-9cd60b1e02b0?source=rss----925561f2ecdf---4>)

Author: Gabriel Bronzatti Moro

Published: 2026-07-06T12:01:01Z

Content type: tutorial

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [coding](<https://devfeed.tech/topics/coding.md>), [Software](<https://devfeed.tech/topics/software.md>), [Ktor](<https://devfeed.tech/topics/ktor.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [clean-architecture](<https://devfeed.tech/tags/clean-architecture.md>), [developer](<https://devfeed.tech/tags/developer.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [ktor](<https://devfeed.tech/tags/ktor.md>), [software](<https://devfeed.tech/tags/software.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-design](<https://devfeed.tech/tags/software-design.md>)

### AI overview

This tutorial explains how Koin can support application architecture based on Clean Architecture and software design practices. It describes using Koin to create and manage object instances, including singleton and factory definitions, with Ktor's HttpClient as an example.

### Source excerpt

Hey, friends! 👋 Today we're going to explore application architecture and how Koin can help us build scalable, maintainable applications by applying the principles of Clean Architecture and other software design best practices. Application architecture is a fundamental skill for every software engineer. A well-designed architecture makes applications easier to understand, test, extend, and maintain as they grow over time. A collection of LEGO towers in various stages of construction -- Unsplash by richard_heFoundation When we think about software architecture, we often picture layered diagrams -- data, domain, and presentation -- along with classes such as use cases, handlers, repositories, and helpers. But how do all these components work together? How do we establish a reliable communication protocol between them? Architecture is more than just organizing classes into packages. It's about defining how objects communicate and collaborate working toward a common goal. With that in mind, let's begin our journey with a simple principle: Every object instance should be created by Koin. My only responsibility as a developer is to describe how each object should be instantiated, while Koin takes care of the creation process.SingletonSingleton Café generated by ChatGPT Koin makes it easy to define singletons, whether you're using the @Single annotation or the single { ... } DSL. By declaring a singleton, you're telling Koin to create and manage a single instance of that object for the lifetime of the application. In the example below, we define an HttpClient as a singleton: @Module class NetworkModule { @Single fun provideHttpClient(): HttpClient { return HttpClientBuilder.build( baseUrl = BuildKonfig.HOST, ) } ... } HttpClient is a class provided by Ktor, and it should typically be instantiated only once. By declaring it as a singleton, Koin ensures that the same HttpClient instance is shared throughout the application. The Singleton pattern is commonly used for objects tha

## Custom Scopes in Koin: A Practical Example

DevFeed: [Custom Scopes in Koin: A Practical Example](<https://devfeed.tech/articles/custom-scopes-in-koin-a-practical-example-22968.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/custom-scopes-in-koin-a-practical-example-79cc1188810f?source=rss----925561f2ecdf---4>)

Author: Gabriel Bronzatti Moro

Published: 2026-06-19T12:01:01Z

Content type: tutorial

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [App](<https://devfeed.tech/topics/app.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>)

Tags: [app](<https://devfeed.tech/tags/app.md>), [components](<https://devfeed.tech/tags/components.md>), [compose-multiplatform](<https://devfeed.tech/tags/compose-multiplatform.md>), [data](<https://devfeed.tech/tags/data.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [lifecycle](<https://devfeed.tech/tags/lifecycle.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [project](<https://devfeed.tech/tags/project.md>), [scopes](<https://devfeed.tech/tags/scopes.md>), [state](<https://devfeed.tech/tags/state.md>), [stateless](<https://devfeed.tech/tags/stateless.md>), [user-experience](<https://devfeed.tech/tags/user-experience.md>)

### AI overview

A practical tutorial on using custom scopes in Koin to keep a selected user profile image available across an application. It demonstrates a session scope, session data, and a stateless session manager using StreamPlayerApp as the example.

### Source excerpt

Hey friends 👋 Today, we are going to explore how we can create a custom scope, one of the powerful features provided by Koin. To make things practical 🔨, we'll walk through a real-world use case from the open-source project StreamPlayerApp (created by CodandoTV). Wireframes of a mobile app -- Unsplash by @alvarordesignWhat is the problem? StreamPlayerApp is an open-source project that aims to recreate the core experience of Netflix. One of its features allows users to select a profile, similar to the profile selection screen found in streaming platforms. The selected profile image needs to be accessible across the entire application, ensuring a consistent user experience on every screen. Whenever a user changes their profile, the updated image should be immediately reflected throughout the app, allowing all screens to stay synchronized with the current profile selection. Screenshots demonstrating the user profile selection feature.How we solve this problem using Custom Scopes? First, we create a class that represents the scope of a user session: class SessionScope Next, we create a lightweight data class containing only the information that needs to be kept in memory throughout the user session: data class UserSessionInfo( // represents the time user changed the profile val userTimestamp: Instant, // represents the selected picture url val profileImageUrl: String ) We then created a dedicated class responsible for managing the user's session lifecycle and state. class SessionManager { private val scopeId: String = "user_session" /** * Create custom scope and hold the user's session data */ fun openSession(imageUrl: String) { closeSession() val koin = KoinPlatform.getKoin() val scope = koin.createScope<SessionScope>( scopeId = scopeId, ) scope.declare( UserSessionInfo( userTimestamp = Clock.System.now(), profileImageUrl = imageUrl ) ) } /** * Retrieve the current user session */ fun userSessionInfo(): UserSessionInfo? { return KoinPlatform.getKoin() .getScopeOrNull(sc

## Koin Annotations Make expect/actual Obsolete in KMP

DevFeed: [Koin Annotations Make expect/actual Obsolete in KMP](<https://devfeed.tech/articles/koin-annotations-make-expect-actual-obsolete-in-kmp-22971.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/koin-annotations-make-expect-actual-obsolete-in-kmp-5f1445e2055e?source=rss----925561f2ecdf---4>)

Author: Tezov

Published: 2026-06-11T08:48:59Z

Content type: tutorial

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [compose-multiplatform](<https://devfeed.tech/topics/compose-multiplatform.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [cross-platform](<https://devfeed.tech/topics/cross-platform.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [compose-multiplatform](<https://devfeed.tech/tags/compose-multiplatform.md>), [cross-platform](<https://devfeed.tech/tags/cross-platform.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [development](<https://devfeed.tech/tags/development.md>), [interface](<https://devfeed.tech/tags/interface.md>), [kmp](<https://devfeed.tech/tags/kmp.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlinmultiplatformmobile](<https://devfeed.tech/tags/kotlinmultiplatformmobile.md>)

### AI overview

A tutorial showing how Koin annotations and the Koin compiler can replace expect/actual declarations in Kotlin Multiplatform projects. It defines shared interfaces in commonMain, provides Android and iOS implementations through dependency injection, and uses Compose Multiplatform to resolve the platform-specific behavior.

### Source excerpt

Source code available at the end of the article In Kotlin Multiplatform (KMP) projects, expect/actual is traditionally used to handle platform-specific implementations. In a previous story, I showed how to reduce expect/actual to only one per module using Koin DSL. Today, we can go further. With Koin annotations and the Koin compiler, you can completely bypass expect/actual. This method works seamlessly with Compose Multiplatform and lets you maintain a clean architecture while keeping platform-specific logic where it belongs. Previous Story Mastering Koin Annotations with the Koin Compiler Through Unit Tests -> link Next Story I don't know yet-> coming soon Setting the Stage Inside commonMain, Koin is initialized like this: @Module @ComponentScan( "com.tezov.store.shared.di", "com.tezov.store.shared.data", "com.tezov.store.shared.domain", "com.tezov.store.shared.presentation" ) class SharedModule @KoinApplication(modules = [SharedModule::class]) class SharedApplication val koinConfiguration = koinConfiguration<SharedApplication> { /* nothing here for the demo */ } I'm using: koinCompiler = "0.6.2" koinCompose = "4.2.1-RC1" koinComposeAnnotation = "4.2.1-RC1" The important part here is the @ComponentScan. Koin doesn't just scan commonMain. It also scans the platform modules: androidMain and iosMain. That detail is key because it lets Koin find all implementations without any manual wiring. Defining Contracts in commonMain Instead of expect, we define interfaces for domain and presentation layers. Domainpackage com.tezov.store.shared.domain interface PlatformDomainProtocol { fun description(): String }Presentationpackage com.tezov.store.shared.presentation import androidx.compose.runtime.Composable interface PlatformPresentationProtocol { @Composable fun ComposableFromPlatform() } Yes, you can even include a @Composable in an interface. This is powerful: your shared code can remain clean while delegating platform-specific behavior entirely to the DI container. When usi

## How to use Koin Compiler in a Multimodule Project?

DevFeed: [How to use Koin Compiler in a Multimodule Project?](<https://devfeed.tech/articles/how-to-use-koin-compiler-in-a-multimodule-project-22969.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/how-to-use-koin-compiler-in-a-multimodule-project-6bd8e57d5e4b?source=rss----925561f2ecdf---4>)

Author: Gabriel Bronzatti Moro

Published: 2026-06-11T08:47:55Z

Content type: tutorial

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [koin](<https://devfeed.tech/topics/koin.md>), [compose-multiplatform](<https://devfeed.tech/topics/compose-multiplatform.md>), [multiplatform](<https://devfeed.tech/topics/multiplatform.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [implementation](<https://devfeed.tech/topics/implementation.md>)

Tags: [build](<https://devfeed.tech/tags/build.md>), [compose](<https://devfeed.tech/tags/compose.md>), [compose-multiplatform](<https://devfeed.tech/tags/compose-multiplatform.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [migrate](<https://devfeed.tech/tags/migrate.md>), [multi-module-project](<https://devfeed.tech/tags/multi-module-project.md>), [plugin](<https://devfeed.tech/tags/plugin.md>)

### 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

## Koin Compiler 1.0: DSL and Annotations, Koin now Compile-Safe

DevFeed: [Koin Compiler 1.0: DSL and Annotations, Koin now Compile-Safe](<https://devfeed.tech/articles/koin-compiler-1-0-dsl-and-annotations-koin-now-compile-safe-22972.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/koin-compiler-1-0-dsl-and-annotations-koin-now-compile-safe-06905a2b04ad?source=rss----925561f2ecdf---4>)

Author: Arnaud Giuliani

Published: 2026-06-03T12:01:01Z

Content type: release

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [Compiler](<https://devfeed.tech/topics/compiler.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [build](<https://devfeed.tech/tags/build.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-compiler](<https://devfeed.tech/tags/kotlin-compiler.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [plugin](<https://devfeed.tech/tags/plugin.md>)

### AI overview

Koin Compiler 1.0 introduces a native Kotlin compiler plugin that verifies Koin dependency graphs at build time. The release supports both DSL and annotation-based wiring, requires no KSP or generated files, and supports Kotlin Multiplatform.

### Source excerpt

Koin Compiler 1.0: DSL and Annotations, Now Compile-Safe Hello, dear Koin Community 👋 Koin Compiler 1.0 is out. Koin's DSL and annotations now sit on a native Kotlin compiler plugin that verifies your dependency graph at build time: the missing-definition error that used to wait for a get<T>() call no longer makes it past gradlew build: e: [Koin] Missing dependency: UserRepository (required by UserService) No KSP, no generated files, full Kotlin Multiplatform support out of the box. It's the biggest ergonomic shift we've made in Koin's nine-year history. Koin Logo with KotlinConf '26 LogoSetup 👀 If you use a Gradle version catalog (the modern default): [versions] koin = "4.2.1" koin-plugin = "1.0.0" [libraries] koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" } koin-annotations = { module = "io.insert-koin:koin-annotations", version.ref = "koin" } [plugins] koin-compiler = { id = "io.insert-koin.compiler.plugin", version.ref = "koin-plugin" } Or the equivalent inline in build.gradle.kts: plugins { id("io.insert-koin.compiler.plugin") version "1.0.0" } dependencies { implementation("io.insert-koin:koin-core:4.2.1") implementation("io.insert-koin:koin-annotations:4.2.1") } koin-annotations is only needed if you use the annotations on your classes for the constructor, or use the annotations flow. On the DSL flow, the plugin works against koin-core alone. The DSL flow -- Safer DSL ✨ Take two classes: class MyDatabase() class MyRepository(val db: MyDatabase) Wiring them up with Koin has progressively required less typing: // 1. Manual -- the wiring is explicit module { single { MyDatabase() } single { MyRepository(get()) } } // 2. Reflection-free constructor binding module { singleOf(::MyDatabase) singleOf(::MyRepository) } // 3. Compiler-intercepted - same DSL, new mechanism module { single<MyDatabase>() single<MyRepository>() } The third form looks like nothing is happening. That's the point: the compiler plugin sees single<MyDatabase>(), walks the

## Migrating from Koin DSL to Koin Annotations in a Multimodule Project: A Step-by-Step Guide

DevFeed: [Migrating from Koin DSL to Koin Annotations in a Multimodule Project: A Step-by-Step Guide](<https://devfeed.tech/articles/migrating-from-koin-dsl-to-koin-annotations-in-a-multimodule-project-a-step-by-step-guide-22975.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/migrating-from-koin-dsl-to-koin-annotations-in-a-multimodule-project-a-step-by-step-guide-a38a82f56e17?source=rss----925561f2ecdf---4>)

Author: Gabriel Bronzatti Moro

Published: 2026-04-24T07:18:23Z

Content type: tutorial

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [multiplatform](<https://devfeed.tech/topics/multiplatform.md>), [compose-multiplatform](<https://devfeed.tech/topics/compose-multiplatform.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>)

Tags: [code-generation](<https://devfeed.tech/tags/code-generation.md>), [compose](<https://devfeed.tech/tags/compose.md>), [compose-multiplatform](<https://devfeed.tech/tags/compose-multiplatform.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [guide](<https://devfeed.tech/tags/guide.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [ksp](<https://devfeed.tech/tags/ksp.md>), [multi-module-project](<https://devfeed.tech/tags/multi-module-project.md>), [tutorial](<https://devfeed.tech/tags/tutorial.md>)

### AI overview

A step-by-step tutorial for migrating a Compose Multiplatform multimodule project from Koin DSL to Koin Annotations. It covers adding Koin Annotations and KSP dependencies, creating a Gradle convention plugin, enabling the setup in a module, and replacing manual Koin definitions with annotation-based registration.

### Source excerpt

Hey friends 👋 Today we're going to explore how to migrate a Compose Multiplatform multi-module project from Koin DSL to Koin Annotations. We'll take a hands-on approach, diving deep into a project example built by the CodandoTV community. ⚠ In this tutorial, we won't cover the new Koin compiler. It's a significant improvement that simplifies much of the complexity we currently deal with when using KSP, but it deserves its own dedicated deep dive. A person's hand fitting a piece into a puzzle -- Unplash by rosssneddonFirst step: Setup Koin Annotations dependency First thing is let's make sure we are running the latest version of Koin. For that, visit our documentation. After that, let's add our Koin Annotations dependency into the libs.versions.toml . // gradle/libs.versions.toml [versions] koin-annotations = "<latest-version>" ksp = "<latest-version>" ... [libraries] ... com-google-devtools-ksp-gradle-plugin = { module = "com.google.devtools.ksp:com.google.devtools.ksp.gradle.plugin", version.ref = "ksp" } koin-annotations = { module = "io.insert-koin:koin-annotations", version.ref = "koin-annotations" } koin-ksp-compiler = { module = "io.insert-koin:koin-ksp-compiler", version.ref = "koin-annotations" } KSP is also required, as it enables the code generation used by Koin Annotations. After adding the dependencies, run a Gradle sync to make them available to the project. Let's make sure we have the ksp plugin enabled in the root gradle project: // root/build.gradle.kts plugins { alias(libs.plugins.ksp) apply false ... } Let's head over to the build-logic folder and encapsulate all this setup inside a new Gradle convention plugin. To make this work, we need to add KSP as a library dependency: // build-logic/build.gradle.kts ... dependencies { implementation(libs.com.google.devtools.ksp.gradle.plugin) } Again, let's run Gradle sync 🐘 Second step: Create your conventional Gradle Plugin Inside of your build-logic , let's create a new custom plugin, we can call it com.st

## Introducing the Koin Migration Skills

DevFeed: [Introducing the Koin Migration Skills](<https://devfeed.tech/articles/introducing-the-koin-migration-skills-22970.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/introducing-the-koin-migration-skills-0b4be9c819cc?source=rss----925561f2ecdf---4>)

Author: Arnaud Giuliani

Published: 2026-04-22T13:23:59Z

Content type: article

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [migration](<https://devfeed.tech/topics/migration.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Claude Code](<https://devfeed.tech/topics/claude-code.md>), [Android](<https://devfeed.tech/topics/android.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [claude-code](<https://devfeed.tech/tags/claude-code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dagger-hilt](<https://devfeed.tech/tags/dagger-hilt.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [migration](<https://devfeed.tech/tags/migration.md>), [module](<https://devfeed.tech/tags/module.md>), [verification](<https://devfeed.tech/tags/verification.md>)

### AI overview

The article introduces the Koin Migration Skill, a Claude Code plugin for migrating Kotlin and Android projects from Hilt, Dagger, Toothpick, Kodein, or older Koin versions to Koin 4.x and the Koin Compiler Plugin. It describes module-by-module inventory, ranked migration planning, compile-time verification, and human checkpoints.

### Source excerpt

Hello all 👋 Migrating a Kotlin or Android project between DI frameworks (Hilt, Dagger, Toothpick, Kodein, or older Koin versions) is one of those strategic refactors that every team puts off. It touches every module, the call sites are everywhere, and the migration plan never quite survives contact with the real codebase. We wanted to take the pain out of it. So we built the Koin Migration Skill: a Claude Code plugin that automates DI migrations to Koin 4.x and the Koin Compiler Plugin, module by module, with compile-time verification and a human-in-the-loop at every step. Koin Migration Project -- 1.0.0What it covers Initially, this project is intended to help Koin developers to migrate to use the new Koin Compiler Plugin. The skill supports every realistic migration path into modern Koin, with Koin Compiler if possible. This uses either annotations or the safe DSL: Hilt -> Koin (with koin-android-dagger bridging during migration) Dagger -> Koin Toothpick -> Koin Kodein -> Koin Koin 3.x -> Koin 4.x upgrade Classic Koin DSL -> Safe DSL Koin KSP Annotations -> Koin Compiler Plugin All paths converge on the same target: Koin 4.x with Annotations or Safe DSL, powered by the Koin Compiler Plugin for compile-time DI graph verification. How it works Project documentation is available: https://github.com/InsertKoinIO/koin-migration. Point Claude at your project and describe what you want to migrate. /plugin marketplace add InsertKoinIO/koin-migration /plugin install koin-migration@koin-migrationAdding Skill in current project The skill opens with a full inventory of your DI setup: every module, binding, qualifier, and scope. It immediately produces a ranked migration table. The NowInAndroid project below has 35 DI files across core, feature, app, and sync layers. The skill maps each one: bindings count, downstream dependants, complexity rating, and a recommended order. Modules inventory, DI features usage and mapping You can't go "big-bang" in that kind of approach. You need to st

## Unlocking Koin Compile Safety -- Koin Compiler Plugin 1.0.0-RC1

DevFeed: [Unlocking Koin Compile Safety -- Koin Compiler Plugin 1.0.0-RC1](<https://devfeed.tech/articles/unlocking-koin-compile-safety-koin-compiler-plugin-1-0-0-rc1-22977.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/unlocking-koin-compile-safety-6278840ab171?source=rss----925561f2ecdf---4>)

Author: Arnaud Giuliani

Published: 2026-04-14T08:08:36Z

Content type: release

Language: en

Sources: [Koin developers - Medium](<https://devfeed.tech/sources/koin-developers-medium.md>)

Topics: [koin](<https://devfeed.tech/topics/koin.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Code generation](<https://devfeed.tech/topics/code-generation.md>)

Tags: [compilation](<https://devfeed.tech/tags/compilation.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [generation](<https://devfeed.tech/tags/generation.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [plugin](<https://devfeed.tech/tags/plugin.md>), [release](<https://devfeed.tech/tags/release.md>), [safety](<https://devfeed.tech/tags/safety.md>)

### 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](<https://devfeed.tech/articles/51-detekt-rules-for-koin-catch-anti-patterns-your-compiler-misses-25957.md>)

Original publisher: [Read original article](<https://blog.insert-koin.io/detekt-rules-koin-c0b6330fc37b?source=rss-7a0a233f88a2------2>)

Author: Kirill Rozov

Published: 2026-03-02T08:17:18Z

Content type: tutorial

Language: en

Sources: [Stories by Kirill Rozov on Medium](<https://devfeed.tech/sources/stories-by-kirill-rozov-on-medium.md>)

Topics: [koin](<https://devfeed.tech/topics/koin.md>), [Android](<https://devfeed.tech/topics/android.md>), [ci](<https://devfeed.tech/topics/ci.md>)

Tags: [analysis](<https://devfeed.tech/tags/analysis.md>), [android](<https://devfeed.tech/tags/android.md>), [best-practices](<https://devfeed.tech/tags/best-practices.md>), [ci](<https://devfeed.tech/tags/ci.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [detekt](<https://devfeed.tech/tags/detekt.md>), [errors](<https://devfeed.tech/tags/errors.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [tests](<https://devfeed.tech/tags/tests.md>)

### 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](<https://devfeed.tech/articles/re-dependency-injection-vs-service-locators-39043.md>)

Original publisher: [Read original article](<https://www.zacsweers.dev/re-dependency-injection-vs-service-locators/>)

Author: Zac Sweers

Published: 2026-02-20T05:10:16Z

Content type: opinion

Language: en

Sources: [Zac Sweers](<https://devfeed.tech/sources/zac-sweers.md>)

Topics: [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>), [koin](<https://devfeed.tech/topics/koin.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [service](<https://devfeed.tech/topics/service.md>), [multiplatform](<https://devfeed.tech/topics/multiplatform.md>)

Tags: [dagger](<https://devfeed.tech/tags/dagger.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [metro](<https://devfeed.tech/tags/metro.md>), [service](<https://devfeed.tech/tags/service.md>)

### 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. <what comes next>. Serious question: Are there any compelling reasons to switch from Koin to Metro in a

## Kotlin Reflection: Method and property references

DevFeed: [Kotlin Reflection: Method and property references](<https://devfeed.tech/articles/kotlin-reflection-method-and-property-references-39214.md>)

Original publisher: [Read original article](<https://kt.academy/article/ak-reflection>)

Published: 2023-10-16T00:15:00Z

Content type: tutorial

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [classes](<https://devfeed.tech/topics/classes.md>), [function](<https://devfeed.tech/topics/function.md>), [properties](<https://devfeed.tech/topics/properties.md>)

Tags: [classes](<https://devfeed.tech/tags/classes.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [functions](<https://devfeed.tech/tags/functions.md>), [gson](<https://devfeed.tech/tags/gson.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [java](<https://devfeed.tech/tags/java.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [property](<https://devfeed.tech/tags/property.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

This tutorial introduces Kotlin reflection, explaining how programs inspect classes, functions, properties, annotations, constructors, and other source-code elements at runtime. It also describes uses in Gson serialization, Koin dependency injection, and the hierarchy of Kotlin reflection reference types.

### Source excerpt

The general hierarchy of Kotlin reference classes, and details about method and property references.

## Building a Note-Taking App in Compose

DevFeed: [Building a Note-Taking App in Compose](<https://devfeed.tech/articles/building-a-note-taking-app-in-compose-20024.md>)

Original publisher: [Read original article](<https://technology.doximity.com/articles/building-a-note-taking-app-in-compose>)

Author: Doximity

Published: 2023-07-05T19:47:00Z

Content type: tutorial

Language: en

Sources: [Doximity](<https://devfeed.tech/sources/doximity.md>)

Topics: [Jetpack Compose](<https://devfeed.tech/topics/jetpack-compose.md>), [App](<https://devfeed.tech/topics/app.md>), [Code](<https://devfeed.tech/topics/code.md>), [Template](<https://devfeed.tech/topics/template.md>)

Tags: [app](<https://devfeed.tech/tags/app.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [build](<https://devfeed.tech/tags/build.md>), [building](<https://devfeed.tech/tags/building.md>), [class](<https://devfeed.tech/tags/class.md>), [clean-architecture](<https://devfeed.tech/tags/clean-architecture.md>), [code](<https://devfeed.tech/tags/code.md>), [collect](<https://devfeed.tech/tags/collect.md>), [compose](<https://devfeed.tech/tags/compose.md>), [data-class](<https://devfeed.tech/tags/data-class.md>), [di](<https://devfeed.tech/tags/di.md>), [extension-function](<https://devfeed.tech/tags/extension-function.md>), [flow](<https://devfeed.tech/tags/flow.md>), [icons](<https://devfeed.tech/tags/icons.md>), [implement](<https://devfeed.tech/tags/implement.md>), [koin](<https://devfeed.tech/tags/koin.md>), [list](<https://devfeed.tech/tags/list.md>), [state](<https://devfeed.tech/tags/state.md>), [state-management](<https://devfeed.tech/tags/state-management.md>), [view](<https://devfeed.tech/tags/view.md>)

### AI overview

A case study showing how to build a note-taking app with Jetpack Compose. It models note state, renders the notes UI, collects note data through a presenter and Clean Architecture use cases, and plans events for adding, editing, checking, and deleting notes.

### Source excerpt

In this case study, we will build a note-taking app that lets the user add, edit and delete notes. It uses Compose for both the view and presentation layers! Note: This is a follow up to Part 1: Simplifying State Management with Compose and assumes the reader is already familiar with Jetpack Compose. The Template I find it useful to start with the model that represents the state of the screen we're building. It will have a list of notes, with each note containing properties for the text and checkbox: data class NotesUiModel(val notes: List<Note>) : UiModel { data class Note(val text: String, val isChecked: Boolean) : UiModel } It'll be the job of the presenter to produce this model. Initially, let's implement a stub to return an empty list of notes (we'll ignore parameters for now): class NotesListPresenter : Presenter<NotesUiModel, Unit> { @Composable override fun present(params: Unit): NotesUiModel { return NotesUiModel(notes = emptyList()) } } Then we can build our view to render the model that's returned by the presenter: @Composable fun NotesScreen() { val presenter: NotesListPresenter = koinInject() // we use koin for DI val uiModel = presenter.present(Unit) Column { TopAppBar(title = { Text("Notes") }) Notes(uiModel) } } } The View The views themselves are pretty self-explanatory if you're already familiar with building UIs in Compose. For the notes, we'll take in a NotesUiModel argument and create a LazyColumn with the notes property. A FAB button is used for adding new notes, although we'll skip the triggering of events and return to this part in a little bit: @Composable private fun Notes(uiModel: NotesUiModel) { Box { LazyColumn { items(uiModel.notes) { note -> Note(note) } } FloatingActionButton(onClick = { /* TODO */ }) { Icon(imageVector = Icons.Rounded.Add) } } } Then we can render each note with a checkbox, text field and delete button: @Composable private fun Note(uiModel: Note) { Row { Checkbox( checked = uiModel.isChecked, onCheckedChange = { /* T

## Dagger/Hilt vs. Koin for Jetpack Compose Apps

DevFeed: [Dagger/Hilt vs. Koin for Jetpack Compose Apps](<https://devfeed.tech/articles/dagger-hilt-vs-koin-for-jetpack-compose-apps-25520.md>)

Original publisher: [Read original article](<https://patrykkosieradzki.com/dagger-hilt-vs-koin-dependency-injection-for-jetpack-compose-apps>)

Published: 2022-03-13T00:00:00Z

Content type: comparison

Language: en

Sources: [Patryk Kosieradzki](<https://devfeed.tech/sources/patryk-kosieradzki.md>)

Topics: [Dagger](<https://devfeed.tech/topics/dagger.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [Jetpack Compose](<https://devfeed.tech/topics/jetpack-compose.md>), [Android](<https://devfeed.tech/topics/android.md>), [interoperability](<https://devfeed.tech/topics/interoperability.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [comparison](<https://devfeed.tech/tags/comparison.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dagger-hilt](<https://devfeed.tech/tags/dagger-hilt.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [interoperability](<https://devfeed.tech/tags/interoperability.md>), [jetpack-compose](<https://devfeed.tech/tags/jetpack-compose.md>), [koin](<https://devfeed.tech/tags/koin.md>)

### AI overview

A comparison of Dagger/Hilt and Koin for dependency injection in Jetpack Compose Android applications. It discusses code generation, build and runtime considerations, Google's recommendation of Hilt, and two Compose integration approaches: pure Compose with navigation-compose or Fragments with ComposeView.

### Source excerpt

A detailed comparison of using Hilt versus Koin for dependency injection in Jetpack Compose applications.

## Comparing Three Dependency Injection Solutions

DevFeed: [Comparing Three Dependency Injection Solutions](<https://devfeed.tech/articles/comparing-three-dependency-injection-solutions-22797.md>)

Original publisher: [Read original article](<http://androidessence.com/comparing-three-dependency-injection-solutions/>)

Author: Adam McNeilly

Published: 2020-08-22T00:00:00Z

Content type: comparison

Language: en

Sources: [Android Essence](<https://devfeed.tech/sources/android-essence.md>)

Topics: [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [Android](<https://devfeed.tech/topics/android.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>), [App](<https://devfeed.tech/topics/app.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dagger-hilt](<https://devfeed.tech/tags/dagger-hilt.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [koin](<https://devfeed.tech/tags/koin.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>), [viewmodel](<https://devfeed.tech/tags/viewmodel.md>)

### AI overview

This comparison examines three approaches to dependency injection on Android: a do-it-yourself approach, Koin, and Dagger Hilt. It explains constructor and field injection, separation of concerns, and testability, then introduces the additional concerns addressed by dependency injection libraries.

### Source excerpt

During a recent live stream on my Twitch channel, we explored three different solutions to dependency injection on Android. A do it yourself approach, Koin, and Dagger Hilt. Let's revisit them side by side, and look at the nuances between them, so we can determine which solution we want to use in our own applications.

## Dagger, Hilt, Koin - a comparison

DevFeed: [Dagger, Hilt, Koin - a comparison](<https://devfeed.tech/articles/dagger-hilt-koin-a-comparison-32046.md>)

Original publisher: [Read original article](<https://www.maiatoday.net/p/dagger-hilt-koin-a-comparison/>)

Published: 2020-08-05T13:02:01Z

Content type: comparison

Language: en

Sources: [maiatoday](<https://devfeed.tech/sources/maiatoday.md>)

Topics: [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>)

Tags: [comparison](<https://devfeed.tech/tags/comparison.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dagger-hilt](<https://devfeed.tech/tags/dagger-hilt.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [di](<https://devfeed.tech/tags/di.md>), [gdg](<https://devfeed.tech/tags/gdg.md>), [hilt](<https://devfeed.tech/tags/hilt.md>), [koin](<https://devfeed.tech/tags/koin.md>), [talk](<https://devfeed.tech/tags/talk.md>)

### AI overview

A talk presented for GDG Johannesburg compares the dependency injection technologies Dagger, Hilt, and Koin.

### Source excerpt

Talk presented for GDG Johannesburg comparing dependency injection technologies. slides

## Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem

DevFeed: [Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem](<https://devfeed.tech/articles/the-forgotten-art-of-construction-25893.md>)

Original publisher: [Read original article](<https://proandroiddev.com/the-forgotten-art-of-construction-cfedc368e67f?source=rss-1331e67af4e1------2>)

Author: Danny Preussler

Published: 2020-06-22T17:39:16Z

Content type: opinion

Language: en

Sources: [Stories by Danny Preussler on Medium](<https://devfeed.tech/sources/stories-by-danny-preussler-on-medium.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [clean-code](<https://devfeed.tech/topics/clean-code.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>), [koin](<https://devfeed.tech/topics/koin.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [clean-code](<https://devfeed.tech/tags/clean-code.md>), [code](<https://devfeed.tech/tags/code.md>), [code-smells](<https://devfeed.tech/tags/code-smells.md>), [constructor](<https://devfeed.tech/tags/constructor.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>)

### 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(),

## Kotlin Multiplatform Library - Touchlab

DevFeed: [Kotlin Multiplatform Library - Touchlab](<https://devfeed.tech/articles/kotlin-multiplatform-library-touchlab-38269.md>)

Original publisher: [Read original article](<https://touchlab.co/kotlin-multiplatform-library>)

Published: 2019-11-19T22:31:00Z

Content type: tutorial

Language: en

Sources: [Touchlab | Enterprise Mobile Innovation & Development](<https://devfeed.tech/sources/touchlab-enterprise-mobile-innovation-development.md>)

Topics: [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [kotlin-multiplatform-libraries](<https://devfeed.tech/topics/kotlin-multiplatform-libraries.md>), [Library](<https://devfeed.tech/topics/library.md>), [cross-platform](<https://devfeed.tech/topics/cross-platform.md>)

Tags: [code-sharing](<https://devfeed.tech/tags/code-sharing.md>), [coroutines](<https://devfeed.tech/tags/coroutines.md>), [cross-platform](<https://devfeed.tech/tags/cross-platform.md>), [kmp](<https://devfeed.tech/tags/kmp.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [kotlin-multiplatform-libraries](<https://devfeed.tech/tags/kotlin-multiplatform-libraries.md>), [ktor](<https://devfeed.tech/tags/ktor.md>), [library](<https://devfeed.tech/tags/library.md>), [sqldelight](<https://devfeed.tech/tags/sqldelight.md>), [sqlite](<https://devfeed.tech/tags/sqlite.md>), [thoughts](<https://devfeed.tech/tags/thoughts.md>)

### AI overview

Touchlab provides an overview of Kotlin Multiplatform libraries, listing libraries used by Touchlab, JetBrains, and the community, along with sample apps and a presentation on Kotlin Multiplatform library development.

### Source excerpt

Introduction to Kotlin Multiplatform explains how KMP is pragmatic programming to develop apps on multiple platforms & avoid writing code twice.

## Koin and Dagger for dependency injection on Android

DevFeed: [Koin and Dagger for dependency injection on Android](<https://devfeed.tech/articles/koin-for-dependency-injection-on-android-is-dagger-dead-27174.md>)

Original publisher: [Read original article](<https://antonioleiva.com/koin-vs-dagger>)

Published: 2019-06-13T00:00:00Z

Content type: tutorial

Language: en

Sources: [Antonio Leiva](<https://devfeed.tech/sources/antonio-leiva.md>)

Topics: [koin](<https://devfeed.tech/topics/koin.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>), [Android](<https://devfeed.tech/topics/android.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>)

### 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