So messen und verkleinern Sie die Größe einer iOS-App mit Xcode und App Store Connect

iOS-Apps wachsen in der Regel mit jedem Release: Neue SDKs, Bilder in höherer Auflösung und Offline-Inhalte kommen hinzu. Der Download dauert länger, und auf dem Gerät wird mehr Speicher belegt. Die Optimierung beginnt mit Messungen, denn der größte Faktor ist bei jeder App ein anderer: Bei manchen sind es die Ressourcen, bei anderen der kompilierte Code oder eingebundene Abhängigkeiten. Auch die „App-Größe" lässt sich nicht auf eine einzige Zahl reduzieren. Download-Größe, Installationsgröße und der nach der Nutzung belegte Speicher überschneiden sich, sind aber nicht austauschbar. Geben Sie deshalb in einem PR, einem Benchmark oder einem Team-Update an, welche Metrik sich geändert hat und wo sie gemessen wurde. Wenn optionale Inhalte erst später geladen werden, fallen der erste Download und die Installation kleiner aus, doch nach dem Herunterladen landen diese Inhalte trotzdem auf dem Gerät. Background Assets, einschließlich wesentlicher Pakete und vorab geladener Inhalte, können sogar vor dem ersten Start eintreffen. Sie müssen separat erfasst und unter demselben Download-Zustand verglichen werden.

Nutzer sehen diese Zahlen an zwei Stellen. Auf der Produktseite im App Store zeigt das Feld „Informationen → Größe" die Installationsgröße. Wenn die App wesentliche, von Apple gehostete Asset-Pakete nutzt, kann dort ein Wert „Bis zu …" stehen, der diese Inhalte einschließt. Unter „iPhone-Speicher" werden die App-Größe und „Dokumente und Daten" getrennt angezeigt, wobei Letztere durch Downloads und Nutzung anwachsen. Lokale APP-, XCARCHIVE- und IPA-Dateien helfen bei der Diagnose, entsprechen aber nicht dem, was der App Store ausliefert: Archive können Debug-Symbole enthalten, und ein universelles IPA bringt Ressourcen für verschiedene Geräte mit. Um die Größe für bestimmte Geräte abzuschätzen, exportieren Sie ein Release-Archiv mit dem Befehl xcodebuild -exportArchive und den Parametern -archivePath, -exportPath und -exportOptionsPlist. Bei manueller Signierung benötigt die plist außerdem signingStyle=manual, eine teamID und eine provisioningProfiles-Zuordnung für jede App oder Erweiterung.

Im Exportordner erscheint die Datei App Thinning Size Report.txt. Sie listet die Varianten mit Geräte- und OS-Beschreibung sowie Werte wie "112 MB compressed, 260 MB uncompressed" auf. Die komprimierte Größe ist eine Schätzung der Downloadgröße, die unkomprimierte eine Schätzung der Installationsgröße. Um ein Bundle zu untersuchen, wählen Sie eine ausgedünnte IPA anhand der Variantenbeschreibung und nicht anhand des Dateinamens aus, denn der Export kann auch eine universelle IPA enthalten. Entpacken Sie sie mit ditto -x -k in ein neues, mit mktemp erstelltes Verzeichnis und suchen Sie die .app im Ordner Payload. Für App Store und TestFlight erfolgt das App Thinning weitgehend automatisch, es sollte aber überprüft werden. Wenn gerätespezifische Ressourcen in allen Varianten landen, prüfen Sie die Einstellungen der Asset-Kataloge und lose Dateien. Halten Sie beim Vergleich Build-Konfiguration, Xcode-Version, Signierungsmethode, Exportmethode und Variantenbeschreibung konstant und wiederholen Sie den Vergleich anschließend mit den verarbeiteten Werten aus App Store Connect. Auch diese sind nur Schätzungen: Apple kann DRM hinzufügen und Dateien neu komprimieren, und die Größen in TestFlight können von denen im App Store abweichen.

Die Diagnose beginnt mit einer Bestandsaufnahme des gesamten ausgedünnten Bundles: Hauptprogramm, Frameworks, PlugIns, Asset-Kataloge und lose Ressourcen, Lokalisierungen, Medien, Datenbanken und ML-Modelle. Der Befehl find mit stat, sort -n und tail -30 zeigt die größten Dateien, doch das sind logische unkomprimierte Größen und damit nur Hinweise. Wenn die Binärdatei relevant ist, aktivieren Sie in den Build Settings die Option Write Link Map File (LD_GENERATE_MAP_FILE), bauen Sie das Projekt und werten Sie die .txt-Datei in DerivedData aus. Gruppieren Sie die Größen aus dem Abschnitt # Symbols nach Dateiindex und ordnen Sie die Indizes über den Abschnitt # Object files zu. So werden umfangreicher generierter Code, statische Bibliotheken, C++-Templates und SDKs von Drittanbietern sichtbar. Die Summen der Symbole zeigen, wem das Gewicht zuzuordnen ist, liefern aber keine vollständige Bilanz: Header, Padding, Signaturen und Linker-Daten sind nicht enthalten. Inlining, Whole-Module-Optimierung und LTO verwischen die Zuordnung des Codes. Schließen Sie per Dead Stripping entfernte Symbole aus und erstellen Sie die Map für jedes Build-Target und jede Architektur.

Den Arbeitsablauf zeigen wir an einem fiktiven Beispiel mit erfundenen Zahlen: jeweils nur eine Änderung, neu bauen und den Bericht für dieselbe Variante neu erzeugen. Eine ressourcenlastige App ist komprimiert 112 MB und unkomprimiert 260 MB groß. Die Schätzung sinkt um 31 MB (etwa 28 %) bzw. 58 MB (etwa 22 %), und App Store Connect meldet 80 MB Download und 200 MB Installation. Die Einsparungen übertragen sich nicht eins zu eins, da Kompilierung, Slicing, Komprimierung, Alignment und Signierung dazwischenwirken. Ein Tutorial, das auf Remote-Auslieferung umgestellt wird, wird aufgeschoben, nicht entfernt. Nach dem Download wächst der belegte Speicher wieder um etwa 32 MB, und auf dem Gerät können gleichzeitig das Archiv und die entpackten Dateien liegen. Testen Sie daher den Offline-Betrieb, Wiederholungsversuche, das Bereinigen und das erneute Herunterladen, und messen Sie Delta-Updates separat.

Ressourcen wiegen oft mehr als der Code. Bewahren Sie eingebettete Bilder in .xcassets auf, damit App Thinning die Ressourcen passend für jedes Gerät auswählen kann. Die Pixelanzahl sollte der Größe auf dem Bildschirm entsprechen: Ein Icon mit 24 × 24 Punkten benötigt 48 × 48 Pixel für 2x und 72 × 72 für 3x, und es muss vor dem Import verkleinert werden. Verwenden Sie für universelle Grafiken eine gemeinsame Version, fügen Sie Varianten für Geräte oder Farbräume nur bei Bedarf hinzu und duplizieren Sie keine Bildsätze. Laden Sie Bilder nach der Migration über ihren Namen, zum Beispiel UIImage(named: "toolbar_search"), und entfernen Sie verbliebene einzelne Kopien aus Copy Bundle Resources. Bestätigen Sie das Ergebnis, indem Sie die Berichte für dieselbe Variante vorher und nachher vergleichen. Für Icons greifen Sie besser auf die System-SF Symbols zurück, sofern Design und minimale Betriebssystemversion dies zulassen.