App Thinning — vad det är, vilka komponenter det består av och hur det fungerar

Vad är App Thinning

App Thinning är en omfattande optimeringsteknik för distribution av iOS-appar som introducerades av Apple tillsammans med iOS 9 (september 2015). Målet med App Thinning är att minimera storleken på den app som användaren laddar ner till sin enhet, utan att ändra källkoden och funktionaliteten. Tekniken fungerar på tre nivåer: i byggfasen (kompilering), på App Store-sidan (leverans) och på enheten (resurshantering).

Före tillkomsten av App Thinning inkluderade utvecklare resurser för alla möjliga enheter i den binära filen — @2x- och @3x-bilder, 32-bitars och 64-bitars kod, Metal-shaders för olika GPU:er. Detta ledde till en uppsvälld appstorlek: en användare av iPhone 6 Plus med Retina HD-skärm fick vektorresurser för iPad Pro som aldrig användes. Apple löste detta problem genom att flytta en del av byggarbetet till App Stores servrar.

Enligt Apples forskning (WWDC 2015, Session 412) kan en typisk app med stöd för flera arkitekturer och upplösningar minska med 30-50% efter tillämpning av App Thinning. För spel med många högdetailjerade texturer kan besparingen nå 70-80%. Apple fortsätter att förbättra tekniken: i iOS 17 lades optimering för ARM64e till och arbetet med On-Demand Resources för appar som använder Swift Package Manager förbättrades.

Problemet som App Thinning löser

Storleken på mobilappar ökar ständigt. Enligt data från Sensor Tower (2025) har den genomsnittliga storleken på en iOS-app ökat med 45% under de senaste 5 åren. För användare med begränsat dataabonnemang eller långsamt internet spelar varje megabyte roll. App Thinning löser detta problem utan utvecklarens medverkan — det räcker med att aktivera stöd i projektinställningarna och ladda upp bygget till App Store Connect.

Hur App Thinning fungerar

Processen för App Thinning börjar efter uppladdning av apparkivet till App Store Connect. App Store analyserar den binära filen och delar upp den i segment baserat på arkitekturer (armv7, arm64, arm64e), skärmupplösningar (iPhone, iPad) och iOS-versioner. För varje kombination skapas en separat variant. När användaren klickar på ”Ladda ner” bestämmer App Store enhetsmodellen, iOS-versionen och anslutningstypen (Wi-Fi / mobilt nätverk) och skickar endast motsvarande variant.

För användaren är processen transparent — det finns inget val av ”lätt version” eller en dialogruta med inställningar. App Store väljer automatiskt den mest lämpliga varianten baserat på enhetens metadata som skickas till servern vid nedladdningsbegäran. Om enheten använder Wi-Fi kan App Store skicka en variant med resurser av högre kvalitet (t.ex. ProRes-video för iPhone 16 Pro). Vid nedladdning via mobilt nätverk används den minsta möjliga uppsättningen.

Den andra optimeringsnivån — Bitcode. Med alternativet ENABLE_BITCODE aktiverat kompilerar Xcode appen inte till maskinkod, utan till en mellanliggande LLVM-representation. App Store kompilerar om Bitcode för användarens specifika processorarkitektur, vilket gör att Apple kan tillämpa kompilatoroptimeringar för nya generationer av chip (A17, M4) utan att utvecklaren behöver uppdatera appen. Bitcode är obligatoriskt för watchOS och tvOS, men valfritt för iOS.

Komponenter i App Thinning: Slicing, Bitcode, ODR

App Thinning består av tre oberoende mekanismer, som var och en ansvarar för sin egen aspekt av optimeringen. Slicing (skivning) delar upp den binära filen i varianter baserat på arkitektur och skärmupplösning. Utvecklaren konfigurerar Slicing via Asset Catalogs — Xcode inkluderar automatiskt i skivan endast de resurser som motsvarar målenheten. Till exempel kommer iPhone SE (tredje generationen) endast att få @2x-bilder och arm64-kod, medan iPad Pro M4 får @3x-bilder och arm64e-kod.

Bitcode är LLVM IR (Intermediate Representation) — en maskinoberoende representation av programmet. När Bitcode är aktiverat genererar Xcode inte slutgiltig maskinkod, utan sparar mellanrepresentationen. App Store Connect tar emot Bitcode vid uppladdning av bygget och kompilerar om det för arkitekturerna hos alla enheter som stöds. Bitcode tillåter Apple att tillämpa optimeringar som inte är tillgängliga under kompileringen hos utvecklaren — till exempel användning av nya processorinstruktioner (SME, SVE) på M4-chip.

On-Demand Resources (ODR) — den tredje mekanismen, som gör det möjligt att avlasta appresurser efter användning. Utvecklaren markerar resurser (spelnivåer, onboarding-bilder, videor) med ODR-taggar. iOS laddar de markerade resurserna på begäran i bakgrunden och avlastar dem vid minnesbrist eller efter användning. ODR är särskilt effektiva för spel med mycket innehåll — de första nivåerna kan levereras i appen och resten laddas allt eftersom spelaren fortskrider.

När man ska välja varje komponent

Valet av App Thinning-mekanismer beror på apptypen och dess målgrupp. Slicing rekommenderas att alltid vara aktiverat — det kräver inga ytterligare åtgärder från utvecklaren förutom korrekt organisation av Asset Catalogs och ger en stabil storleksminskning på 20-30%. Bitcode är värt att aktivera om appen använder anpassade Metal-shaders eller planerar att stödja nya Apple-arkitekturer utan ombyggnad. ODR är motiverat för appar med stor volym innehåll — spel, fotoredigerare, streaming-appar.

För en typisk affärsapp (dataflöden, formulär, REST API) räcker Slicing och minimal ODR-konfiguration för onboarding-bilder. Spel med 3D-grafik drar nytta av alla tre mekanismerna: Slicing tar bort onödiga shaders, Bitcode optimerar rendering för GPU och ODR avlastar slutförda nivåer. Enligt Apple (WWDC 2024) minskar kombinationen av alla tre mekanismer den initiala installationsstorleken med i genomsnitt 45-55% jämfört med en universell binärfil.

Konfigurera App Thinning i Xcode

För att aktivera App Thinning i ett Xcode-projekt måste flera steg utföras. Slicing konfigureras via App Thinning i bygginställningarna: Build Settings → App Thinning. Tre värden finns tillgängliga: None (utan optimering), Automatic (standard automatisk konfiguration) och Manual med val av specifika varianter för testning. Apple rekommenderar Automatic för de flesta projekt.

För Asset Catalogs är korrekt organisation av resurser viktigt: bilder placeras i en universell katalog med angivande av bredd/höjd, och Xcode skapar automatiskt @1x-, @2x- och @3x-varianterna. Xcode inkluderar vid byggandet endast de upplösningar som används i projektet. Metal-shaders kompileras separat för varje GPU-familj — Apple GPU, PowerVR, Mali, vilket också hanteras via Asset Catalogs.

Bitcode aktiveras med flaggan ENABLE_BITCODE = YES i Build Settings. För iOS är denna flagga valfri (inaktiverad som standard sedan Xcode 14), men för watchOS och tvOS är den obligatorisk. När Bitcode aktiveras i ett projekt som använder tredjepartsbibliotek måste alla dessa också vara byggda med Bitcode, annars misslyckas bygget. Bitcode ökar kompileringstiden med 20-30%, men säkerställer full kompatibilitet med framtida arkitekturer.

Kontroll av App Thinning-resultat

Efter uppladdning till App Store Connect kan du kontrollera skivornas storlekar i avsnittet Activity → Build Metric. App Store Connect visar Estimated App Store Size för olika enheter. För lokal kontroll tillhandahåller Xcode kommandot xcodebuild med flaggan -exportArchive och alternativet thinning för att skapa skivor på den lokala datorn. Resultatet av Slicing kan ses i Organizer (Window → Organizer) efter arkivering — fliken App Thinning Profiles visar storlekarna för olika enheter.

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

Xcodebuild med flaggan -thinning skapar .app-filer för varje kombination av arkitektur, bit och GPU. Parametern <thin-for-all-variants> skapar alla möjliga varianter — användbart för kontroll. För CI-pipelines används en specifik kombination, till exempel iPhone14,4 (iPhone SE 3). De resulterande .app-filerna kan analyseras med verktyget app-size.

Fördelar och effekter av App Thinning

Den främsta fördelen med App Thinning är minskad nedladdningsstorlek för slutanvändaren. Enligt Apple (WWDC 2024) laddas en typisk app som använder alla tre App Thinning-mekanismerna i genomsnitt 40% snabbare via mobilt nätverk och tar upp 35% mindre diskutrymme. Detta påverkar direkt installationskonverteringen: enligt Sensor Tower minskar varje 10 MB appstorlek konverteringen med 1%.

Den andra fördelen — optimering för framtida enheter tack vare Bitcode. Apple kan kompilera om Bitcode-appar för nya arkitekturer utan utvecklarens medverkan. Till exempel vid övergången från Intel till Apple Silicon (M1) fungerade Bitcode-appar på macOS via Rosetta 2 utan ytterligare kompilering. Utvecklare som inte aktiverade Bitcode tvingades bygga om sina appar för arm64.

Den tredje fördelen — ODR (On-Demand Resources) minskar belastningen på enhetens lagring. Spel med dussintals nivåer, som Asphalt 8: Airborne, använder ODR för att ladda nya banor allt eftersom spelaren fortskrider. Utvecklaren kan ställa in Initial Install Tags för resurser som laddas tillsammans med appen och Prefetch Tags för innehåll som laddas i bakgrunden efter installation. Apple kontrollerar ODR-gränserna: upp till 512 MB per begäran och upp till 20 GB total cache på enheten.

Begränsningar för App Thinning

App Thinning har flera viktiga begränsningar som måste beaktas vid utformningen av appen. För det första tillämpas Slicing inte på appar som distribueras via Enterprise (in-house) eller Ad Hoc — dessa byggen innehåller alla varianter och går inte via App Store. För att testa Slicing kan utvecklaren använda TestFlight, som också bearbetar Slicing på Apples serversida.

För det andra ökar Bitcode byggtiden och storleken på .xcarchive-arkivet med cirka 30-50%. Alla tredjepartsbibliotek stöder inte Bitcode — om minst ett beroende är byggt utan Bitcode kommer bygget av projektet med ENABLE_BITCODE att misslyckas. Apple rekommenderar att kontrollera bibliotekens kompatibilitet innan Bitcode aktiveras. Dessutom stöder Bitcode inte Swift Package Manager fullt ut — vissa Swift-paket kan störa Bitcode-bygget.

För det tredje garanterar On-Demand Resources inte omedelbar tillgång till innehåll — ODR-laddning sker i bakgrunden och kan försenas om enheten är i lågt batteriläge eller svag nätverkssignal. Utvecklaren måste implementera hantering av ODR-laddningsstatus via NSBundleResourceRequest och visa en förloppsindikator för användaren. Misslyckad ODR-laddning bör inte blockera appens funktionalitet — en graceful fallback är nödvändig.