Mobile App Size Optimization

Diagnose Current Size

Mobile app size optimization is the practice of reducing the download and install footprint of binary packages (APKs, AABs, IPAs) without breaking functionality. It matters for every release that reaches a user's device, especially on constrained networks, limited storage devices, or when store upload quotas and review guidelines impose size caps. This reference page walks through concrete, repeatable steps to audit, trim, and enforce size boundaries across typical mobile build pipelines.

Using the build tool’s size reporter

Most modern build systems expose a one‑command snapshot of the final package’s size breakdown. On Apple platforms, xcodebuild -showBuildSizes -scheme MyApp -configuration Release prints a table that includes the executable size, frameworks, assets, and the total IPA footprint. On Android‑based pipelines, apkanalyzer measure --apk build/outputs/apk/release/app-release.apk emits a similar decomposition, listing the compressed APK size, the raw DEX size, and the AAR contributions.

> Exact command output example (truncated) > `` > $ xcodebuild -showBuildSizes -scheme App -configuration Release > === Showing build sizes === > Target "App" has total size: 48.3 MB > Executable: 22.1 MB > Frameworks: 12.4 MB > Assets: 13.8 MB > ` > The same command on Android yields: > ` > $ apkanalyzer measure --apk app-release.apk > Compressed size: 12.5 MB > Raw DEX size: 8.1 MB > Native libs: 3.2 MB > ``

If the paths are wrong, both tools emit a clear “No such file or directory” error that pinpoints the missing artifact, making it easy to locate the correct build output before re‑running the measurement.

Manual filesystem check

When a dedicated reporter isn’t available, a quick du scan of the build root reveals the heavy hitters.

du -sh build/outputs/**/*

Running this against a missing directory produces the standard Unix diagnostic:

du: cannot read 'build/outputs/release/app-release.apk': No such file or directory

Adjust the glob to match your project’s output layout, then iterate until the largest contributors are visible.

Shrink the Code Footprint

Reducing the amount of machine‑code and bytecode that ships with the app is the most direct way to shrink size. The mechanics are generic across platforms: a build‑configuration flag turns on a minifier, and a rules file tells the tool which entries to preserve.

Enable the build system’s minifier

Most contemporary build systems accept a boolean flag in the project configuration that switches on code shrinking. When the flag is set, the tool invokes its default minifier on the compiled artifacts. A rules file placed at a project‑convention location is read at minification time; each line follows the tool’s pattern syntax to list classes, methods, or resources that must remain accessible at runtime. Lines beginning with -keep preserve the named element, while everything else is eligible for removal.

> Example rule pattern (generic) > `` > -keep public class com.example.MyApplication { *; } > -keepclassmembers class com.example.MyModel { *; } > ``

If the flag is set but the rules file is absent or incomplete, the minifier may report “nothing to shrink” and the binary size remains unchanged. This silent no‑op is a common pitfall: the build succeeds, the CI passes, but the user’s download size is identical to the previous release.

Strip unused symbols from binaries

After minification, the next low‑effort win is removing symbols that aren’t needed at runtime. On iOS‑derived platforms, the strip utility removes debug and symbol table entries from the Mach‑O binary.

Exact command

strip -u build/Products/Release-iphoneos/App.app/App

The -u flag keeps local symbols while discarding global ones that aren’t referenced elsewhere. If the path is incorrect, strip exits with:

strip: build/Products/Release-iphoneos/App.app/App: No such file or directory

On Android, the equivalent is typically handled by the minifier or by running zipalign and enabling ndk.abiFilters to exclude unnecessary architectures, but the principle—removing what isn’t referenced—is the same.

Optimize Assets

Assets—images, audio, fonts—often constitute the largest portion of a mobile package. Standard command‑line compressors can shave bytes without altering content.

Raster images

pngcrush provides brute‑force lossless compression that iterates through many filter types and chunk arrangements to find the smallest valid PNG.

Exact command

pngcrush -brute source.png output.png

If the input file isn’t a valid PNG, pngcrush aborts with:

pngcrush: source.png is not a PNG file or is corrupted

The tool writes the compressed result to the specified output path, leaving the original untouched.

Audio

For compressed audio streams (M4A, AAC, MP3), ffmpeg can re‑encode at a lower bitrate. This is a lossy operation, so it should only be applied to assets where perceptual quality loss is acceptable (e.g., background music, long‑form narration).

Exact command

ffmpeg -i source.m4a -b:a 64k output.m4a

The -b:a 64k flag sets the audio bitrate to 64 kbps. If the source file doesn’t exist or ffmpeg can’t parse the codec, the command fails with:

ffmpeg: error while loading input 'source.m4a': Invalid data found when processing input

Adjust the bitrate flag to match the desired quality‑size trade‑off; the tool reports the new file size after encoding.

Vector and other assets

SVG files are already text‑based and typically smaller than raster equivalents. When an app bundles raster assets that could be replaced by vectors, the conversion step is a design‑time decision rather than a CLI transformation, but the general pattern is: source file → vector format → bundled asset. No vendor‑specific config keys are involved.

Enforce Size Limits in CI

Automating the size check prevents regressions from slipping into production. A small shell script can run the auditor, parse the output, and fail the job if the binary exceeds a project‑defined ceiling.

CI‑gate script

#!/usr/bin/env bash
set -euo pipefail

APK_PATH="build/outputs/apk/release/app-release.apk"
MAX_SIZE=$MAX_APP_SIZE_BYTES   # set by the pipeline environment

if [ ! -f "$APK_PATH" ]; then
  echo "❌ APK not found at $APK_PATH"
  exit 1
fi

SIZE=$(du -b "$APK_PATH" | cut -f1)

if [ "$SIZE" -gt "$MAX_SIZE" ]; then
  echo "❌ APK size $SIZE bytes exceeds limit $MAX_SIZE bytes"
  exit 1
fi

echo "✅ APK size $SIZE bytes is within the $MAX_SIZE byte limit"

The script uses only POSIX‑compatible tools (du, cut, bash) and reads a threshold from the environment—no vendor‑specific SDK calls. If the APK is missing, the early if guard prints a clear error and exits non‑zero, surfacing the problem before any size comparison runs.

Sharp Edges — What Silently Fails and What You Learn After It Breaks

Minifier flag set, rules incomplete

A common pattern: the minify flag is toggled to true in the build configuration, the CI job passes, yet the APK/IPA size is unchanged. The reason is usually that the rules file either doesn’t exist, contains patterns that match nothing, or is read from a path the minifier doesn’t scan. The symptom is a “no‑op” shrink—no error is emitted, no warning, just a binary that’s the same weight as before. The discovery comes when a teammate points out the unchanged du -sh output after a release branch is merged.

strip -u removes symbols needed by native extensions

Running strip -u on a binary that links against third‑party native libraries can strip symbols those libraries expect at runtime. The immediate effect is often a launch crash on devices running the new build, because the dynamic linker can’t resolve symbols it previously found in the symbol table. The failure mode is subtle: debug builds work, release builds crash, and the stack trace points to an unresolved symbol deep in the native library. The lesson is to keep a debug‑symbol copy (e.g., an .app.dSYM on iOS or a mapping.txt on Android) before stripping, and to validate on a staging device before pushing to production.

Asset compression introduces rendering glitches

pngcrush -brute and ffmpeg -b:a are lossless and lossy respectively, but edge cases exist. Aggressive PNG filtering can produce files that some Android versions render with incorrect gamma, resulting in visibly darker or washed‑out images. Similarly, lowering an audio bitrate below a perceptual threshold may introduce audible artifacts that only appear on low‑quality playback hardware. The silent failure is that the CI passes, the binary size shrinks, but QA flags visual or audio regressions during device testing. The remedy is to run the compressors on a representative sample of devices as part of the release verification step, not solely on the build machine.

Fat binaries exceed store size caps

Many projects build for all CPU architectures (arm64, armv7, x86_64, mips) by default, producing a “fat” binary that contains code for every supported instruction set. The Apple App Store rejects IPAs exceeding 2 GB, and Google Play rejects APKs over 100 MB (unless split via APK Expansion files). The size inflation is often not apparent until the upload step, because local du on a thin‑only machine underreports the final package. The discovery moment is the store rejection email: “Your binary size exceeds the limit.” The fix is to narrow ndk.abiFilters on Android or set valid archs on iOS, but this requires a rebuild and a re‑run of the size auditor—steps that are easy to omit in a rushed release cycle.

Bitcode inclusion adds a hidden segment

Enabling bitcode on iOS adds a bitcode segment to the final IPA, typically a few megabytes. Disabling it reduces size, but if downstream dependencies (e.g., static libraries) were compiled with bitcode enabled, the build may fail with linker errors unless those libraries are rebuilt without the flag. The size impact isn’t visible in the Xcode report until the bitcode segment is stripped, and the breakage only surfaces when the CI pipeline toggles the setting. The takeaway: bitcode is a configuration toggle with downstream build‑system repercussions; changing it requires a full dependency audit, not just a flag flip.

*This reference page is intended for the “mobile engineering” section of an engineering wiki. All commands and configuration patterns are drawn from shipping tools and well‑documented build‑system behaviours. Readers should map the generic patterns to their own platform’s terminology; the mechanics described here apply across Android, iOS, React Native, Flutter, and any other mobile build chain that exposes a command‑line interface for package inspection and transformation.*

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.