Ok so been googling and can’t find a good answer. I’ve got a library written in Kotlin multiplatform...

# kotlin-native

[Shannon Duncan]

Ok so been googling and can’t find a good answer. I’ve got a library written in Kotlin multiplatform. The ios fat-framework (arm32&arm64) is a whole 11.5MB. Is there any way I can remove unused parts of the stdlib or something to bring that down. It is basically one class file.

[Nikolay Kasyanov]

that’s probably a long shot, but have you tried setting transitiveExport to false while configuring the framework binary?

[Nikolay Kasyanov]

This is done with Swift bit-code, but I have not found documentation on the fat-binary side.

as far as I know, App Store arch slicing doesn’t require bitcode

[Shannon Duncan]

I’m in my project atm, so I’ll try and see if transitive changes it at all.

[Shannon Duncan]

@Siggi Gunnarss

So far the advice seems to be to not expose internal kotlin types since they add bloat

How do we prevent this?

[Shannon Duncan]

@Nikolay Kasyanov Unfortunately that did not work 😞

[Siggi Gunnarss]

In my case, public api was exposing Flow. Instead I expose an interface with some Flow functionality, that uses Flow behind the scenes.
This prevents the Coroutine types from bein added to the exported header file.

This didn't help binary size in my case and made the code more awkward, but I should probably keep it.

[Shannon Duncan]

Ah I’m not using any libraries like that. Mostly String, ByteArrays, and BitSet.

[Siggi Gunnarss]

Here's a previous discussion:
https://twitter.com/kpgalligan/status/1359510911715835911

The finding was that for iOS, the actual size increase wasn't as bad as it looked.
I'm measuring the delta in the total binary size inside the .ipa/.app file, so I don't think the optimistic 1mb estimate holds.

[Nikolay Kasyanov]

Thanks for sharing it, it helped me realize that removing stuff from the header isn’t only about smaller header, but also about having less Obj-C <-> Kotlin bridging code in the binary.

[Shannon Duncan]

So removed public class members that exposed types outside of Int/Number/String/Boolean and it reduced my library by 1MB… 😞

Gotta be a way to remove parts of the kotlin runtime that aren’t being used at all. Doubt there is much we can remove beyond this to reduce the kotlin bridge code.

[Siggi Gunnarss]

In the case of iOS, there's some helpful information here:
https://developer.apple.com/documentation/xcode/reducing_your_app_s_size

To accurately measure your impact on the final binary size, you can export the app in a special way, that creates a report and optimized .ipa files that resemble what the user will get.

In my tests, this seems to result in the expected binary size of ~ 2 mb.

I don't know how this compares on other native platforms and how it would be best to debug similar issues there