Comprehensive Guide to iOS App Size Reduction Using App Thinning, Build Optimizations, and Continuous Resource Compression

1. Introduction Reducing the size of iOS installation packages is a long‑standing concern; many resources exist, but few provide a complete, end‑to‑end solution. This article shares a full workflow derived from optimizing the "XiaoHou SiWei" iOS app (v1.0) and outlines future improvements.

Large app bundles affect installation and update rates, especially on cellular networks where packages over 150 MB cannot be downloaded (2019‑2020). Additionally, iOS 8 and earlier require the Mach‑O text segment to stay below 60 MB.

2. Overall Solution

Official solution: App Thinning and compilation optimizations.

Technical solution: Analyze the space occupied by each file inside the bundle and apply targeted optimizations.

Continuous assurance: Standards and toolchains to keep the bundle size under control as the app evolves.

The core of the article is a single diagram (shown below) that visualizes the entire slimming plan.

3. Official Solution

App Thinning (supported since iOS 9 SDK) reduces the installed size by delivering only the resources and architectures needed for the target device. It consists of:

Slicing: Split resources and binary slices per device variant.

Bitcode: Upload intermediate representation (IR) to App Store Connect, allowing Apple to re‑compile for new CPUs or LLVM versions.

On‑Demand Resources: Store large assets on Apple’s servers and download them only when needed.

Note: Even if a static library contains multiple architectures, Slicing automatically removes unused slices, so the final bundle size is not affected.

Compilation Optimizations The typical CocoaPods‑based build pipeline includes file packaging, pre‑script processing, .m compilation, linking, framework handling, xib compilation, resource copying, Asset Catalog compilation, info.plist processing, script execution, standard library copying, .app creation, and signing. By adjusting LLVM, ld, and Clang options you can further shrink the binary. Common flags include Generate Debug Symbols, Asset Catalog Compiler, Dead Code Stripping, Code Generation, Link‑Time Optimization, Swift Compiler settings, Symbol Stripping, and exception handling.

4. Technical Solution An analysis of the bundle’s internal composition reveals the following major file categories:

Mach‑O (executable code)

Resources (images, xibs, storyboards, etc.)

(SDK).framework (dynamic libraries)

(AppExtension).appex (extensions)

(Watch).app (watchOS companion app)

The table below maps each bundle file type to its counterpart in the project and suggests concrete reduction actions:

Package

Project

Mitigation

Mach‑O

Code / (StaticLibrary).a

1) Remove dead code 2) Reduce classes, categories, blocks, macros, inline functions

Resources

Resources

1) Slicing 2) Delete duplicate assets 3) Remove unused resources via subspecs 4) Convert PNG to WebP 5) Lazy‑load resources (local unzip, download, ORD) 6) Replace xib/storyboard with code where feasible

(SDK).framework

(SDK).framework

1) Delete unused frameworks 2) Prefer static libraries over dynamic ones 3) Limit supported architectures 4) Optimize embedded resources

(AppExtension).appex

Similar to main app

1) Optimize Mach‑O 2) Optimize Resources 3) Increase framework reuse

(Watch).app

Similar to main app

1) Optimize Mach‑O 2) Optimize Resources 3) Increase framework reuse

5. Continuous Assurance Beyond static guidelines, a cost‑effective, cross‑platform solution is to automate resource compression via a git‑hook combined with a compression script. By triggering the script in the pre‑commit phase, images are automatically compressed, a whitelist can be maintained for exceptions, and the process integrates seamlessly with existing CI pipelines.

6. Practice

Case study on the "XiaoHou SiWei" iOS app:

Before slimming (v1.0.0): 154.7 MB

After slimming (v1.1.0): 90 MB

Key takeaways:

The primary reduction came from resource‑level optimizations and the introduction of a git‑hook based image compression workflow.

Because the business logic is relatively simple, code‑related size gains were minimal (≈‑0.1 MB), highlighting the importance of analyzing the actual bottlenecks before applying generic tricks.

7. References

iOS Slimming – Common Techniques Overview

iOS App Installation Package Slimming Guide (https://www.cnblogs.com/jzy996492849/p/7737136.html)

Deep Dive into iOS Compilation – Clang & LLVM (https://github.com/ming1016/study/wiki/深入剖析-iOS-编译-Clang---LLVM)