Бинарник приложения 180 МБ — от чего он большой, как измерить это и что реально его режет?
Размер вашего приложения в App Store ~180 МБ. Ниже разбивка размера из отчёта App Store Connect и размеры секций на диске. Объясните, от чего iOS-бинарник большой, как вы это измерили и что реально его режет.
Category Size
Asset catalog (images) 96 MB
Executable __TEXT 41 MB
Frameworks (embedded) 28 MB
On-demand resources 9 MB
Other 6 MBОбъясните, что вы бы урезали и как.
Размер идёт в основном от ассетов, исполняемого __TEXT и встроенных фреймворков. Мерьте по отчёту размера App Store Connect и linkmap, а не по сжатому .ipa. Здесь 96 МБ — картинки, так что сжимайте ассеты и берите on-demand resources, затем dead-strip кода.
- ✗Думают, что размер задают строки исходника, а не ассеты и фреймворки
- ✗Мерят сжатый .ipa вместо отчёта размера в App Store Connect
- ✗Добавляют динамические фреймворки или bitcode, ожидая уменьшения
- →Почему размер загрузки в App Store отличается от
.ipaна диске? - →Как dead-code stripping решает, какие символы удалить?
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.
