How to Shrink Your iOS App by 31%: Practical Thinning & Optimization Guide

1. Why App Size Matters

Google’s analysis shows that every 6 MB increase in an app’s package reduces download conversion by about 1 %. In the App Store, packages over 200 MB require user permission for cellular download, further hurting conversion. Therefore, reducing package size is essential for user experience and acquisition.

2. Composition of an iOS App Package

An IPA contains a .app bundle that includes the binary, extensions, embedded frameworks, and a large amount of resource files (images, videos, etc.). The diagram below (originally in the source) illustrates these components.

3. Apple’s App Thinning Solutions

3.1 App Slicing

Before slicing, a single universal package contained resources for all device configurations, inflating size. App Slicing creates device‑specific variants that include only the assets needed for a given screen resolution or CPU architecture.

3.2 Bitcode

Bitcode stores LLVM intermediate representation instead of a final binary. Apple recompiles the code for each target architecture on the App Store side, eliminating the need to ship binaries for unused architectures.

Enable Bitcode in Xcode: Build Settings → Enable Bitcode → YES.

3.3 On‑Demand Resources (ODR)

ODR keeps rarely used assets on Apple’s servers and downloads them only when needed, dramatically shrinking the initial download.

Resources are tagged as Initial install, Prefetch, or Download on demand to control when they are fetched.

4. Binary Optimization

4.1 Compiler Flags

Adjust the Xcode Optimization Level to balance size and speed. Common settings:

O0 – No optimization (default for Debug).

O1 – Small size and speed gains.

O2 – More aggressive size‑saving options.

O3 – Enables inlining and register renaming.

Os – Optimizes for size while preserving reasonable speed (recommended for release).

Ofast – Maximizes speed, may increase size.

For Swift, use -Osize together with Whole Module compilation to achieve 5‑30 % binary size reduction.

4.2 Dead Code Stripping

Enable Dead Code Stripping for C/C++/Swift to remove unreachable code at link time. It does not affect Objective‑C because of its dynamic nature.

4.3 Third‑Party Library Management

Common causes of bloat include unused libraries, large libraries for tiny features, and lack of modular imports. Mitigation strategies:

Audit and remove unused dependencies.

Import only required sub‑modules.

Replace internal frameworks with asset catalogs to benefit from slicing.

Periodically review and update third‑party versions.

5. Resource Optimization

5.1 Unused Resource Cleanup

Tools such as LSUnusedResources can detect orphaned image assets. In Yanxuan’s workflow, a custom command‑line tool “FengNiao” was adapted to fit the project’s naming conventions and integrated into the build script.

5.2 Asset Compression

PNG assets are compressed with tools like pngcrush or TinyPNG. JPEGs are processed with ImageOptim. Switching to WebP for both remote and local images further reduces size.

6. Yanxuan App Thinning Practice

By applying the above techniques, Yanxuan reduced its iOS package from 210 MB to 144 MB (31 % reduction, 67 MB saved). Specific gains include:

41 MB saved by removing the legacy Weex SDK.

19 MB saved by asset catalog migration and compression.

~5 MB removed by deleting obsolete promotional images.

~2 MB saved by prefetching H5 resources.

7. Future Directions

7.1 CI/CD Automation

A closed‑loop CI/CD pipeline now runs static analysis for unused code, duplicate code detection, unused‑resource scanning, and package‑size threshold alerts, ensuring continuous size control.

7.2 Deeper App Thinning Exploration

Future work includes full Bitcode adoption, broader use of On‑Demand Resources for seasonal promotional assets, and further migration of local images to WebP.