App Size Optimization in mobiele ontwikkeling: basis, methoden en praktijken

Wat is App Size Optimization

App Size Optimization — discipline in mobiele ontwikkeling gericht op het minimaliseren van de grootte van het installatiepakket van de app. Het omvat het verwijderen van dode code en bronnen, compressie van afbeeldingen, optimalisatie van bibliotheken, fragmentatie van compilatie voor verschillende architecturen en het gebruik van levering-op-aanvraag-technologieën.

De grootte van de app beïnvloedt ongelijkmatig verschillende gebruikerssegmenten. In regio's met ontwikkelde mobiele infrastructuur (VS, Europa, Japan) kan het verschil tussen 50 en 100 MB onmerkbaar zijn. In ontwikkelingsregio's (India, Indonesië, Brazilië) vermindert elke extra megabyte de conversie van installaties vanwege tarieflimieten en snelheid van mobiel internet. Google Play beperkt de APK-grootte tot 200 MB, maar raadt aan de grootte onder 100 MB te houden.

Voor iOS App Store is de maximale downloadgrootte via het mobiele netwerk 200 MB (tot 2023 was dit 150 MB). Als IPA deze limiet overschrijdt, kan de gebruiker de app alleen via Wi-Fi installeren. Apple ondersteunt ook App Thinning, dat Slicing, Bitcode en On-Demand Resources omvat — technologieën die automatisch de installatiegrootte op een specifiek apparaat verminderen zonder tussenkomst van de ontwikkelaar.

Waarom de grootte van de app kritisch is

De grootte van de app beïnvloedt niet alleen de conversie van installaties, maar ook de retentie, frequentie van updates en de snelheid van de eerste keer opstarten. Elke extra megabyte is een barrière tussen de gebruiker en het gebruik van uw product.

Impact op conversie van installaties

Volgens gegevens van Google I/O 2024 verhoogt het verkleinen van APK met 10 MB de conversie van installaties gemiddeld met 3,5%. Voor apps van 150+ MB kan de conversie 20–30% lager zijn dan voor apps van dezelfde klasse van 50 MB. Het effect is vooral zichtbaar in Google Play, waar de gebruiker de grootte ziet vóór installatie. In App Store wordt de grootte getoond op de app-pagina en gebruikers met een beperkt tarief stellen de installatie uit tot Wi-Fi, waarna ze de app vaak vergeten.

Updatefrequentie en updates via de lucht

Een grote app wordt minder vaak via de lucht bijgewerkt — gebruikers stellen het downloaden van patches uit tot Wi-Fi en missen kritieke beveiligingsupdates. Google Play maakt gebruik van Incremental Updates (patches tot 10 MB) mogelijk, maar een volledige herinstallatie downloadt nog steeds de volledige APK of AAB. Apple App Store gebruikt Delta Updates, waarbij alleen gewijzigde bestanden worden verzonden, maar zelfs de delta kan aanzienlijk zijn bij het wijzigen van bronnen.

Eerste keer opstarten en uitpakken

De grootte heeft directe invloed op de tijd van de eerste keer opstarten: de app moet bronnen uitpakken, code compileren (Android) of de cache ondertekenen (iOS). Een app van 200 MB kan 10–15 seconden langer opstarten dan een app van 50 MB op een gemiddeld apparaat. Dit verslechtert de Onboarding Experience — de gebruiker kan de app sluiten zonder te wachten op het laden.

Optimalisatie van bronnen en assets

Bronnen — afbeeldingen, lettertypen, geluiden, video — vormen 60–80% van de grootte van een typische mobiele app. Optimalisatie van bronnen levert de grootste winst op met minimale inspanning. De belangrijkste richtingen: compressie, verwijderen van duplicaten en ongebruikte assets, kiezen van de juiste formaten.

Optimalisatie van afbeeldingen

WebP — beeldformaat van Google, dat 25–35% betere compressie biedt dan PNG en 15–20% beter dan JPEG bij dezelfde visuele kwaliteit. Android ondersteunt WebP native vanaf API 18. Voor iOS wordt WebP ondersteund via de bibliotheek SDWebImage of Kingfisher, en sinds iOS 17 is er native ondersteuning. AVIF — een moderner formaat dat een extra besparing van 10–15% biedt ten opzichte van WebP, maar met langzamere decodering.

Verwijderen van ongebruikte bronnen — de eenvoudigste manier om de grootte te verminderen. Gebruik in Android refactoring met Android Studio: Analyze → Run Inspection → Unused Resources. In iOS — Build Settings → Remove Unused Resources. Vaak blijven in projecten sprites van eerdere versies, oude pictogrammen, ongebruikte opstartschermafbeeldingen achter die de grootte opblazen zonder enige functionele belasting.

Optimalisatie van lettertypen en geluiden

Aangepaste lettertypen kunnen 5–15 MB in beslag nemen, vooral als de hele familie is aangesloten (alle stijlen: Regular, Bold, Italic, BoldItalic). Gebruik alleen de benodigde stijlen en subsets van tekens via subsetting — verwijderen van glyphs voor talen die niet worden ondersteund door de app. Diensten zoals Google Fonts en Transfonter maken het mogelijk een minimale tekenset te maken. Gebruik voor geluiden AAC/HE-AAC in plaats van WAV en niet-gecomprimeerde formaten — tot 90% besparing zonder kwaliteitsverlies.

Optimalisatie van code en bibliotheken

Code vormt 20–40% van de app-grootte, maar de optimalisatie ervan is moeilijker dan van bronnen, omdat het analyse van afhankelijkheden, obfuscatie en verwijdering van dode code vereist zonder het risico de functionaliteit te breken.

ProGuard en R8 voor Android

ProGuard — tool voor Android die obfuscatie, minificatie en optimalisatie van code uitvoert. R8 — de opvolger, ingebouwd in Android Gradle Plugin, werkt sneller en efficiënter. R8 verwijdert ongebruikte klassen en methoden, verkort variabelenamen en herschrijft code om het aantal instructies te verminderen. Typische vermindering van de grootte van DEX-bestanden met R8 is 30–50%.

// build.gradle — configuratie van R8 voor minificatie
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Optimalisatie van bibliotheken en afhankelijkheden

Bibliotheken — een veelvoorkomende oorzaak van opgeblazen grootte. Eén bibliotheek kan transitieve afhankelijkheden meebrengen die de grootte met 5–20 MB vergroten zonder direct voordeel voor de app. Gebruik Gradle Version Catalog voor Android en Swift Package Manager voor iOS met expliciete vermelding van afhankelijkheden. Analyseer de grootte met Build Analyzer in Android Studio of Xcode Build Timeline. Vervang zware bibliotheken door lichtere alternatieven: bijvoorbeeld OkHttp (3 MB) in plaats van Apache HTTP (15 MB).

Verwijderen van ongebruikte code in iOS

Dead Code Stripping — automatische verwijdering van ongebruikte methoden en klassen in de linkfase in Xcode. Inschakelen via Build Settings → Dead Code Stripping = YES. Bitcode — tussentijdse representatie die Apple kan hercompileren voor verschillende architecturen, waarbij ongebruikte functies worden verwijderd. Maar sinds Xcode 14 is Bitcode optioneel geworden en de bijdrage aan groottevermindering is 5–15% voor Objective-C-projecten en minder voor Swift.

App Thinning en levering op aanvraag

App Thinning — Apple-technologie die automatisch de grootte van de geïnstalleerde app vermindert door alleen de bronnen te leveren die nodig zijn voor een specifiek apparaat. Bestaat uit drie componenten: Slicing, On-Demand Resources en Bitcode. In Android is het equivalent Android App Bundle (AAB) met Dynamic Delivery.

Android App Bundle (AAB)

AAB — publicatieformaat in Google Play, waarbij de winkel APK genereert voor elk apparaat afzonderlijk, met alleen bronnen voor de architectuur (armeabi-v7a, arm64-v8a), schermdichtheid (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) en talen. Typische vermindering van de installatiegrootte bij overgang van universele APK naar AAB is 20–40%. Play Feature Delivery maakt het mogelijk modules op aanvraag te downloaden, terwijl Install-time-modules worden opgenomen in de basisinstallatie.

// build.gradle — configuratie van AAB en Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources in iOS

On-Demand Resources (ODR) — iOS-mechanisme waarbij bronnen (spelniveaus, hoge-resolutie-afbeeldingen, video) worden gedownload van Apple-servers alleen wanneer ze echt nodig zijn voor de gebruiker. De grootte van de initiële installatie kan met 50–80% worden verminderd. Bronnen worden onderverdeeld in drie categorieën: Initial Install Tags (gedownload bij installatie), Prefetched Tag Order (gedownload op de achtergrond na installatie) en On-Demand (alleen gedownload op verzoek). Apple raadt aan ODR te gebruiken voor inhoud die niet nodig is op het eerste scherm: spelniveaus, aanvullende inhoud, video-instructies.

SwiftUI ondersteunt ODR via het attribuut Bundle.module, en UIKit via NSBundleResourceRequest. Voor games op Unity en Unreal Engine wordt ODR geïntegreerd op het niveau van de native wrapper. De belangrijkste beperking — ODR-bronnen worden door het systeem verwijderd bij gebrek aan ruimte, dus gegevens die kritisch zijn voor de werking moeten worden opgenomen in de hoofdcompilatie.