Has anyone published any metrics etc on effect usi...

# multiplatform

[John O'Reilly]

Has anyone published any metrics etc on effect using explicitApi() has on a KMP project?

[François]

For iOS, mainly the size of objc umbrella header

[John O'Reilly]

yeah, have been looking at that and not seeing drastic reduction so far.....this is pretty large project but have only made first pass applying public/internal etc so could be stuff leaking that shouldn't be still

[François]

Be careful of generated KSP code, sometimes the visibility can’t be changed.

[François]

Use public interface + internal implementation.
It helps a lot to reduce exposed content.

[François]

Oh, yes, it’s not just about the header, it’s also about security and binary size
With nm -g yourKMPLib , you can see everything inside your file.

[François]

@kpgalligan could tell a lot about it 😄

[kpgalligan]

Yeah. We haven't run numbers in a few years, but Kotlin and Swift binary seems to grow at a similar rate if the Kotlin is not exported. If you're exporting a lot, binary gets much bigger, relative to how much API you're exporting. The Kotlin compiler needs to generate ObjC adapters, essentially. SqlDelight can be particularly bad if you have a lot of tables. That's what originally trigger digging into it. Somebody from (redacted) reached out saying they had done a POC with ~100 tables and the binary was quite large. SqlDelight generates a lot of declarations, all public. If you're not directly accessing them from Swift, that's all wasted binary. For SqlDelight specifically, just have it in a different module and don't export the whole thing. It's also easy to have a dependency in the API, which can drag a bunch of related classes. For example, Ktor or Coroutines. If you're not calling them directly from Kotlin, leaving a dependency in the API is an easy way to pull in extra binary. A few years back I did some quick edits to KaMPKit, and dropped the binary by like 20%. The simplest way to diagnose is looking at the header. If you see things you're not calling, well.

[John O'Reilly]

@kpgalligan were you using explicitApi() ?

[kpgalligan]

Not at the time. I was doing it the hard way 🙂

[François]

Explicit API has been introduced on kotlin 1.4

[kpgalligan]

I mean, I would use explicitApi now. That helps, but it won't stop somebody from marking something public that isn't needed. Also, CMP apps would be a little more similar as far as their KMP, but an app with native UI might need to craft the iOS API differently. A CMP app could have a minimal API available to iOS, but there's also much less to gain from stressing the API if the Swift-facing part is mostly just entry points.