@ContributesBinding in multi-module KMP project

[itsmattking]

Hello,

I'm working on adding kotlin-inject-anvil to a new KMP project.

Similar to this issue, I'm trying to understand how I can have an interface in one module (say :domain) and an implementation in another (say :data). A parent module (say :parent) contains :domain and :data.

I want it so that if consumers include :parent that they automatically have injectable implementations of the items in it's :domain without seeing the implementations in :data.

:domain

interface MyDataSource {
  fun getThing(): String
}

:data (includes :domain dependency)

@ContributesBinding(AppScope::class)
@SingleIn(AppScope::class)
class MyDataSourceImpl @Inject constructor() : MyDataSource {
  override fun getThing(): String = "a string"
}

However when I try to create a component in :parent:

@MergeComponent(AppScope::class)
@SingleIn(AppScope::class)
abstract class CoreComponent {
    abstract val myDataSource: MyDataSource
}

it says that Cannot find an @Inject constructor or provider for MyDataSource, though I've defined it on MyDataSourceImpl via @ContributesBinding. I tried using @Provides the way typically done using plan kotlin-inject, but it's no difference.

Oddly enough though, this seems to only affect iosArm64 and iosSimulatorArm64 - I'm able to get it to work on JVM/Android with a bit of fiddling around.

So I guess my questions are:

1. Am I just fundamentally misunderstanding how @ContributesBinding works or are there limitations around having it in different modules?
2. Is my understanding of how to use kotlin-inject and kotlin-inject-anvil in KMP incorrect?

I've followed the documentation both here and here as well as looked at the samples provided in both this repo and kotlin-anvil.

[vRallev]

How is :parent importing :domain and :data? It's important that :data is imported using an :api dependency, otherwise :data is not exposed on the compile classpath and the annotations aren't working as you hope.

Your dependency graph looks like this:

:app -> :parent ->      :domain
               \-> :data  -^

In general we stay away from such a dependency graph and avoid hardcoding implementations. Instead we use:

:app -> :parent ->      :domain
    \-> :data            -^

More details are here: https://amzn.github.io/app-platform/module-structure/

[itsmattking]

How is :parent importing :domain and :data? It's important that :data is imported using an :api dependency, otherwise :data is not exposed on the compile classpath and the annotations aren't working as you hope.

:parent is using api when importing :domain and implementation when importing :data. Would this be the reason?

:app -> :parent ->      :domain
    \-> :data            -^

I guess the issue I can see with this is that I wanted multiple modules similar to :parent where each had self-contained :domain and :data modules, and only exposing its :domain via api and contributing concrete implementations via a component. Is that just fundamentally not possible? Or is there another way to structure modules to achieve the same effect while allowing dependency injection among all modules?

More details are here: https://amzn.github.io/app-platform/module-structure/

This is a really helpful read - thanks! I was at KotlinConf 2025 and saw your talk, this is the reason I wanted to try out kotlin-inject-anvil.

Thanks again for taking time to answer my questions 😄

[vRallev]

When you use @MergeComponent, then the KSP processor is scanning the compile classpath for contributed classes. If you do this:

:app -- implementation --> :parent -- implementation --> :data

Then :app will not see any code from :data during compilation and therefore the contributed classes aren't found. This would fix it:

:app -- implementation --> :parent -- api --> :data

[itsmattking]

Just wanted to mention I tried using @ContributesBinding in a very simple setup.

:module1

interface MyInterface {
  fun doSomething(): String
}

@ContributesBinding(AppScope::class)
@Inject
class MyInterfaceImpl : MyInterface {
  override fun doSomething() = "something"
}

:app (including :module1 by implementation)

@MergeComponent(AppScope::class)
abstract class AppComponent {
  abstract val myInterface: MyInterface
}

This results in the same issue with Cannot find an @Inject constructor or provider.

However if I move MyInterface and MyInterfaceImpl into :app, it works as expected.

Is this expected behaviour?

[vRallev]

No, that's not expected. At this point I'd need to ask for a sample, because we see no issues with that.

[TepesLucian]

I'm also seeing this issue when migrating from vanilla kotlin-inject and not really sure what I'm doing wrong. Put together a sample android project from the example above here

[TepesLucian]

Adding ksp compilers to module1 seems to fix the issue. Is it the missing piece or should it work without it? Would be great if the documentation mention it to avoid further confusion and issues.

[vRallev]

@TepesLucian The setup section shows that the KSP plugin should be applied: https://github.com/amzn/kotlin-inject-anvil?tab=readme-ov-file#setup Do you mind updating the section to make this clearer? Thanks!

[TepesLucian]

So all sub modules should have the ksp plugin applied or dependens on the annotation? @SingleIn seems okay but @ContributesBinding makes sense to require it since it generates code.

[vRallev]

I suggest to enable KSP and the processor in all modules where you use any runtime annotations / APIs.

[Elijah-Dangerfield]

@vRallev Really appreicate all the help you've given in issues. I am having a very similar if not the same issue with multi-binding in a multi module KMP project.
cannot find an @Inject constructor or provider for: Set<...>

Project Structure

The Multibinding Setup

library1 defines: interface InterfaceDef
feature1:impl and feature2:impl both implement InterfaceDef with @ContributesBinding(AppScope::class, multibinding = true)
App module expects: Set to be injectable

Dependencies (Diagram Below)

App depends on all modules via implementation
Api Modules Depend on nothing
Impl modules Depend on their own api modules implementation
FeatureImpl modules Depend on api of library modules

fun Project.configureKotlinInject() {
    project.pluginManager.apply("com.google.devtools.ksp")

    extensions.configure<KotlinMultiplatformExtension> {
        sourceSets.apply {
            commonMain.dependencies {
                implementation(libs.kotlin.inject.runtime.kmp)
                implementation(libs.anvil.runtime)
                implementation(libs.anvil.runtime.optional)
            }
        }
    }

    dependencies {
        add("kspAndroid", libs.kotlin.inject.compiler.ksp)
        add("kspAndroid", libs.anvil.compiler)

        add("kspIosArm64", libs.kotlin.inject.compiler.ksp)
        add("kspIosArm64", libs.anvil.compiler)

        add("kspIosSimulatorArm64", libs.kotlin.inject.compiler.ksp)
        add("kspIosSimulatorArm64", libs.anvil.compiler)
    }
}

What Works vs What Fails
✅ Android: Multibinding works perfectly, Set is properly resolved
✅ iOS feature modules: Build successfully, generate correct multibinding interfaces. I see the @provides @IntoSet in the generated/ksp file
❌ iOS app module: Cannot find @Inject constructor or provider for: Set

Versions:

kotlin-inject 0.8.0
kotlin-inject-anvil 0.1.6
KSP 2.2.20-2.0.4

Obligatory Diagram

[Elijah-Dangerfield]

@itsmattking Did you end up figuring this out?