Slicing — este un mecanism App Thinning prin care App Store creează automat mai multe variante ale fișierului binar, fiecare conținând resurse doar pentru un anumit model de dispozitiv. Conform Apple Developer Documentation, 2026, Slicing exclude din distribuție resursele pentru configurații nesuportate, reducând dimensiunea instalării. Să analizăm principiul de funcționare, variantele de tăiere și verificarea rezultatelor.
Principalele puncte
Slicing — este componenta App Thinning responsabilă de crearea variantelor (felii) ale fișierului binar al aplicației pe partea App Store. Când dezvoltatorul încarcă un fișier binar universal (fat binary) care conține cod și resurse pentru toate configurațiile suportate, App Store îl analizează și generează mai multe felii: separat pentru iPhone cu procesor A17, separat pentru iPad cu M4, separat pentru Apple Watch. Fiecare felie conține doar acele fragmente de cod și resurse care sunt necesare pentru această combinație specifică de arhitectură și rezoluție.
Înainte de iOS 9, dezvoltatorii creau manual fișiere binare separate pentru diferite dispozitive sau livrau un fat binary universal care conținea totul deodată. Slicing a automatizat complet acest proces: dezvoltatorul pregătește un proiect în Xcode, încarcă o arhivă în App Store Connect, iar Slicing pe partea de server creează numărul optim de variante. Utilizatorul nu vede niciodată procesul de tăiere — el primește un .app gata, optimizat pentru dispozitivul său.
Slicing se aplică nu doar codului și imaginilor, ci și shader-urilor Metal. Apple GPU folosește propriul set de instrucțiuni (Metal Shading Language) care diferă de instrucțiunile PowerVR sau ARM Mali. Slicing include în felie doar shader-urile pentru familia GPU a dispozitivului țintă. Acest lucru este deosebit de important pentru jocurile cu shader-uri personalizate — de exemplu, efectele avansate de post-procesare sunt compilate doar pentru dispozitivele cu GPU puternic (iPad Pro M4, iPhone 16 Pro Max).
Compilatorul Xcode creează un fat binary cu mai multe arhitecturi (armv7, arm64, arm64e), dar nu elimină resursele — toate imaginile pentru toate rezoluțiile rămân în interiorul .app. Slicing merge mai departe: analizează Asset Catalogs, shader-urile Metal și bibliotecile Swift, eliminând din fiecare felie ceea ce nu este necesar pentru un scop specific. De exemplu, din felia pentru iPhone SE nu intră grafica @3x, iar din felia pentru iPad Air — controlerele specifice iPhone (dacă sunt separate în resurse distincte).
Procesul Slicing începe după încărcarea build-ului în App Store Connect și constă din trei etape: analiză, tăiere și ambalare. În etapa de analiză, serverul App Store descompune fișierul binar, extrage din el informații despre arhitecturile suportate, dispozitive, rezoluții ale ecranelor și versiuni iOS. App Store folosește maparea tuturor modelelor comerciale Apple la specificațiile lor tehnice — baza de date a dispozitivelor (Device Database) se actualizează cu fiecare lansare iOS.
În etapa de tăiere, serverul creează copii separate ale fișierului binar pentru fiecare combinație unică. Pentru aceasta, App Store extrage din Asset Catalogs imaginile cu etichete specifice (idiom, subtype, scale), selectează doar pe cele care corespund dispozitivului țintă și construiește un nou pachet de resurse. Biblioteca standard Swift este, de asemenea, supusă tăierii — din ea sunt eliminate simbolurile și metodele neutilizate de aplicația respectivă (dead code stripping).
În etapa de ambalare, fiecare felie este plasată într-un pachet de distribuție separat și asociată cu metadate — lista modelelor de dispozitive pentru care această felie este destinată. App Store la descărcarea aplicației de către utilizator selectează felia potrivită în funcție de modelul dispozitivului, versiunea iOS și tipul conexiunii. Dacă nu există o potrivire exactă, serverul folosește cea mai apropiată felie ca specificații. Apple stochează toate variantele în rețeaua CDN CloudKit pentru livrare rapidă în întreaga lume.
Slicing — este unul dintre cele trei mecanisme App Thinning, dar aduce cea mai mare contribuție la reducerea dimensiunii descărcării. Bitcode se ocupă de optimizarea codului mașină, On-Demand Resources — de gestionarea resurselor pe dispozitiv, iar Slicing — de eliminarea resurselor redundante în etapa de distribuție. Fără Slicing, primele două mecanisme funcționează, dar utilizatorii primesc resurse pentru toate dispozitivele, ceea ce mărește dimensiunea cu 20-40% în funcție de numărul de Asset Catalogs.
Diferența dintre Slicing și Bitcode este în punctul de aplicare: Slicing funcționează la nivel de resurse (imagini, shader-uri, fișiere NIB), Bitcode — la nivel de cod mașină. Slicing împarte codul pe arhitecturi (arm64 vs arm64e), Bitcode permite Apple să recompileze codul pentru arhitecturi noi. Bitcode + Slicing împreună oferă optimizare maximă: Bitcode generează cod pentru arhitectura specifică, iar Slicing elimină resursele inutile pentru acea arhitectură.
Relația cu On-Demand Resources — Slicing și ODR nu se suprapun. Slicing decide ce resurse vor intra în distribuția pe dispozitiv, iar ODR gestionează când aceste resurse se încarcă și se descarcă. Dezvoltatorul poate marca o resursă cu o etichetă ODR, iar Slicing o va include în felie dacă corespunde dispozitivului. Apple recomandă utilizarea tuturor celor trei mecanisme simultan pentru o dimensiune minimă de instalare.
| Mecanism | Obiect de optimizare | Când se aplică | Efect asupra dimensiunii |
|---|---|---|---|
| Slicing | Resurse (imagini, shader-uri) | Pe partea App Store | Elimină ~30% resurse inutile |
| Bitcode | Cod mașină | La descărcare de către utilizator | Optimizarea codului pentru arhitectură |
| ODR | Resurse pe dispozitiv | După instalare | Reduce dimensiunea inițială cu 40-60% |
Slicing creează felii separate după mai multe dimensiuni: arhitectura procesorului, dimensiunea ecranului (rezoluția), versiunea iOS și familia GPU (pentru Metal). Arhitectura determină setul de instrucțiuni CPU: arm64 — setul de bază pe 64 de biți (iPhone 5s — iPhone X), arm64e — set extins cu suport pentru Pointer Authentication și PAC (iPhone XS și mai noi, iPad Pro cu A12X+). Felia pentru arm64e include cod cu instrucțiuni de protecție a memoriei indisponibile pe dispozitivele arm64.
Rezoluția ecranului — a doua dimensiune cheie a Slicing. Apple folosește scările @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus și mai noi) și specifice iPad (2x și 3x cu metrici suplimentare). Slicing include în felie doar imaginile cu scara corespunzătoare dispozitivului țintă. Cu o organizare corectă a Asset Catalogs în Xcode, acest lucru elimină necesitatea gestionării manuale a seturilor de resurse — este suficient să adăugați imaginea în catalog, specificând tipurile de dispozitive suportate.
Familia GPU — a treia dimensiune, critică pentru aplicațiile Metal. Apple folosește clasificarea GPU pe generații: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Shader-urile Metal sunt compilate pentru fiecare familie separat, deoarece setul de instrucțiuni Metal Shading Language se extinde cu fiecare generație GPU. Slicing include în felie doar shader-urile pentru familia GPU a dispozitivului țintă, ceea ce reduce semnificativ dimensiunea jocurilor și aplicațiilor care folosesc Metal pentru randare.
Arhitectura CPU influențează direct dimensiunea feliei: codul arm64e conține instrucțiuni suplimentare Pointer Authentication (PAC) și Signed Return Address care măresc fișierul binar cu 5-10% față de arm64. Totuși, această creștere este compensată de faptul că Slicing include codul arm64e doar în felii pentru dispozitive cu procesoare A12+. Pentru iPhone SE (a treia generație) cu A15 Bionic, Slicing creează o felie separată optimizată pentru capacitățile acestui cip.
Configurarea Slicing în Xcode este minimă — configurarea principală se face prin Asset Catalogs și Build Settings. Asset Catalog trebuie să conțină resurse organizate pe tipuri de dispozitive (Any, iPhone, iPad, Apple Watch, Apple TV) cu indicarea corectă a scării și modului de afișare. Xcode include automat în compilare doar resursele care corespund dispozitivelor țintă specificate în setările Deployment Target.
Setarea cheie a Slicing în Xcode — Build Setting App Thinning. Valorile disponibile:
Targeted Device Families în General → Deployment Info determină pentru ce tipuri de dispozitive este compilată aplicația (iPhone / iPad / Universal). Slicing se bazează pe acest parametru la tăiere — dacă aplicația suportă doar iPhone, felia pentru iPad nu este creată. Deployment Target (versiunea minimă iOS) influențează și el Slicing: pentru versiunile vechi de iOS pot fi necesare felii armv7 care nu sunt necesare pentru iOS 13+. Apple recomandă setarea Deployment Target la cea mai recentă versiune stabilă iOS — aceasta reduce numărul de felii și dimensiunea fișierului binar.
Pentru o eficiență maximă a Slicing, Asset Catalogs trebuie să folosească etichete specifice pentru fiecare resursă. Xcode oferă în Attributes Inspector pentru imagini: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Combinând aceste etichete, dezvoltatorul controlează în care felii va intra fiecare imagine. De exemplu, o imagine pentru iPad cu eticheta Regular Width + Regular Height va intra doar în felii pentru iPad în orientare landscape.
# Exportul feliei pentru un dispozitiv specific
xcodebuild -exportArchive \
-archivePath "App.xcarchive" \
-exportPath "sliced/" \
-exportOptionsPlist "export.plist" \
-thinning "iPhone17,2" # iPhone 16 Pro Max
Xcodebuild cu parametrul -thinning și identificatorul de model creează o felie doar pentru acest model. Lista identificatorilor poate fi găsită în Device Database Apple (format: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Această metodă este utilă pentru verificarea dimensiunii feliei înainte de trimiterea în App Store Connect. CI/CD poate folosi această comandă pentru verificare automată — dacă dimensiunea feliei depășește limita (de exemplu, 100 MB pentru descărcare mobilă), pipeline emite o avertizare.
După încărcarea arhivei în App Store Connect, Apple oferă statistici detaliate despre dimensiunile feliiilor. App Store Connect → Activity → selectați build-ul → App Thinning — afișează Estimated App Store Size pentru fiecare categorie de dispozitive: iPhone, iPad, Apple Watch, tvOS. Dimensiunile sunt împărțite pe versiuni iOS și tipuri de procesoare. Dacă o felie depășește dimensiunea așteptată, App Store Connect o marchează cu un avertisment galben.
Verificare locală prin Xcode Organizer: după arhivare, deschideți Window → Organizer, selectați arhiva și faceți clic pe App Thinning Profiles. Xcode va afișa dimensiunile pentru fiecare felie posibilă pe baza configurației curente a proiectului. De asemenea, este disponibilă opțiunea Export pentru crearea unui IPA cu un profil Slicing specific. Xcode generează fișierul .app-thinning.plist cu informații despre ce resurse au intrat în fiecare felie.
Pentru automatizarea verificării Slicing în CI/CD, utilizați xcodebuild cu -thinning și analizați dimensiunea fișierelor .app create. Apple oferă instrumentul de linie de comandă app-size (instalat prin Xcode Command Line Tools) care afișează un raport detaliat: dimensiunea codului, dimensiunea resurselor pe categorii (imagini, shader-uri, NIB), dimensiunea bibliotecilor Swift. Compararea dimensiunilor feliiilor înainte și după optimizarea Asset Catalogs ajută la identificarea resurselor care nu participă la Slicing din cauza unei configurații incorecte.
# Analiza dimensiunii feliei
app-size -m "sliced/App.app" \
--format json
App-size afișează un raport JSON cu defalcare pe categorii de resurse. Dacă Slicing este configurat corect, în secțiunea „images” va fi doar un set de scară (@2x sau @3x), nu toate variantele. Eroarea de configurare a Asset Catalogs se manifestă prin faptul că toate scările (@1x, @2x, @3x) sunt prezente în felie — înseamnă că Xcode nu a putut determina dispozitivul țintă pentru aceste imagini, iar Slicing nu a funcționat.
Întrebări frecvente
Da, TestFlight suportă și Slicing. Când testerul descarcă aplicația prin TestFlight, serverul Apple livrează o felie optimizată pentru dispozitivul testerului. App Store Connect procesează automat Slicing pentru toate distribuțiile, inclusiv TestFlight, cu excepția build-urilor Enterprise și Ad Hoc.
Da, în Asset Catalogs pentru fiecare imagine puteți debifa anumite tipuri de dispozitive. Xcode permite în Attributes Inspector să specificați pentru care Idiom (iPhone, iPad, Apple Watch, Mac) și scări resursa trebuie inclusă. Dacă resursa este necesară tuturor dispozitivelor, utilizați Universal cu orice scară.
Framework-urile personalizate (.framework) participă și ele la Slicing dacă sunt compilate ca XCFramework (cu mai multe arhitecturi). App Store include în felie doar arhitectura framework-ului care corespunde dispozitivului țintă. Bibliotecile statice (.a) nu sunt supuse Slicing — ele sunt încorporate în fișierul binar integral.
Xcode Organizer arată estimated size — dimensiunea estimată fără a lua în considerare tăierea reală pe serverele Apple. App Store Connect afișează dimensiunea reală după Slicing, care poate fi cu 10-15% mai mică decât cea estimată, deoarece serverul aplică optimizări suplimentare (algoritmi de compresie LZFSE, Zstandard) indisponibile local.
Da, Slicing este complet compatibil cu SwiftUI. Asset Catalogs sunt utilizate de SwiftUI prin tipurile Image, Color, SymbolImage. Slicing se aplică imaginilor vectoriale și raster, simbolurilor SF Symbols și shader-urilor Metal, indiferent dacă pentru construirea interfeței se folosește SwiftUI sau UIKit.
Rezumat
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și