How much larger should we expect a KMP iOS framewo...
# multiplatform
m
How much larger should we expect a KMP iOS framework binary to be compared with an equivalent native Swift framework? We have a super app where binary size is closely monitored. In our case, adding a KMP library typically increases app size by ~2–3 MB. After enabling
latinString
,
smallBinary
, and also ran
strip - rSTx
the size improved, but our KMP frameworks are still consistently around 1.3–1.4× larger than equivalent Swift implementations. We tested this with: • Two small equivalent Swift/KMP libraries • One real production library implemented in both All showed roughly the same 1.3–1.4× difference. We have also reduced unnecessary public APIs and removed some data classes. Removing data classes alone saved ~180 KB. Are there any additional Kotlin/Native compiler, linker, or code-structure optimizations that can realistically bring the difference closer to ~1.1× native size? Or is ~1.3–1.4× a reasonable baseline for Kotlin/Native frameworks on iOS?
u
It's very reasonable, unlike Android, iOS apps are very heavy, Gmail is 700mb lol, in 2026 we're no longer at 1 or 2 mb.
🤯 1
p
Are you using the Apple guidelines to measure the App sizes?
m
We are using this google tool mainly https://github.com/google/bloaty
p
Have a look at the official guidelines developer.apple.com/documentation/xcode/reducing-your-app-s-size#… from Apple
f
FYI, kmp iOS framework will be always bigger than Swift framework, it’s not only about your code but also about kotlin runtime ecosystem, and that make a big difference than Swift which it's runtime is also already in the filesystem.
✅ 3
r
The K/N runtime should just be a fixed cost, though. If you're seeing KMP dramatically larger than pure Swift even in a larger app, that may indicate something else. But it's also enormously difficult to really do an apples-to-apples comparison of that for a large codebase.
m
@François I think KMP runtime cost is already covered and not part of number we analysed. As we have 8-9 libs but for testing we used only 2-3. How are we doing this is: we add one test lib measure the size, remove that test lib measure the size and check the diff, same for native swift lib. Also we have bloaty and some in house script which give package level size estimate, in package level analysis also we see kotlin size is bigger. @russhwolf I don't know what is acceptable increase ratio? I agree that its very hard to make it true apple to apple yet we want to establish a baseline. Right now we are at 120mb on app store, so its important for us as we don't want to hit 200 limit.