Skip to main content

Mobile App Bundle Size Benchmark

Bundle size benchmarks measure download and install size with per-component and per-architecture breakdowns, tracking deltas across releases to control bloat. Reporting the realistic per-device delivered size matters more than the universal artifact.

Mobile app bundle size benchmarks measure how large an app is to download and to install. Size matters because large apps see lower install conversion, especially on cellular networks and lower-end devices with limited storage, and app stores impose size limits and over-cellular download caps.

The relevant numbers differ: the download size (compressed, what the user fetches) is smaller than the installed size (decompressed code, resources, and runtime data on the device).

What It Measures

Core metrics are download size and install size, broken down by component: native code per CPU architecture (ABI), resources and assets, fonts and media, and the application code itself. Benchmarks track size delta between releases to catch creeping bloat and report the contribution of each dependency or module so the heaviest additions are visible.

Methodology

Size is measured from the final distributable artifact as the store would deliver it, accounting for store-side optimizations like per-device splits (Android App Bundles deliver only the matching ABI and density; iOS app thinning delivers device-specific slices). Tooling analyzes the artifact to attribute bytes to code, resources, and libraries, and compares against the previous release to compute deltas. Because users download device-specific splits, the benchmark should report the realistic per-device download size, not the universal artifact. Tracking size in continuous integration on every build catches regressions early, and per-dependency attribution identifies which library or asset drove an increase.

How to Interpret Results

Report the per-device delivered size, since the universal package overstates what any user actually downloads. Watch the trend: bundle size tends to grow monotonically as features and dependencies accumulate, so a budget and a per-release delta alert are more useful than a one-time measurement. Large resource contributions often indicate uncompressed images or unused assets, while large code contributions point to heavy dependencies or duplicated functionality. Install size affects retention because users low on storage uninstall large apps first. Compare download and install size together, as aggressive compression can hide a large on-device footprint.

Limitations

The meaningful size depends on store delivery mechanisms that vary by platform and device, so a single universal number misleads. Size does not directly measure performance or quality; a small app can still be slow. Dynamic feature modules and on-demand resources shift bytes out of the initial download in ways simple measurements miss. Compression ratios vary by asset type, complicating attribution. Benchmarks should track per-device delivered size over time and pair size with install-conversion data to judge real impact.