App Size Optimization in der mobilen Entwicklung: Grundlagen, Methoden und Praktiken

Was ist App Size Optimization

App Size Optimization ist eine Disziplin der mobilen Entwicklung, die darauf abzielt, die Größe des Installationspakets der Anwendung zu minimieren. Dazu gehören die Entfernung von totem Code und Ressourcen, die Komprimierung von Bildern, die Optimierung von Bibliotheken, die Aufteilung von Builds für verschiedene Architekturen und die Nutzung von On-Demand-Bereitstellungstechnologien.

Die Größe der Anwendung wirkt sich ungleichmäßig auf verschiedene Benutzersegmente aus. In Regionen mit entwickelter mobiler Infrastruktur (USA, Europa, Japan) kann der Unterschied zwischen 50 und 100 MB unbemerkt bleiben. In Entwicklungsländern (Indien, Indonesien, Brasilien) reduziert jedes zusätzliche Megabyte die Installationskonversion aufgrund von Datenplanlimits und mobiler Internetgeschwindigkeit. Google Play begrenzt die APK-Größe auf 200 MB, empfiehlt jedoch, sie unter 100 MB zu halten.

Für den iOS App Store beträgt die maximale Download-Größe über das Mobilfunknetz 200 MB (vor 2023 waren es 150 MB). Überschreitet die IPA diese Grenze, kann der Benutzer die App nur über Wi-Fi installieren. Apple unterstützt auch App Thinning, das Slicing, Bitcode und On-Demand Resources umfasst — Technologien, die die Installationsgröße auf einem bestimmten Gerät ohne Eingreifen des Entwicklers automatisch reduzieren.

Warum die App-Größe entscheidend ist

Die App-Größe beeinflusst nicht nur die Installationskonversion, sondern auch die Bindung, Aktualisierungshäufigkeit und Geschwindigkeit des ersten Starts. Jedes zusätzliche Megabyte ist eine Barriere zwischen dem Benutzer und der Nutzung Ihres Produkts.

Auswirkungen auf die Installationskonversion

Laut Daten von Google I/O 2024 erhöht eine Reduzierung des APK um 10 MB die Installationskonversion um durchschnittlich 3,5%. Bei Apps mit 150+ MB kann die Konversion 20–30% niedriger sein als bei gleichartigen Apps mit 50 MB. Der Effekt ist besonders bei Google Play ausgeprägt, wo der Benutzer die Größe vor der Installation sieht. Im App Store wird die Größe auf der App-Seite angezeigt, und Benutzer mit begrenzten Datenplänen verschieben die Installation auf Wi-Fi, wonach sie die App oft vergessen.

Aktualisierungshäufigkeit und Over-the-Air-Updates

Große Apps werden seltener over-the-air aktualisiert — Benutzer verschieben das Herunterladen von Patches auf Wi-Fi und verpassen dabei kritische Sicherheitskorrekturen. Google Play ermöglicht Incremental Updates (Patches bis zu 10 MB), aber eine vollständige Neuinstallation lädt immer noch das gesamte APK oder AAB herunter. Der Apple App Store verwendet Delta Updates, die nur geänderte Dateien übertragen, aber selbst das Delta kann bei Änderungen von Ressourcen erheblich sein.

Erster Start und Entpacken

Die Größe wirkt sich direkt auf die Zeit des ersten Starts aus: Die App muss Ressourcen entpacken, Code kompilieren (Android) oder den Cache signieren (iOS). Eine 200 MB App kann auf einem durchschnittlichen Gerät 10–15 Sekunden langsamer starten als eine 50 MB App. Dies verschlechtert das Onboarding-Erlebnis — der Benutzer kann die App schließen, ohne auf das Laden zu warten.

Optimierung von Ressourcen und Assets

Ressourcen — Bilder, Schriftarten, Sounds, Videos — machen 60–80% der Größe einer typischen mobilen App aus. Die Ressourcenoptimierung bringt den größten Gewinn bei minimalem Aufwand. Die Hauptrichtungen sind: Komprimierung, Entfernung von Duplikaten und ungenutzten Assets, Wahl der richtigen Formate.

Bildoptimierung

WebP — ein Bildformat von Google, das bei gleicher visueller Qualität eine 25–35% bessere Komprimierung als PNG und 15–20% bessere als JPEG bietet. Android unterstützt WebP nativ ab API 18. Für iOS wird WebP über die Bibliotheken SDWebImage oder Kingfisher unterstützt, und mit iOS 17 kam native Unterstützung hinzu. AVIF — ein moderneres Format, das zusätzliche 10–15% Einsparungen gegenüber WebP bietet, aber mit langsamerer Dekodierung.

Entfernung ungenutzter Ressourcen — der einfachste Weg, die Größe zu reduzieren. Verwenden Sie in Android die Refactoring-Funktion mit Android Studio: Analyze → Run Inspection → Unused Resources. In iOS — Build Settings → Remove Unused Resources. Oft verbleiben in Projekten Sprites aus früheren Versionen, alte Symbole, ungenutzte Startbildschirmbilder, die die Größe ohne funktionale Belastung aufblähen.

Schriftart- und Audio-Optimierung

Benutzerdefinierte Schriftarten können 5–15 MB belegen, insbesondere wenn die gesamte Schriftfamilie enthalten ist (alle Stile: Regular, Bold, Italic, BoldItalic). Verwenden Sie nur die notwendigen Stile und Zeichensubsets durch Subsetting — Entfernung von Glyphen für Sprachen, die von der App nicht unterstützt werden. Dienste wie Google Fonts und Transfonter ermöglichen die Erstellung eines minimalen Zeichensatzes. Verwenden Sie für Audio AAC/HE-AAC anstelle von WAV und unkomprimierten Formaten — Einsparungen von bis zu 90% ohne Qualitätsverlust.

Optimierung von Code und Bibliotheken

Code macht 20–40% der App-Größe aus, aber seine Optimierung ist komplexer als die von Ressourcen, da sie Abhängigkeitsanalyse, Verschleierung und Entfernung von totem Code erfordert, ohne die Funktionalität zu gefährden.

ProGuard und R8 für Android

ProGuard ist ein Tool für Android, das Code-Verschleierung, -Minimierung und -Optimierung durchführt. R8 — sein Nachfolger, integriert in das Android Gradle Plugin, arbeitet schneller und effizienter. R8 entfernt ungenutzte Klassen und Methoden, kürzt Variablennamen und schreibt Code um, um die Anzahl der Anweisungen zu reduzieren. Die typische Reduzierung der DEX-Dateigröße mit R8 beträgt 30–50%.

// build.gradle — R8-Konfiguration für die Minimierung
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Optimierung von Bibliotheken und Abhängigkeiten

Bibliotheken — eine häufige Ursache für aufgeblähte Größe. Eine Bibliothek kann transitive Abhängigkeiten mit sich ziehen, die die Größe um 5–20 MB erhöhen, ohne direkten Nutzen für die App. Verwenden Sie Gradle Version Catalog für Android und Swift Package Manager für iOS mit expliziter Deklaration von Abhängigkeiten. Analysieren Sie die Größe mit dem Build Analyzer in Android Studio oder der Xcode Build Timeline. Ersetzen Sie schwere Bibliotheken durch leichtere Alternativen: zum Beispiel OkHttp (3 MB) statt Apache HTTP (15 MB).

Entfernung von ungenutztem Code in iOS

Dead Code Stripping — automatische Entfernung ungenutzter Methoden und Klassen in der Link-Phase in Xcode. Aktiviert über Build Settings → Dead Code Stripping = YES. Bitcode — eine Zwischendarstellung, die Apple für verschiedene Architekturen neu kompilieren kann, wobei ungenutzte Funktionen entfernt werden. Seit Xcode 14 ist Bitcode jedoch optional geworden, und sein Beitrag zur Größenreduzierung beträgt 5–15% für Objective-C-Projekte und weniger für Swift.

App Thinning und On-Demand-Bereitstellung

App Thinning — Apples Technologie, die die Größe der installierten App automatisch reduziert, indem nur die Ressourcen bereitgestellt werden, die ein bestimmtes Gerät benötigt. Sie besteht aus drei Komponenten: Slicing, On-Demand Resources und Bitcode. Unter Android ist das Äquivalent das Android App Bundle (AAB) mit Dynamic Delivery.

Android App Bundle (AAB)

AAB — ein Veröffentlichungsformat bei Google Play, bei dem der Shop APKs für jedes Gerät separat generiert und nur die Ressourcen für dessen Architektur (armeabi-v7a, arm64-v8a), Bildschirmdichte (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) und Sprachen einbezieht. Die typische Reduzierung der Installationsgröße beim Wechsel von einem universellen APK zu AAB beträgt 20–40%. Play Feature Delivery ermöglicht das Laden von Modulen bei Bedarf, während Install-time-Module in der Basisinstallation enthalten sind.

// build.gradle — AAB- und Dynamic Features-Konfiguration
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources in iOS

On-Demand Resources (ODR) — ein iOS-Mechanismus, bei dem Ressourcen (Spiel-Level, hochauflösende Bilder, Videos) nur dann von Apples Servern heruntergeladen werden, wenn der Benutzer sie tatsächlich benötigt. Die Größe der Erstinstallation kann um 50–80% reduziert werden. Die Ressourcen werden in drei Kategorien unterteilt: Initial Install Tags (werden bei der Installation heruntergeladen), Prefetched Tag Order (werden nach der Installation im Hintergrund heruntergeladen) und On-Demand (werden nur auf Anfrage heruntergeladen). Apple empfiehlt die Verwendung von ODR für Inhalte, die nicht auf dem ersten Bildschirm benötigt werden: Spiel-Level, zusätzliche Inhalte, Video-Tutorials.

SwiftUI unterstützt ODR über das Bundle.module-Attribut, während UIKit NSBundleResourceRequest verwendet. Für Spiele auf Unity und Unreal Engine wird ODR auf der Ebene des nativen Wrappers integriert. Die Haupteinschränkung ist, dass ODR-Ressourcen vom System gelöscht werden, wenn der Speicherplatz knapp wird. Daher müssen kritische Daten im Haupt-Build enthalten sein.