Why App Size Matters and How to Shrink It

App size is one of the metrics developers care about least and users see most. The store page lists the file size, and anyone downloading over mobile data looks at it.

Size directly affects three things: your download rate (especially on slow connections), your update rate (people postpone large updates), and how much space it takes on the device (someone freeing up storage deletes the biggest app first).

Measure first: what's actually in there?

Optimizing by guesswork is a waste of time. Both platforms have tools that show you what's inside the package and how much space each part takes — APK Analyzer in Android Studio, and the size report generated after a build on the Xcode side.

Almost every time I look, the same two things top the list: images and unused library code.

1. Use the Android App Bundle

A single APK has to carry everything needed for every screen density and every CPU architecture. With the App Bundle format, Google Play ships each device only the pieces that device actually needs.

That's a win you get without changing a single line of code. Changing the publishing format is enough.

2. Turn on code shrinking

On Android, R8 strips out unused classes and methods and shortens the names that remain. Because it's off by default, plenty of projects never turn it on at all.

android {
    buildTypes {
        release {
            minifyEnabled true        // strip unused code
            shrinkResources true      // strip unused resources
        }
    }
}

3. Images: the biggest win is here

In my experience images make up the largest share of the size, and they're also the easiest place to win.

• Use vectors. For icons and simple illustrations a vector is a single file; a PNG means a separate file for every screen density.
• Convert photos to WebP. At the same visual quality it gives you a noticeably smaller file.
• Ship them at their real size. Bundling a 3000-pixel-wide image for a slot that renders at 300 pixels inflates both the package and memory usage.
• Delete the unused ones. Images that pile up in a project over time and no longer appear on any screen take up a surprising amount of space.

4. Review your libraries

A large library pulled in for a single helper function brings its own weight along with it. It helps to go down the dependency list and ask: am I really using this, or is it still here for one function?

I applied the same approach to this site: it's written in plain HTML, CSS and JavaScript with no framework at all. Most of the time the fastest solution is not adding the thing.

5. Download large content later

Large assets that not everyone needs — extra language packs, high-resolution content, game levels — can be downloaded on demand instead of being included in the install. Both platforms offer a mechanism for this.

It brings the initial download size down noticeably, and that first download is what really matters, because that's where the user makes the decision.

Don't do it once and forget it

Size grows quietly over time: every release adds an image, a library, a feature. I added noting the size to my pre-release checklist; if there's an unexpected jump compared to the previous release, I find out why before it ships.

The user has no idea how well your app is written. The only technical detail they know is how long the download took.

• App size
• App Bundle
• R8
• Image optimization
• Performance