Как измерить и уменьшить размер iOS-приложения с помощью Xcode и App Store Connect

iOS-приложения обычно растут с каждым релизом: добавляются новые SDK, изображения в более высоком разрешении и офлайн-контент. Загрузка становится дольше, а на устройстве занято больше места. Оптимизацию начинают с измерений, потому что главный источник веса у всех приложений свой: у одних это ресурсы, у других скомпилированный код или встроенные зависимости. «Размер приложения» тоже нельзя свести к одному числу. Размер загрузки, размер установки и место, занятое после использования, пересекаются, но не заменяют друг друга. Поэтому в PR, бенчмарке или отчёте команде указывайте, какая метрика изменилась и где её измеряли. Если необязательный контент загружается позже, первоначальные загрузка и установка становятся меньше, но после скачивания этот контент всё равно оказывается на устройстве. Background Assets, в том числе обязательные пакеты и заранее загружаемый контент, могут прийти даже до первого запуска. Их нужно учитывать отдельно и сравнивать при одинаковом состоянии загрузки.

Пользователь видит эти цифры в двух местах. На странице приложения в App Store поле «Информация → Размер» показывает размер установки. Если приложение использует обязательные пакеты ресурсов на серверах Apple, там может стоять значение «До …» с учётом этого контента. В разделе «Хранилище iPhone» отдельно указаны размер приложения и «Документы и данные», которые копятся по мере загрузок и использования. Локальные файлы APP, XCARCHIVE и IPA помогают в диагностике, но не совпадают с тем, что доставляет App Store: в архивах бывают отладочные символы, а универсальный IPA несёт ресурсы для разных устройств. Чтобы оценить размер для конкретных устройств, экспортируйте Release-архив командой xcodebuild -exportArchive с параметрами -archivePath, -exportPath и -exportOptionsPlist. При ручной подписи в plist также нужны signingStyle=manual, teamID и сопоставление provisioningProfiles для каждого приложения или расширения.

В папке экспорта появится App Thinning Size Report.txt. В нём перечислены варианты с описанием устройства и ОС и значениями вроде «112 MB compressed, 260 MB uncompressed». Сжатый размер - это оценка загрузки, несжатый - оценка установки. Чтобы изучить бандл, выберите прорежённый IPA по описанию варианта, а не по имени файла: экспорт может содержать и универсальный IPA. Распакуйте его через ditto -x -k в новый каталог, созданный mktemp, и найдите.app в папке Payload. Для App Store и TestFlight прореживание работает в основном само, но его стоит проверить. Если ресурсы для отдельных устройств попадают во все варианты, проверьте настройки каталогов ресурсов и отдельные файлы. При сравнении не меняйте конфигурацию сборки, версию Xcode, способ подписи, способ экспорта и описание варианта, а потом повторите сравнение по обработанным значениям App Store Connect. Это тоже лишь оценки: Apple может добавить DRM и пережать файлы, а размеры в TestFlight могут отличаться от App Store.

Диагностику начинают с описи всего прорежённого бандла: главный исполняемый файл, Frameworks, PlugIns, каталоги ресурсов и отдельные ресурсы, локализации, медиа, базы данных и ML-модели. Команда find со stat, sort -n и tail -30 покажет самые крупные файлы, но это логические несжатые размеры, то есть лишь подсказка. Если важен бинарник, включите в Build Settings параметр Write Link Map File (LD_GENERATE_MAP_FILE), соберите проект и разберите.txt в DerivedData. Сгруппируйте размеры из раздела # Symbols по индексу файла, а индексы сопоставьте с разделом # Object files. Так видны тяжёлый сгенерированный код, статические библиотеки, шаблоны C++ и сторонние SDK. Суммы по символам показывают, кому принадлежит вес, но не дают полного счёта: заголовки, выравнивание, подписи и данные компоновщика туда не входят. Встраивание, оптимизация всего модуля и LTO размывают принадлежность кода. Символы, удалённые как мёртвый код, исключайте, а карту стройте для каждой цели сборки и архитектуры.

Порядок работы покажем на условном примере с выдуманными числами: меняем что-то одно, пересобираем и заново получаем отчёт для того же варианта. Приложение с большим количеством ресурсов весит 112 МБ в сжатом виде и 260 МБ в несжатом. Оценка уменьшается на 31 МБ (около 28%) и 58 МБ (около 22%), а App Store Connect показывает 80 МБ загрузки и 200 МБ установки. Экономия не переносится один к одному: вмешиваются компиляция, нарезка, сжатие, выравнивание и подпись. Обучение, перенесённое на удалённую доставку, откладывается, а не удаляется. После его загрузки занятое место снова растёт примерно на 32 МБ, и на диске могут одновременно лежать архив и распакованные файлы. Поэтому проверяйте работу без сети, повторные попытки, очистку и повторную загрузку, а дельта-обновления измеряйте отдельно.

Ресурсы часто весят больше кода. Встроенные изображения держите в.xcassets, чтобы прореживание подбирало ресурсы под каждое устройство. Число пикселей должно соответствовать размеру на экране: иконке 24 × 24 пункта нужно 48 × 48 пикселей для 2x и 72 × 72 для 3x, и уменьшать её надо до импорта. Универсальную графику используйте общую, варианты под устройства или цветовой охват добавляйте только при необходимости и не дублируйте наборы изображений. После переноса загружайте изображения по имени, например UIImage(named: "toolbar_search"), а оставшиеся отдельные копии уберите из Copy Bundle Resources. Результат подтвердите, сравнив отчёты для одного и того же варианта до и после. Для иконок лучше брать системные SF Symbols, если это позволяют дизайн и минимальная версия ОС.