Ok so been googling and can’t find a good answer. ...
# kotlin-native
s
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.
n
that’s probably a long shot, but have you tried setting
transitiveExport
to
false
while configuring the framework binary?
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
s
I’m in my project atm, so I’ll try and see if transitive changes it at all.
@Siggi Gunnarss
So far the advice seems to be to not expose internal kotlin types since they add bloat
How do we prevent this?
@Nikolay Kasyanov Unfortunately that did not work 😞
😢 1
s
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.
s
Ah I’m not using any libraries like that. Mostly String, ByteArrays, and BitSet.
s
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.
n
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.
s
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.
s
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