Apple указывает, что App Thinning Size Report помогает оценить варианты приложения для устройств, а App Store Connect показывает более точные сведения о размере сборки и вариантов (измерение размера приложения в документации Apple, просмотр сборок в App Store Connect). Поэтому действуйте так: сначала экспортируйте сборку из Xcode 27 с отчётом, затем сверяйте вариант в App Store Connect. Размер Archive или загруженного IPA не считайте размером пользовательской загрузки.
Эта инструкция для независимых iOS-разработчиков, которые готовят новую версию и заметили рост приложения.
Она поможет командам с несколькими вариантами устройств или языков найти ресурсы, которые можно пересмотреть.
Если вы регулярно собираете приложение на удалённом Mac, здесь также описан способ сравнивать результаты без смешения настроек.
Сначала установите, какой именно размер вы измеряете
Слово «размер» в процессе сборки обозначает несколько разных вещей. Их смешение приводит к неверному диагнозу: разработчик видит крупный локальный файл, удаляет материалы, а пользовательский вариант почти не меняется. Или, наоборот, принимает небольшой IPA за доказательство того, что все варианты для устройств компактны.
Archive — результат архивирования проекта. Это контейнер для дальнейшей проверки и экспорта. Его размер зависит от содержимого архива и не равен размеру того, что загрузит пользователь.
IPA — экспортированный файл приложения. Он нужен для передачи, тестирования или загрузки в зависимости от выбранного способа экспорта. В него могут входить данные, которые не попадут в конкретный вариант приложения для конкретного устройства.
Размер варианта для устройства — оценка или значение для набора ресурсов и бинарных компонентов, предназначенных для соответствующего устройства. App Thinning может исключить часть ресурсов, не подходящих этому устройству. Поэтому два устройства могут получить разные варианты одной сборки. Механизм каталогов ресурсов, включая варианты изображений, описан в документации Apple по Asset Catalog.
Размер установки и занятое хранилище тоже не стоит подменять размером загрузки. Загруженный пакет, установленное приложение и данные, которые оно создаёт при работе, — разные объекты. На пользовательское хранилище могут влиять кэш, загруженный контент и документы приложения. Если ваша проблема — нехватка места на Mac, а не размер приложения у пользователей, это отдельная задача: проверьте подход к дисковому пространству сборочного сервера.
Для диагностики записывайте показатель вместе с источником. Например: «размер IPA в экспортированной папке», «вариант для указанного устройства в отчёте» или «размер, показанный в App Store Connect». Так вы не сравните файл передачи с пользовательским вариантом и не примете установочные данные за скачивание.
02Первый этап: получите отчёт для той же сборки, которую проверяете
App Thinning Size Report полезен только тогда, когда соответствует проекту, схеме и параметрам экспорта, которые вы собираетесь выпускать. Сравнение отчётов от разных конфигураций даст ложный сигнал: изменение могло появиться из-за настроек, а не из-за нового ресурса или кода.
Действуйте последовательно:
- Проверьте, что выбраны нужные проект, схема и конфигурация. Убедитесь, что версия проекта соответствует кандидату на публикацию.
- Выполните Archive для этой конфигурации. Если сборка завершилась с предупреждениями или ошибками, сначала разберитесь с ними: отчёт не исправляет неверную конфигурацию.
- Экспортируйте архив способом, предназначенным для распространения через App Store Connect. Не сравнивайте экспорт для одного сценария с отчётом, полученным из другого.
- В параметрах экспорта включите генерацию App Thinning Size Report, если соответствующая опция доступна для выбранного процесса. Apple описывает измерение и получение отчёта в руководстве по уменьшению размера приложения.
- Сохраните сам отчёт рядом с экспортированным IPA и зафиксируйте идентификатор версии проекта, выбранную схему и ключевые параметры экспорта.
- Откройте отчёт и выпишите размеры для универсального результата и доступных вариантов устройств. Не делайте вывод по одной строке, если приложение поддерживает разные устройства.
- После загрузки сборки дождитесь обработки и сравните результат с данными App Store Connect.
Не исправляйте размер, пока не зафиксировали исходную точку. Если вы сразу измените изображения, настройки сжатия и состав фреймворков, а затем повторно экспортируете проект с другими параметрами, станет неясно, какое действие повлияло на итог.
03Ресурсы: ищите повторения и материалы, которые не нужны при первой установке
Изображения, видео, аудио, локализации и другие ресурсы часто заметны в файловой структуре, но их наличие само по себе не доказывает, что именно они раздули пользовательский вариант. Сначала сопоставьте содержимое проекта с отчётом, затем выберите конкретный класс данных для проверки.
Начните с ресурсов, которые дублируются по каталогам или языкам. Проверьте, не лежат ли в проекте одновременно старые и новые версии одного изображения, не попадают ли в сборку демонстрационные видео и не включены ли материалы, которые больше не используются. В каталогах ресурсов учитывайте, что разные варианты могут предназначаться для разных характеристик устройства. Удалять их без проверки нельзя: вы можете убрать ресурс, который нужен поддерживаемой группе устройств.
Затем проверьте медиафайлы. Сравните исходники с тем, что действительно включается в продукт: разрешение, длительность, формат и сценарий воспроизведения. Если контент загружается только в отдельных разделах приложения, оцените, должен ли он поставляться при первой установке или может быть получен позднее. Apple описывает базовые варианты оптимизации в рекомендациях по уменьшению размера приложения, а более сложные подходы, включая работу с контентом по запросу, — в материале о расширенной оптимизации.
Для каждой идеи ответьте на три вопроса: действительно ли ресурс входит в проблемный вариант; можно ли изменить его без ухудшения качества или функциональности; когда он должен быть доступен пользователю. Например, удаление неиспользуемого демонстрационного видео обычно безопаснее, чем снижение качества всех изображений без проверки экранов. Перенос контента на последующую загрузку может помочь, если он не нужен при первом запуске, но потребует обработки сетевого состояния, ожидания и повторной загрузки.
Не выбирайте один метод только потому, что он сработал в другом проекте. Оптимизация изображений бессмысленна, если отчёт указывает на крупные фреймворки. Разбиение контента на загрузки не поможет пользователям, которым нужный материал необходим сразу. После одного изменения снова экспортируйте сборку и сравните тот же показатель для тех же условий.
04Бинарные файлы и настройки сборки: отделите доставляемое от диагностического
Когда ресурсы не объясняют рост, переходите к исполняемым файлам и встроенным фреймворкам. Сверьте содержимое экспортированного приложения с результатами отчёта. Ищите крупные компоненты, которые появились после добавления зависимости, нового модуля или изменения способа интеграции.
Проверьте, какие фреймворки действительно нужны приложению и попадают ли они в конечный продукт. Размер самой зависимости в исходном проекте не всегда показывает её вклад в вариант для пользователя. Важен экспортированный продукт и то, какие компоненты в нём остаются после сборки и обработки.
Отдельно проверьте символы отладки. dSYM используется для диагностики и символикации, но наличие таких файлов рядом с Archive не означает, что они входят в пользовательскую загрузку. Не удаляйте диагностические материалы только из-за того, что они делают архивную папку большой. Сначала убедитесь, что сравниваете каталог диагностических символов с составом экспортированного приложения, а не с размером варианта.
Если предполагаете, что дело в оптимизации компилятора, проверьте итоговое значение настроек для нужного Target и конфигурации. Значение по умолчанию в одном месте проекта не гарантирует, что оно действует для всех целей сборки. Apple описывает доступные параметры в справочнике настроек сборки и объясняет, как проверить фактические настройки Target в руководстве по конфигурации Build Settings.
Сначала зафиксируйте текущее значение и только потом меняйте его. Изменение настроек оптимизации может повлиять не только на размер, но и на поведение сборки и диагностику. После правки проверьте приложение на тестовом сценарии, затем соберите и экспортируйте его заново. Не приписывайте уменьшение размера одной настройке, если одновременно менялись зависимости, ресурсы и конфигурация.
05Варианты устройств: сравнивайте не только универсальный пакет
App Thinning влияет на то, какой набор ресурсов и бинарных компонентов предназначен для разных устройств. Поэтому универсальный результат не всегда отражает размер, который увидит конкретная категория пользователей. В отчёте найдите доступные варианты и сопоставьте их с реальными устройствами, которые поддерживает приложение.
Проверьте, есть ли значительное различие между универсальным результатом и конкретными вариантами. Если оно есть, выясните, какие ресурсы исключаются или остаются для соответствующего устройства. Затем сравните эти сведения с каталогами ресурсов, поддерживаемыми архитектурами и встроенными компонентами. Не делайте вывод «всем скачивается именно столько» по одному значению на локальном компьютере.
Данные отчёта — этап диагностики, а не окончательное подтверждение пользовательского результата. После загрузки сборки откройте её в App Store Connect и найдите сведения о размере и вариантах в описании сборки. Apple поясняет расположение этих данных в инструкции просмотра сборок и метаданных. Именно там следует перепроверить версию, которую вы намерены выпустить.
Если значения в отчёте и App Store Connect отличаются, проверьте, что речь идёт об одной сборке и одном и том же типе размера. Убедитесь, что не сравниваете IPA с вариантом устройства, не сопоставляете разные версии и не проверяете необработанную сборку вместо обработанной. При необходимости повторите экспорт с сохранёнными настройками и загрузите тот же артефакт.
06Загрузка через сотовую сеть: проверяйте применимое ограничение, а не догадку
Предупреждение о размере не всегда означает, что все пользователи не смогут установить приложение. Ограничения загрузки зависят от правил и настроек, применимых к устройству и способу подключения. Поэтому сначала проверьте формулировку предупреждения и актуальную документацию Apple, а не переносите старое числовое значение на любую версию iOS и любого пользователя.
Apple отдельно публикует требования к размеру загружаемых сборок в справке об ограничениях файлов сборок. Эти максимумы для загрузки сборки в App Store Connect нельзя путать с ограничениями пользовательской загрузки через сотовую сеть: это разные этапы и разные критерии.
Проверяйте сначала размер варианта в App Store Connect, затем условия, о которых сообщает Apple для пользовательской загрузки. Если вариант превышает порог, который важен для вашей аудитории, выясните, есть ли реально крупный ресурс, не обязательный при первом запуске. Если данных недостаточно, не удаляйте содержимое на основании одного уведомления: подтвердите проблему на целевой версии приложения и только затем меняйте способ доставки.
Условия выбора следующего действия
- Если вырос только размер Archive, а размер экспортированного приложения и вариантов не изменился, проверьте состав архива и диагностические файлы. Не удаляйте пользовательские ресурсы без подтверждения.
- Если вырос IPA, но значения вариантов в отчёте стабильны, проверьте способ экспорта и дополнительные файлы. Не называйте IPA пользовательским размером загрузки.
- Если отчёт показывает рост конкретного варианта, исследуйте ресурсы и бинарные компоненты, которые входят именно в него.
- Если отчёт стабилен, но App Store Connect показывает изменение после обработки сборки, сверяйте версию, вариант и тип размера. Не выпускайте вывод по локальному файлу вместо серверных сведений.
- Если размер вырос за счёт контента, который не нужен при первом запуске, оцените последующую загрузку. Если ресурс нужен сразу или перенос ухудшит работу приложения, сохраните его и рассмотрите другие источники роста.
- Если ни отчёт, ни App Store Connect не подтверждают превышение значимого для вашей аудитории порога, зафиксируйте результат и не применяйте оптимизацию ради уменьшения числа.
Повторная проверка: сделайте сравнение воспроизводимым
Для небольшого проекта достаточно хранить отчёт рядом с записью о выпуске и фиксировать, какие параметры использовались. Для команды, которая часто выпускает обновления, важнее не просто собирать цифры, а сохранять сопоставимость. Иначе изменение метрики может означать переход на другую схему экспорта, а не рост приложения.
Выберите одинаковый процесс для всех проверок: один и тот же способ Archive, одинаковый сценарий экспорта и отчёт для тех же поддерживаемых вариантов устройств. Сохраняйте отчёт, сведения о версии исходников и краткую заметку о важных изменениях ресурсов или зависимостей. При следующей сборке сравните показатели по каждому варианту, а не только общий размер.
Не задавайте автоматическое правило вроде «любое увеличение блокирует выпуск», если проект не определил допустимый предел и важность конкретного варианта. Небольшое увеличение может быть оправдано новой функцией, тогда как крупный рост одного варианта из-за случайно включённого медиафайла может потребовать исправления. Решение должно учитывать пользу изменения, состав приложения и аудиторию.
| Что сравнивать | Где брать данные | Какое решение принять |
|---|---|---|
| Размер Archive | Локальный архив Xcode | Использовать для проверки артефакта, но не как пользовательский размер |
| Размер экспортированного IPA | Каталог экспорта | Проверить способ экспорта и состав файла; не приравнивать к загрузке |
| Размер варианта устройства | App Thinning Size Report | Найти ресурсы или бинарные компоненты, влияющие на этот вариант |
| Обработанные данные сборки | App Store Connect | Подтвердить показатели для загруженной версии и вариантов |
| Занятое место после установки | Устройство и данные приложения | Отдельно оценивать установочный пакет и содержимое, созданное приложением |
Для повторных Archive и экспорта на удалённом Mac сохраняйте ту же дисциплину: одна и та же версия исходников, один процесс сборки и сохранённые отчёты. Удалённая среда не меняет логику измерения, но позволяет держать отдельное рабочее место для выпуска, не занимая локальный Mac постоянными архивами и зависимостями. Если такой сценарий вам подходит, изучите варианты удалённой Mac-среды VpsMesh и порядок оформления удалённого Mac.
Перед выпуском сверьте данные ещё раз:
| Проверка перед публикацией | Готово, если… | Если не готово |
|---|---|---|
| Условия сравнения | Версия проекта, схема и способ экспорта зафиксированы | Повторите Archive и экспорт с согласованными параметрами |
| Отчёт | Есть значения для нужных вариантов | Сформируйте отчёт из подходящего экспорта |
| Ресурсы и бинарные компоненты | Рост связан с конкретным содержимым или объяснён функцией | Сравните состав экспорта с предыдущей версией |
| App Store Connect | Проверена именно загруженная сборка | Дождитесь обработки и откройте сведения о нужной версии |
| Решение о выпуске | Вы понимаете влияние на целевую аудиторию | Сначала подтвердите тип размера и применимое ограничение |
Частые вопросы
Размер IPA совпадает с размером загрузки из App Store?
Нет. IPA — экспортированный файл для передачи или публикации, а не точная копия варианта для каждого устройства. App Thinning Size Report показывает сведения о вариантах, а App Store Connect позволяет перепроверить обработанную сборку. Поэтому сравнивайте одинаковые типы показателей: Archive с Archive, IPA с IPA, вариант устройства с соответствующими данными App Store Connect.
Как получить App Thinning Size Report в Xcode 27?
Сначала заархивируйте правильную схему и конфигурацию проекта. Затем экспортируйте сборку для распространения через App Store Connect и включите отчёт, если соответствующая опция доступна для этого процесса. Сохраните отчёт вместе с экспортом и настройками сборки. Если сравниваете две версии, повторите тот же процесс для обеих.
Где найти размер вариантов устройства в App Store Connect?
Откройте сведения о загруженной сборке и найдите данные о размере приложения и вариантах. Проверяйте именно ту сборку, которую собираетесь распространять: локальный отчёт помогает диагностировать состав, но серверные данные относятся к обработанной загрузке. Если сведения пока не появились, дождитесь обработки и не заменяйте их оценкой по размеру архива.
Что делать при предупреждении о загрузке через сотовую сеть?
Сначала установите, какой вариант и какой размер показываются для приложения, затем проверьте применимые ограничения в документации Apple для пользовательской загрузки. Не переносите требования к максимальному размеру файла сборки в App Store Connect на сотовую загрузку пользователя. Если ограничение затрагивает вашу аудиторию, найдите в отчёте ресурсы, которые можно доставлять отдельно, не ухудшая первый запуск.
Для проверки размера не нужен собственный универсальный порог: нужны сопоставимые отчёты и подтверждение в App Store Connect. Если сейчас вы собираете приложение на личном Mac, это избавляет от аренды, но архивы занимают его диск, среду приходится обслуживать, а повторяемый выпуск требует держать машину доступной. Покупка отдельного Mac решает вопрос выделенного оборудования, но добавляет расходы на приобретение и обслуживание. Если же вам нужно периодически архивировать и проверять сборки без покупки отдельной машины, удалённый Mac от VpsMesh может быть удобнее для такой задачи. При долгой непрерывной нагрузке или необходимости в физических интерфейсах разумнее оценить собственное оборудование; для временной проверки размеров и выпусков рассмотрите удалённую среду.