skip to content

A teammate wired Dagger/Hilt with kapt and asks whether they can just switch to ksp(...) for faster builds. How do you advise them, and how does the Gradle wiring differ for Hilt specifically?

level: middleimportance: should knowfreq 55%

answer

  1. Dagger 2.48+ added KSP — no longer kapt-only
  2. Move compiler from kapt(...) to ksp(...)
  3. Hilt still needs its own Gradle plugin (bytecode transform)
  4. You can apply kapt and KSP plugins together
  5. KSP version must match Kotlin version

basics

~10 s

Recent Dagger/Hilt versions support KSP, so they can move the compilers from kapt(...) to ksp(...). Hilt also needs its own Gradle plugin applied, regardless of kapt or KSP.

solid answer

~30 s

Dagger and Hilt were historically kapt-only, but modern Dagger (2.48+) ships KSP support, so you can replace kapt("com.google.dagger:hilt-android-compiler") with ksp("com.google.dagger:hilt-android-compiler") and likewise for plain Dagger's dagger-compiler. You must apply the KSP plugin so ksp(...) resolves, and separately apply the Hilt Gradle plugin (com.google.dagger.hilt.android) which does bytecode transformation independent of the processor backend. If any other processor in the module still needs kapt (e.g. a legacy library), you can apply both plugins and mix kapt(...) and ksp(...) configurations. Validate generated components still build, since KSP and kapt can surface annotations slightly differently in edge cases.

code

kotlin · 9 lines
kotlin
plugins {
    id("com.google.devtools.ksp")
    id("com.google.dagger.hilt.android")
}

dependencies {
    implementation("com.google.dagger:hilt-android")
    ksp("com.google.dagger:hilt-android-compiler")
}

go deeper

for a junior

Knows the compiler line and that a plugin must be applied.

for a middle

Knows Dagger gained KSP support and that Hilt needs its own plugin beyond the processor.

for a senior

Explains kapt+KSP coexistence, the bytecode-transform role of the Hilt plugin, and version coupling.

for a principal

Plans the org-wide migration: convention plugins, version-catalog alignment, build-time benchmarking, and risk of subtle codegen differences.

## The historical state For years, **Dagger** and **Hilt** were **kapt-only**: their processors used the Java `javax.annotation.processing` API, so on Kotlin you needed kapt to generate Java stubs for them. kapt is slow because it forces a stub-generation pass. ## What changed Modern **Dagger (2.48+)** ships **native KSP** support. So the compiler artifacts can move from `kapt(...)` to `ksp(...)`: ```kotlin // before (kapt) kapt("com.google.dagger:hilt-android-compiler") // after (KSP) ksp("com.google.dagger:hilt-android-compiler") ``` Same for plain Dagger's `dagger-compiler`. ## Hilt's extra plugin Hilt is **not just** an annotation processor. The **Hilt Gradle plugin** (`com.google.dagger.hilt.android`) performs **bytecode transformation** (e.g., to make `@AndroidEntryPoint` work) — that's orthogonal to whether the codegen runs via kapt or KSP. So Hilt always needs: ```kotlin plugins { id("com.google.devtools.ksp") // so ksp(...) exists id("com.google.dagger.hilt.android") // bytecode transform } dependencies { implementation("com.google.dagger:hilt-android") ksp("com.google.dagger:hilt-android-compiler") } ``` ## Mixing kapt and KSP You can apply **both** the `kotlin-kapt` and KSP plugins in the same module and use both configurations — useful when one library is still kapt-only while you move others to KSP. They run as separate passes. ## Caveats - KSP and kapt can differ subtly in how they see generated symbols; re-run the build and tests after switching. - Keep the KSP plugin version compatible with your Kotlin version — KSP versions are pinned to specific Kotlin releases.

  • Why does Hilt need a Gradle plugin while plain Dagger doesn't?
    Hilt does compile-time bytecode transformation (e.g., for @AndroidEntryPoint base-class swapping) that a pure annotation processor can't do; the plugin performs that transform. Plain Dagger only generates code, so the processor alone suffices.
  • Can you keep one library on kapt and move Hilt to KSP in the same module?
    Yes — apply both the kotlin-kapt and KSP plugins and use kapt(...) for the legacy processor and ksp(...) for Hilt; they run as separate passes.

saying these in an interview costs you the question

  • Insisting Dagger/Hilt can never use KSP
  • Forgetting the Hilt Gradle plugin and assuming KSP alone is enough
  • Believing you cannot mix kapt and KSP in one module
  • Ignoring KSP/Kotlin version coupling

context

resolving links…