For cocoapods plugin can we set additional export frameworks?

# multiplatform

[Dmitry Motyl]

For cocoapods plugin can we set additional export frameworks?

[Kris Wong]

I was curious about that as well. didn't spend the time to investiate yet.

[h0tk3y]

cc @ilya.matveev

[ilya.matveev]

Yes, it's possible. The plugin creates both debug and release frameworks by default so you can access them and configure exports you need. E.g.

iosX64("iOS") {
    binaries.getFramework("RELEASE").export(project(":exported"))
}

[Kris Wong]

is that also possible for frameworks that are brought in via cinterop?

[ilya.matveev]

What do you mean by frameworks brought in via cinterop?

[Dmitry Motyl]

@ilya.matveev this code tries to create new one framework.
And cocoapods plugin shows error that framework name is dublicated

[Dmitry Motyl]

Anyway, if you set another name for this framework, podspec file exports original framework without external projects

[ilya.matveev]

this code tries to create new one framework

@Dmitry Motyl It shouldn't. Could you share a link to your buildscript?

[Dmitry Motyl]

apply plugin: 'kotlin-multiplatform'
apply plugin: 'kotlin-native-cocoapods'

version = "1.0"

kotlin {
    targets {
        fromPreset(presets.jvm, 'android')
    }

    sourceSets {
        commonMain.dependencies {
            api project(':domain')
            api project(':networking')
        }
    }

    iosX64("ios").binaries {
        framework {
            export project(':domain')
            export project(':networking')
        }
    }

    cocoapods {
        summary = "..."
        homepage = "..."
    }

}

[Dmitry Motyl]

I get error:

Cannot create binary debugFramework: binary with such a name already exists

[Dmitry Motyl]

if I set

iosX64("ios").binaries {
        framework("shared") {
            export project(':domain')
            export project(':networking')
        }
    }

It creates new one framework but cocoapods dependency export original framework without ‘domain’ and ‘networking’

[Kris Wong]

iosX64("ios") {
        compilations.main {
            cinterops {
                phonenumbers
            }
        }
        binaries {
            framework("$ios_framework_name")
        }
    }

[Kris Wong]

'phonenumbers' is an Obj-C framework

[Kris Wong]

i do also notice that the cocoapods plugin creates 'debugFramework' and 'releaseFramework', so I end up with duplicates

[ilya.matveev]

@Dmitry Motyl Yes, the framework() call does create a new framework. To configure already existing one, use the getFramework() method I've shown above.

[ilya.matveev]

@Kris Wong No, the plugin have no DSL allowing exporting declarations generated by cinterop. But why do you need to do it? A library you want to interop with should be accessible from ObjC/Swift without building an intermediate Kotlin/Native library.

[Dmitry Motyl]

@ilya.matveev In your example You get access to “release” framework. Can I configure both “release” and “debug” in one-line code?

[ilya.matveev]

There is no such option in plugin's DSL but you can use Gradle's standard configure method:

linuxX64("linux") {
    binaries {
        val release = getExecutable("RELEASE")
        val debug = getExecutable("DEBUG")
        configure(listOf(release, debug)) {
            /* Configuration. */
        }
    }
}

[Kris Wong]

I actually used vendored_frameworks within the generated podspec to export the framework binary

[Kris Wong]

it works nicely

[ilya.matveev]

I see. It looks like we have some confusion of concepts here. I was telling about exporting other Kotlin/Native modules in a framework as described here: https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#building-final-native-binaries (see the Exporting dependencies in frameworks section). It's technically possible to export Kotlin declarations produced by cinterop for a native library too but such an export doesn't make much sense.

While you mean exporting a native framework in terms of CocoaPods by adding it to vendored_frameworks. The plugin doesn't provide such a DSL but you alway can post process the podspec file generated by the plugin.
You can write your own task that modifies the vendored_frameworks field and register it as a finalizer for the podspec task (see https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:finalizer_tasks).