App Thinning — was es ist, aus welchen Komponenten es besteht und wie es funktioniert

Was ist App Thinning

App Thinning — eine umfassende Technologie zur Optimierung der iOS-App-Verteilung, die von Apple mit iOS 9 (September 2015) eingeführt wurde. Das Ziel von App Thinning ist es, die Größe der App, die der Benutzer auf sein Gerät herunterlädt, zu minimieren, ohne den Quellcode und die Funktionalität zu ändern. Die Technologie arbeitet auf drei Ebenen: in der Build-Phase (Kompilierung), auf Seiten des App Stores (Verteilung) und auf dem Gerät (Ressourcenverwaltung).

Vor App Thinning haben Entwickler in die Binärdatei Ressourcen für alle möglichen Geräte aufgenommen — @2x- und @3x-Bilder, 32-Bit- und 64-Bit-Code, Metal-Shader für verschiedene GPUs. Dies führte zu einer Aufblähung der App-Größe: Ein Benutzer des iPhone 6 Plus mit Retina-HD-Display erhielt Vektorressourcen für das iPad Pro, die nie verwendet wurden. Apple hat dieses Problem gelöst, indem es einen Teil der Build-Arbeit auf die App Store-Server verlagert hat.

Laut Apple-Forschung (WWDC 2015, Session 412) kann eine typische App mit Unterstützung für mehrere Architekturen und Auflösungen nach Anwendung von App Thinning um 30-50% verkleinert werden. Bei Spielen mit vielen hochauflösenden Texturen kann der Gewinn 70-80% erreichen. Apple verbessert die Technologie weiter: In iOS 17 wurden Optimierungen für ARM64e und eine verbesserte Arbeit mit On-Demand Resources für Apps, die Swift Package Manager verwenden, hinzugefügt.

Das Problem, das App Thinning löst

Die Größe mobiler Apps wächst ständig. Laut Sensor Tower (2025) ist die durchschnittliche Größe von iOS-Apps in den letzten 5 Jahren um 45% gestiegen. Für Benutzer mit begrenztem Datentarif oder langsamem Internet zählt jedes Megabyte. App Thinning löst dieses Problem ohne Beteiligung des Entwicklers — aktivieren Sie einfach die Unterstützung in den Projekteinstellungen und laden Sie den Build in App Store Connect hoch.

Wie App Thinning funktioniert

Der App Thinning-Prozess beginnt nach dem Hochladen des App-Archivs in App Store Connect. Der App Store analysiert die Binärdatei und teilt sie in Segmente nach Architekturen (armv7, arm64, arm64e), Bildschirmauflösungen (iPhone, iPad) und iOS-Versionen auf. Für jede Kombination wird eine separate Variante erstellt. Wenn der Benutzer auf „Herunterladen“ klickt, ermittelt der App Store das Gerätemodell, die iOS-Version und den Verbindungstyp (Wi-Fi / Mobilfunknetz) und sendet nur die entsprechende Variante.

Für den Benutzer ist der Prozess transparent — es gibt keine Auswahl einer „leichten Version“ oder einen Einstellungsdialog. Der App Store wählt automatisch die am besten geeignete Variante basierend auf den Gerätemetadaten aus, die bei der Download-Anfrage an den Server gesendet werden. Wenn das Gerät Wi-Fi verwendet, kann der App Store eine Variante mit höherwertigen Ressourcen (z. B. ProRes-Video für iPhone 16 Pro) senden. Beim Herunterladen über das Mobilfunknetz wird der minimal mögliche Satz verwendet.

Die zweite Optimierungsebene — Bitcode. Wenn die Option ENABLE_BITCODE aktiviert ist, kompiliert Xcode die App nicht in Maschinencode, sondern in eine intermediate LLVM-Darstellung. Der App Store kompiliert Bitcode für die Prozessorarchitektur des Benutzers neu, sodass Apple Compiler-Optimierungen für neue Chip-Generationen (A17, M4) anwenden kann, ohne dass der Entwickler die App aktualisieren muss. Bitcode ist für watchOS und tvOS obligatorisch, aber für iOS optional.

Komponenten von App Thinning: Slicing, Bitcode, ODR

App Thinning besteht aus drei unabhängigen Mechanismen, die jeweils für einen bestimmten Aspekt der Optimierung zuständig sind. Slicing teilt die Binärdatei in Varianten nach Architektur und Bildschirmauflösung auf. Der Entwickler konfiguriert Slicing über Asset Catalogs — Xcode fügt automatisch nur die Ressourcen in den Slice ein, die dem Zielgerät entsprechen. Zum Beispiel erhält das iPhone SE (dritte Generation) nur @2x-Bilder und arm64-Code, während das iPad Pro M4 @3x-Bilder und arm64e-Code erhält.

Bitcode — LLVM IR (Intermediate Representation) — eine maschinenunabhängige Darstellung des Programms. Wenn Bitcode aktiviert ist, generiert Xcode keinen endgültigen Maschinencode, sondern speichert die intermediate Darstellung. App Store Connect erhält beim Hochladen des Builds den Bitcode und kompiliert ihn für die Architekturen aller unterstützten Geräte neu. Bitcode ermöglicht es Apple, Optimierungen anzuwenden, die in der Kompilierungsphase des Entwicklers nicht verfügbar sind — zum Beispiel die Verwendung neuer Prozessorbefehle (SME, SVE) auf M4-Chips.

On-Demand Resources (ODR) — der dritte Mechanismus, der es ermöglicht, App-Ressourcen nach der Nutzung zu entladen. Der Entwickler markiert Ressourcen (Spiellevel, Bilder für Onboarding, Videos) mit ODR-Tags. iOS lädt die markierten Ressourcen bei Bedarf im Hintergrund herunter und entlädt sie bei Speichermangel oder nach der Nutzung. ODR ist besonders effektiv für Spiele mit großen Inhaltmengen — die ersten Level können mit der App ausgeliefert werden, die restlichen werden nach und nach heruntergeladen.

Wann welche Komponente wählen

Die Wahl der App Thinning-Mechanismen hängt vom App-Typ und der Zielgruppe ab. Slicing wird immer empfohlen — es erfordert außer der korrekten Organisation der Asset Catalogs keine zusätzlichen Maßnahmen des Entwicklers und bietet eine stabile Größenreduktion von 20-30%. Bitcode sollte aktiviert werden, wenn die App benutzerdefinierte Metal-Shader verwendet oder neue Apple-Architekturen ohne Neukompilierung unterstützen soll. ODR ist für Apps mit großen Inhaltmengen gerechtfertigt — Spiele, Fotobearbeitungs-Apps, Streaming-Apps.

Für eine typische Geschäfts-App (Datenfeeds, Formulare, REST-API) reichen Slicing und eine minimale ODR-Konfiguration für Onboarding-Bilder aus. Spiele mit 3D-Grafik profitieren von allen drei Mechanismen: Slicing entfernt unnötige Shader, Bitcode optimiert das Rendering für die GPU und ODR entlädt abgeschlossene Level. Laut Apple (WWDC 2024) reduziert die Kombination aller drei Mechanismen die anfängliche Installationsgröße im Durchschnitt um 45-55% im Vergleich zu einer universellen Binärdatei.

App Thinning in Xcode konfigurieren

Um App Thinning in einem Xcode-Projekt zu aktivieren, müssen mehrere Schritte ausgeführt werden. Slicing wird über App Thinning in den Build-Einstellungen konfiguriert: Build Settings → App Thinning. Drei Werte stehen zur Verfügung: None (ohne Optimierung), Automatic (standardmäßige automatische Einstellung) und Manual mit Auswahl bestimmter Varianten zum Testen. Apple empfiehlt Automatic für die meisten Projekte.

Für Asset Catalogs ist es wichtig, die Ressourcen richtig zu organisieren: Bilder werden in einem universellen Katalog mit Angabe von Breite/Höhe platziert, und Xcode erstellt automatisch @1x-, @2x- und @3x-Varianten. Xcode fügt beim Build nur die im Projekt verwendeten Auflösungen ein. Metal-Shader werden für jede GPU-Familie separat kompiliert — Apple GPU, PowerVR, Mali — was ebenfalls über Asset Catalogs verwaltet wird.

Bitcode wird mit dem Flag ENABLE_BITCODE = YES in den Build Settings aktiviert. Für iOS ist dieses Flag optional (standardmäßig seit Xcode 14 deaktiviert), aber für watchOS und tvOS obligatorisch. Bei Aktivierung von Bitcode in einem Projekt, das Drittanbieter-Bibliotheken verwendet, müssen diese alle ebenfalls mit Bitcode kompiliert sein, sonst schlägt der Build fehl. Bitcode erhöht die Kompilierungszeit um 20-30%, bietet aber volle Kompatibilität mit zukünftigen Architekturen.

Überprüfung der App Thinning-Ergebnisse

Nach dem Hochladen in App Store Connect können die Slice-Größen im Bereich Activity → Build Metric überprüft werden. App Store Connect zeigt die geschätzte App Store-Größe für verschiedene Geräte an. Für die lokale Überprüfung stellt Xcode den Befehl xcodebuild mit dem Flag -exportArchive und der Option thinning zur Verfügung, um Slices auf dem lokalen Rechner zu erstellen. Das Ergebnis von Slicing kann nach der Archivierung im Organizer (Window → Organizer) eingesehen werden — der Tab App Thinning Profiles zeigt die Größen für verschiedene Geräte.

# Lokale Überprüfung von Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild erstellt mit dem Flag -thinning .app-Dateien für jede Kombination von Architektur, Bitbreite und GPU. Der Parameter <thin-for-all-variants> erstellt alle möglichen Varianten — nützlich für Tests. Für CI-Pipelines geben Sie eine bestimmte Kombination an, z. B. iPhone14,4 (iPhone SE 3). Die resultierenden .app-Dateien können mit dem Dienstprogramm app-size analysiert werden.

Vorteile und Auswirkungen von App Thinning

Der Hauptvorteil von App Thinning ist die Reduzierung der Download-Größe für den Endbenutzer. Laut Apple (WWDC 2024) wird eine typische App, die alle drei App Thinning-Mechanismen verwendet, im mobilen Netzwerk durchschnittlich 40% schneller heruntergeladen und belegt 35% weniger Speicherplatz. Dies wirkt sich direkt auf die Installationskonversion aus: Laut Sensor Tower reduziert jede 10 MB App-Größe die Konversion um 1%.

Der zweite Vorteil — Optimierung für zukünftige Geräte durch Bitcode. Apple kann Bitcode-Apps ohne Beteiligung des Entwicklers für neue Architekturen neu kompilieren. Zum Beispiel funktionierten Bitcode-Apps während des Übergangs von Intel zu Apple Silicon (M1) ohne zusätzlichen Build über Rosetta 2 auf macOS. Entwickler, die Bitcode nicht aktiviert hatten, mussten ihre Apps für arm64 neu kompilieren.

Der dritte Vorteil — ODR (On-Demand Resources) reduziert die Belastung des Gerätespeichers. Spiele mit Dutzenden von Levels, wie Asphalt 8: Airborne, verwenden ODR, um neue Strecken nach und nach herunterzuladen. Der Entwickler kann Initial Install Tags für Ressourcen setzen, die mit der App heruntergeladen werden, und Prefetch Tags für Inhalte, die nach der Installation im Hintergrund heruntergeladen werden. Apple kontrolliert die ODR-Grenzen: bis zu 512 MB pro Anfrage und bis zu 20 GB Gesamt-Cache auf dem Gerät.

Einschränkungen von App Thinning

App Thinning hat mehrere wichtige Einschränkungen, die bei der App-Entwicklung berücksichtigt werden müssen. Erstens: Slicing wird nicht auf Apps angewendet, die über Enterprise (in-house) oder Ad Hoc verteilt werden — diese Builds enthalten alle Varianten und durchlaufen nicht den App Store. Zum Testen von Slicing kann der Entwickler TestFlight verwenden, das Slicing ebenfalls auf den Apple-Servern verarbeitet.

Zweitens: Bitcode erhöht die Build-Zeit und die Größe des .xcarchive-Archivs um etwa 30-50%. Nicht alle Drittanbieter-Bibliotheken unterstützen Bitcode — wenn mindestens eine Abhängigkeit ohne Bitcode kompiliert wurde, schlägt der Build mit ENABLE_BITCODE fehl. Apple empfiehlt, vor der Aktivierung von Bitcode die Bibliothekskompatibilität zu überprüfen. Darüber hinaus unterstützt Bitcode Swift Package Manager nicht in vollem Umfang — einige Swift-Pakete können den Bitcode-Build beschädigen.

Drittens: On-Demand Resources garantieren keine sofortige Verfügbarkeit von Inhalten — der ODR-Download erfolgt im Hintergrund und kann verzögert werden, wenn sich das Gerät im Energiesparmodus oder bei schwachem Signal befindet. Der Entwickler muss die Verarbeitung der ODR-Download-Status über NSBundleResourceRequest implementieren und dem Benutzer einen Fortschrittsindikator anzeigen. Ein Fehler beim ODR-Download darf die App-Funktionalität nicht blockieren — ein Graceful Fallback ist erforderlich.