When a Kotlin codebase grows past a handful of screens, dependency injection stops being optional and starts being structural. In a recent Fragmented podcast episode, host Don sits down with Fred Porciúncula—a Google Developer Expert who contributes to Kotlin Inject—to discuss what DI actually solves, why the choices look different once Kotlin Multiplatform enters the picture, and where Kotlin Inject fits among Dagger, Hilt, Anvil, and Koin. They also dig into whether you need a DI library at all.
Why this conversation matters now
The DI landscape has been relatively stable for Android developers: Hilt for most teams, Dagger if you needed the heavy machinery, Koin if you wanted something lightweight. Kotlin Multiplatform changes the equation. Once you start sharing code between Android and iOS, the question shifts from "which DI tool for Android?" to "which DI tool for each target?" Fred flags that Dagger still lacks proper KMP support, which creates a genuine gap that Kotlin Inject was designed to fill.
The episode also challenges the assumption that DI is always worth it. Fred frames it as a tool whose payoff scales with project complexity, not a universal rule. That framing matters for teams deciding whether to adopt Kotlin Inject incrementally versus committing to it application-wide.
How Kotlin Inject positions itself
Kotlin Inject leans on constructor injection, scope handling, and compile-time graph construction—features that sidestep the runtime reflection cost some developers associate with reflective DI libraries. Fred argues these capabilities are sufficient to run Kotlin Inject across an entire application, not just the shared KMP module.
The service detection debate gets airtime too. Rather than injecting dependencies, you could locate them through a lookup mechanism. Fred's take, as paraphrased in the recap, is that explicit injection still wins for testability, but understanding the alternative helps teams make a deliberate choice rather than defaulting to convention.
Who should care
| Scenario | Recommendation |
|---|---|
| Solo Android dev, small app | Stick with Hilt or Koin—maturity and community support still matter |
| Team with shared KMP module targeting Android + iOS | Kotlin Inject deserves a serious look; prototype it before committing |
| Team already on Dagger/Hilt with no KMP plans | No urgent reason to switch; watch Dagger's KMP progress instead |
| Anyone considering "vanilla injection" (no library) | Valid for small projects or perf-critical paths; document the trade-off |
The honest summary: Kotlin Inject is most compelling when your codebase already spans platforms or when Dagger's generator-heavy setup feels like overkill. For plain Android work, the established tools remain lower-friction.
What to watch next
Dagger's KMP progress is the biggest variable. The moment Dagger crosses into KMP cleanly, the calculus shifts for teams that wanted compile-time safety without switching libraries. Also worth tracking: Kotlin Inject's feature requests for Anvil-style component aggregation, which would narrow the gap with Dagger's flexibility.
Key takeaways
- Kotlin Inject's strongest case is shared Kotlin Multiplatform code; for Android-only projects, Hilt or Koin often remain the pragmatic choice.
- The real competition is between Kotlin Inject and Dagger for compile-time safety, with Koin as the lightweight alternative.
- The "vanilla injection" option—wiring dependencies by hand with no library—is a legitimate strategy for small projects or perf-sensitive paths.
- Treat any DI migration as a sprint spike with clear success metrics before committing the team.
Frequently asked questions
What is Kotlin Inject in one sentence?
A Kotlin-first dependency injection library offering constructor injection, scopes, and compile-time dependency graphs, designed to work cleanly in Kotlin Multiplatform projects where Dagger currently falls short.
How does Kotlin Inject differ from Dagger or Hilt?
Dagger and Hilt are the most established Android DI tools with deep IDE integration, but they lack first-class Kotlin Multiplatform support. Kotlin Inject was built with KMP in mind and targets compile-time safety with a lighter setup.
Does the episode argue you should abandon other DI libraries?
No. The conversation compares options and highlights where Kotlin Inject shines, while acknowledging that Koin, Hilt, and even hand-rolled approaches remain valid depending on project size and platform mix.
What is "vanilla injection"?
The practice of wiring dependencies manually without a DI library—sometimes used in small projects or to avoid library overhead entirely.
Where can I learn more about the tools discussed?
The show notes on fragmentedpodcast.com link to Fred Porciúncula's online presence, his article on transitioning from Dagger/Hilt to Kotlin Inject, and Kotlin Inject's own documentation.