I’m using a KMM library that declares a pod in it’...

# ios

[Landry Norris]

I’m using a KMM library that declares a pod in it’s build.gradle.kts for iOS, and I’m having trouble running tests on the module that uses the library. If I don’t include pod("FirebaseAnalytics") in my build.gradle.kts, I get a missing symbol error when trying to run tests. If I add pod("FirebaseAnalytics") , I get Compilation failed: Linking globals named 'knifunptr_cocoapods_FirebaseAnalytics0_kFIREventAdImpression_getter': symbol multiply defined! . Is there a way to tell the cocoapods plugin that I want to pull down the binary, but I don’t care to have the cinterop generated in my module?

[a-dd]

There is no built-in feature, but you can do something like this:

targets.withType<KotlinNativeTarget>().forEach { it.binaries.forEach { it.linkerOpts(
        "-U", "missing_symbol_1",
        "-U", "missing_symbol_2",
        "-U", "missing_symbol_3",
        ...
) } }

where you list all the missing symbols

[a-dd]

You can also add a vote to https://youtrack.jetbrains.com/issue/KT-41830/CocoaPods-integration-Support-link-only-mode-for-pods :)

[Landry Norris]

If I add the -U linkerOpt, what happens when the method is called? The debugTest binary won’t pull the binary down without a pod declaration.

[Landry Norris]

When I add -U, I get symbol not found in flat namespace when I try to run my tests. I’ll have to experiment some more.

[a-dd]

Yes, I forgot to mention this. With these flags kotlin framework should build without errors but you have to link this pod/framework later when building a final app

[a-dd]

Also I think everything will work more or less from the box if you make your kotlin framework static and add pod("FirebaseAnalytics") to cocoapods plugin extension (if static linkage works for you of course)

[kpgalligan]

I think you also may need to turn off compiler caching for tests. We haven’t done a deep dive on that, but it seems like test builds used to statically link only what they needed, but more recently, tests builds are dynamic, or at least they will fail if they can’t find the binary. And, of course, you can’t call the binary in your tests. We had a lot of this in Crashlytics and Bugsnag work:

kotlin.native.cacheKind.iosX64=none
kotlin.native.cacheKind.iosSimulatorArm64=none

[Landry Norris]

I’ll have to add that. I noticed that CrashKIOS uses a def file with headers, but no link options instead of cocoapods. Is this the reason why?