Slicing: definizione, principio di funzionamento e relazione con App Thinning

Cos'è lo Slicing

Slicing è un componente di App Thinning responsabile della creazione di varianti (fette) del file binario dell'applicazione sul lato App Store. Quando lo sviluppatore carica un binario universale (fat binary) contenente codice e risorse per tutte le configurazioni supportate, l'App Store lo analizza e genera più fette: separatamente per iPhone con processore A17, separatamente per iPad con M4, separatamente per Apple Watch. Ogni fetta contiene solo i frammenti di codice e le risorse necessari per quella specifica combinazione di architettura e risoluzione.

Prima di iOS 9, gli sviluppatori creavano manualmente file binari separati per diversi dispositivi o distribuivano un fat binary universale che conteneva tutto in una volta. Lo Slicing ha completamente automatizzato questo processo: lo sviluppatore prepara un progetto in Xcode, carica un archivio su App Store Connect, e lo Slicing lato server crea il numero ottimale di varianti. L'utente non vede mai il processo di taglio — riceve un .app pronto, ottimizzato per il suo dispositivo.

Lo Slicing si applica non solo al codice e alle immagini, ma anche agli shader Metal. La GPU Apple utilizza il proprio set di istruzioni (Metal Shading Language), che differisce dalle istruzioni PowerVR o ARM Mali. Lo Slicing include nella fetta solo gli shader per la famiglia GPU del dispositivo di destinazione. Ciò è particolarmente importante per i giochi con shader personalizzati — ad esempio, gli effetti di post-elaborazione ad alta qualità vengono compilati solo per dispositivi con GPU potente (iPad Pro M4, iPhone 16 Pro Max).

Differenza tra Slicing e semplice compilazione per architettura

Il compilatore Xcode crea un fat binary con più architetture (armv7, arm64, arm64e), ma non rimuove le risorse — tutte le immagini per tutte le risoluzioni rimangono all'interno del .app. Lo Slicing va oltre: analizza Asset Catalogs, shader Metal e librerie Swift, rimuovendo da ogni fetta ciò che non è necessario per la destinazione specifica. Ad esempio, la grafica @3x non finisce nella fetta per iPhone SE, e i controller specifici per iPhone (se estratti in risorse separate) non finiscono nella fetta per iPad Air.

Come funziona lo Slicing

Il processo di Slicing inizia dopo il caricamento del build su App Store Connect e si compone di tre fasi: analisi, taglio e impacchettamento. Nella fase di analisi, il server App Store analizza il file binario, estrae informazioni sulle architetture, dispositivi, risoluzioni dello schermo e versioni iOS supportate. L'App Store utilizza una mappatura di tutti i modelli commerciali Apple alle loro specifiche tecniche — il database dei dispositivi viene aggiornato con ogni versione di iOS.

Nella fase di taglio, il server crea copie separate del file binario per ogni combinazione unica. Per farlo, l'App Store estrae immagini dagli Asset Catalogs con tag specifici (idiom, subtype, scale), seleziona solo quelle corrispondenti al dispositivo di destinazione e assembla un nuovo pacchetto di risorse. La libreria standard Swift è anch'essa sottoposta al taglio — i simboli e i metodi non utilizzati vengono rimossi (dead code stripping).

Nella fase di impacchettamento, ogni fetta viene inserita in un pacchetto di distribuzione separato e collegata a metadati — un elenco di modelli di dispositivo per cui questa fetta è destinata. Quando l'utente scarica l'applicazione, l'App Store seleziona la fetta appropriata in base al modello del dispositivo, alla versione iOS e al tipo di connessione. Se non c'è una corrispondenza esatta, il server utilizza la fetta più vicina per caratteristiche. Apple memorizza tutte le varianti nella rete CDN di CloudKit per una consegna rapida in tutto il mondo.

Lo Slicing nel contesto di App Thinning

Lo Slicing è uno dei tre meccanismi di App Thinning, ma è quello che contribuisce maggiormente alla riduzione delle dimensioni di download. Bitcode si occupa dell'ottimizzazione del codice macchina, On-Demand Resources della gestione delle risorse sul dispositivo, e lo Slicing della rimozione delle risorse ridondanti nella fase di distribuzione. Senza Slicing, i primi due meccanismi funzionano, ma gli utenti ricevono risorse per tutti i dispositivi, aumentando le dimensioni del 20–40% a seconda del numero di Asset Catalogs.

La differenza tra Slicing e Bitcode risiede nel punto di applicazione: lo Slicing lavora a livello di risorse (immagini, shader, file NIB), Bitcode a livello di codice macchina. Lo Slicing divide il codice per architetture (arm64 vs arm64e), Bitcode consente ad Apple di ricompilare il codice per nuove architetture. Bitcode + Slicing insieme offrono la massima ottimizzazione: Bitcode genera codice per un'architettura specifica e lo Slicing rimuove le risorse non necessarie per quell'architettura.

Il rapporto con On-Demand Resources — Slicing e ODR non si sovrappongono. Lo Slicing determina quali risorse arriveranno alla distribuzione sul dispositivo, mentre ODR gestisce quando queste risorse vengono caricate e scaricate. Lo sviluppatore può contrassegnare una risorsa con un tag ODR e lo Slicing la includerà nella fetta se corrisponde al dispositivo. Apple raccomanda di utilizzare tutti e tre i meccanismi simultaneamente per la dimensione di installazione minima.

Varianti di Slicing per diversi dispositivi

Lo Slicing crea fette separate secondo diverse dimensioni: architettura del processore, dimensione dello schermo (risoluzione), versione iOS e famiglia GPU (per Metal). L'architettura determina il set di istruzioni della CPU: arm64 — set base a 64 bit (iPhone 5s — iPhone X), arm64e — set esteso con supporto Pointer Authentication e PAC (iPhone XS e successivi, iPad Pro con A12X+). La fetta per arm64e include codice con istruzioni di protezione della memoria non disponibili sui dispositivi arm64.

Risoluzione dello schermo — la seconda dimensione chiave dello Slicing. Apple utilizza scale @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus e successivi) e scale specifiche per iPad (2x e 3x con metriche aggiuntive). Lo Slicing include nella fetta solo le immagini con la scala corrispondente al dispositivo di destinazione. Con una corretta organizzazione degli Asset Catalogs in Xcode, ciò elimina la necessità di gestire manualmente i set di risorse — basta aggiungere un'immagine al catalogo, specificando i tipi di dispositivo supportati.

Famiglia GPU — la terza dimensione, di importanza critica per le applicazioni Metal. Apple classifica le GPU per generazioni: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Gli shader Metal vengono compilati per ogni famiglia separatamente, poiché il set di istruzioni Metal Shading Language si espande con ogni generazione di GPU. Lo Slicing include nella fetta solo gli shader per la famiglia GPU del dispositivo di destinazione, riducendo significativamente le dimensioni di giochi e applicazioni che utilizzano Metal per il rendering.

Impatto dell'architettura sulla dimensione della fetta

L'architettura della CPU influisce direttamente sulla dimensione della fetta: il codice arm64e contiene istruzioni aggiuntive di Pointer Authentication (PAC) e Signed Return Address, che aumentano il file binario del 5–10% rispetto a arm64. Tuttavia, questo aumento è compensato dal fatto che lo Slicing include codice arm64e solo nelle fette per dispositivi con processori A12+. Per l'iPhone SE (terza generazione) con A15 Bionic, lo Slicing crea una fetta separata ottimizzata per le capacità di questo chip.

Configurazione dello Slicing in Xcode

La configurazione dello Slicing in Xcode è minima — la configurazione principale viene eseguita tramite Asset Catalogs e Build Settings. Asset Catalog deve contenere risorse organizzate per tipo di dispositivo (Any, iPhone, iPad, Apple Watch, Apple TV) con scala e modalità di visualizzazione correttamente indicate. Xcode include automaticamente nella build solo le risorse corrispondenti ai dispositivi di destinazione specificati nelle impostazioni Deployment Target.

L'impostazione chiave dello Slicing in Xcode è il Build Setting App Thinning. Valori disponibili:

• None — Slicing disattivato, l'applicazione viene distribuita come fat binary universale
• Automatic — Xcode attiva lo Slicing con le impostazioni predefinite
• Manual — lo sviluppatore seleziona combinazioni specifiche per lo Slicing

Targeted Device Families in General → Deployment Info determina per quali tipi di dispositivo viene compilata l'applicazione (iPhone / iPad / Universal). Lo Slicing si basa su questo parametro durante il taglio — se l'applicazione supporta solo iPhone, non viene creata una fetta per iPad. Deployment Target (versione minima iOS) influisce anch'esso sullo Slicing: le versioni iOS precedenti potrebbero richiedere fette armv7, non necessarie per iOS 13+. Apple raccomanda di impostare Deployment Target all'ultima versione stabile di iOS — ciò riduce il numero di fette e la dimensione del binario.

Parametri di Asset Catalog per lo Slicing

Per la massima efficienza dello Slicing, gli Asset Catalogs devono utilizzare tag specifici per ogni risorsa. Xcode fornisce in Attributes Inspector per le immagini: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Combinando questi tag, lo sviluppatore controlla in quali fette appare ogni immagine. Ad esempio, un'immagine per iPad con i tag Regular Width + Regular Height apparirà solo nelle fette per iPad in orientamento orizzontale.

# Esportare la fetta per un dispositivo specifico
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild con il parametro -thinning e l'identificatore del modello crea una fetta solo per quel modello. L'elenco degli identificatori si trova nel database dei dispositivi Apple (formato: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Questo metodo è utile per verificare la dimensione della fetta prima dell'invio ad App Store Connect. CI/CD può utilizzare questo comando per la verifica automatica — se la dimensione della fetta supera il limite (ad esempio, 100 MB per download mobile), la pipeline emette un avviso.

Verifica dei risultati dello Slicing

Dopo aver caricato l'archivio su App Store Connect, Apple fornisce statistiche dettagliate sulle dimensioni delle fette. App Store Connect → Activity → seleziona il build → App Thinning — mostra la dimensione stimata dell'App Store per ogni categoria di dispositivo: iPhone, iPad, Apple Watch, tvOS. Le dimensioni sono suddivise per versioni iOS e tipi di processore. Se una fetta supera la dimensione prevista, App Store Connect la contrassegna con un avviso giallo.

Verifica locale tramite Xcode Organizer: dopo l'archiviazione, apri Window → Organizer, seleziona l'archivio e fai clic su App Thinning Profiles. Xcode mostrerà le dimensioni per ogni possibile fetta in base alla configurazione corrente del progetto. L'opzione Export è disponibile anche per creare un IPA con un profilo di Slicing specifico. Xcode genera un file .app-thinning.plist con informazioni su quali risorse sono incluse in ogni fetta.

Per automatizzare la verifica dello Slicing in CI/CD, utilizza xcodebuild con -thinning e analizza la dimensione dei file .app creati. Apple fornisce l'utilità da riga di comando app-size (installata tramite Xcode Command Line Tools), che genera un report dettagliato: dimensione del codice, dimensione delle risorse per categoria (immagini, shader, NIB), dimensione delle librerie Swift. Il confronto delle dimensioni delle fette prima e dopo l'ottimizzazione degli Asset Catalogs aiuta a identificare le risorse che non partecipano allo Slicing a causa di una configurazione errata.

# Analizzare la dimensione della fetta
app-size -m "sliced/App.app" \
  --format json

App-size genera un report JSON suddiviso per categorie di risorse. Se lo Slicing è configurato correttamente, nella sezione “images” sarà presente solo un set di scala (@2x o @3x), non tutte le varianti. Un errore di configurazione di Asset Catalog si manifesta quando tutte le scale (@1x, @2x, @3x) sono presenti nella fetta — ciò significa che Xcode non ha potuto determinare il dispositivo di destinazione per queste immagini e lo Slicing non ha funzionato.