Apple weist darauf hin, dass App Store Connect genauere Angaben zur App-Größe liefert als ein lokales Exportartefakt (Dokumentation zur Größenmessung). Wenn Sie die iOS-App-Größe mit Xcode 27 optimieren wollen, vergleichen Sie deshalb zuerst den App Thinning Size Report mit den Gerätevarianten in App Store Connect. Behandeln Sie weder die Größe des Archives noch die der hochgeladenen IPA-Datei automatisch als tatsächliche Downloadgröße.

Diese Anleitung richtet sich an unabhängige Entwickler, die vor einer Veröffentlichung einen Größenanstieg untersuchen.
Sie hilft auch Teams, die mehrere Gerätevarianten oder umfangreiche Sprachressourcen pflegen.
Wenn Sie Archive wiederholt auf einem Remote Mac erstellen, erfahren Sie, wie Sie die Ergebnisse reproduzierbar festhalten.

01

Erst den Messwert bestimmen, bevor Sie Inhalte kürzen

Die Größenangabe hängt davon ab, welches Artefakt Sie betrachten. Ein Archive enthält mehr als das, was auf einem Gerät installiert wird. Eine exportierte IPA-Datei ist ein Übertragungsartefakt. App Store Connect kann für unterstützte Gerätevarianten andere Werte anzeigen als eine einzelne lokale Datei. Und der Speicherplatz nach der Installation ist nicht identisch mit der komprimierten Downloadgröße.

Diese Werte beantworten unterschiedliche Fragen. Die Dateigröße einer IPA hilft Ihnen etwa beim Vergleich Ihrer Exportdateien. Sie beantwortet aber nicht zuverlässig, wie groß der Download für ein bestimmtes Gerät ist. Ein Archive kann außerdem Symbole und weitere Dateien enthalten, die nicht im installierten App-Paket landen. Prüfen Sie deshalb zuerst, ob Sie Upload, Gerätevariante, Download oder installierten Inhalt vergleichen.

Messwert Was Sie damit beurteilen Was Sie daraus nicht direkt ableiten sollten
Archive Ergebnis des Archivierungsschritts und mögliche Bestandteile für weitere Verteilungsschritte Die Downloadgröße für alle Nutzer
Exportierte IPA Größe des exportierten Pakets, das Sie weitergeben oder hochladen Die Größe der App-Thinning-Variante auf einem bestimmten Gerät
App-Thinning-Variante Eine für eine Geräteklasse zusammengestellte Auslieferungsvariante Den Speicherbedarf nach jeder späteren Nutzung
Downloadgröße in App Store Connect Die von Apple für die jeweilige Variante ausgewiesene Größe Den vollständigen späteren Platzbedarf im Gerätespeicher
Installierter Inhalt Speicherbedarf der installierten App auf dem Gerät Die komprimierte Größe beim Herunterladen

Die Unterscheidung ist auch für die Fehlersuche wichtig: Wer eine große IPA sieht und sofort Bilder löscht, handelt möglicherweise am eigentlichen Problem vorbei. Umgekehrt kann eine unauffällige IPA einzelne Varianten verdecken, die wegen ihrer Ressourcen oder Architektur deutlich größer ausfallen.

Ist die Größe der hochgeladenen IPA auch die Downloadgröße?

Nein. Die IPA-Datei ist nicht automatisch die Datei, die jede Person vollständig und unverändert herunterlädt. App Thinning kann Inhalte anhand der Geräteeigenschaften aufteilen. Apple erklärt, dass Sie für eine verlässlichere Einschätzung die Größenangaben in App Store Connect heranziehen sollen (Apple zur Größenmessung und zum App Thinning Size Report).

Nutzen Sie die IPA daher als Vergleichswert für Ihren Exportprozess, nicht als alleinige Entscheidungsgrundlage für Nutzer. Vergleichen Sie nach einer Änderung immer dieselbe Art von Messwert: beispielsweise Downloadvariante mit Downloadvariante, nicht Archive mit Installationsgröße.

Wie erzeugen Sie den App Thinning Size Report in Xcode?

Erstellen Sie zunächst ein Archive mit der Release-Konfiguration. Wählen Sie anschließend das Archive in der Xcode-Verwaltung aus und starten Sie den Export für die App-Store-Verteilung. Aktivieren Sie dabei den App Thinning Size Report, sofern die Exportoption in der verwendeten Xcode-Version angeboten wird. Apple beschreibt das Erstellen und Auswerten des Berichts in der Anleitung zur Reduzierung der App-Größe.

Die genaue Beschriftung einzelner Dialoge kann sich zwischen Versionen ändern. Wichtig ist das Ergebnis: Bewahren Sie sowohl das exportierte Artefakt als auch den zugehörigen Bericht auf. Der Bericht soll Ihnen zeigen, wie die berechneten Varianten im Verhältnis zum universellen Export stehen. Prüfen Sie die angezeigten Spalten und Einheiten, bevor Sie Werte in eine interne Tabelle übernehmen.

Prüfschritt Beleg, den Sie sichern Nächste Aktion
Release-Archive erstellen Archivierungsprotokoll und verwendete Konfiguration Sicherstellen, dass Sie nicht versehentlich einen Debug-Build vergleichen
App-Store-Export anstoßen Exportoptionen und Exportprotokoll App Thinning Size Report mit dem Artefakt ablegen
Bericht auswerten Größen pro ausgewiesener Variante Auffällige Ressourcen- oder Binäranteile untersuchen
Build in App Store Connect prüfen dort angezeigte Varianteninformationen Lokale Schätzung mit der Apple-Angabe abgleichen
Ergebnis dokumentieren Commit, Exportoptionen und Messwerte Spätere Versionen mit derselben Methode vergleichen

Wo finden Sie die Größen der Gerätevarianten in App Store Connect?

Öffnen Sie in App Store Connect den betreffenden Build und prüfen Sie die zugehörigen Metadaten und Größenangaben. Apple beschreibt, wie Sie Builds und ihre Informationen dort anzeigen (Builds und Metadaten in App Store Connect). Kontrollieren Sie nicht nur einen allgemeinen App-Wert, wenn eine Ansicht gerätespezifische Varianten aufführt. Notieren Sie, welche Variante und welche Größenart Sie tatsächlich ablesen.

Falls die Darstellung noch nicht zu Ihrem Export passt, prüfen Sie zunächst, ob der erwartete Build verarbeitet wurde und ob Sie die korrekte Version betrachten. Verwechseln Sie auch die maximale Größe eines Uploads nicht mit der Downloadgröße für Nutzer. Eine Upload-Grenze ist keine Messung Ihrer Gerätevariante.

02

Ressourcen als eigenen Größenindikator untersuchen

Wenn der Bericht für eine Variante einen auffälligen Wert zeigt, prüfen Sie zunächst, welche Inhalte überhaupt mit der App ausgeliefert werden. Häufige Kandidaten sind Bilder, Audio- und Videodateien, Schriftdateien, Karten- oder Offline-Inhalte sowie mehrfach eingebundene Ressourcen. Das ist keine Diagnose im Voraus: Eine große Ressource ist nur dann ein sinnvoller Optimierungskandidat, wenn sie tatsächlich unnötig, redundant oder für den ersten App-Start nicht erforderlich ist.

Beginnen Sie mit einem Vergleich der Ressourcenverzeichnisse zwischen dem aktuellen und dem letzten bekannten Build. Suchen Sie nach neuen Dateien, mehrfach vorhandenen Varianten und Inhalten, die noch im Paket liegen, obwohl sie nicht mehr verwendet werden. Prüfen Sie anschließend, ob Asset Catalogs die benötigten Varianten passend bereitstellen. Apples Dokumentation erläutert, wie Asset Catalogs Ressourcenvarianten verwalten (Asset Catalogs und Ressourcenvarianten).

Die passende Maßnahme hängt vom Inhalt ab. Eine Kompression kann bei Bildern oder Medien helfen, darf aber keine sichtbaren Qualitätsprobleme erzeugen. Das Entfernen ungenutzter Dateien reduziert nur dann die Auslieferung, wenn diese Dateien zuvor tatsächlich im Paket enthalten waren. Wenn bestimmte Inhalte nicht beim ersten Start benötigt werden, können Sie prüfen, ob eine spätere Bereitstellung für Ihren Anwendungsfall sinnvoll und mit Ihrer Verteilungsstrategie vereinbar ist. Apple beschreibt fortgeschrittene Ansätze wie Ressourcenkompression und bedarfsgesteuerte Inhalte in seinen weiterführenden Empfehlungen zur Größenreduzierung.

Ein typischer Fall: Nach dem Ergänzen mehrerer Sprachen wächst ein Build, obwohl sich die Kernfunktionen kaum geändert haben. Der sinnvolle nächste Schritt ist nicht, pauschal alle Sprachressourcen zu entfernen. Vergleichen Sie, welche Lokalisierungsdateien und Bilder in den Varianten auftauchen, prüfen Sie die Zuordnung in den Asset Catalogs und entscheiden Sie, ob jede Ressource für alle Nutzer sofort erforderlich ist. So bleiben benötigte Inhalte erhalten, während Sie überflüssige Duplikate gezielt angehen.

03

Binärdateien, Frameworks und Diagnosematerial getrennt bewerten

Zeigt der Bericht keinen klaren Ressourcenanstieg, untersuchen Sie die Binärdateien und eingebetteten Frameworks. Vergleichen Sie zunächst den App-Code und die eingebundenen Frameworks zwischen den Builds. Achten Sie darauf, ob neue Abhängigkeiten, zusätzliche Architekturen oder versehentlich doppelt eingebundene Komponenten in das Produkt gelangt sind. Eine Veränderung im Binäranteil ist ein Hinweis, aber noch kein Beweis für eine bestimmte Ursache.

Prüfen Sie für das Release-Target die tatsächlich wirksamen Build-Einstellungen. Ein Wert auf Projektebene kann durch Einstellungen des Targets oder einer Konfiguration überschrieben werden. Xcode stellt dafür die effektiven Einstellungen bereit; Apple beschreibt, wie Sie die Build-Einstellungen eines Targets konfigurieren. Relevant ist unter anderem, ob die Release-Konfiguration die vorgesehenen Compiler- und Optimierungseinstellungen verwendet. Die verfügbaren Optimierungsstufen sind in der Referenz der Xcode-Build-Einstellungen dokumentiert.

Vergleichen Sie Debug- und Release-Artefakte nicht so, als wären sie gleichartige Produkte. Ein Debug-Build kann andere Einstellungen und zusätzliche Diagnoseinformationen enthalten. Auch eine dSYM-Datei ist nicht mit dem App-Binärinhalt gleichzusetzen: Sie dient der Symbolisierung und Diagnose und ist nicht automatisch Teil der an Nutzer ausgelieferten App. Prüfen Sie deshalb die Bestandteile des exportierten Pakets, bevor Sie aus der Größe eines vollständigen Archive auf den Speicherbedarf der installierten App schließen.

Apples Empfehlungen zur grundlegenden Optimierung der App-Größe sind ein sinnvoller Einstieg, ersetzen aber keinen Vergleich Ihrer eigenen Release-Artefakte. Aktivieren Sie nicht blind eine Einstellung, nur weil sie kleiner erscheinende Dateien verspricht. Verifizieren Sie danach Funktion, Absturzberichte und die tatsächliche Größenänderung anhand desselben Exportwegs.

04

Gerätevarianten und Downloadwirkung richtig einordnen

App Thinning kann dazu führen, dass unterschiedliche Geräte nicht dieselbe Zusammenstellung von Ressourcen und Binärinhalten erhalten. Deshalb sollten Sie die Variante prüfen, die zu den von Ihnen unterstützten Gerätetypen passt. Ein Wert aus einem einzigen lokalen Export sagt nicht zwangsläufig aus, welche Größe alle Nutzer sehen.

Wenn die Varianten voneinander abweichen, fragen Sie zuerst, welcher Bestandteil den Unterschied erzeugt: Ressourcenvarianten, enthaltene Architekturen oder andere verteilte Inhalte. Der Bericht liefert den Diagnoseeinstieg. App Store Connect dient anschließend als Abgleich mit den dort ausgewiesenen Informationen. Eine Abweichung zwischen lokaler Schätzung und App-Store-Angabe ist nicht automatisch ein Fehler. Sie kann auf unterschiedliche Messgegenstände oder Verarbeitungsstufen zurückgehen.

Was prüfen Sie bei einem Hinweis zur Mobilfunkgröße zuerst?

Prüfen Sie zuerst die tatsächliche Downloadgröße der betroffenen Variante in App Store Connect, nicht die Größe des Archives. Apple beschreibt in seinen Informationen zur Größenreduzierung auch die Einschränkungen, die beim Download über Mobilfunk relevant sein können (Apple zur App-Größe und zum Download). Lesen Sie die dort geltende Erläuterung im Kontext des vorgesehenen Verteilungswegs. Leiten Sie aus einem Upload-Limit keine Mobilfunkregel ab.

Ordnen Sie danach die Downloadgröße dem Nutzungsszenario zu. Eine große Offline-Mediensammlung kann für eine App, deren Hauptzweck gerade die Offline-Nutzung ist, gerechtfertigt sein. Für Inhalte, die nur selten benötigt werden, kann ein späterer Abruf die Erstinstallation entlasten. Berücksichtigen Sie dabei auch den zusätzlichen Datenbedarf, die Verfügbarkeit bei schlechter Verbindung und den Speicherbedarf nach der Installation. Eine kleinere Downloaddatei bedeutet nicht automatisch weniger Platzbedarf nach dem Start.

05

Wiederholbare Prüfungen für jede Veröffentlichung einrichten

Ein Größenvergleich ist nur belastbar, wenn Sie vergleichbare Builds gegenüberstellen. Halten Sie daher den Projektstand, die Release-Konfiguration, die Exportoptionen und den Bericht gemeinsam fest. Ändern Sie möglichst nicht mehrere Größenfaktoren auf einmal. Sonst lässt sich später schwer erkennen, welche Änderung den Messwert beeinflusst hat.

  1. Ausgangsstand sichern. Notieren Sie den Commit oder eine eindeutige Versionskennung des Quellstands. Erfassen Sie auch Änderungen an Abhängigkeiten und Assets, die seit dem letzten Release hinzugekommen sind.

  2. Release-Einstellungen prüfen. Kontrollieren Sie das richtige Scheme, das App-Store-Target und die tatsächlich wirksamen Build-Einstellungen. Dokumentieren Sie Abweichungen von Ihrer bisherigen Release-Konfiguration.

  3. Archive reproduzierbar erstellen. Verwenden Sie denselben Build-Ablauf wie für die Veröffentlichung. Ein lokaler Debug-Export ist kein geeigneter Ersatz, wenn Sie die Größe eines App-Store-Releases beurteilen wollen.

  4. Bericht und Export zusammen ablegen. Bewahren Sie App Thinning Size Report, exportierte IPA und relevante Exportoptionen beim jeweiligen Build auf. Vergeben Sie eindeutige Dateinamen oder Ordnernamen, damit Sie spätere Versionen nicht versehentlich überschreiben.

  5. App Store Connect abgleichen. Sobald die Build-Informationen verfügbar sind, notieren Sie die angezeigten Variantenwerte. Vergleichen Sie nur Messwerte gleicher Art und halten Sie fest, falls die Apple-Angabe von Ihrer lokalen Schätzung abweicht.

  6. Änderungen gezielt bewerten. Prüfen Sie bei einem Anstieg zuerst die zuletzt geänderten Ressourcen, Frameworks und Einstellungen. Nach einer Korrektur erstellen Sie den Bericht erneut und kontrollieren zugleich, ob die App weiterhin erwartungsgemäß funktioniert.

Für kleine Teams ist eine einfache Versionshistorie häufig aussagekräftiger als ein einzelner Grenzwert. Eine Tabelle mit Build-Kennung, Commit, betroffener Gerätevariante, Downloadgröße und Änderungsnotiz zeigt, ob ein Sprung mit einer konkreten Inhalts- oder Codeänderung zusammenfällt. Legen Sie vorab fest, wer einen Anstieg untersucht und wer die Entscheidung über zusätzliche Inhalte oder eine spätere Bereitstellung trifft.

06

Nach Messwert entscheiden statt pauschal verkleinern

Nutzen Sie diese Bedingungen als Entscheidungshilfe:

  • Wenn die IPA groß wirkt, App Store Connect aber keine entsprechende Auffälligkeit bei den Gerätevarianten zeigt, dann behandeln Sie zuerst die IPA als Exportgröße und untersuchen Sie nicht vorschnell die Nutzer-Downloads.
  • Wenn eine bestimmte Gerätevariante heraussticht, dann vergleichen Sie ihre Ressourcen und Binärbestandteile mit den übrigen Varianten und beheben Sie den Unterschied gezielt.
  • Wenn der Größenanstieg vor allem aus neuen Medien oder Sprachressourcen kommt, dann prüfen Sie Duplikate, Asset-Zuordnung, Kompression und die Notwendigkeit einer sofortigen Auslieferung.
  • Wenn die Ressourcen unverändert sind, dann vergleichen Sie Frameworks, Binärdateien und die effektiven Release-Einstellungen.
  • Wenn die Downloadgröße für den vorgesehenen Einsatz akzeptabel ist und die zusätzlichen Inhalte für die Kernfunktion benötigt werden, dann dokumentieren Sie die bewusste Entscheidung, statt eine riskante Optimierung nur für einen kleineren Messwert vorzunehmen.

Diese Einordnung schützt Sie vor zwei gegensätzlichen Fehlern: unnötiger Arbeit an einem harmlosen IPA-Unterschied und einem übersehenen Problem in einer einzelnen Gerätevariante. Entscheidend ist, dass Bericht und App-Store-Angabe denselben Build und dieselbe Frage betreffen.

Wenn Sie für wiederholte Archive und Exporte keinen eigenen Mac bereitstellen möchten, vergleichen Sie zunächst den Aufwand mit Ihrer tatsächlichen Build-Frequenz. Ein eigener Rechner ist oft die passendere Lösung, wenn Sie dauerhaft hohe Auslastung haben oder physische Anschlüsse und direkten Zugriff auf lokale Geräte benötigen. Für zeitlich begrenzte Release-Arbeit kann ein gemieteter Remote Mac dagegen vermeiden, dass Sie Hardware nur für gelegentliche Größenprüfungen anschaffen und warten müssen. Prüfen Sie dazu die Mietkosten für Mac mini und die verfügbaren Mac-Optionen zur Miete. Entscheidend bleibt: Erst wenn die Messwerte vergleichbar sind, lohnt sich die Optimierung der App oder die Wahl einer anderen Build-Umgebung.