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, Сесия 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. За всяка комбинация се създава отделен вариант. Когато потребителят кликне върху „Изтегли“, 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 MB от размера на приложението намалява конверсията с 1%.

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

Третото предимство — ODR (On-Demand Resources) намалява натоварването на паметта на устройството. Игри с десетки нива, като Asphalt 8: Airborne, използват ODR за зареждане на нови писти с напредването на играча. Разработчикът може да зададе Initial Install Tags за ресурси, които се зареждат заедно с приложението, и Prefetch Tags за съдържание, което се зарежда на заден план след инсталиране. Apple контролира ODR лимитите: до 512 MB на заявка и до 20 GB общ кеш на устройството.

Ограничения на 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.