Build Config nelle app mobili — cos'è, configurazione e principio di funzionamento

Cos'è Build Config nello sviluppo mobile

Build Config è un insieme di impostazioni che definiscono il processo di compilazione, costruzione e impacchettamento di un'applicazione mobile. La configurazione di build include la selezione della piattaforma target, della versione minima SDK, dei flag di ottimizzazione, delle chiavi di firma e delle variabili d'ambiente.

I progetti mobili moderni raramente hanno un'unica configurazione di build. Di solito ne hanno diverse: debug (per lo sviluppo con debug), release (per la produzione con ottimizzazione), staging (per test con dati reali) e vari flavor (demo, completa, enterprise).

Secondo il Gradle Build Tool Survey (2025), un progetto Android medio utilizza 3,2 configurazioni di build diverse, mentre un progetto iOS ne utilizza 2,8. Ogni configurazione può avere i propri flag di compilazione, certificati di firma e URL dei server.

Il compito principale di Build Config è automatizzare il passaggio tra queste configurazioni. Invece di modificare manualmente l'URL del server o il flag di debug, lo sviluppatore seleziona il Build Variant desiderato nell'IDE e il sistema di build sostituisce i parametri corrispondenti.

Una corretta configurazione di Build Config influisce criticamente sulla sicurezza dell'applicazione: le build debug includono log dettagliati, ispettore del database ed endpoint di debug che devono essere fisicamente esclusi dal binario release. Gradle risolve questo tramite Build Types: debug può avere il flag debuggable true, release — minifyEnabled true con ProGuard. iOS ottiene lo stesso risultato tramite Swift Active Compilation Conditions, dove il codice all'interno di #if DEBUG non viene compilato nella configurazione release.

Build Config in Android: Gradle e BuildConfig

Android utilizza il sistema di build Gradle con due concetti chiave: Build Types e Product Flavors. La loro combinazione forma Build Variants — ogni variante ha la propria configurazione di build completa.

Build Types: Debug e Release

Build Type è una configurazione che definisce come viene costruita l'applicazione. Per impostazione predefinita, Gradle crea due tipi: debug (con debug, senza offuscamento) e release (con ProGuard/R8, firmato per la pubblicazione). Lo sviluppatore può aggiungere i propri tipi: staging, benchmark, qa.

// build.gradle.kts
android {
    buildTypes {
        debug {
            isDebuggable = true
            buildConfigField("String", "API_URL", "\"http://dev.api.com\"")
        }
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            buildConfigField("String", "API_URL", "\"https://prod.api.com\"")
        }
    }
}

Product Flavors: Versioni dell'applicazione

Product Flavors consentono di creare diverse versioni della stessa applicazione da un'unica base di codice. Ad esempio: versione gratuita con pubblicità, versione a pagamento senza pubblicità e versione enterprise con funzionalità aggiuntive. Ogni flavor può avere il proprio applicationId, risorse e dipendenze SDK.

android {
    productFlavors {
        register("demo") {
            applicationId = "com.example.app.demo"
            versionNameSuffix = "-demo"
        }
        register("full") {
            applicationId = "com.example.app"
            versionNameSuffix = ""
        }
    }
}

Classe BuildConfig: Accesso dal codice

Per ogni Build Variant, Gradle genera una classe BuildConfig con campi di configurazione. Lo sviluppatore aggiunge campi personalizzati tramite buildConfigField, mentre i campi standard (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) vengono creati automaticamente.

// Utilizzo di BuildConfig nel codice
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig consente anche di abilitare o disabilitare funzionalità al momento della compilazione. Ad esempio, puoi aggiungere un campo FEATURE_CHAT_ENABLED e abilitare la chat solo nella versione completa dell'applicazione, senza controlli a runtime e operatori condizionali nel codice.

Per il debug delle richieste di rete, BuildConfig con il campo DEBUG consente di allegare automaticamente HttpLoggingInterceptor in OkHttp solo per le build debug. Questo garantisce che nessuna richiesta HTTP venga registrata in produzione, anche se lo sviluppatore dimentica accidentalmente di rimuovere la registrazione prima di compilare la release.

Build Config in iOS: Xcode e Build Settings

Nell'ecosistema iOS, Build Config viene gestito tramite Xcode Build Settings — una tabella di parametri in cui ogni parametro può avere valori diversi per diverse configurazioni (Debug, Release, Staging).

Configurazioni di build Xcode

Per impostazione predefinita, Xcode crea due configurazioni: Debug (per lo sviluppo, senza ottimizzazioni) e Release (per la produzione, con ottimizzazione -Os). Lo sviluppatore può aggiungere le proprie configurazioni tramite il menu Project > Info > Configurations.

Per ogni configurazione, vengono configurati Build Settings: flag del compilatore (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), codice di firma (CODE_SIGN_IDENTITY), profili di provisioning e entitlements. Xcode scrive queste impostazioni nel file project.pbxproj.

xcconfig: File di configurazione esterni

Per una gestione comoda di Build Settings, gli sviluppatori iOS utilizzano file .xcconfig — file di testo con parametri in formato KEY = VALUE. Sono l'analogo di .env per Xcode: i valori vengono collegati al progetto e sovrascrivono le impostazioni in project.pbxproj.

// Debug.xcconfig
BUNDLE_ID_SUFFIX = .debug
API_BASE_URL = http://localhost:8080
SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG
CODE_SIGN_IDENTITY = Apple Development

// Release.xcconfig
BUNDLE_ID_SUFFIX =
API_BASE_URL = https://api.production.com
SWIFT_ACTIVE_COMPILATION_CONDITIONS =
CODE_SIGN_IDENTITY = Apple Distribution

Info.plist: Configurazione a runtime

Parte dei parametri di Build Config finisce in Info.plist — il file manifesto dell'applicazione iOS. Tramite Info.plist vengono configurati schemi URL, permessi (fotocamera, microfono), modalità background e configurazione di login con servizi terzi.

I valori da xcconfig possono essere sostituiti in Info.plist tramite la sintassi $(VARIABLE_NAME). Ad esempio, $(API_BASE_URL) in Info.plist verrà espanso in base alla configurazione di build attiva. Questo centralizza la gestione dei parametri ambientali per tutte le piattaforme Apple.

Build Config nelle pipeline CI/CD

Nei progetti moderni, Build Config si integra con i sistemi di integrazione continua: GitLab CI, GitHub Actions, Bitrise, CircleCI. Ogni pipeline può sovrascrivere i parametri di Build Config tramite variabili d'ambiente del sistema CI/CD.

Gradle Build Config in CI

Per Android, la pipeline CI esegue Gradle con il Build Variant specificato: ./gradlew assembleFullRelease. I parametri di firma vengono passati tramite variabili CI: STORE_PASSWORD, KEY_ALIAS. Gradle li legge dall'ambiente di esecuzione e li sostituisce in build.gradle.kts.

// build.gradle.kts — lettura da variabili CI
android {
    signingConfigs {
        register("release") {
            storeFile = file(System.getenv("KEYSTORE_PATH") ?: "debug.keystore")
            storePassword = System.getenv("STORE_PASSWORD") ?: ""
            keyAlias = System.getenv("KEY_ALIAS") ?: "key"
            keyPassword = System.getenv("KEY_PASSWORD") ?: ""
        }
    }
}

Xcode Build Config in CI

Per iOS, CI utilizza xcodebuild con flag di configurazione: -configuration Release. I certificati di firma vengono forniti tramite CI secrets e i profili tramite Apple Developer Portal API o Fastlane match.

Lo strumento Fastlane automatizza la gestione di Build Config: genera xcconfig, aggiorna le versioni in Info.plist, firma gli IPA costruiti e li carica su App Store Connect. Fastlane gym (build) e match (firma) sono lo standard per le pipeline CI iOS.

Secondo il Bitrise Build Report (2025), i progetti con Build Config configurato in CI riducono il tempo di configurazione manuale della build del 73% e riducono gli errori di firma dell'89%. Build Config automatizzato è un elemento obbligatorio di una pipeline pronta per la produzione.

Un altro aspetto importante è la parametrizzazione del versionamento tramite Build Config. Gradle consente di leggere versionCode e versionName dalle variabili CI e sostituirli dinamicamente in build.gradle.kts, eliminando la desincronizzazione delle versioni tra sviluppatori. In iOS, un compito simile viene risolto tramite agvtool (Apple Generic Versioning Tool), che può incrementare il numero di build basandosi su tag git o sul numero di build in CI.