An app binary is 180 MB — what makes it big, how do you measure it, and what cuts it?
Your app's App Store size is ~180 MB. Below is the size breakdown from the App Store Connect report and the on-disk section sizes. Explain what makes an iOS binary big, how you measured this, and what actually cuts it.
Category Size
Asset catalog (images) 96 MB
Executable __TEXT 41 MB
Frameworks (embedded) 28 MB
On-demand resources 9 MB
Other 6 MBExplain what you would cut, and how.
Size comes mainly from assets, the executable __TEXT, and embedded frameworks. Measure from the App Store Connect size report and the linkmap, not the compressed .ipa on disk. Here 96 MB is images, so compress assets and use on-demand resources, then dead-strip code.
- ✗Thinking source lines, not assets and frameworks, drive binary size
- ✗Measuring the compressed .ipa instead of the App Store size report
- ✗Adding dynamic frameworks or bitcode expecting them to shrink the app
- →Why is the App Store download size different from the
.ipaon disk? - →How does dead-code stripping decide which symbols to remove?
The three big contributors, in order for this app: the asset catalog (96 MB of images), the executable __TEXT (41 MB of code), and embedded dynamic frameworks (28 MB, often with duplicated symbols). You measure the real number from the App Store Connect App Size report (the thinned, per-device download + install size) and the linkmap for the executable — never the .ipa in Finder, which is a compressed archive and understates the installed footprint.
Biggest win first:
96 MB images → HEIC/compressed asset catalogs + on-demand resources (largest lever)
41 MB __TEXT → dead-code stripping, -Osize, remove unused generics/deps
28 MB frameworks → static linking to merge/dead-strip, drop unused SPM packagesAssets dominate here, so start there; then dead-strip code and reconsider linkage. Static linking lets the linker strip unreferenced symbols that a dynamic framework must keep, cutting duplication.
