Slicing: wat is het, werkingsprincipe en verband met App Thinning

Wat is Slicing

Slicing — is de component van App Thinning die verantwoordelijk is voor het maken van varianten (slices) van het binaire app-bestand aan de kant van App Store. Wanneer een ontwikkelaar een universeel binair bestand (fat binary) uploadt dat code en bronnen bevat voor alle ondersteunde configuraties, analyseert App Store het en genereert meerdere slices: apart voor iPhone met A17-processor, apart voor iPad met M4, apart voor Apple Watch. Elke slice bevat alleen die codefragmenten en bronnen die nodig zijn voor deze specifieke combinatie van architectuur en resolutie.

Vóór iOS 9 maakten ontwikkelaars handmatig aparte binaire bestanden voor verschillende apparaten of leverden ze een universele fat binary die alles in één keer bevatte. Slicing heeft dit proces volledig geautomatiseerd: de ontwikkelaar bereidt één project in Xcode voor, uploadt één archief naar App Store Connect, en Slicing aan de serverkant creëert het optimale aantal varianten. De gebruiker ziet nooit het snijproces — hij krijgt een kant-en-klare .app geoptimaliseerd voor zijn apparaat.

Slicing wordt niet alleen toegepast op code en afbeeldingen, maar ook op Metal-shaders. Apple GPU gebruikt zijn eigen instructieset (Metal Shading Language) die verschilt van de instructies van PowerVR of ARM Mali. Slicing neemt in de slice alleen shaders op voor de GPU-familie van het doelapparaat. Dit is vooral belangrijk voor games met aangepaste shaders — bijvoorbeeld zeer gedetailleerde post-processing-effecten worden alleen gecompileerd voor apparaten met een krachtige GPU (iPad Pro M4, iPhone 16 Pro Max).

Verschil tussen Slicing en eenvoudige compilatie voor architectuur

De Xcode-compiler maakt een fat binary met meerdere architecturen (armv7, arm64, arm64e), maar verwijdert geen bronnen — alle afbeeldingen voor alle resoluties blijven in .app. Slicing gaat verder: het analyseert Asset Catalogs, Metal-shaders en Swift-bibliotheken, en verwijdert uit elke slice wat niet nodig is voor een specifiek doel. Zo komt in de slice voor iPhone SE geen @3x-graphics terecht, en in de slice voor iPad Air — iPhone-specifieke controllers (als ze zijn uitgesplitst in aparte bronnen).

Hoe werkt Slicing

Het Slicing-proces start na het uploaden van de build naar App Store Connect en bestaat uit drie fasen: analyse, snijden en verpakken. In de analyse-fase ontleedt de App Store-server het binaire bestand, haalt er informatie uit over ondersteunde architecturen, apparaten, schermresoluties en iOS-versies. App Store gebruikt de mapping van alle commerciële Apple-modellen naar hun technische specificaties — de apparaatdatabase (Device Database) wordt bijgewerkt met elke iOS-release.

In de snij-fase maakt de server aparte kopieën van het binaire bestand voor elke unieke combinatie. Hiervoor haalt App Store afbeeldingen met specifieke tags (idiom, subtype, scale) uit Asset Catalogs, selecteert alleen die welke overeenkomen met het doelapparaat en stelt een nieuw bronnenpakket samen. De Swift-standaardbibliotheek wordt ook gesneden — er worden symbolen en methoden uit verwijderd die niet door de specifieke app worden gebruikt (dead code stripping).

In de verpakkings-fase wordt elke slice in een apart distributiepakket geplaatst en gekoppeld aan metadata — de lijst van apparaatmodellen waarvoor deze slice bedoeld is. App Store selecteert bij het downloaden van de app door de gebruiker de juiste slice op basis van het apparaatmodel, de iOS-versie en het type verbinding. Als er geen exacte overeenkomst is, gebruikt de server de qua specificaties meest nabije slice. Apple bewaart alle varianten in het CloudKit CDN-netwerk voor snelle levering wereldwijd.

Slicing in de context van App Thinning

Slicing — is een van de drie mechanismen van App Thinning, maar levert de grootste bijdrage aan het verkleinen van de downloadgrootte. Bitcode is verantwoordelijk voor optimalisatie van machinecode, On-Demand Resources — voor het beheer van bronnen op het apparaat, en Slicing — voor het verwijderen van overbodige bronnen in de distributiefase. Zonder Slicing werken de eerste twee mechanismen wel, maar gebruikers ontvangen bronnen voor alle apparaten, wat de grootte met 20-40% vergroot, afhankelijk van het aantal Asset Catalogs.

Het verschil tussen Slicing en Bitcode zit in het toepassingspunt: Slicing werkt op bronniveau (afbeeldingen, shaders, NIB-bestanden), Bitcode — op machineniveau. Slicing verdeelt code over architecturen (arm64 vs arm64e), Bitcode stelt Apple in staat code opnieuw te compileren voor nieuwe architecturen. Bitcode + Slicing geven samen maximale optimalisatie: Bitcode genereert code voor een specifieke architectuur, en Slicing verwijdert overbodige bronnen voor die architectuur.

Relatie met On-Demand Resources — Slicing en ODR overlappen elkaar niet. Slicing bepaalt welke bronnen überhaupt in de distributie naar het apparaat komen, en ODR beheert wanneer deze bronnen worden geladen en verwijderd. De ontwikkelaar kan een bron markeren met een ODR-tag, en Slicing zal deze in de slice opnemen als deze overeenkomt met het apparaat. Apple raadt aan alle drie mechanismen tegelijk te gebruiken voor een minimale installatiegrootte.

Slicing-varianten voor verschillende apparaten

Slicing maakt aparte slices op basis van meerdere dimensies: processorarchitectuur, schermgrootte (resolutie), iOS-versie en GPU-familie (voor Metal). Architectuur bepaalt de instructieset van de CPU: arm64 — basis 64-bit set (iPhone 5s — iPhone X), arm64e — uitgebreide set met ondersteuning voor Pointer Authentication en PAC (iPhone XS en nieuwer, iPad Pro met A12X+). De slice voor arm64e bevat code met geheugenbeschermingsinstructies die niet beschikbaar zijn op arm64-apparaten.

Schermresolutie — de tweede belangrijke dimensie van Slicing. Apple gebruikt schalen @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus en nieuwer) en iPad-specifieke (2x en 3x met extra metrieken). Slicing neemt in de slice alleen afbeeldingen op met de schaal die overeenkomt met het doelapparaat. Met een correcte organisatie van Asset Catalogs in Xcode elimineert dit de noodzaak om handmatig bronnensets te beheren — het volstaat om een afbeelding aan de catalogus toe te voegen met vermelding van de ondersteunde apparaattypen.

GPU-familie — de derde dimensie, cruciaal voor Metal-applicaties. Apple gebruikt GPU-classificatie per generatie: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Metal-shaders worden voor elke familie apart gecompileerd, omdat de instructieset van Metal Shading Language zich uitbreidt met elke GPU-generatie. Slicing neemt in de slice alleen shaders op voor de GPU-familie van het doelapparaat, wat de grootte van games en apps die Metal gebruiken voor rendering aanzienlijk vermindert.

Invloed van architectuur op slicegrootte

CPU-architectuur heeft directe invloed op de slicegrootte: arm64e-code bevat extra Pointer Authentication (PAC) en Signed Return Address-instructies die het binaire bestand met 5-10% vergroten ten opzichte van arm64. Deze toename wordt echter gecompenseerd doordat Slicing arm64e-code alleen opneemt in slices voor apparaten met A12+ processors. Voor iPhone SE (derde generatie) met A15 Bionic creëert Slicing een aparte slice geoptimaliseerd voor de mogelijkheden van deze chip.

Slicing configureren in Xcode

Het configureren van Slicing in Xcode is minimaal — de hoofdconfiguratie gebeurt via Asset Catalogs en Build Settings. Asset Catalog moet bronnen bevatten die georganiseerd zijn per apparaattype (Any, iPhone, iPad, Apple Watch, Apple TV) met correcte vermelding van schaal en weergavemodus. Xcode neemt automatisch alleen die bronnen op in de compilatie die overeenkomen met de doelapparaten zoals gespecificeerd in de Deployment Target-instellingen.

De belangrijkste Slicing-instelling in Xcode — Build Setting App Thinning. Beschikbare waarden:

• None — Slicing uitgeschakeld, app wordt geleverd als universal fat binary
• Automatic — Xcode schakelt Slicing in met standaardinstellingen
• Manual — ontwikkelaar selecteert specifieke combinaties voor Slicing

Targeted Device Families in General → Deployment Info bepaalt voor welke apparaattypen de app wordt gebouwd (iPhone / iPad / Universal). Slicing vertrouwt op deze parameter bij het snijden — als de app alleen iPhone ondersteunt, wordt er geen slice voor iPad gemaakt. Deployment Target (minimale iOS-versie) heeft ook invloed op Slicing: voor oude iOS-versies kunnen armv7-slices nodig zijn die niet nodig zijn voor iOS 13+. Apple raadt aan Deployment Target in te stellen op de nieuwste stabiele iOS-versie — dit vermindert het aantal slices en de grootte van het binaire bestand.

Asset Catalog-parameters voor Slicing

Voor maximale Slicing-efficiëntie moeten Asset Catalogs specifieke tags gebruiken voor elke bron. Xcode biedt in Attributes Inspector voor afbeeldingen: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Door deze tags te combineren, bepaalt de ontwikkelaar in welke slices elke afbeelding terechtkomt. Een afbeelding voor iPad met de tag Regular Width + Regular Height komt bijvoorbeeld alleen in slices voor iPad in landscape-oriëntatie.

# Exporteren van slice voor specifiek apparaat
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild met parameter -thinning en model-identificatiecode maakt een slice alleen voor dat model. De lijst met identificatiecodes is te vinden in de Apple Device Database (formaat: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Deze methode is handig om de slicegrootte te controleren voordat deze naar App Store Connect wordt verzonden. CI/CD kan deze opdracht gebruiken voor automatische verificatie — als de slicegrootte de limiet overschrijdt (bijv. 100 MB voor mobiele download), geeft de pipeline een waarschuwing.

Resultaten van Slicing controleren

Na het uploaden van het archief naar App Store Connect biedt Apple gedetailleerde statistieken over de slicegroottes. App Store Connect → Activity → selecteer build → App Thinning — toont de Estimated App Store Size voor elke apparaatcategorie: iPhone, iPad, Apple Watch, tvOS. De groottes zijn uitgesplitst naar iOS-versies en processortypen. Als een slice de verwachte grootte overschrijdt, markeert App Store Connect deze met een gele waarschuwing.

Lokale controle via Xcode Organizer: open na archivering Window → Organizer, selecteer het archief en klik op App Thinning Profiles. Xcode toont de groottes voor elke mogelijke slice op basis van de huidige projectconfiguratie. Ook is er de optie Export beschikbaar om een IPA te maken met een specifiek Slicing-profiel. Xcode genereert het bestand .app-thinning.plist met informatie over welke bronnen in elke slice zijn terechtgekomen.

Gebruik voor automatisering van Slicing-controle in CI/CD xcodebuild met -thinning en analyseer de grootte van de gemaakte .app-bestanden. Apple biedt de opdrachtregeltool app-size (geïnstalleerd via Xcode Command Line Tools) die een gedetailleerd rapport toont: codegrootte, brongrootte per categorie (afbeeldingen, shaders, NIB), grootte van Swift-bibliotheken. Vergelijking van slicegroottes voor en na optimalisatie van Asset Catalogs helpt bij het identificeren van bronnen die niet deelnemen aan Slicing vanwege een onjuiste configuratie.

# Analyse van slicegrootte
app-size -m "sliced/App.app" \
  --format json

App-size toont een JSON-rapport met uitsplitsing per brontategorie. Als Slicing correct is geconfigureerd, staat er in de sectie „images” slechts één schaalset (@2x of @3x) in plaats van alle varianten. Een configuratiefout van Asset Catalogs blijkt uit het feit dat alle schalen (@1x, @2x, @3x) aanwezig zijn in de slice — dit betekent dat Xcode het doelapparaat voor deze afbeeldingen niet kon bepalen en Slicing niet heeft gewerkt.