I'm trying to implement a ViewModelStoreOwner on t...

# multiplatform

[Jason]

I'm trying to implement a ViewModelStoreOwner on the iOS side using Swift. Is it possible to change the name of an exported KMP class? For some reason, when I export the org.jetbrains.androidx.lifecycle:lifecycle-viewmodel library in gradle, on the iOS side the ViewModelStoreOwner class name is created as Lifecycle_viewmodelViewModelStoreOwner instead of just ViewModelStoreOwner. I've seen some examples where it does create names like this and also some that don't, for instance in the FantasyPremierLeague repo, Swift can reference the class ViewModelStoreOwner just like that. I had this issue w/ Koin at one point, but Koin exported classes are not renamed any longer like the androidx lifecycle viewmodel classes are.

[François]

https://github.com/frankois944/kmp-mvvm-exploration

[Boy Hoody]

are you adding the dependancy with api on common target like this?

commonMain.dependencies {
api(libs.androidx.lifecycle.viewmodel)
}

In my case, that was the reason for the weird naming

[François]

it’s the toml naming, see https://github.com/frankois944/kmp-mvvm-exploration/blob/main/gradle/libs.versions.toml.
It’s starting to be a standard for declaring versions

[Boy Hoody]

@François he is not about the name in gradle files coming from toml. Once you are done with importing, using those classes comes with weird naming on ios side

[François]

Oh I see, you mean the naming with “_”.
You can typealias them with swift if you want to be more naturel

[Michael Krussel]

You get names like that if the type is in your public API but you didn't export the library in your binary declaration in gradle.

But if you do export it, then all the symbols from the library are add.

[François]

yes, that’s it.
In kotlin everything in a module is public/open by default so everything is exported.
Internal/private of Property/Method/class are not exported
the gradle rule explicitApi() is really usefull to reduce exposed content

[François]

In swift, the rule is in inverse 😄

[Jason]

Thanks for your guys feedback. @Boy Hoody I do bring in the lib from common like this:

commonMain.dependencies {
    api(libs.androidx.lifecycle.viewmodel)
    ...
}

@Michael Krussel I am using the type in my public common API but I also export the library in gradle like so. If I remove that export below, it seems it isn't even needed as I still can access the `Lifecycle_viewmodelViewModelStoreOwner`since it's being used in one of my common public API's. if I don't use that type in my public common API, even with the explicit export of the lib below, that type is not exported, seems like I have to be using it in the API for it be available in Native side.

targets.withType<KotlinNativeTarget> {
    binaries.withType<Framework> {
        isStatic = false

        export(libs.androidx.lifecycle.viewmodel)
        
        transitiveExport = false
    }
}

@François I am not exporting everything, i have transitiveExport = false, so I don't expose everything to native, just the ones I explicitly export. I will look into explicitApi() haven't seen that but sounds like it behaves similar to the transitiveExport maybe.

Thanks for your help again, while I'm ok with the verbose naming of exported type names, I do want to understand how to avoid it. Will keep trying.

[Michael Krussel]

explicitApi just reports warnings if you do not explicitly specify your visibility and return types. It doesn't change what gets exported, but instead encourages you not to accidentally export something you don't mean to.

[François]

explicitAPI changes what gets exported by forcing you to choose what you want to export 😛

[François]

for iOS, it’s reducing the size of the binary / header and also , I guess, increase the compilation speed.