App Thinning — co to jest, z jakich komponentów się składa i jak działa

Czym jest App Thinning

App Thinning to kompleksowa technologia optymalizacji dystrybucji aplikacji iOS, wprowadzona przez Apple wraz z iOS 9 (wrzesień 2015). Celem App Thinning jest minimalizacja rozmiaru aplikacji pobieranej przez użytkownika na swoje urządzenie, bez zmiany kodu źródłowego i funkcjonalności. Technologia działa na trzech poziomach: na etapie budowania (kompilacja), po stronie App Store (dostarczanie) i na urządzeniu (zarządzanie zasobami).

Przed pojawieniem się App Thinning programiści dołączali do pliku binarnego zasoby dla wszystkich możliwych urządzeń — obrazy @2x i @3x, kod 32-bitowy i 64-bitowy, shadery Metal dla różnych GPU. Prowadziło to do rozdęcia rozmiaru aplikacji: użytkownik iPhone 6 Plus z wyświetlaczem Retina HD otrzymywał zasoby wektorowe dla iPad Pro, które nigdy nie były używane. Apple rozwiązało ten problem, przenosząc część pracy związanej z budowaniem na serwery App Store.

Według badań Apple (WWDC 2015, Sesja 412), typowa aplikacja z obsługą wielu architektur i rozdzielczości może zmniejszyć się o 30-50% po zastosowaniu App Thinning. Dla gier z dużą liczbą wysokoszczegółowych tekstur zysk może sięgać 70-80%. Apple kontynuuje ulepszanie technologii: w iOS 17 dodano optymalizację dla ARM64e i ulepszono pracę z On-Demand Resources dla aplikacji korzystających z Swift Package Manager.

Problem, który rozwiązuje App Thinning

Rozmiar aplikacji mobilnych stale rośnie. Według danych Sensor Tower (2025), średni rozmiar aplikacji iOS wzrósł o 45% w ciągu ostatnich 5 lat. Dla użytkowników z ograniczonym planem taryfowym lub wolnym internetem każdy megabajt ma znaczenie. App Thinning rozwiązuje ten problem bez udziału programisty — wystarczy włączyć wsparcie w ustawieniach projektu i przesłać build do App Store Connect.

Jak działa App Thinning

Proces App Thinning rozpoczyna się po przesłaniu archiwum aplikacji do App Store Connect. App Store analizuje plik binarny i dzieli go na segmenty według architektur (armv7, arm64, arm64e), rozdzielczości ekranów (iPhone, iPad) i wersji iOS. Dla każdej kombinacji tworzony jest osobny wariant (variant). Gdy użytkownik kliknie „Pobierz”, App Store określa model urządzenia, wersję iOS i typ połączenia (Wi-Fi / sieć komórkowa) i wysyła tylko odpowiedni wariant.

Dla użytkownika proces jest przezroczysty — nie ma wyboru „lekkiej wersji” ani okna dialogowego z ustawieniami. App Store automatycznie wybiera najbardziej odpowiedni wariant na podstawie metadanych urządzenia, które są przekazywane do serwera przy żądaniu pobrania. Jeśli urządzenie korzysta z Wi-Fi, App Store może wysłać wariant z zasobami wyższej jakości (np. wideo ProRes dla iPhone 16 Pro). Przy pobieraniu przez sieć komórkową używany jest minimalny możliwy zestaw.

Drugi poziom optymalizacji — Bitcode. Przy włączonej opcji ENABLE_BITCODE Xcode kompiluje aplikację nie do kodu maszynowego, ale do pośredniej reprezentacji LLVM. App Store rekompiluje Bitcode dla konkretnej architektury procesora użytkownika, co pozwala Apple stosować optymalizacje kompilatora dla nowych generacji układów (A17, M4) bez aktualizacji aplikacji przez programistę. Bitcode jest obowiązkowy dla watchOS i tvOS, ale opcjonalny dla iOS.

Komponenty App Thinning: Slicing, Bitcode, ODR

App Thinning składa się z trzech niezależnych mechanizmów, z których każdy odpowiada za swój aspekt optymalizacji. Slicing (krojenie) dzieli plik binarny na warianty według architektury i rozdzielczości ekranu. Programista konfiguruje Slicing przez Asset Catalogs — Xcode automatycznie dołącza do wycinka tylko te zasoby, które odpowiadają docelowemu urządzeniu. Na przykład iPhone SE (trzecia generacja) otrzyma tylko obrazy @2x i kod arm64, a iPad Pro M4 — obrazy @3x i kod arm64e.

Bitcode to LLVM IR (Intermediate Representation) — maszynowo niezależna reprezentacja programu. Przy włączeniu Bitcode Xcode nie generuje ostatecznego kodu maszynowego, ale zapisuje pośrednią reprezentację. App Store Connect przy przesyłaniu builda otrzymuje Bitcode i rekompiluje go dla architektur wszystkich obsługiwanych urządzeń. Bitcode pozwala Apple stosować optymalizacje niedostępne na etapie kompilacji u programisty — na przykład wykorzystanie nowych instrukcji procesora (SME, SVE) w układach M4.

On-Demand Resources (ODR) — trzeci mechanizm, który umożliwia zwalnianie zasobów aplikacji po ich użyciu. Programista oznacza zasoby (poziomy gry, obrazy do onboardingu, wideo) tagami ODR. iOS ładuje oznaczone zasoby na żądanie w tle i zwalnia je przy braku pamięci lub po użyciu. ODR są szczególnie efektywne dla gier z dużą ilością treści — pierwsze poziomy można dostarczyć w ramach aplikacji, a pozostałe ładować w miarę postępów.

Kiedy wybrać każdy komponent

Wybór mechanizmów App Thinning zależy od typu aplikacji i jej grupy docelowej. Slicing zaleca się włączać zawsze — nie wymaga dodatkowych działań programisty poza prawidłową organizacją Asset Catalogs i daje stabilne zmniejszenie rozmiaru o 20-30%. Bitcode warto włączyć, jeśli aplikacja używa niestandardowych shaderów Metal lub planuje obsługiwać nowe architektury Apple bez przebudowy. ODR jest uzasadniony dla aplikacji z dużą ilością treści — gry, edytory zdjęć, aplikacje do streamingu.

Dla typowej aplikacji biznesowej (kanały danych, formularze, REST API) wystarczy Slicing i minimalna konfiguracja ODR dla obrazów onboardingu. Gry z grafiką 3D zyskują na wszystkich trzech mechanizmach: Slicing usuwa zbędne shadery, Bitcode optymalizuje renderowanie pod GPU, a ODR zwalnia ukończone poziomy. Według Apple (WWDC 2024), kombinacja wszystkich trzech mechanizmów zmniejsza początkowy rozmiar instalacji średnio o 45-55% w porównaniu z uniwersalnym plikiem binarnym.

Konfiguracja App Thinning w Xcode

Aby włączyć App Thinning w projekcie Xcode, należy wykonać kilka kroków. Slicing konfiguruje się przez App Thinning w ustawieniach budowania: Build Settings → App Thinning. Dostępne są trzy wartości: None (bez optymalizacji), Automatic (automatyczna konfiguracja domyślna) i Manual z wyborem konkretnych wariantów do testowania. Apple zaleca Automatic dla większości projektów.

Dla Asset Catalogs ważne jest prawidłowe zorganizowanie zasobów: obrazy umieszcza się w uniwersalnym katalogu z podaniem szerokości/wysokości, a Xcode automatycznie tworzy warianty @1x, @2x i @3x. Xcode przy budowaniu dołącza tylko te rozdzielczości, które są używane w projekcie. Shadery Metal są kompilowane osobno dla każdej rodziny GPU — Apple GPU, PowerVR, Mali, co również jest zarządzane przez Asset Catalogs.

Bitcode włącza się flagą ENABLE_BITCODE = YES w Build Settings. Dla iOS ta flaga jest opcjonalna (domyślnie wyłączona od Xcode 14), ale dla watchOS i tvOS obowiązkowa. Przy włączeniu Bitcode w projekcie korzystającym z bibliotek zewnętrznych, wszystkie one również muszą być zbudowane z Bitcode, w przeciwnym razie budowanie zakończy się błędem. Bitcode zwiększa czas kompilacji o 20-30%, ale zapewnia pełną kompatybilność z przyszłymi architekturami.

Sprawdzanie wyników App Thinning

Po przesłaniu do App Store Connect można sprawdzić rozmiary wycinków w sekcji Activity → Build Metric. App Store Connect wyświetla Estimated App Store Size dla różnych urządzeń. Do lokalnego sprawdzenia Xcode udostępnia polecenie xcodebuild z flagą -exportArchive i opcją thinning do tworzenia wycinków na lokalnej maszynie. Wynik Slicing można zobaczyć w Organizer (Window → Organizer) po archiwizacji — zakładka App Thinning Profiles pokazuje rozmiary dla różnych urządzeń.

# Lokalne sprawdzenie Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild z flagą -thinning tworzy pliki .app dla każdej kombinacji architektury, rozdzielczości i GPU. Parametr <thin-for-all-variants> tworzy wszystkie możliwie warianty — przydatne do sprawdzenia. Dla pipeline’ów CI używa się określenia konkretnej kombinacji, na przykład iPhone14,4 (iPhone SE 3). Wynikowe pliki .app można analizować narzędziem app-size.

Zalety i wpływ App Thinning

Główną zaletą App Thinning jest zmniejszenie rozmiaru pobierania dla końcowego użytkownika. Według Apple (WWDC 2024), typowa aplikacja korzystająca ze wszystkich trzech mechanizmów App Thinning pobiera się średnio o 40% szybciej przez sieć komórkową i zajmuje o 35% mniej miejsca na dysku. To bezpośrednio wpływa na konwersję instalacji: według Sensor Tower, każde 10 MB rozmiaru aplikacji obniża konwersję o 1%.

Drugą zaletą jest optymalizacja pod przyszłe urządzenia dzięki Bitcode. Apple może rekompilować aplikacje z Bitcode dla nowych architektur bez udziału programisty. Na przykład przy przejściu z Intel na Apple Silicon (M1) aplikacje z Bitcode działały na macOS przez Rosetta 2 bez dodatkowej kompilacji. Programiści, którzy nie włączyli Bitcode, byli zmuszeni do przebudowy aplikacji pod arm64.

Trzecią zaletą jest to, że ODR (On-Demand Resources) zmniejsza obciążenie pamięci urządzenia. Gry z dziesiątkami poziomów, takie jak Asphalt 8: Airborne, używają ODR do ładowania nowych tras w miarę postępów. Programista może ustawić tagi Initial Install Tags dla zasobów ładowanych wraz z aplikacją oraz Prefetch Tags dla treści ładowanej w tle po instalacji. Apple kontroluje limity ODR: do 512 MB na żądanie i do 20 GB całkowitego cache na urządzeniu.

Ograniczenia App Thinning

App Thinning ma kilka ważnych ograniczeń, które należy uwzględnić przy projektowaniu aplikacji. Po pierwsze, Slicing nie jest stosowany do aplikacji rozpowszechnianych przez Enterprise (in-house) lub Ad Hoc — te buildy zawierają wszystkie warianty i nie przechodzą przez App Store. Do testowania Slicing programista może użyć TestFlight, który również przetwarza Slicing po stronie serwerów Apple.

Po drugie, Bitcode zwiększa czas budowania i rozmiar archiwum .xcarchive o około 30-50%. Nie wszystkie biblioteki zewnętrzne obsługują Bitcode — jeśli przynajmniej jedna zależność jest zbudowana bez Bitcode, budowanie projektu z ENABLE_BITCODE zakończy się błędem. Apple zaleca sprawdzenie kompatybilności bibliotek przed włączeniem Bitcode. Ponadto Bitcode nie obsługuje w pełni Swift Package Manager — niektóre pakiety Swift mogą łamać budowanie z Bitcode.

Po trzecie, On-Demand Resources nie gwarantują natychmiastowej dostępności treści — ładowanie ODR odbywa się w tle i może być opóźnione, jeśli urządzenie jest w trybie niskiego poziomu baterii lub słabego sygnału sieci. Programista musi zaimplementować obsługę statusów ładowania ODR przez NSBundleResourceRequest i pokazać użytkownikowi wskaźnik postępu. Awaria ładowania ODR nie powinna blokować funkcjonalności aplikacji — konieczny jest graceful fallback.