Slicing: vad det är, funktionsprincip och samband med App Thinning

Vad är Slicing

Slicing — är komponenten i App Thinning som ansvarar för att skapa varianter (skivor) av appens binärfil på App Stores sida. När en utvecklare laddar upp en universell binärfil (fat binary) som innehåller kod och resurser för alla supportade konfigurationer, analyserar App Store den och genererar flera skivor: separat för iPhone med A17-processor, separat för iPad med M4, separat för Apple Watch. Varje skiva innehåller endast de kodfragment och resurser som krävs för den specifika kombinationen av arkitektur och upplösning.

Före iOS 9 skapade utvecklare manuellt separata binärfiler för olika enheter eller levererade en universell fat binary som innehöll allt på en gång. Slicing automatiserade denna process helt: utvecklaren förbereder ett projekt i Xcode, laddar upp ett arkiv till App Store Connect och Slicing på serversidan skapar det optimala antalet varianter. Användaren ser aldrig skärningsprocessen — hen får en färdig .app optimerad för sin enhet.

Slicing tillämpas inte bara på kod och bilder, utan även på Metal-shaders. Apple GPU använder sin egen instruktionsuppsättning (Metal Shading Language) som skiljer sig från instruktionerna i PowerVR eller ARM Mali. Slicing inkluderar i skivan endast shaders för GPU-familjen på målenheten. Detta är särskilt viktigt för spel med anpassade shaders — till exempel kompileras högdetailjerade efterbehandlingseffekter endast för enheter med kraftfull GPU (iPad Pro M4, iPhone 16 Pro Max).

Skillnad mellan Slicing och vanlig kompilering för arkitektur

Xcode-kompilatorn skapar en fat binary med flera arkitekturer (armv7, arm64, arm64e), men tar inte bort resurser — alla bilder för alla upplösningar finns kvar i .app. Slicing går längre: den analyserar Asset Catalogs, Metal-shaders och Swift-bibliotek, och tar bort från varje skiva det som inte behövs för ett specifikt ändamål. Till exempel kommer inte @3x-grafik in i skivan för iPhone SE, och iPhone-specifika kontrollanter (om de är separerade i egna resurser) kommer inte in i skivan för iPad Air.

Hur fungerar Slicing

Slicing-processen startar efter att builden laddats upp till App Store Connect och består av tre steg: analys, skärning och paketering. I analys-steget bryter App Store-servern ner binärfilen, extraherar information om supportade arkitekturer, enheter, skärmupplösningar och iOS-versioner. App Store använder mappning av alla kommersiella Apple-modeller till deras tekniska specifikationer — enhetsdatabasen (Device Database) uppdateras med varje iOS-utgåva.

I skärning-steget skapar servern separata kopior av binärfilen för varje unik kombination. För detta extraherar App Store bilder med specifika taggar (idiom, subtype, scale) från Asset Catalogs, väljer endast de som matchar målenheten och sätter ihop ett nytt resurspaket. Swift-standardbiblioteket genomgår också skärning — symboler och metoder som inte används av den specifika appen tas bort från det (dead code stripping).

I paketering-steget placeras varje skiva i ett separat distributionspaket och kopplas till metadata — listan över enhetsmodeller som skivan är avsedd för. App Store när användaren laddar ner appen väljer lämplig skiva baserat på enhetsmodell, iOS-version och anslutningstyp. Om det inte finns någon exakt matchning använder servern den skiva som ligger närmast i specifikationerna. Apple lagrar alla varianter i CloudKit CDN-nätverket för snabb leverans över hela världen.

Slicing i kontexten av App Thinning

Slicing — är en av tre mekanismer i App Thinning, men bidrar mest till att minska nedladdningsstorleken. Bitcode ansvarar för optimering av maskinkod, On-Demand Resources — för hantering av resurser på enheten, och Slicing — för borttagning av överflödiga resurser i distributionssteget. Utan Slicing fungerar de första två mekanismerna, men användarna får resurser för alla enheter, vilket ökar storleken med 20-40% beroende på antalet Asset Catalogs.

Skillnaden mellan Slicing och Bitcode ligger i tillämpningspunkten: Slicing arbetar på resursnivå (bilder, shaders, NIB-filer), Bitcode — på maskinkodnivå. Slicing delar upp kod efter arkitektur (arm64 vs arm64e), Bitcode tillåter Apple att kompilera om kod för nya arkitekturer. Bitcode + Slicing tillsammans ger maximal optimering: Bitcode genererar kod för en specifik arkitektur och Slicing tar bort överflödiga resurser för den arkitekturen.

Relation till On-Demand Resources — Slicing och ODR överlappar inte varandra. Slicing bestämmer vilka resurser som överhuvudtaget kommer in i distributionen till enheten, och ODR hanterar när dessa resurser laddas och avlastas. Utvecklaren kan markera en resurs med en ODR-tagg och Slicing inkluderar den i skivan om den matchar enheten. Apple rekommenderar att använda alla tre mekanismer samtidigt för minimal installationsstorlek.

Slicing-varianter för olika enheter

Slicing skapar separata skivor baserat på flera dimensioner: processorarkitektur, skärmstorlek (upplösning), iOS-version och GPU-familj (för Metal). Arkitektur bestämmer CPU:ns instruktionsuppsättning: arm64 — grundläggande 64-bitars uppsättning (iPhone 5s — iPhone X), arm64e — utökad uppsättning med stöd för Pointer Authentication och PAC (iPhone XS och nyare, iPad Pro med A12X+). Skivan för arm64e innehåller kod med minnesskyddsinstruktioner som inte är tillgängliga på arm64-enheter.

Skärmupplösning — den andra nyckeldimensionen för Slicing. Apple använder skalor @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus och nyare) samt iPad-specifika (2x och 3x med ytterligare metriker). Slicing inkluderar i skivan endast bilder med den skala som matchar målenheten. Med korrekt organisation av Asset Catalogs i Xcode eliminerar detta behovet av manuell hantering av resursuppsättningar — det räcker att lägga till bilden i katalogen och ange supportade enhetstyper.

GPU-familj — den tredje dimensionen, kritisk för Metal-applikationer. Apple använder GPU-klassificering per generation: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Metal-shaders kompileras för varje familj separat, eftersom Metal Shading Language-instruktionsuppsättningen utökas med varje GPU-generation. Slicing inkluderar i skivan endast shaders för GPU-familjen på målenheten, vilket avsevärt minskar storleken på spel och appar som använder Metal för rendering.

Inverkan av arkitektur på skivstorlek

CPU-arkitektur påverkar direkt skivstorleken: arm64e-kod innehåller ytterligare instruktioner för Pointer Authentication (PAC) och Signed Return Address som ökar binärfilen med 5-10% jämfört med arm64. Dock kompenseras denna ökning av att Slicing endast inkluderar arm64e-kod i skivor för enheter med A12+-processorer. För iPhone SE (tredje generationen) med A15 Bionic skapar Slicing en separat skiva optimerad för detta chips kapacitet.

Konfigurera Slicing i Xcode

Konfiguration av Slicing i Xcode är minimal — huvudkonfigurationen görs via Asset Catalogs och Build Settings. Asset Catalog ska innehålla resurser organiserade efter enhetstyp (Any, iPhone, iPad, Apple Watch, Apple TV) med korrekt angivelse av skala och visningsläge. Xcode inkluderar automatiskt endast de resurser i kompileringen som matchar målenheterna som specificerats i Deployment Target-inställningarna.

Den viktigaste Slicing-inställningen i Xcode — Build Setting App Thinning. Tillgängliga värden:

• None — Slicing avaktiverat, appen levereras som universal fat binary
• Automatic — Xcode aktiverar Slicing med standardinställningar
• Manual — utvecklaren väljer specifika kombinationer för Slicing

Targeted Device Families i General → Deployment Info bestämmer för vilka enhetstyper appen byggs (iPhone / iPad / Universal). Slicing förlitar sig på denna parameter vid skärning — om appen endast stöder iPhone skapas ingen skiva för iPad. Deployment Target (minsta iOS-version) påverkar också Slicing: för gamla iOS-versioner kan armv7-skivor krävas som inte behövs för iOS 13+. Apple rekommenderar att ställa in Deployment Target på den senaste stabila iOS-versionen — detta minskar antalet skivor och storleken på binärfilen.

Asset Catalog-parametrar för Slicing

För maximal Slicing-effektivitet bör Asset Catalogs använda specifika taggar för varje resurs. Xcode tillhandahåller i Attributes Inspector för bilder: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Genom att kombinera dessa taggar styr utvecklaren vilka skivor varje bild hamnar i. Till exempel hamnar en bild för iPad med taggen Regular Width + Regular Height endast i skivor för iPad i liggande orientering.

# Exportera skiva för specifik enhet
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild med parametern -thinning och modellidentifierare skapar en skiva endast för den modellen. Listan över identifierare finns i Apple Device Database (format: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Denna metod är användbar för att kontrollera skivstorleken innan den skickas till App Store Connect. CI/CD kan använda detta kommando för automatisk verifiering — om skivstorleken överstiger gränsen (t.ex. 100 MB för mobil nedladdning) utfärdar pipelinen en varning.

Kontrollera resultat av Slicing

Efter uppladdning av arkivet till App Store Connect tillhandahåller Apple detaljerad statistik över skivstorlekar. App Store Connect → Activity → välj build → App Thinning — visar Estimated App Store Size för varje enhetskategori: iPhone, iPad, Apple Watch, tvOS. Storlekarna är uppdelade efter iOS-versioner och processortyper. Om en skiva överstiger den förväntade storleken markerar App Store Connect den med en gul varning.

Lokal kontroll via Xcode Organizer: efter arkivering, öppna Window → Organizer, välj arkivet och klicka på App Thinning Profiles. Xcode visar storlekarna för varje möjlig skiva baserat på den aktuella projektkonfigurationen. Det finns också Export-alternativet för att skapa en IPA med en specifik Slicing-profil. Xcode genererar filen .app-thinning.plist med information om vilka resurser som hamnade i varje skiva.

För automatisering av Slicing-kontroll i CI/CD, använd xcodebuild med -thinning och analysera storleken på de skapade .app-filerna. Apple tillhandahåller kommandoradsverktyget app-size (installeras via Xcode Command Line Tools) som skriver ut en detaljerad rapport: kodstorlek, resursstorlek per kategori (bilder, shaders, NIB), storlek på Swift-bibliotek. Jämförelse av skivstorlekar före och efter optimering av Asset Catalogs hjälper till att identifiera resurser som inte deltar i Slicing på grund av felaktig konfiguration.

# Analys av skivstorlek
app-size -m "sliced/App.app" \
  --format json

App-size skriver ut en JSON-rapport med uppdelning per resurskategori. Om Slicing är korrekt konfigurerat finns det i avsnittet „images” endast en skaluppsättning (@2x eller @3x), inte alla varianter. Ett konfigurationsfel i Asset Catalogs visar sig genom att alla skalor (@1x, @2x, @3x) finns i skivan — detta innebär att Xcode inte kunde bestämma målenheten för dessa bilder och Slicing fungerade inte.