App Size Optimization nello sviluppo mobile: fondamenti, metodi e pratiche

Cos'è App Size Optimization

App Size Optimization è una disciplina dello sviluppo mobile volta a minimizzare le dimensioni del pacchetto di installazione dell'applicazione. Include la rimozione di codice morto e risorse, la compressione delle immagini, l'ottimizzazione delle librerie, la frammentazione della compilazione per diverse architetture e l'uso di tecnologie di distribuzione on-demand.

Le dimensioni dell'applicazione influenzano in modo diseguale diversi segmenti di utenti. Nelle regioni con infrastruttura mobile sviluppata (USA, Europa, Giappone) la differenza tra 50 e 100 MB può essere impercettibile. Nelle regioni in via di sviluppo (India, Indonesia, Brasile) ogni megabyte extra riduce la conversione delle installazioni a causa dei limiti dei piani dati e della velocità di internet mobile. Google Play limita le dimensioni dell'APK a 200 MB, ma raccomanda di mantenerle al di sotto di 100 MB.

Per l'App Store di iOS, la dimensione massima di download sulla rete cellulare è di 200 MB (era 150 MB prima del 2023). Se l'IPA supera questo limite, l'utente può installare l'app solo tramite Wi-Fi. Apple supporta anche App Thinning, che include Slicing, Bitcode e On-Demand Resources — tecnologie che riducono automaticamente le dimensioni di installazione su un dispositivo specifico senza intervento dello sviluppatore.

Perché le dimensioni dell'app sono critiche

Le dimensioni dell'app influenzano non solo la conversione delle installazioni, ma anche la fidelizzazione, la frequenza degli aggiornamenti e la velocità del primo avvio. Ogni megabyte aggiuntivo è una barriera tra l'utente e l'uso del tuo prodotto.

Impatto sulla conversione delle installazioni

Secondo i dati di Google I/O 2024, ridurre l'APK di 10 MB aumenta la conversione delle installazioni in media del 3,5%. Per le app di dimensioni 150+ MB, la conversione può essere del 20–30% inferiore rispetto ad app della stessa classe di 50 MB. L'effetto è particolarmente evidente su Google Play, dove l'utente vede le dimensioni prima dell'installazione. Nell'App Store, le dimensioni vengono mostrate sulla pagina dell'app e gli utenti con piani dati limitati rimandano l'installazione al Wi-Fi, dopo di che spesso dimenticano l'app.

Frequenza degli aggiornamenti e aggiornamenti OTA

Le app di grandi dimensioni vengono aggiornate OTA meno frequentemente — gli utenti rimandano il download delle patch al Wi-Fi, perdendo correzioni di sicurezza critiche. Google Play consente Incremental Updates (patch fino a 10 MB), ma una reinstallazione completa scarica comunque l'intero APK o AAB. L'App Store di Apple utilizza Delta Updates, trasferendo solo i file modificati, ma anche il delta può essere significativo quando le risorse cambiano.

Primo avvio e decompressione

Le dimensioni influenzano direttamente il tempo del primo avvio: l'app deve decomprimere le risorse, compilare il codice (Android) o firmare la cache (iOS). Un'app di 200 MB può avviarsi 10–15 secondi più lentamente di un'app di 50 MB su un dispositivo medio. Ciò peggiora l'Esperienza di onboarding — l'utente potrebbe chiudere l'app senza attendere il caricamento.

Ottimizzazione di risorse e asset

Le risorse — immagini, font, suoni, video — costituiscono il 60–80% delle dimensioni di un'app mobile tipica. L'ottimizzazione delle risorse offre il maggior guadagno con il minimo sforzo. Le direzioni principali sono: compressione, rimozione di duplicati e asset inutilizzati, scelta dei formati giusti.

Ottimizzazione delle immagini

WebP — un formato immagine di Google che offre una compressione dal 25–35% migliore del PNG e dal 15–20% migliore del JPEG alla stessa qualità visiva. Android supporta WebP nativamente dall'API 18. Per iOS, WebP è supportato tramite le librerie SDWebImage o Kingfisher, e con iOS 17 è arrivato il supporto nativo. AVIF — un formato più moderno che offre un risparmio aggiuntivo del 10–15% rispetto a WebP, ma con decodifica più lenta.

Rimozione delle risorse inutilizzate — il modo più semplice per ridurre le dimensioni. Su Android, usa il refactoring con Android Studio: Analyze → Run Inspection → Unused Resources. Su iOS — Build Settings → Remove Unused Resources. Spesso nei progetti rimangono sprite di versioni precedenti, icone vecchie, immagini di schermata di avvio inutilizzate che gonfiano le dimensioni senza alcun carico funzionale.

Ottimizzazione di font e suoni

I font personalizzati possono occupare 5–15 MB, specialmente se è inclusa l'intera famiglia di caratteri (tutti gli stili: Regular, Bold, Italic, BoldItalic). Usa solo gli stili necessari e sottoinsiemi di caratteri tramite subsetting — rimozione di glifi per lingue non supportate dall'applicazione. Servizi come Google Fonts e Transfonter consentono di creare un set di caratteri minimo. Per l'audio, usa AAC/HE-AAC invece di WAV e formati non compressi — risparmio fino al 90% senza perdita di qualità.

Ottimizzazione di codice e librerie

Il codice costituisce il 20–40% delle dimensioni dell'app, ma la sua ottimizzazione è più complessa di quella delle risorse perché richiede analisi delle dipendenze, offuscamento e rimozione di codice morto senza rischiare di rompere la funzionalità.

ProGuard e R8 per Android

ProGuard è uno strumento per Android che esegue offuscamento, minificazione e ottimizzazione del codice. R8 — il suo successore, integrato in Android Gradle Plugin, funziona più velocemente ed efficientemente. R8 rimuove classi e metodi inutilizzati, abbrevia i nomi delle variabili e riscrive il codice per ridurre il numero di istruzioni. La riduzione tipica delle dimensioni dei file DEX con R8 è del 30–50%.

// build.gradle — configurazione di R8 per la minificazione
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Ottimizzazione di librerie e dipendenze

Le librerie — una causa comune di dimensioni gonfiate. Una libreria può trascinare dipendenze transitive che aumentano le dimensioni di 5–20 MB senza beneficio diretto per l'applicazione. Usa Gradle Version Catalog per Android e Swift Package Manager per iOS con dichiarazione esplicita delle dipendenze. Analizza le dimensioni con Build Analyzer in Android Studio o Xcode Build Timeline. Sostituisci le librerie pesanti con alternative più leggere: ad esempio, OkHttp (3 MB) invece di Apache HTTP (15 MB).

Rimozione del codice inutilizzato in iOS

Dead Code Stripping — rimozione automatica di metodi e classi inutilizzati nella fase di linking in Xcode. Attivato tramite Build Settings → Dead Code Stripping = YES. Bitcode — una rappresentazione intermedia che Apple può ricompilare per diverse architetture, rimuovendo funzioni inutilizzate. Tuttavia, da Xcode 14, Bitcode è diventato opzionale e il suo contributo alla riduzione delle dimensioni è del 5–15% per i progetti Objective-C e inferiore per Swift.

App Thinning e distribuzione on-demand

App Thinning — la tecnologia di Apple che riduce automaticamente le dimensioni dell'app installata fornendo solo le risorse necessarie a un dispositivo specifico. Si compone di tre componenti: Slicing, On-Demand Resources e Bitcode. Su Android, l'equivalente è Android App Bundle (AAB) con Dynamic Delivery.

Android App Bundle (AAB)

AAB — un formato di pubblicazione su Google Play in cui lo store genera APK per ogni dispositivo separatamente, includendo solo le risorse per la sua architettura (armeabi-v7a, arm64-v8a), densità dello schermo (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) e lingue. La riduzione tipica delle dimensioni di installazione passando da un APK universale ad AAB è del 20–40%. Play Feature Delivery consente di caricare moduli on-demand, mentre i moduli Install-time sono inclusi nell'installazione di base.

// build.gradle — configurazione di AAB e Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources in iOS

On-Demand Resources (ODR) — un meccanismo iOS in cui le risorse (livelli di gioco, immagini ad alta risoluzione, video) vengono scaricate dai server Apple solo quando l'utente ne ha effettivamente bisogno. Le dimensioni dell'installazione iniziale possono essere ridotte del 50–80%. Le risorse sono divise in tre categorie: Initial Install Tags (scaricate durante l'installazione), Prefetched Tag Order (scaricate in background dopo l'installazione) e On-Demand (scaricate solo su richiesta). Apple raccomanda di utilizzare ODR per contenuti che non sono necessari sulla prima schermata: livelli di gioco, contenuti aggiuntivi, tutorial video.

SwiftUI supporta ODR tramite l'attributo Bundle.module, mentre UIKit utilizza NSBundleResourceRequest. Per i giochi su Unity e Unreal Engine, ODR è integrato a livello di wrapper nativo. La limitazione principale è che le risorse ODR vengono eliminate dal sistema quando lo spazio è scarso, quindi i dati critici devono essere inclusi nella build principale.