App Thinning — cos'è, di quali componenti è composto e come funziona

Cos'è App Thinning

App Thinning — è una tecnologia completa di ottimizzazione della distribuzione delle app iOS, introdotta da Apple con iOS 9 (settembre 2015). L'obiettivo di App Thinning è minimizzare la dimensione dell'app che l'utente scarica sul proprio dispositivo, senza modificare il codice sorgente e la funzionalità. La tecnologia opera a tre livelli: nella fase di build (compilazione), dal lato dell'App Store (distribuzione) e sul dispositivo (gestione delle risorse).

Prima di App Thinning, gli sviluppatori includevano nel file binario risorse per tutti i possibili dispositivi — immagini @2x e @3x, codice a 32 e 64 bit, shader Metal per diverse GPU. Ciò portava a un gonfiamento della dimensione dell'app: un utente di iPhone 6 Plus con display Retina HD riceveva risorse vettoriali per iPad Pro che non venivano mai utilizzate. Apple ha risolto questo problema trasferendo parte del lavoro di build sui server dell'App Store.

Secondo le ricerche di Apple (WWDC 2015, Session 412), un'app tipica con supporto per più architetture e risoluzioni può essere ridotta del 30-50% dopo l'applicazione di App Thinning. Per i giochi con grandi quantità di texture ad alta definizione, il guadagno può raggiungere il 70-80%. Apple continua a migliorare la tecnologia: in iOS 17 sono state aggiunte ottimizzazioni per ARM64e e un migliore funzionamento con On-Demand Resources per le app che utilizzano Swift Package Manager.

Il problema che App Thinning risolve

La dimensione delle app mobili continua a crescere. Secondo Sensor Tower (2025), la dimensione media delle app iOS è aumentata del 45% negli ultimi 5 anni. Per gli utenti con un piano dati limitato o Internet lento, ogni megabyte conta. App Thinning risolve questo problema senza la partecipazione dello sviluppatore — basta attivare il supporto nelle impostazioni del progetto e caricare il build in App Store Connect.

Come funziona App Thinning

Il processo di App Thinning inizia dopo il caricamento dell'archivio dell'app in App Store Connect. L'App Store analizza il file binario e lo divide in segmenti per architetture (armv7, arm64, arm64e), risoluzioni dello schermo (iPhone, iPad) e versioni iOS. Per ogni combinazione viene creata una variante separata. Quando l'utente fa clic su “Scarica”, l'App Store determina il modello del dispositivo, la versione iOS e il tipo di connessione (Wi-Fi / rete mobile) e invia solo la variante corrispondente.

Per l'utente, il processo è trasparente — non c'è opzione di “versione leggera” o dialogo delle impostazioni. L'App Store seleziona automaticamente la variante più appropriata in base ai metadati del dispositivo, che vengono inviati al server durante la richiesta di download. Se il dispositivo utilizza il Wi-Fi, l'App Store può inviare una variante con risorse di qualità superiore (ad esempio, video ProRes per iPhone 16 Pro). Durante il download tramite rete mobile, viene utilizzato il set minimo possibile.

Il secondo livello di ottimizzazione — Bitcode. Quando l'opzione ENABLE_BITCODE è attivata, Xcode compila l'app non in codice macchina, ma in una rappresentazione intermedia LLVM. L'App Store ricompila il Bitcode per l'architettura del processore dell'utente, consentendo ad Apple di applicare ottimizzazioni del compilatore per le nuove generazioni di chip (A17, M4) senza che lo sviluppatore aggiorni l'app. Bitcode è obbligatorio per watchOS e tvOS, ma opzionale per iOS.

Componenti di App Thinning: Slicing, Bitcode, ODR

App Thinning si compone di tre meccanismi indipendenti, ciascuno responsabile di un aspetto dell'ottimizzazione. Il Slicing divide il file binario in varianti per architettura e risoluzione dello schermo. Lo sviluppatore configura lo Slicing tramite Asset Catalogs — Xcode include automaticamente nello slice solo le risorse che corrispondono al dispositivo di destinazione. Ad esempio, l'iPhone SE (terza generazione) riceverà solo immagini @2x e codice arm64, mentre l'iPad Pro M4 riceverà immagini @3x e codice arm64e.

Bitcode — è LLVM IR (Intermediate Representation) — una rappresentazione del programma indipendente dalla macchina. Quando Bitcode è attivato, Xcode non genera il codice macchina finale, ma salva la rappresentazione intermedia. App Store Connect durante il caricamento del build riceve il Bitcode e lo ricompila per le architetture di tutti i dispositivi supportati. Bitcode consente ad Apple di applicare ottimizzazioni non disponibili nella fase di compilazione dello sviluppatore — ad esempio, l'uso di nuove istruzioni del processore (SME, SVE) sui chip M4.

On-Demand Resources (ODR) — il terzo meccanismo, che consente di scaricare le risorse dell'app dopo l'uso. Lo sviluppatore contrassegna le risorse (livelli di gioco, immagini per l'onboarding, video) con tag ODR. iOS scarica le risorse contrassegnate su richiesta in background e le scarica in caso di carenza di memoria o dopo l'uso. Gli ODR sono particolarmente efficaci per i giochi con grandi quantità di contenuti — i primi livelli possono essere forniti con l'app e i restanti scaricati man mano che si progredisce.

Quando scegliere ogni componente

La scelta dei meccanismi di App Thinning dipende dal tipo di app e dal suo pubblico di destinazione. Il Slicing è raccomandato sempre — non richiede azioni aggiuntive dello sviluppatore oltre alla corretta organizzazione degli Asset Catalogs e offre una riduzione stabile del 20-30%. Bitcode vale la pena attivarlo se l'app utilizza shader Metal personalizzati o prevede di supportare nuove architetture Apple senza ricompilazione. ODR è giustificato per app con grandi volumi di contenuti — giochi, editor di foto, app di streaming.

Per un'app aziendale tipica (feed di dati, moduli, API REST), lo Slicing e una configurazione minima di ODR per le immagini di onboarding sono sufficienti. I giochi con grafica 3D beneficiano di tutti e tre i meccanismi: Slicing rimuove gli shader non necessari, Bitcode ottimizza il rendering per la GPU e ODR scarica i livelli completati. Secondo Apple (WWDC 2024), la combinazione di tutti e tre i meccanismi riduce la dimensione iniziale di installazione in media del 45-55% rispetto a un binario universale.

Configurare App Thinning in Xcode

Per attivare App Thinning in un progetto Xcode, è necessario eseguire diversi passaggi. Il Slicing viene configurato tramite App Thinning nelle impostazioni di build: Build Settings → App Thinning. Sono disponibili tre valori: None (senza ottimizzazione), Automatic (impostazione automatica predefinita) e Manual con selezione di varianti specifiche per il test. Apple raccomanda Automatic per la maggior parte dei progetti.

Per gli Asset Catalogs, è importante organizzare correttamente le risorse: le immagini vengono inserite in un catalogo universale con indicazione di larghezza/altezza e Xcode crea automaticamente le varianti @1x, @2x e @3x. Xcode durante la build include solo le risoluzioni utilizzate nel progetto. Gli shader Metal vengono compilati separatamente per ogni famiglia di GPU — Apple GPU, PowerVR, Mali — anch'esso gestito tramite Asset Catalogs.

Bitcode viene attivato con il flag ENABLE_BITCODE = YES in Build Settings. Per iOS, questo flag è opzionale (disattivato per impostazione predefinita da Xcode 14), ma per watchOS e tvOS è obbligatorio. Attivando Bitcode in un progetto che utilizza librerie di terze parti, tutte devono essere compilate con Bitcode, altrimenti la build fallirà. Bitcode aumenta il tempo di compilazione del 20-30%, ma offre piena compatibilità con le architetture future.

Verifica dei risultati di App Thinning

Dopo il caricamento in App Store Connect, le dimensioni degli slice possono essere verificate nella sezione Activity → Build Metric. App Store Connect mostra la dimensione stimata dell'App Store per diversi dispositivi. Per la verifica locale, Xcode fornisce il comando xcodebuild con il flag -exportArchive e l'opzione thinning per creare slice sulla macchina locale. Il risultato dello Slicing può essere visto nell'Organizer (Window → Organizer) dopo l'archiviazione — la scheda App Thinning Profiles mostra le dimensioni per diversi dispositivi.

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

Xcodebuild con il flag -thinning crea file .app per ogni combinazione di architettura, larghezza di bit e GPU. Il parametro <thin-for-all-variants> crea tutte le varianti possibili — utile per la verifica. Per le pipeline CI, specificare una combinazione specifica, ad esempio iPhone14,4 (iPhone SE 3). I file .app risultanti possono essere analizzati con l'utilità app-size.

Vantaggi e impatto di App Thinning

Il principale vantaggio di App Thinning è la riduzione della dimensione del download per l'utente finale. Secondo Apple (WWDC 2024), un'app tipica che utilizza tutti e tre i meccanismi di App Thinning viene scaricata in media il 40% più velocemente sulla rete mobile e occupa il 35% in meno di spazio sul disco. Ciò influisce direttamente sul tasso di conversione dell'installazione: secondo Sensor Tower, ogni 10 MB di dimensione dell'app riducono la conversione dell'1%.

Il secondo vantaggio — ottimizzazione per dispositivi futuri tramite Bitcode. Apple può ricompilare le app Bitcode per nuove architetture senza la partecipazione dello sviluppatore. Ad esempio, durante la transizione da Intel ad Apple Silicon (M1), le app Bitcode funzionavano su macOS tramite Rosetta 2 senza build aggiuntiva. Gli sviluppatori che non avevano attivato Bitcode sono stati costretti a ricompilare le loro app per arm64.

Il terzo vantaggio — ODR (On-Demand Resources) riduce il carico sulla memoria del dispositivo. Giochi con decine di livelli, come Asphalt 8: Airborne, utilizzano ODR per scaricare nuove piste man mano che si progredisce. Lo sviluppatore può impostare Initial Install Tags per le risorse scaricate con l'app e Prefetch Tags per i contenuti scaricati in background dopo l'installazione. Apple controlla i limiti ODR: fino a 512 MB per richiesta e fino a 20 GB di cache totale sul dispositivo.

Limitazioni di App Thinning

App Thinning presenta diverse limitazioni importanti da considerare durante la progettazione dell'app. In primo luogo, lo Slicing non si applica alle app distribuite tramite Enterprise (in-house) o Ad Hoc — questi build contengono tutte le varianti e non passano attraverso l'App Store. Per testare lo Slicing, lo sviluppatore può utilizzare TestFlight, che elabora anche lo Slicing sui server Apple.

In secondo luogo, Bitcode aumenta il tempo di build e la dimensione dell'archivio .xcarchive di circa il 30-50%. Non tutte le librerie di terze parti supportano Bitcode — se almeno una dipendenza è compilata senza Bitcode, la build del progetto con ENABLE_BITCODE fallirà. Apple raccomanda di verificare la compatibilità delle librerie prima di attivare Bitcode. Inoltre, Bitcode non supporta Swift Package Manager nella sua interezza — alcuni pacchetti Swift possono rompere la build Bitcode.

In terzo luogo, gli On-Demand Resources non garantiscono la disponibilità immediata dei contenuti — il download ODR avviene in background e può essere ritardato se il dispositivo è in modalità di risparmio energetico o con segnale debole. Lo sviluppatore deve implementare la gestione degli stati di download ODR tramite NSBundleResourceRequest e mostrare un indicatore di progresso all'utente. Un errore di download ODR non deve bloccare la funzionalità dell'app — è necessario un graceful fallback.