Slicing: Was es ist, Funktionsprinzip und Zusammenhang mit App Thinning

Was ist Slicing

Slicing ist eine Komponente von App Thinning, die für die Erstellung von Varianten (Scheiben) der Anwendungsbinärdatei auf Seiten des App Store verantwortlich ist. Wenn der Entwickler eine universelle Fat-Binary hochlädt, die Code und Ressourcen für alle unterstützten Konfigurationen enthält, analysiert der App Store sie und generiert mehrere Scheiben: separat für iPhone mit A17-Prozessor, separat für iPad mit M4, separat für Apple Watch. Jede Scheibe enthält nur die Codefragmente und Ressourcen, die für diese spezifische Kombination von Architektur und Auflösung erforderlich sind.

Vor iOS 9 erstellten Entwickler manuell separate Binärdateien für verschiedene Geräte oder lieferten eine universelle Fat-Binary, die alles auf einmal enthielt. Slicing automatisierte diesen Prozess vollständig: Der Entwickler erstellt ein Projekt in Xcode, lädt ein Archiv in App Store Connect hoch, und Slicing auf der Serverseite erstellt die optimale Anzahl von Varianten. Der Benutzer sieht den Slicing-Prozess nie — er erhält eine fertige .app, optimiert für sein Gerät.

Slicing gilt nicht nur für Code und Bilder, sondern auch für Metal-Shader. Apple GPU verwendet einen eigenen Befehlssatz (Metal Shading Language), der sich von PowerVR- oder ARM-Mali-Befehlen unterscheidet. Slicing nimmt in die Scheibe nur Shader für die GPU-Familie des Zielgeräts auf. Dies ist besonders wichtig für Spiele mit benutzerdefinierten Shadern — zum Beispiel werden hochdetaillierte Nachbearbeitungseffekte nur für Geräte mit leistungsstarker GPU (iPad Pro M4, iPhone 16 Pro Max) kompiliert.

Unterschied zwischen Slicing und einfacher Architekturkompilierung

Der Xcode-Compiler erstellt eine Fat-Binary mit mehreren Architekturen (armv7, arm64, arm64e), entfernt jedoch keine Ressourcen — alle Bilder für alle Auflösungen bleiben innerhalb der .app. Slicing geht weiter: Es analysiert Asset Catalogs, Metal-Shader und Swift-Bibliotheken und entfernt aus jeder Scheibe, was für das spezifische Ziel nicht benötigt wird. Beispielsweise gelangen @3x-Grafiken nicht in die Scheibe für iPhone SE, und iPhone-spezifische Controller (wenn in separate Ressourcen ausgelagert) gelangen nicht in die Scheibe für iPad Air.

Wie Slicing funktioniert

Der Slicing-Prozess beginnt nach dem Hochladen des Builds in App Store Connect und besteht aus drei Phasen: Analyse, Slicing und Paketierung. In der Analyse-Phase parst der App Store-Server die Binärdatei, extrahiert Informationen über unterstützte Architekturen, Geräte, Bildschirmauflösungen und iOS-Versionen. Der App Store verwendet eine Zuordnung aller kommerziellen Apple-Modelle zu ihren technischen Spezifikationen — die Gerätedatenbank wird mit jeder iOS-Version aktualisiert.

In der Slicing-Phase erstellt der Server separate Kopien der Binärdatei für jede eindeutige Kombination. Dazu extrahiert der App Store Bilder aus Asset Catalogs mit bestimmten Tags (idiom, subtype, scale), wählt nur die aus, die dem Zielgerät entsprechen, und erstellt ein neues Ressourcenbündel. Die Swift-Standardbibliothek unterliegt ebenfalls dem Slicing — nicht verwendete Symbole und Methoden werden daraus entfernt (Dead Code Stripping).

In der Paketierung-Phase wird jede Scheibe in ein separates Distributionspaket gelegt und mit Metadaten verknüpft — einer Liste von Gerätemodellen, für die diese Scheibe bestimmt ist. Wenn der Benutzer die Anwendung herunterlädt, wählt der App Store die geeignete Scheibe basierend auf Gerätemodell, iOS-Version und Verbindungstyp aus. Wenn keine genaue Übereinstimmung vorliegt, verwendet der Server die in den Eigenschaften nächstgelegene Scheibe. Apple speichert alle Varianten im CloudKit-CDN-Netzwerk für eine schnelle Auslieferung weltweit.

Slicing im Kontext von App Thinning

Slicing ist einer von drei Mechanismen von App Thinning, trägt aber am meisten zur Reduzierung der Downloadgröße bei. Bitcode ist für die Optimierung des Maschinencodes zuständig, On-Demand Resources für die Ressourcenverwaltung auf dem Gerät und Slicing für die Entfernung redundanter Ressourcen in der Distributionsphase. Ohne Slicing funktionieren die ersten beiden Mechanismen zwar, aber die Benutzer erhalten Ressourcen für alle Geräte, was die Größe je nach Anzahl der Asset Catalogs um 20–40% erhöht.

Der Unterschied zwischen Slicing und Bitcode liegt im Anwendungspunkt: Slicing arbeitet auf Ressourcenebene (Bilder, Shader, NIB-Dateien), Bitcode auf Maschinencode-Ebene. Slicing teilt Code nach Architekturen (arm64 vs arm64e), Bitcode ermöglicht Apple, Code für neue Architekturen neu zu kompilieren. Bitcode + Slicing zusammen bieten maximale Optimierung: Bitcode generiert Code für eine bestimmte Architektur, und Slicing entfernt unnötige Ressourcen für diese Architektur.

Das Verhältnis zu On-Demand Resources — Slicing und ODR überlappen sich nicht. Slicing bestimmt, welche Ressourcen überhaupt in die Geräteverteilung gelangen, während ODR verwaltet, wann diese Ressourcen geladen und entladen werden. Der Entwickler kann eine Ressource mit einem ODR-Tag versehen, und Slicing wird sie in die Scheibe aufnehmen, wenn sie dem Gerät entspricht. Apple empfiehlt, alle drei Mechanismen gleichzeitig zu verwenden, um eine minimale Installationsgröße zu erreichen.

Slicing-Varianten für verschiedene Geräte

Slicing erstellt separate Scheiben nach mehreren Dimensionen: Prozessorarchitektur, Bildschirmgröße (Auflösung), iOS-Version und GPU-Familie (für Metal). Die Architektur bestimmt den CPU-Befehlssatz: arm64 — grundlegender 64-Bit-Satz (iPhone 5s — iPhone X), arm64e — erweiterter Satz mit Pointer Authentication und PAC-Unterstützung (iPhone XS und neuer, iPad Pro mit A12X+). Die Scheibe für arm64e enthält Code mit Speicherschutzbefehlen, die auf arm64-Geräten nicht verfügbar sind.

Bildschirmauflösung — die zweite Schlüsseldimension von Slicing. Apple verwendet Skalierungen @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus und neuer) und iPad-spezifische (2x und 3x mit zusätzlichen Metriken). Slicing nimmt in die Scheibe nur Bilder mit der Skalierung auf, die dem Zielgerät entspricht. Bei richtiger Organisation der Asset Catalogs in Xcode entfällt die Notwendigkeit, Ressourcensets manuell zu verwalten — fügen Sie einfach ein Bild zum Katalog hinzu und geben Sie die unterstützten Gerätetypen an.

GPU-Familie — die dritte Dimension, kritisch für Metal-Anwendungen. Apple klassifiziert GPUs nach Generationen: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Metal-Shader werden für jede Familie separat kompiliert, da der Befehlssatz von Metal Shading Language mit jeder GPU-Generation erweitert wird. Slicing nimmt in die Scheibe nur Shader für die GPU-Familie des Zielgeräts auf, was die Größe von Spielen und Anwendungen, die Metal zum Rendern verwenden, erheblich reduziert.

Auswirkung der Architektur auf die Scheibengröße

Die CPU-Architektur wirkt sich direkt auf die Scheibengröße aus: arm64e-Code enthält zusätzliche Pointer Authentication (PAC)- und Signed Return Address-Befehle, die die Binärdatei im Vergleich zu arm64 um 5–10% vergrößern. Dieser Anstieg wird jedoch dadurch ausgeglichen, dass Slicing arm64e-Code nur in Scheiben für Geräte mit A12+-Prozessoren aufnimmt. Für das iPhone SE (dritte Generation) mit A15 Bionic erstellt Slicing eine separate, auf die Fähigkeiten dieses Chips optimierte Scheibe.

Slicing in Xcode konfigurieren

Die Konfiguration von Slicing in Xcode ist minimal — die Hauptkonfiguration erfolgt über Asset Catalogs und Build Settings. Asset Catalog sollte Ressourcen enthalten, die nach Gerätetyp (Any, iPhone, iPad, Apple Watch, Apple TV) organisiert sind, mit korrekt angegebener Skalierung und Anzeigemodus. Xcode nimmt automatisch nur die Ressourcen in den Build auf, die den in den Deployment Target-Einstellungen angegebenen Zielgeräten entsprechen.

Die wichtigste Slicing-Einstellung in Xcode ist die Build Setting App Thinning. Verfügbare Werte:

• None — Slicing deaktiviert, die Anwendung wird als universelle Fat-Binary ausgeliefert
• Automatic — Xcode aktiviert Slicing mit Standardeinstellungen
• Manual — der Entwickler wählt bestimmte Kombinationen für Slicing aus

Targeted Device Families in General → Deployment Info legt fest, für welche Gerätetypen die Anwendung erstellt wird (iPhone / iPad / Universal). Slicing stützt sich beim Slicing auf diesen Parameter — wenn die Anwendung nur iPhone unterstützt, wird keine Scheibe für iPad erstellt. Deployment Target (Mindest-iOS-Version) beeinflusst ebenfalls Slicing: Ältere iOS-Versionen erfordern möglicherweise armv7-Scheiben, die für iOS 13+ nicht benötigt werden. Apple empfiehlt, Deployment Target auf die neueste stabile iOS-Version zu setzen — dies reduziert die Anzahl der Scheiben und die Binärgröße.

Asset Catalog-Parameter für Slicing

Für maximale Slicing-Effizienz sollten Asset Catalogs für jede Ressource spezifische Tags verwenden. Xcode bietet im 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). Durch Kombination dieser Tags steuert der Entwickler, in welchen Scheiben jedes Bild erscheint. Beispielsweise erscheint ein iPad-Bild mit den Tags Regular Width + Regular Height nur in Scheiben für iPad im Querformat.

# Scheibe für ein bestimmtes Gerät exportieren
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild mit dem Parameter -thinning und der Modellkennung erstellt eine Scheibe nur für dieses Modell. Die Liste der Kennungen finden Sie in der Apple-Gerätedatenbank (Format: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Diese Methode ist nützlich, um die Scheibengröße vor dem Senden an App Store Connect zu überprüfen. CI/CD kann diesen Befehl zur automatischen Überprüfung verwenden — wenn die Scheibengröße das Limit überschreitet (z.B. 100 MB für mobilen Download), gibt die Pipeline eine Warnung aus.

Slicing-Ergebnisse überprüfen

Nach dem Hochladen des Archivs in App Store Connect stellt Apple detaillierte Statistiken zu den Scheibengrößen bereit. App Store Connect → Activity → Build auswählen → App Thinning — zeigt die geschätzte App Store-Größe für jede Gerätekategorie: iPhone, iPad, Apple Watch, tvOS. Die Größen sind nach iOS-Versionen und Prozessortypen aufgeschlüsselt. Wenn eine Scheibe die erwartete Größe überschreitet, markiert App Store Connect sie mit einer gelben Warnung.

Lokale Überprüfung über Xcode Organizer: Öffnen Sie nach der Archivierung Window → Organizer, wählen Sie das Archiv aus und klicken Sie auf App Thinning Profiles. Xcode zeigt die Größen für jede mögliche Scheibe basierend auf der aktuellen Projektkonfiguration an. Die Export-Option steht ebenfalls zur Verfügung, um ein IPA mit einem bestimmten Slicing-Profil zu erstellen. Xcode generiert eine .app-thinning.plist mit Informationen darüber, welche Ressourcen in jeder Scheibe enthalten sind.

Zur Automatisierung der Slicing-Überprüfung in CI/CD verwenden Sie xcodebuild mit -thinning und analysieren die Größe der erstellten .app-Dateien. Apple stellt das Befehlszeilentool app-size bereit (über Xcode Command Line Tools installiert), das einen detaillierten Bericht ausgibt: Codegröße, Ressourcengröße nach Kategorien (Bilder, Shader, NIB), Größe der Swift-Bibliotheken. Der Vergleich der Scheibengrößen vor und nach der Asset Catalog-Optimierung hilft, Ressourcen zu identifizieren, die aufgrund falscher Konfiguration nicht am Slicing teilnehmen.

# Scheibengröße analysieren
app-size -m "sliced/App.app" \
  --format json

App-size gibt einen JSON-Bericht aus, der nach Ressourcenkategorien aufgeschlüsselt ist. Wenn Slicing korrekt konfiguriert ist, enthält der Abschnitt "images" nur einen Skalierungssatz (@2x oder @3x), nicht alle Varianten. Ein Konfigurationsfehler des Asset Catalog zeigt sich darin, dass alle Skalierungen (@1x, @2x, @3x) in der Scheibe vorhanden sind — dies bedeutet, dass Xcode das Zielgerät für diese Bilder nicht bestimmen konnte und Slicing nicht funktioniert hat.