iOS IPA Package Size Optimization: Practices, Settings, and Monitoring

The author was assigned a package‑size monitoring task and decided to document a complete workflow for optimizing iOS installation packages (IPA) to help peers.

An ipa file is simply an xxx.ipa archive; by renaming it to xxx.zip and extracting it, the full list of bundled resources becomes visible, including _CodeSignature , Assets.car , embedded.mobileprovision , Info.plist , Plugins , .Iproj , executable files ( exec ), image assets, and various other files such as .xml , .json , .plist , .bundle , .cer , .wav , .js , .nib , .sqlite , and .txt .

Before optimization the IPA was 76.5 MB (compressed) and 140.1 MB after extraction. A detailed size breakdown is shown in a table, highlighting that the executable ( exec ) accounts for the majority of the payload.

Optimization strategy follows three steps: Xcode compile settings, resource file optimization, and code optimization.

Xcode compile optimization includes:

Limiting architectures to arm64 only (removing armv7 ).

Setting the optimization level to -Oz for maximum size reduction.

Configuring the Asset Catalog Compiler to use the space algorithm, which reduces Assets.car size.

Disabling debug symbols generation ( Generate Debug Symbols = NO ) to avoid extra .o bloat.

Enabling Strip Linked Product and Strip Debug Symbols During Copy in Release builds.

Hiding symbols by default, making only explicitly exported symbols visible.

Marking strings as read‑only to enable literal reuse.

Turning on dead‑code stripping ( Dead Code Stripping = YES ).

Disabling exception handling when not needed ( -fno-exceptions ).

After applying these compile tweaks the IPA shrank to roughly 51 MB (compressed) and 90 MB uncompressed, with the executable dropping from 104.9 MB to about 56.6 MB.

Resource file optimization focuses on removing unused assets and compressing needed ones. The author recommends:

Regularly auditing code, business modules, and image usage.

Using tools like AppCode or Clang static analysis to find dead classes, methods, variables, and imports.

Employing LSUnusedResources to locate orphaned images.

Scanning for duplicate files with fdupes (MD5‑based).

Compressing small images (< 100 KB) with TinyPNG (or batch scripts) and larger ones with WebP via tools such as iSparta.

Placing frequently used small images in xcassets so that Xcode can generate device‑specific @2x/@3x assets and avoid bundling unnecessary resolutions.

Additional resource‑type tips include moving large JSON files to the backend, minifying HTML/JS, and using high‑efficiency audio codecs.

Monitoring mechanism involves a post‑build script that compares the current IPA size with a baseline; if the increase exceeds a defined threshold, an email alert is sent. All size changes and their causes are logged for future reference.

The article concludes that maintaining a small package size requires continuous vigilance, disciplined development processes, and regular size monitoring.