Hi, My iOSFramework size is ~15mb when generated using kotlin multiplatform. Not sure if it is norma...

# kotlin-native

[Amritansh]

Hi, My iOSFramework size is ~15mb when generated using kotlin multiplatform. Not sure if it is normal to have large framework file size since it looks like it is on a higher side.

[Michal Klimczak]

Someone in my ios team was complaining recently that the native framework from the template kmm project was 12 MB. Didnt look into it yet, though

[KamilH]

My Kotlin’s iOS framework (.xcframework) size is ~30 MB (included both ARM and x86 for the real devices and the simulator), but final .ipa file that is built from the app that includes this framework is just 1.5 MB bigger than the app without framework added

[Amritansh]

@KamilH thanks for sharing this

[kpgalligan]

We've done (relatively) extensive testing on size. You really do have to look at what the final file size increase on the device is. The framework on your build system's disk is not going to tell you much about what the final will be. I generally say figure about 500k for bare minimum and a few meg for something with a fair number of libraries and code. It will vary considerably based on what you're doing.

[kpgalligan]

There is a lot more to this discussion that would need to be summarized in some kind of a blog post. Overview of thoughts here:

https://youtu.be/hrRqX7NYg3Q?t=1893▾

[Amritansh]

@kpgalligan thanks for sharing

[kpgalligan]

Twitter thread from today https://twitter.com/kpgalligan/status/1359587710369988609?s=21

[Amritansh]

@kpgalligan we tested our final app install size and there was a jump of ~16% . Earlier our app size was ~ 70mb but after adding KMM library, the app size was 81.6mb.
OUR KMM library has dependency on Ktor, Klock, benasherUUID, stately, sqlDelight and coroutine.

[Amritansh]

We also have anothe KMP library which we built a while back and it increased our ios app size by around 4mb. That one does not have any dependency

[kpgalligan]

They all technically depend on the stdlib, but only the parts you use. Just something to keep in mind.

[Amritansh]

I am assuming these external libraries are adding to the increase in size

[Amritansh]

right

[kpgalligan]

All of the libraries will of course add, but the kotlin compiler tries to limit what's actually included to code you're actually referencing. So, if you include ktor, but for some reason never actually call it, I don't think it would add anything. If you include stately, but only use a tiny bit, in theory it wouldn't add much.

[kpgalligan]

However, the code that is exposed externally to your ios framework needs to be included in your generated interface. That's the easiest way to reduce size. So, for example, say you include a bunch of modules and export all of them, they'll all be available to Swift, but each class/interface generates an Objc adapter, which adds a whole lot of binary weight.

[kpgalligan]

On the other hand, if you make everything you can internal, and minimize the available iOS surface, you'll save a lot.

[Amritansh]

that makes sense. I saw that you mentioned internal in the video you sent, that was a good idea.

[kpgalligan]

For example, in the sample above, the iOS interface was exporting a lot of the coroutines library, but none of that was needed (or usable) from iOS. Marking a few classes as internal allowed the compiler to not need to export coroutines definitions, and dropped the total size by almost a full meg.

[kpgalligan]

To be clear, that changed none of the functionality at all, but dropped binary size significantly.