Build Config in mobiele apps — wat is het, configuratie en werkingsprincipe

Wat is Build Config in mobiele ontwikkeling

Build Config — is het geheel van instellingen dat het proces van compilatie, build en verpakking van de mobiele app bepaalt. De buildconfiguratie omvat de keuze van het doelplatform, de minimale SDK-versie, optimalisatievlaggen, ondertekeningssleutels en omgevingsvariabelen.

Moderne mobiele projecten hebben zelden één enkele buildconfiguratie. Meestal zijn er meerdere: debug (voor ontwikkeling met debugging), release (voor productie met optimalisatie), staging (voor testen met productiegegevens) en verschillende flavors (demo, volledige, bedrijfsversie).

Volgens de enquête Gradle Build Tool Survey (2025) gebruikt een gemiddeld Android-project 3.2 verschillende buildconfiguraties en een iOS-project — 2.8. Elke configuratie kan eigen compilatievlaggen, ondertekeningscertificaten en server-URL's hebben.

De hoofdtaak van Build Config is het automatiseren van het schakelen tussen deze configuraties. In plaats van de server-URL of de debugvlag handmatig te wijzigen, selecteert de ontwikkelaar de gewenste Build Variant in de IDE, en het bouwsysteem vult de bijbehorende parameters in.

Een correcte Build Config-configuratie is van cruciaal belang voor de beveiliging van de app: in de debug-build zijn gedetailleerde logs, de database-inspector en debug-endpoints ingeschakeld, die fysiek moeten worden uitgesloten van het release-binair bestand. Gradle lost dit op via Build Types: in debug kan de vlag debuggable true worden ingesteld, in release — minifyEnabled true met ProGuard. iOS bereikt hetzelfde via Swift Active Compilation Conditions, waar code binnen #if DEBUG niet wordt gecompileerd in de release-configuratie.

Build Config in Android: Gradle en BuildConfig

Android gebruikt het bouwsysteem Gradle met twee kernbegrippen: Build Types en Product Flavors. Hun combinatie vormt Build Variants — elke variant heeft een eigen volledige buildconfiguratie.

Build Types: debug en release

Build Type — is de configuratie die bepaalt hoe de app wordt gebouwd. Standaard maakt Gradle twee typen aan: debug (met debugging, zonder obfuscatie) en release (met ProGuard/R8, ondertekend voor publicatie). De ontwikkelaar kan eigen typen toevoegen: 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: versies van de app

Product Flavors maken het mogelijk om vanuit één codebase verschillende versies van één app te maken. Bijvoorbeeld: een gratis versie met advertenties, een betaalde versie zonder advertenties en een bedrijfsversie met extra functionaliteit. Elke flavor kan een eigen applicationId, resources en SDK-afhankelijkheden hebben.

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

De klasse BuildConfig: toegang vanuit code

Voor elke Build Variant genereert Gradle de klasse BuildConfig met configuratievelden. De ontwikkelaar voegt eigen velden toe via buildConfigField, en de standaardvelden (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) worden automatisch aangemaakt.

// BuildConfig gebruiken in code
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig maakt het ook mogelijk om functionaliteit in de buildfase in of uit te schakelen. Zo kan men bijvoorbeeld het veld FEATURE_CHAT_ENABLED toevoegen en de chat alleen in de volledige versie van de app inschakelen, zonder runtime-controles en voorwaardelijke operatoren in de code.

Voor het debuggen van netwerkverzoeken maakt BuildConfig met het veld DEBUG het mogelijk om HttpLoggingInterceptor in OkHttp alleen voor debug-builds automatisch aan te sluiten. Dit garandeert dat in productie geen enkele HTTP-aanvraag wordt gelogd, zelfs niet als de ontwikkelaar vergeet de logging voor de release-build te verwijderen.

Build Config in iOS: Xcode en Build Settings

In het iOS-ecosysteem wordt Build Config beheerd via Xcode Build Settings — een tabel met parameters waarin elke parameter verschillende waarden kan hebben voor verschillende configuraties (Debug, Release, Staging).

Xcode Build Configurations

Standaard maakt Xcode twee configuraties aan: Debug (voor ontwikkeling, zonder optimalisatie) en Release (voor productie, met optimalisatie -Os). De ontwikkelaar kan eigen configuraties toevoegen via het menu Project > Info > Configurations.

Voor elke configuratie worden Build Settings ingesteld: compilatorvlaggen (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), ondertekeningscode (CODE_SIGN_IDENTITY), provisioning-profielen en entitlements. Xcode slaat deze instellingen op in het bestand project.pbxproj.

xcconfig: externe configuratiebestanden

Voor het handig beheren van Build Settings gebruiken iOS-ontwikkelaars .xcconfig-bestanden — tekstbestanden met parameters in het formaat KEY = VALUE. Dit is het equivalent van .env voor Xcode: waarden worden aan het project gekoppeld en overschrijven instellingen 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: configuratie tijdens uitvoering

Een deel van de Build Config-parameters komt terecht in Info.plist — het manifestbestand van de iOS-app. Via Info.plist worden URL-schema's, machtigingen (camera, microfoon), achtergrondmodi en de configuratie van aanmelding via services van derden ingesteld.

Waarden uit xcconfig kunnen in Info.plist worden ingevoegd via de syntaxis $(VARIABLE_NAME). Bijvoorbeeld $(API_BASE_URL) in Info.plist wordt uitgebreid volgens de actieve buildconfiguratie. Dit centraliseert het beheer van omgevingsparameters voor alle Apple-platforms.

Build Config in CI/CD-pipelines

In moderne projecten integreert Build Config met systemen voor continue integratie: GitLab CI, GitHub Actions, Bitrise, CircleCI. Elke pipeline kan Build Config-parameters overschrijven via omgevingsvariabelen van het CI/CD-systeem.

Gradle Build Config in CI

Voor Android start de CI-pipeline Gradle met opgave van de Build Variant: ./gradlew assembleFullRelease. Ondertekeningsparameters worden doorgegeven via CI-variabelen: STORE_PASSWORD, KEY_ALIAS. Gradle leest ze uit de uitvoeringsomgeving en vult ze in build.gradle.kts in.

// build.gradle.kts — lezen uit CI-variabelen
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

Voor iOS gebruikt CI xcodebuild met configuratievlaggen: -configuration Release. Ondertekeningscertificaten worden geleverd via CI-secrets en profielen — via Apple Developer Portal API of Fastlane match.

Het hulpprogramma Fastlane automatiseert het beheer van Build Config: het genereert xcconfig, werkt versies bij in Info.plist, ondertekent gebouwde IPA-bestanden en uploadt ze naar App Store Connect. Fastlane gym (build) en match (ondertekening) — de standaard van iOS CI-pipelines.

Volgens Bitrise Build Report (2025) verkorten projecten met Build Config in CI de tijd voor handmatige buildconfiguratie met 73% en verminderen ze het aantal ondertekeningsfouten met 89%. Geautomatiseerde Build Config — een verplicht onderdeel van een production-ready pipeline.

Een ander belangrijk aspect — parametrisering van versiebeheer via Build Config. Gradle maakt het mogelijk om versionCode en versionName uit CI-variabelen te lezen en dynamisch in build.gradle.kts in te vullen, wat desynchronisatie van versies tussen ontwikkelaars voorkomt. In iOS wordt een vergelijkbare taak opgelost via agvtool (Apple Generic Versioning Tool), dat het buildnummer kan verhogen op basis van git-tags of het buildnummer in CI.