How Much Does Kotlin Multiplatform Add to Your App Size?

Published August 2026 by Batteries Included

Adopting Kotlin Multiplatform makes your app bigger, but how much depends on what you share. According to published measurements, sharing only business logic adds a small amount on both platforms. Sharing UI with Compose Multiplatform adds little on Android and roughly 10 to 30 MB on iOS.

Quoted figures often seem to contradict each other because they measure different things: logic versus UI, Android versus iOS, download versus install size, debug versus release builds. This article collects what has been published, explains the differences, and shows how to measure the size Kotlin Multiplatform adds to your own app.

Short answer

• Sharing logic only (Kotlin Multiplatform): the added size is usually small. Community reports range from about 200 KB to a few megabytes, depending on which libraries the shared code pulls in.
• Sharing UI on Android (Compose Multiplatform): no meaningful difference from native Jetpack Compose in the independent sample we cite below.
• Sharing UI on iOS (Compose Multiplatform): this is where the cost is. Reported increases run from about 9 MB (JetBrains' benchmark) to 25 to 32 MB (an independent sample on older versions), because the rendering stack ships inside your app.

So “is Kotlin Multiplatform too big?” is usually the wrong question. The useful one is whether you are sharing UI on iOS, and if so, whether roughly 10 to 30 MB matters for your users.

What the published numbers say

Treat every row as a single data point with its own toolchain, assets and dependencies. None is a forecast for your app. Also note the versions: at the time of writing Compose Multiplatform is on the 1.12 line, and we did not find a widely cited size measurement for anything newer than the 1.8.0 benchmark. Re-measure on current versions before you rely on any of this.

Why iOS is different

A native SwiftUI app leans on UI code that already lives in the operating system. Compose Multiplatform on iOS draws its own UI, so it ships its own rendering stack. A reply in a Compose iOS Slack thread put it simply: a Swift app relies mostly on APIs that are part of the OS, while a Kotlin app packs things like Skiko. The independent comparison below notes the same thing: Skia ships with the iOS Compose build, while Android relies on the Skia that is already built into the OS.

Logic-only Kotlin Multiplatform is a different story. Kotlin's documentation describes integrating a shared module into an iOS app as a generated framework that you add as a dependency, and the compiler only keeps what your code uses. In a Kotlin Slack thread, one developer measured the effect in App Store Connect at roughly 1.5 MB download and 4.5 MB on disk for a droidcon app with SQLDelight, serialization, Ktor and other libraries, and another reported about 200 KB for a small shared pod added to a legacy iOS project.

The evidence in more detail

JetBrains: about 9 MB (Compose Multiplatform 1.8.0)

When JetBrains marked Compose for iOS stable in the 1.8.0 announcement, it said Compose adds about 9 MB to an iOS app compared with a fully native SwiftUI app with the same UI logic and assets. The LazyGridImageView benchmark in the Compose Multiplatform repository compares size, startup time, frame rate and CPU/GPU use across Compose Multiplatform, Jetpack Compose and SwiftUI, and includes scripts for measuring and comparing sizes. It is a reproducible harness for one workload, not a prediction for yours.

An independent side-by-side sample

Jacob Ras maintains a public comparison of one small image-list app built natively, with Kotlin Multiplatform and Compose, and with Flutter. He measured Android with bundletool on a signed, minified release bundle, and iOS with Xcode's App Thinning Size Report. Android came out identical for native and Compose Multiplatform at 1.463 MB. On iOS, native was 1.7 MB, Compose Multiplatform 24.8 MB (version 1.4) and 32.2 MB (1.5), and Flutter 17.9 MB. This is the clearest example of what a matched method looks like, and it is from 2023-era versions.

Two production-style reports

In a GitHub issue, the author reported that adding Compose to their shared module took their iOS app from 70 MB to 86 MB on the App Store (Kotlin 1.9.0, Compose Multiplatform 1.5.0). In a 2025 Kotlin Slack thread, a JetBrains engineer pointed to the KotlinConf app, built with Compose Multiplatform, as an example that needs around 50 MB depending on the target device. These are real apps, but each includes everything else the app ships, so they show the order of magnitude, not the delta.

Academic work

A 2024 thesis evaluated Kotlin Multiplatform with Compose Multiplatform. It found no apparent performance or quality overhead against native Android, while the iOS product had issues including significantly larger app size and slower launch time. It is consistent with the rest of the evidence: Android is fine, iOS UI sharing costs more.

Why published numbers disagree

Most gaps between two quoted figures come from measuring different things. Four to watch for:

• Download vs install. Download size is compressed and what users fetch. Install size is what sits on disk. Google Play and App Store Connect report both, and they differ substantially (the 1.5 MB vs 4.5 MB example above).
• Debug vs release. Debug builds are not representative. In the Ras sample, the debug simulator builds were several times larger than the thinned release builds (per his Kotlin Slack post).
• Framework size vs final app delta. A Kotlin framework file on disk can look huge, but a static link only pulls in what is used. In one thread, a framework of about 30 MB (both device and simulator architectures) added only about 1.5 MB to the final app. What matters is the change in the thinned app.
• Store reprocessing. Stores re-package your upload for each device. Flutter's size documentation makes this point for any framework: the package you upload is not what users download.

How to measure your own app

Build a thin vertical slice of your real product with the dependencies you plan to ship, then measure a release build.

Android

1. Build a minified release Android App Bundle with your real R8/ProGuard settings.
2. Estimate download size with bundletool (build-apks, then get-size). Google notes this is close to, but not identical to, Play Console.
3. For the authoritative number, upload to an internal testing track and read download and install size in Play Console under Android vitals, App size.

iOS

1. Archive a Release build that embeds the Kotlin framework.
2. Export with app thinning for all compatible device variants and read the App Thinning Size Report, as described in Apple's Reducing your app's size. Apple says App Store Connect gives the most accurate figures.
3. Report compressed (download) and uncompressed (install) sizes separately, and compare against the same build without the Kotlin code.

Whatever you do, keep the comparison fair: same features and assets in every variant, same device class, and no debug or simulator builds. Record the Xcode, Kotlin and Compose Multiplatform versions next to each number.

How to reduce the iOS cost

• Try the small-binary option. Since Kotlin 2.2.20, the compiler flag -Xbinary=smallBinary=true makes release binaries smaller and speeds up builds, though JetBrains notes it may affect runtime performance in some cases. One team reported a 65 MB framework dropping to 40 MB with it, though that figure is framework size, not store size.
• Export less to Swift. Only code exposed to iOS needs to be in the generated interface. One community reportstopped exporting coroutines definitions that iOS never used and saved nearly a megabyte with no functional change.
• Test static vs dynamic linking. Results are mixed in community reports (one saved about 1 MB, another got larger), so measure rather than assume.
• Audit what you pull in. Transitive dependencies, image libraries and bundled assets add up. The size of a shared module often tracks its dependencies more than its own code.
• Share logic, keep SwiftUI. If the iOS delta is too high, sharing business logic while keeping native UI avoids shipping a rendering stack at all.

When should size decide the stack?

Size is a real constraint for products aimed at users on slow or metered connections, for offline-first field apps, and for apps already close to store limits. Google Play notes that app size can affect install and uninstall metrics. If that describes you, measure early.

For most teams, a one-time cost of roughly 10 to 30 MB on iOS is a trade against shipping one UI codebase instead of two. That can be a good trade or a bad one, depending on your users and team. It is a reason to measure, not a reason to rule Kotlin Multiplatform out: logic-only sharing carries a small cost, and Android shows no meaningful gap in the sample we found. For the broader decision, see our guide to shared logic first and when to add Compose Multiplatform.