Slicing: co to jest, zasada działania i związek z App Thinning

Co to jest Slicing

Slicing — to komponent App Thinning odpowiedzialny za tworzenie wariantów (wycinków) pliku binarnego aplikacji po stronie App Store. Gdy programista przesyła uniwersalny plik binarny (fat binary) zawierający kod i zasoby dla wszystkich obsługiwanych konfiguracji, App Store analizuje go i generuje kilka wycinków: osobno dla iPhone z procesorem A17, osobno dla iPad z M4, osobno dla Apple Watch. Każdy wycinek zawiera tylko te fragmenty kodu i zasoby, które są niezbędne dla danej kombinacji architektury i rozdzielczości.

Przed iOS 9 programiści ręcznie tworzyli osobne pliki binarne dla różnych urządzeń lub dostarczali uniwersalny fat binary, który zawierał wszystko naraz. Slicing całkowicie zautomatyzował ten proces: programista przygotowuje jeden projekt w Xcode, przesyła jeden archiwum do App Store Connect, a Slicing po stronie serwera tworzy optymalną liczbę wariantów. Użytkownik nigdy nie widzi procesu cięcia — otrzymuje gotowy .app zoptymalizowany pod swoje urządzenie.

Slicing stosuje się nie tylko do kodu i obrazów, ale także do shaderów Metal. Apple GPU używa własnego zestawu instrukcji (Metal Shading Language), który różni się od instrukcji PowerVR czy ARM Mali. Slicing włącza do wycinka tylko shadery dla rodziny GPU docelowego urządzenia. Jest to szczególnie ważne dla gier z niestandardowymi shaderami — na przykład wysoko szczegółowe efekty post-processingu są kompilowane tylko dla urządzeń z wydajnym GPU (iPad Pro M4, iPhone 16 Pro Max).

Różnica między Slicing a zwykłą kompilacją pod architekturę

Kompilator Xcode tworzy fat binary z kilkoma architekturami (armv7, arm64, arm64e), ale nie usuwa zasobów — wszystkie obrazy dla wszystkich rozdzielczości pozostają wewnątrz .app. Slicing idzie dalej: analizuje Asset Catalogs, shadery Metal i biblioteki Swift, usuwając z każdego wycinka to, co nie jest potrzebne dla konkretnego celu. Na przykład z wycinka dla iPhone SE nie trafia grafika @3x, a z wycinka dla iPad Air — kontrolery specyficzne dla iPhone (jeśli są wydzielone do osobnych zasobów).

Jak działa Slicing

Proces Slicing uruchamia się po przesłaniu buildu do App Store Connect i składa się z trzech etapów: analiza, cięcie i pakowanie. Na etapie analizy serwer App Store rozbiera plik binarny, wyodrębnia z niego informacje o obsługiwanych architekturach, urządzeniach, rozdzielczościach ekranów i wersjach iOS. App Store używa mapowania wszystkich komercyjnych modeli Apple do ich parametrów technicznych — baza danych urządzeń (Device Database) jest aktualizowana z każdym wydaniem iOS.

Na etapie cięcia serwer tworzy osobne kopie pliku binarnego dla każdej unikalnej kombinacji. W tym celu App Store wyodrębnia z Asset Catalogs obrazy z konkretnymi tagami (idiom, subtype, scale), wybiera tylko te, które odpowiadają docelowemu urządzeniu, i składa nowy pakiet zasobów. Biblioteka standardowa Swift również podlega cięciu — usuwane są z niej symbole i metody nieużywane przez konkretną aplikację (dead code stripping).

Na etapie pakowania każdy wycinek jest umieszczany w osobnym pakiecie dystrybucyjnym i powiązany z metadanymi — lista modeli urządzeń, dla których ten wycinek jest przeznaczony. App Store przy pobieraniu aplikacji przez użytkownika wybiera odpowiedni wycinek na podstawie modelu urządzenia, wersji iOS i typu połączenia. Jeśli nie ma dokładnego dopasowania, serwer używa najbliższego pod względem parametrów wycinka. Apple przechowuje wszystkie warianty w sieci CDN CloudKit w celu szybkiej dostawy na całym świecie.

Slicing w kontekście App Thinning

Slicing — to jeden z trzech mechanizmów App Thinning, ale wnosi największy wkład w zmniejszenie rozmiaru pobierania. Bitcode odpowiada za optymalizację kodu maszynowego, On-Demand Resources — za zarządzanie zasobami na urządzeniu, a Slicing — za usuwanie nadmiarowych zasobów na etapie dystrybucji. Bez Slicing pierwsze dwa mechanizmy działają, ale użytkownicy otrzymują zasoby dla wszystkich urządzeń, co zwiększa rozmiar o 20-40% w zależności od liczby Asset Catalogs.

Różnica między Slicing a Bitcode polega na punkcie zastosowania: Slicing działa na poziomie zasobów (obrazy, shadery, pliki NIB), Bitcode — na poziomie kodu maszynowego. Slicing dzieli kod według architektur (arm64 vs arm64e), Bitcode pozwala Apple przekompilować kod pod nowe architektury. Bitcode + Slicing razem dają maksymalną optymalizację: Bitcode generuje kod pod konkretną architekturę, a Slicing usuwa zbędne zasoby dla tej architektury.

Relacja z On-Demand Resources — Slicing i ODR nie nakładają się. Slicing decyduje, które zasoby w ogóle trafią do dystrybucji na urządzenie, a ODR zarządza, kiedy te zasoby zostaną pobrane i zwolnione. Programista może oznaczyć zasób tagiem ODR, a Slicing włączy go do wycinka, jeśli odpowiada urządzeniu. Apple zaleca używanie wszystkich trzech mechanizmów jednocześnie dla minimalnego rozmiaru instalacji.

Warianty Slicing dla różnych urządzeń

Slicing tworzy osobne wycinki według kilku wymiarów: architektura procesora, rozmiar ekranu (rozdzielczość), wersja iOS i rodzina GPU (dla Metal). Architektura określa zestaw instrukcji CPU: arm64 — podstawowy 64-bitowy zestaw (iPhone 5s — iPhone X), arm64e — rozszerzony zestaw z obsługą Pointer Authentication i PAC (iPhone XS i nowsze, iPad Pro z A12X+). Wycinek dla arm64e zawiera kod z instrukcjami ochrony pamięci niedostępnymi na urządzeniach arm64.

Rozdzielczość ekranu — drugi kluczowy wymiar Slicing. Apple używa skal @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus i nowsze) oraz specyficznych dla iPad (2x i 3x z dodatkowymi metrykami). Slicing włącza do wycinka tylko obrazy ze skalą odpowiadającą docelowemu urządzeniu. Przy prawidłowej organizacji Asset Catalogs w Xcode eliminuje to konieczność ręcznego zarządzania zestawami zasobów — wystarczy dodać obraz do katalogu, wskazując obsługiwane typy urządzeń.

Rodzina GPU — trzeci wymiar, krytyczny dla aplikacji Metal. Apple używa klasyfikacji GPU według pokoleń: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Shadery Metal są kompilowane dla każdej rodziny osobno, ponieważ zestaw instrukcji Metal Shading Language rozszerza się z każdym pokoleniem GPU. Slicing włącza do wycinka tylko shadery dla rodziny GPU docelowego urządzenia, co znacznie zmniejsza rozmiar gier i aplikacji używających Metal do renderowania.

Wpływ architektury na rozmiar wycinka

Architektura CPU bezpośrednio wpływa na rozmiar wycinka: kod arm64e zawiera dodatkowe instrukcje Pointer Authentication (PAC) i Signed Return Address, które zwiększają plik binarny o 5-10% w porównaniu z arm64. Jednak to zwiększenie jest kompensowane przez fakt, że Slicing włącza kod arm64e tylko do wycinków dla urządzeń z procesorami A12+. Dla iPhone SE (trzeciej generacji) z A15 Bionic Slicing tworzy osobny wycinek zoptymalizowany pod możliwości tego układu.

Konfiguracja Slicing w Xcode

Konfiguracja Slicing w Xcode jest minimalna — główna konfiguracja odbywa się przez Asset Catalogs i Build Settings. Asset Catalog powinien zawierać zasoby zorganizowane według typów urządzeń (Any, iPhone, iPad, Apple Watch, Apple TV) z poprawnym wskazaniem skali i trybu wyświetlania. Xcode automatycznie włącza do kompilacji tylko te zasoby, które odpowiadają docelowym urządzeniom określonym w ustawieniach Deployment Target.

Kluczowe ustawienie Slicing w Xcode — Build Setting App Thinning. Dostępne wartości:

• None — Slicing wyłączone, aplikacja dostarczana jako universal fat binary
• Automatic — Xcode włącza Slicing z ustawieniami domyślnymi
• Manual — programista wybiera konkretne kombinacje dla Slicing

Targeted Device Families w General → Deployment Info określa, dla jakich typów urządzeń kompilowana jest aplikacja (iPhone / iPad / Universal). Slicing opiera się na tym parametrze przy cięciu — jeśli aplikacja obsługuje tylko iPhone, wycinek dla iPad nie jest tworzony. Deployment Target (minimalna wersja iOS) również wpływa na Slicing: dla starych wersji iOS mogą być potrzebne wycinki armv7, które nie są potrzebne dla iOS 13+. Apple zaleca ustawianie Deployment Target na najnowszą stabilną wersję iOS — zmniejsza to liczbę wycinków i rozmiar pliku binarnego.

Parametry Asset Catalog dla Slicing

Dla maksymalnej efektywności Slicing Asset Catalogs powinny używać specyficznych tagów dla każdego zasobu. Xcode udostępnia w Attributes Inspector dla obrazów: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Łącząc te tagi, programista steruje tym, do których wycinków trafi każdy obraz. Na przykład obraz dla iPad z tagiem Regular Width + Regular Height trafi tylko do wycinków dla iPad w orientacji landscape.

# Eksport wycinka dla konkretnego urządzenia
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild z parametrem -thinning i identyfikatorem modelu tworzy wycinek tylko dla tego modelu. Listę identyfikatorów można znaleźć w Device Database Apple (format: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Ta metoda jest przydatna do sprawdzania rozmiaru wycinka przed wysłaniem do App Store Connect. CI/CD może używać tego polecenia do automatycznej weryfikacji — jeśli rozmiar wycinka przekracza limit (np. 100 MB dla pobierania mobilnego), pipeline wyświetla ostrzeżenie.

Sprawdzanie wyników Slicing

Po przesłaniu archiwum do App Store Connect Apple udostępnia szczegółowe statystyki dotyczące rozmiarów wycinków. App Store Connect → Activity → wybierz build → App Thinning — wyświetla Estimated App Store Size dla każdej kategorii urządzeń: iPhone, iPad, Apple Watch, tvOS. Rozmiary są podzielone według wersji iOS i typów procesorów. Jeśli jakiś wycinek przekracza oczekiwany rozmiar, App Store Connect oznacza go żółtym ostrzeżeniem.

Lokalne sprawdzanie przez Xcode Organizer: po archiwizacji otwórz Window → Organizer, wybierz archiwum i kliknij App Thinning Profiles. Xcode pokaże rozmiary dla każdego możliwego wycinka na podstawie bieżącej konfiguracji projektu. Dostępna jest również opcja Export do tworzenia IPA z konkretnym profilem Slicing. Xcode generuje plik .app-thinning.plist z informacją o tym, które zasoby trafiły do każdego wycinka.

Do automatyzacji sprawdzania Slicing w CI/CD używaj xcodebuild z -thinning i analizuj rozmiar utworzonych plików .app. Apple udostępnia narzędzie wiersza poleceń app-size (instalowane przez Xcode Command Line Tools), które wyświetla szczegółowy raport: rozmiar kodu, rozmiar zasobów według kategorii (obrazy, shadery, NIB), rozmiar bibliotek Swift. Porównanie rozmiarów wycinków przed i po optymalizacji Asset Catalogs pomaga zidentyfikować zasoby nieuczestniczące w Slicing z powodu nieprawidłowej konfiguracji.

# Analiza rozmiaru wycinka
app-size -m "sliced/App.app" \
  --format json

App-size wyświetla raport JSON z podziałem według kategorii zasobów. Jeśli Slicing jest skonfigurowane prawidłowo, w sekcji „images” będzie tylko jeden zestaw skali (@2x lub @3x), a nie wszystkie warianty. Błąd konfiguracji Asset Catalogs objawia się tym, że wszystkie skale (@1x, @2x, @3x) są obecne w wycinku — oznacza to, że Xcode nie mógł określić docelowego urządzenia dla tych obrazów, a Slicing nie zadziałało.