Release nello sviluppo mobile: basi, build e pubblicazione di app

Cos'è un build Release

Release — è una configurazione di build in cui vengono applicate tutte le ottimizzazioni del compilatore, le informazioni di debug vengono rimosse, le risorse vengono compresse e il codice eseguibile viene offuscato per proteggere la proprietà intellettuale. L'obiettivo di Release è ottenere un file binario il più veloce e compatto possibile, pronto per la distribuzione attraverso i canali ufficiali.

A differenza di Debug, un build Release non contiene punti di ingresso per il debugger, le asserzioni sono disabilitate e la registrazione è ridotta al minimo. Non è semplicemente un cambio di flag — è una pipeline di build diversa con certificati, profili di provisioning e impostazioni di impacchettamento differenti. Un build Release richiede più tempo perché il compilatore esegue passaggi aggiuntivi di ottimizzazione.

Per iOS, il build Release viene firmato con un certificato di distribuzione Apple e viene sottoposto a revisione in App Store Connect. Per Android, il build Release viene firmato con una chiave di upload e può essere caricato su Google Play Console. Entrambe le piattaforme richiedono la firma digitale: un'app buildata senza di essa non verrà installata sul dispositivo dell'utente.

Release e Debug: confronto delle configurazioni

La differenza tra Debug e Release si manifesta a tutti i livelli: dai flag del compilatore alla dimensione finale del .apk o .ipa. Comprendere queste differenze è fondamentale per la pipeline CI/CD e per trovare regressioni che compaiono solo nei build Release.

Flag del compilatore

In Release, il compilatore abilita l'ottimizzazione per dimensione (-Os per LLVM) o velocità (-O2). Ciò significa incorporamento di funzioni inline, rimozione di codice morto, riordinamento delle istruzioni e ottimizzazione aggressiva dei loop. In Debug, tutte queste fasi vengono saltate, rendendo il codice più lento ma preservando la corrispondenza completa tra le righe sorgente e le istruzioni macchina.

Offuscamento e minificazione

ProGuard/R8 (Android) rinomina classi, metodi e campi in nomi brevi (a, b, c), complicando il reverse engineering e riducendo la dimensione del file DEX. Su iOS, la funzionalità equivalente è fornita da Strip Symbols e Swift Symbolication. È importante configurare regole keep per le classi utilizzate tramite reflection o nei layout XML, altrimenti l'app si bloccherà con ClassNotFoundException all'avvio.

Dimensione del build

I build Release sono significativamente più compatti dei build Debug. Il rapporto tipico: una versione Debug occupa 40–80 MB, Release — 15–30 MB. La differenza è dovuta alla rimozione dei simboli di debug (DWARF), alla compressione delle risorse (aapt2) e all'offuscamento DEX. Per gli utenti, la dimensione dell'app è un fattore importante di conversione delle installazioni, quindi l'ottimizzazione della dimensione in Release è una pratica obbligatoria.

Processo di build Release su Android

Gradle fornisce task integrati per buildare la versione Release: assembleRelease, bundleRelease (per AAB) e signingReport. La corretta configurazione di build.gradle a livello di modulo è la base di un build CI/CD stabile. Esaminiamo le fasi principali utilizzando un progetto tipico come esempio.

Configurazione di build.gradle

Nel blocco buildTypes viene specificata la configurazione release: la minificazione è abilitata, shrinkResources è attivato e le regole proguard sono impostate. Il blocco signingConfig deve riferire a storeFile, storePassword, keyAlias e keyPassword — questi parametri non devono essere memorizzati in VCS. Per CI/CD, utilizzare variabili d'ambiente o il plugin Keystore Provisioning.

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile(
                "proguard-android-optimize.txt"
            ), "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
    }
}

Build di AAB e APK

Android App Bundle (AAB) è il formato consigliato per la pubblicazione su Google Play. Un AAB non contiene un singolo APK ma un insieme modulare di risorse, da cui Google Play genera dinamicamente un APK ottimizzato per un dispositivo specifico. Il comando ./gradlew bundleRelease builda un AAB, mentre ./gradlew assembleRelease builda un APK universale per i test prima del caricamento.

Firma e verifica

Un APK/AAB firmato viene verificato tramite apksigner verify. Google Play Console controlla automaticamente la firma al caricamento. A partire da Android 9 (API 28), Google richiede schemi di firma v2 o v3. Per Wear OS e Android TV, è inoltre richiesto v3.1 con chiave rotante.

Processo di build Release su iOS

Xcode builda la versione Release nella configurazione Archive — non è solo un build ma una pipeline completa: compilazione con ottimizzazione, impacchettamento in .xcarchive, firma con un certificato di distribuzione ed esportazione in .ipa. Il processo viene avviato tramite Product → Archive o il comando xcodebuild.

Configurazione dello schema di build

In Edit Scheme → Run → Build Configuration, seleziona Release per i test finali. Per inviare ad App Store Connect, usa Archive dal menu Product. Xcode crea un .xcarchive contenente il file binario, dSYM e i bundle di risorse. Dall'archivio, .ipa viene esportato per la distribuzione Ad Hoc, Development o App Store.

App Store Connect e TestFlight

TestFlight accetta build Release firmati con un certificato di distribuzione App Store. Prima dell'invio all'App Store, il build viene sottoposto a convalida automatica in Xcode: vengono verificati la conformità dei certificati, le icone di tutte le dimensioni, la correttezza di Info.plist e l'assenza di architetture del simulatore nel file binario.

# Build Release tramite xcodebuild
xcodebuild archive \
  -project MyApp.xcodeproj \
  -scheme "MyApp" \
  -configuration "Release" \
  -archivePath "build/MyApp.xcarchive"

# Esportazione .ipa per App Store
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/" \
  -exportOptionsPlist "export.plist"

Bitcode e App Thinning

App Thinning è la tecnologia Apple per ridurre la dimensione dell'app scaricata. Durante il caricamento sull'App Store, Apple ricompila il file binario per il dispositivo specifico dell'utente, rimuovendo le architetture inutilizzate. Bitcode (rappresentazione intermedia LLVM) viene incluso nei build Release se il progetto utilizza iOS 14+ e Xcode 12+.

Errori comuni nella preparazione di una Release

Gli errori di configurazione del build Release si dividono in tre categorie: problemi di compilazione, problemi di firma ed errori logici che compaiono solo dopo l'ottimizzazione. Esaminiamo gli scenari più comuni che gli sviluppatori affrontano quando passano da Debug a Release.

ClassNotFoundException dopo offuscamento

L'errore più comune su Android — un crash all'avvio dopo l'abilitazione di minifyEnabled. Causa: R8 ha rinominato una classe utilizzata tramite reflection (ad esempio, serializzazione Gson, Retrofit @Body con data class). Soluzione — aggiungi una regola -keep per tutte le classi coinvolte nella serializzazione e verifica le regole proguard prima del build.

Mancanza di dSYM per la symbolication

Su iOS, gli sviluppatori spesso dimenticano di salvare i file dSYM dopo Archive. Senza dSYM, i log di crash da App Store Connect arrivano come indirizzi esadecimali invece di nomi di funzioni leggibili. Soluzione — configura CI/CD per archiviare dSYM insieme a .ipa e caricarli su App Store Connect.

Problemi con i profili di provisioning

Un certificato di distribuzione scaduto o un App ID errato nel profilo di provisioning è il motivo per cui App Store Connect rifiuta il build. I certificati sono validi per 1 anno (Apple) o 3 anni (Google) e il loro rinnovo deve essere pianificato nel calendario delle release. Verificare lo stato del certificato prima di ogni build Release è un passaggio obbligatorio nella pipeline CI/CD.

Incompatibilità delle versioni SDK e del deployment target

Un problema comune quando si passa da Debug a Release — l'uso di API non disponibili sulla versione del sistema operativo target. In Debug, il build viene testato sul simulatore con l'ultima versione, dove tutte le nuove API sono disponibili. In Release, l'app viene installata su dispositivi di utenti con diverse versioni del sistema operativo e chiamare un'API non disponibile provoca un crash all'avvio. Usa @available (Swift) o compileSdkVersion + minSdkVersion (Android) per specificare esplicitamente la versione minima.

Localizzazione mancante e risorse per diverse configurazioni

Nei build Debug, le risorse vengono spesso caricate dalle directory di origine senza verifica della configurazione. In Release, Gradle e Xcode applicano il filtraggio delle risorse: se una stringa o drawable non viene trovata nella lingua di destinazione, l'app si blocca o mostra un segnaposto. Questo è particolarmente critico per Android: l'assenza di traduzione in values-XX causa ClassCastException durante l'analisi XML. Controlla tutte le lingue prima di un build Release con lint e xcodebuild -showBuildSettings. Per rilevare tali problemi, usa TestFlight e i track Internal Testing prima del rilascio pubblico — vengono eseguiti su dispositivi reali con diverse impostazioni linguistiche.