App Thinning — что это, из каких компонентов состоит и как работает

Что такое App Thinning

App Thinning — это комплексная технология оптимизации дистрибуции iOS-приложений, внедрённая Apple вместе с iOS 9 (сентябрь 2015). Цель App Thinning — минимизировать размер приложения, которое пользователь загружает на своё устройство, без изменения исходного кода и функциональности. Технология работает на трёх уровнях: на этапе сборки (компиляция), на стороне App Store (доставка) и на устройстве (управление ресурсами).

До появления App Thinning разработчики включали в бинарный файл ресурсы для всех возможных устройств — изображения @2x и @3x, 32-битный и 64-битный код, Metal-шейдеры для разных GPU. Это приводило к раздуванию размера приложения: пользователь iPhone 6 Plus с Retina HD дисплеем получал векторные ресурсы для iPad Pro, которые никогда не использовались. Apple решила эту проблему, перенеся часть работы по сборке на серверы App Store.

Согласно исследованиям Apple (WWDC 2015, Session 412), типовое приложение с поддержкой нескольких архитектур и разрешений может уменьшиться на 30-50% после применения App Thinning. Для игр с большим количеством высокодетализированных текстур выигрыш может достигать 70-80%. Apple продолжает улучшать технологию: в iOS 17 добавлена оптимизация для ARM64e и улучшена работа с On-Demand Resources для приложений, использующих Swift Package Manager.

Проблема, которую решает App Thinning

Размер мобильных приложений постоянно растёт. По данным Sensor Tower (2025), средний размер iOS-приложения вырос на 45% за последние 5 лет. Для пользователей с ограниченным тарифным планом или медленным интернетом каждый мегабайт имеет значение. App Thinning решает эту проблему без участия разработчика — достаточно включить поддержку в настройках проекта и загрузить билд в App Store Connect.

Как работает App Thinning

Процесс App Thinning начинается после загрузки архива приложения в App Store Connect. App Store анализирует бинарный файл и разбивает его на сегменты по архитектурам (armv7, arm64, arm64e), разрешениям экранов (iPhone, iPad) и версиям iOS. Для каждой комбинации создаётся отдельный вариант (variant). Когда пользователь нажимает "Загрузить", App Store определяет модель устройства, версию iOS и тип подключения (Wi-Fi / мобильная сеть) и отправляет только соответствующий вариант.

Для пользователя процесс прозрачен — нет выбора "лёгкой версии" или диалога с настройками. App Store автоматически выбирает наиболее подходящий вариант на основе метаданных устройства, которые передаются серверу при запросе загрузки. Если устройство использует Wi-Fi, App Store может отправить вариант с ресурсами более высокого качества (например, ProRes-видео для iPhone 16 Pro). При загрузке по мобильной сети используется минимально возможный набор.

Второй уровень оптимизации — Bitcode. При включённой опции ENABLE_BITCODE Xcode компилирует приложение не в машинный код, а в промежуточное LLVM-представление. App Store перекомпилирует Bitcode под конкретную архитектуру процессора пользователя, что позволяет Apple применять оптимизации компилятора для новых поколений чипов (A17, M4) без обновления приложения разработчиком. Bitcode обязателен для watchOS и tvOS, но опционален для iOS.

Компоненты App Thinning: Slicing, Bitcode, ODR

App Thinning состоит из трёх независимых механизмов, каждый из которых отвечает за свой аспект оптимизации. Slicing (нарезка) разделяет бинарный файл на варианты по архитектуре и разрешению экрана. Разработчик настраивает Slicing через Asset Catalogs — Xcode автоматически включает в срез только те ресурсы, которые соответствуют целевому устройству. Например, iPhone SE (третий поколения) получит только @2x-изображения и arm64-код, а iPad Pro M4 — @3x-изображения и arm64e-код.

Bitcode — это LLVM IR (Intermediate Representation) — машинно-независимое представление программы. При включении Bitcode Xcode не генерирует окончательный машинный код, а сохраняет промежуточное представление. App Store Connect при загрузке билда получает Bitcode и перекомпилирует его под архитектуры всех поддерживаемых устройств. Bitcode позволяет Apple применять оптимизации, недоступные на этапе компиляции у разработчика — например, использование новых инструкций процессора (SME, SVE) на чипах M4.

On-Demand Resources (ODR) — третий механизм, который позволяет выгружать ресурсы приложения после их использования. Разработчик маркирует ресурсы (уровни игры, изображения для onboarding, видео) тегами ODR. iOS загружает помеченные ресурсы по требованию на фоне и выгружает их при нехватке памяти или после использования. ODR особенно эффективны для игр с большим количеством контента — первые уровни можно поставлять в составе приложения, а остальные загружать по мере прохождения.

Когда выбирать каждый компонент

Выбор механизмов App Thinning зависит от типа приложения и его целевой аудитории. Slicing рекомендуется включать всегда — он не требует дополнительных действий разработчика кроме правильной организации Asset Catalogs и даёт стабильное уменьшение размера на 20-30%. Bitcode стоит включать, если приложение использует кастомные Metal-шейдеры или планирует поддерживать новые архитектуры Apple без пересборки. ODR оправдан для приложений с большим объёмом контента — игры, фоторедакторы, приложения для стриминга.

Для типового бизнес-приложения (ленты данных, формы, REST API) достаточно Slicing и минимальной настройки ODR для изображений onboarding. Игры с 3D-графикой выигрывают от всех трёх механизмов: Slicing удаляет лишние шейдеры, Bitcode оптимизирует рендеринг под GPU, а ODR выгружает завершённые уровни. По данным Apple (WWDC 2024), комбинация всех трёх механизмов сокращает начальный размер установки в среднем на 45-55% по сравнению с универсальным бинарником.

Настройка App Thinning в Xcode

Для включения App Thinning в проекте Xcode необходимо выполнить несколько шагов. Slicing настраивается через App Thinning в настройках сборки: Build Settings → App Thinning. Доступны три значения: None (без оптимизации), Automatic (автоматическая настройка по умолчанию) и Manual с выбором конкретных вариантов для тестирования. Apple рекомендует Automatic для большинства проектов.

Для Asset Catalogs важно правильно организовать ресурсы: изображения размещаются в универсальном каталоге с указанием ширины/высоты, а Xcode автоматически создаёт @1x, @2x и @3x варианты. Xcode при сборке включает только те разрешения, которые используются в проекте. Metal-шейдеры компилируются отдельно для каждого GPU-семейства — Apple GPU, PowerVR, Mali, что также управляется через Asset Catalogs.

Bitcode включается флагом ENABLE_BITCODE = YES в Build Settings. Для iOS этот флаг опционален (по умолчанию выключен с Xcode 14), но для watchOS и tvOS обязателен. При включении Bitcode в проекте, использующем сторонние библиотеки, все они также должны быть собраны с Bitcode, иначе сборка завершится ошибкой. Bitcode увеличивает время компиляции на 20-30%, но даёт полную совместимость с будущими архитектурами.

Проверка результатов App Thinning

После загрузки в App Store Connect можно проверить размеры срезов в разделе Activity → Build Metric. App Store Connect отображает Estimated App Store Size для разных устройств. Для локальной проверки Xcode предоставляет команду xcodebuild с флагом -exportArchive и опцией thinning для создания срезов на локальной машине. Результат Slicing можно увидеть в Organizer (Window → Organizer) после архивации — вкладка App Thinning Profiles показывает размеры для разных устройств.

# Локальная проверка Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild с флагом -thinning создаёт .app-файлы для каждой комбинации архитектуры, разрядности и GPU. Параметр <thin-for-all-variants> создаёт все возможные варианты — полезно для проверки. Для CI-пайплайнов используется определить конкретную комбинацию, например iPhone14,4 (iPhone SE 3). Результирующие .app-файлы можно проанализировать утилитой app-size.

Преимущества и влияние App Thinning

Главное преимущество App Thinning — уменьшение размера загрузки для конечного пользователя. По данным Apple (WWDC 2024), типовое приложение с использованием всех трёх механизмов App Thinning загружается в среднем на 40% быстрее по мобильной сети и занимает на 35% меньше места на диске. Это напрямую влияет на конверсию установки: по данным Sensor Tower, каждые 10 МБ размера приложения снижают конверсию на 1%.

Второе преимущество — оптимизация под будущие устройства за счёт Bitcode. Apple может перекомпилировать Bitcode-приложения под новые архитектуры без участия разработчика. Например, при переходе с Intel на Apple Silicon (M1) Bitcode-приложения работали на macOS через Rosetta 2 без дополнительной сборки. Разработчики, не включившие Bitcode, были вынуждены пересобирать приложения под arm64.

Третье преимущество — OFR (On-Demand Resources) снижает нагрузку на хранилище устройства. Игры с десятками уровней, такие как Asphalt 8: Airborne, используют ODR для загрузки новых трасс по мере прохождения. Разработчик может установить теги Initial Install Tags для ресурсов, которые загружаются вместе с приложением, и Prefetch Tags для контента, который загружается на фоне после установки. Apple контролирует лимиты ODR: до 512 МБ на запрос и до 20 ГБ общего кэша на устройстве.

Ограничения App Thinning

App Thinning имеет несколько важных ограничений, которые необходимо учитывать при проектировании приложения. Во-первых, Slicing не применяется к приложениям, распространяемым через Enterprise (in-house) или Ad Hoc — эти сборки содержат все варианты и не проходят через App Store. Для тестирования Slicing разработчик может использовать TestFlight, который также обрабатывает Slicing на стороне серверов Apple.

Во-вторых, Bitcode увеличивает время сборки и размер архива .xcarchive примерно на 30-50%. Не все сторонние библиотеки поддерживают Bitcode — если хотя бы одна зависимость собрана без Bitcode, сборка проекта с ENABLE_BITCODE завершится ошибкой. Apple рекомендует проверять совместимость библиотек перед включением Bitcode. Кроме того, Bitcode не поддерживает Swift Package Manager в полном объёме — некоторые Swift-пакеты могут ломать Bitcode-сборку.

В-третьих, On-Demand Resources не гарантируют мгновенную доступность контента — загрузка ODR происходит в фоне и может быть отложена, если устройство находится в режиме низкого заряда батареи или слабого сигнала сети. Разработчик должен реализовать обработку статусов загрузки ODR через NSBundleResourceRequest и показать пользователю индикатор прогресса. Сбой загрузки ODR не должен блокировать функциональность приложения — необходим graceful fallback.