Mobile Development 22 min read

How We Cut a 420 MB iOS App to 330 MB: Real‑World Package Size Optimization

This article details the systematic analysis and practical techniques—resource cleaning, Asset Catalog migration, compression, cloud migration, unused‑code removal, library trimming, and compiler flags—that reduced the Cloud Music iOS client’s install size by 87 MB and download size by 65 MB, while establishing safeguards against future bloat.

NetEase Cloud Music Tech Team
NetEase Cloud Music Tech Team
NetEase Cloud Music Tech Team
How We Cut a 420 MB iOS App to 330 MB: Real‑World Package Size Optimization

Background

The Cloud Music iOS client, originally released in 2013, grew to a platform‑scale application with an App Store install size exceeding 420 MB. Reducing the install size was chosen as the primary optimization goal because it is the metric most visible to users.

Package Size Metrics

Apple reports three size metrics:

Original IPA size (unpacked app size)

Download size (shown during download)

Install size (shown on the App Store detail page)

Install size was used as the target metric.

Initial Analysis

Static analysis showed resources accounted for >50 % of the package and the binary for ~25 %. Optimization therefore focused on both resources and code.

Resource Optimizations

Resource Cleaning

Static reference checks (e.g., ImageName usage) identified unused images, configuration files, audio and video assets. Over 1,200 files were removed, saving ~12 MB.

Asset Catalog Migration

Legacy resources were migrated to .xcassets. Asset catalogs compress images losslessly and combine them into a single Assets.car file, which benefits App Thinning. The compiled catalog can be inspected with:

xcrun --sdk iphoneos assetutil --info Assets.car

ImageSet resources receive lossless compression and are packed into texture atlases; DataSet resources remain uncompressed. Small images (<5 KB) and multi‑scale assets gain the most benefit.

Resource Compression

Lossy compression was applied to the remaining images:

pngquant (≈80 % quality) for PNGs

tinypng for additional PNG optimization

Webpmux for splitting and recompressing large WebP animations

A unified script processed all image types, achieving a 42 MB reduction.

Cloud Migration of Large Assets

Assets larger than 50 KB were classified as “large resources”. Over 100 such assets were moved to a CDN, saving ~31 MB while preserving user experience through design guidelines.

Resource Merging

Deduplication of similar images and merging of Asset Catalogs yielded little benefit because the project already used centralized resource management.

Binary Optimizations

Unused Code Detection

Dynamic runtime data and static analysis identified thousands of unused Objective‑C classes. A custom snippet reads the isInitialized flag from class metadata to determine usage:

struct objc_class : objc_object {
    bool isInitialized() {
        return getMeta()->data()->flags & RW_INITIALIZED;
    }
}

Using this information, 1,200 classes were reviewed, 300 were safely removed, saving ~2 MB.

Third‑Party Library Removal

Clustering of unused classes revealed several third‑party libraries that could be dropped, contributing an additional ~4 MB reduction.

Dynamic Library Dependency Trimming

Duplicate OpenSSL symbols existed in the main binary and two dynamic frameworks. Converting the dynamic frameworks to static libraries and linking a single copy eliminated the duplication, saving ~3 MB.

Compilation Flag Optimizations

Asset Catalog Compiler Optimization : Enabled for all targets, saving 2.1 MB.

EXPORTED_SYMBOLS_FILE : Provided an empty symbol list (except __mh_execute_header for Firebase), saving 2.4 MB.

Link‑Time Optimization (LTO) : Enabled cross‑module dead‑code elimination, saving 1 MB.

GCC_OPTIMIZATION_LEVEL : Tested -Oz for aggressive size reduction; potential ~10 MB gain (not yet deployed).

Additional flags: disabled Objective‑C and C++ exceptions, limited architectures, enabled dead‑code stripping, set symbols hidden by default, made strings read‑only, and applied post‑processing settings.

Binary Summary

Other techniques such as DRM‑bypass renaming, binary segment compression, and property dynamicization were evaluated but not adopted due to limited ROI or platform restrictions.

Degradation Prevention

Automated gates and checks were introduced to prevent post‑optimization bloat:

Large‑resource gate blocks commits adding assets >50 KB.

Third‑party library gate flags new or upgraded dependencies.

Automatic compression pipeline for newly added resources.

Periodic full‑app scans for resource and code waste.

Collaboration with UI/UX to define on‑device vs. cloud asset usage rules.

Results

After applying the above optimizations, install size dropped from >420 MB to ~330 MB (‑87 MB) and download size fell by 65 MB, bringing the package under Apple’s OTA limit of 200 MB and improving perceived performance.

References

What is App Thinning? – Apple Documentation

Asset Catalog Format Reference – Apple

pngquant – https://pngquant.org/

Webpmux – https://developers.google.com/speed/webp/docs/webpmux

Code Size Performance Guidelines – Apple

Exported Symbols for Package Size – Jianshu article

LLVM Link‑Time Optimization – https://llvm.org/docs/LinkTimeOptimization.html

Reducing Code Size Using Outlining – MNT.io

Interprocedural MIR‑level outlining pass – LLVM dev mailing list

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Mobile DevelopmentiOSResource Compressionapp size optimizationbinary reductionpackage thinning
NetEase Cloud Music Tech Team
Written by

NetEase Cloud Music Tech Team

Official account of NetEase Cloud Music Tech Team

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.