Build e pubblicazione nello sviluppo mobile: cosa sono, quali formati e come funzionano

Formati di build: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — il formato tradizionale di build e pubblicazione di app mobili su Android. APK contiene tutto il codice, le risorse e il manifest dell'app. AAB (Android App Bundle) — un formato introdotto da Google nel 2018 e diventato obbligatorio per le nuove app da agosto 2021. AAB non viene installato direttamente — Google Play genera dinamicamente un APK ottimizzato per ogni dispositivo da AAB.

Vantaggi di AAB: la dimensione del download è in media del 15% inferiore (fornendo solo le risorse necessarie: corrette densità dello schermo, lingue, architetture CPU). AAB supporta anche la consegna modulare — puoi caricare moduli su richiesta (Play Feature Delivery) o differiti (Play On-Demand). Per gli sviluppatori, AAB è obbligatorio; per la distribuzione al di fuori di Google Play (sideloading, marketplace) — solo APK.

IPA

IPA (iOS App Store Package) — il file installabile di iOS, che è un archivio ZIP contenente un'app firmata. IPA contiene una cartella Payload/ con il bundle .app, Provisioning Profile e firma. IPA viene costruito solo su macOS tramite Xcode, che crea un archivio (.xcarchive) ed esporta IPA. Per la distribuzione tramite App Store, IPA viene firmato con un Apple Distribution Certificate; per Ad Hoc o Enterprise — con i certificati corrispondenti.

Compilazione e ottimizzazione: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — compilazione del codice durante l'esecuzione dell'app, che influenza la velocità di build e pubblicazione. Su Android fino alla versione 5.0 (Lollipop), veniva utilizzato Dalvik VM con compilazione JIT. A ogni avvio dell'app, il bytecode DEX veniva convertito in codice macchina «al volo». Svantaggio: rallentamento al primo avvio e consumo energetico aggiuntivo. AOT (Ahead-Of-Time) — compilazione del codice prima dell'avvio dell'app, durante l'installazione. A partire da Android 7.0 (Nougat), ART (Android Runtime) compila completamente l'app durante l'installazione.

ART (Android Runtime) — l'ambiente di esecuzione che ha sostituito Dalvik in Android 5.0. ART utilizza un approccio ibrido: compilazione AOT durante l'installazione + JIT per i metodi eseguiti frequentemente. Questo combina la velocità di AOT (avvio rapido) con la flessibilità di JIT (ottimizzazione adattiva). Risultato: le prestazioni delle app Android sono aumentate del 20-30% rispetto a Dalvik. Per gli sviluppatori, la transizione ad ART è trasparente — il codice non richiede modifiche.

Bitcode e App Thinning

Bitcode — una rappresentazione intermedia del codice (IR) che Apple utilizza per ricompilare IPA per diverse architetture di processori. Bitcode è opzionale: per le app iOS è abilitato per impostazione predefinita, per watchOS e tvOS è obbligatorio. Apple può ricompilare Bitcode all'uscita di nuovi processori senza il coinvolgimento dello sviluppatore. App Thinning — la tecnologia di Apple che include Slicing (consegna solo delle risorse necessarie per il dispositivo) e On-Demand Resources (caricamento delle risorse su richiesta). App Thinning riduce la dimensione del download dall'App Store del 30-50%.

DEX — formato bytecode per Android, eseguito da ART/Dalvik. Il codice sorgente Kotlin/Java viene compilato in file class, poi in DEX tramite dx o d8 (uno strumento moderno e più veloce). Multidex — un meccanismo per le app che superano il limite di 65.536 metodi in un singolo file DEX. Nei progetti moderni, multidex viene abilitato automaticamente se targetSdkVersion >= 21.

Firma del codice: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — un file contenente la chiave privata e il certificato per firmare un'app Android durante il build. Keystore viene creato tramite keytool (il comando -genkey) o Android Studio. Importante: Keystore non può essere perso — senza di esso non è possibile aggiornare l'app su Google Play. Parametri di firma: keyAlias, keyPassword, storePassword e storeFile. Formato: JKS (Java KeyStore) o PEPK (Play Encrypted Private Key) per AAB.

App Bundle ID (Android) — l'identificatore univoco dell'app in notazione pacchetto (com.example.app). Version Code — un numero intero per la numerazione interna delle versioni (ogni nuovo build lo incrementa). Version Name — una stringa visualizzata all'utente (1.2.3). Questi parametri vengono impostati in build.gradle a livello di app.

iOS: Apple Certificate e Provisioning Profile

Apple Certificate — un certificato digitale che verifica l'identità dello sviluppatore. Tipi: Development (per il debug), Distribution (per App Store), Ad Hoc (per distribuzione limitata). I certificati vengono creati in Apple Developer Account e scaricati in Keychain. Provisioning Profile — un file che collega il certificato, l'App ID (Bundle Identifier) e un elenco di dispositivi consentiti. Senza Provisioning Profile, l'app non verrà eseguita su un dispositivo.

Bundle ID (iOS) — l'identificatore univoco dell'app (com.example.app). Build Number — il numero di build, incrementato a ogni build. Marketing Version — la versione mostrata all'utente. Gestione delle versioni: per iOS, i parametri vengono impostati in Info.plist e Project Settings; per Android — in build.gradle. In IT Sectr, automatizziamo gli aggiornamenti di versione tramite Fastlane — questo elimina gli errori umani durante il rilascio.

Processo di pubblicazione negli store

Google Play Console

Google Play Console — uno strumento per pubblicare app Android. Processo: registrazione di un account sviluppatore ($25 una tantum), creazione dell'app, compilazione dei metadati (nome, descrizione, screenshot, categoria), caricamento di AAB, configurazione di prezzi e distribuzione, revisione. Google controlla l'app automaticamente (virus, conformità alle politiche) e manualmente per alcune categorie. La revisione richiede da poche ore a 2-3 giorni.

App Store Connect

App Store Connect — la piattaforma Apple per pubblicare app iOS. Processo: account sviluppatore Apple ($99/anno), creazione dell'app in App Store Connect, preparazione di IPA in Xcode (Archive → Distribute App → App Store Connect), caricamento tramite Transporter o Xcode, compilazione dei metadati, invio per la revisione. App Review — la revisione manuale di Apple può richiedere da 24 ore a 7 giorni. Motivi tipici di rifiuto: pulsanti non funzionanti, contenuto incompleto, richiesta di autorizzazioni senza spiegazione.

Test beta: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — lo strumento ufficiale di Apple per i test beta di app iOS. TestFlight supporta Internal Testing (fino a 100 tester via email, senza revisione) e External Testing (fino a 10.000 tester, con revisione Apple). I build sono disponibili per 90 giorni, dopo i quali è necessario caricare un nuovo build. TestFlight aggiorna automaticamente l'app sui dispositivi dei tester quando viene caricato un nuovo build.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — fino a 100 tester, senza revisione Google, build disponibile immediatamente. Closed Beta — fino a 1000 tester via email o Google Groups, senza revisione. Open Beta — tester illimitati tramite un collegamento pubblico, con revisione Google. Staged Rollout — aumento graduale della percentuale di utenti che ricevono l'aggiornamento (5% → 20% → 50% → 100%). Questo è il metodo di rilascio più sicuro.

App Thinning (iOS) — riduzione automatica della dimensione dell'IPA scaricato: Slicing (solo risorse necessarie per il dispositivo), Bitcode (ottimizzazione del processore), On-Demand Resources (download su richiesta). In IT Sectr, utilizziamo TestFlight per i test beta iOS e Internal Testing per Android — questo permette di individuare i problemi prima di un rilascio di massa.