Build Config i mobilappar — vad är det, konfigurering och funktionsprincip

Vad är Build Config i mobilutveckling

Build Config — är den samling inställningar som avgör processen för kompilering, byggande och paketering av mobilappen. Byggkonfigurationen omfattar val av målplattform, lägsta SDK-version, optimeringsflaggor, signeringsnycklar och miljövariabler.

Moderna mobilprojekt har sällan en enda byggkonfiguration. Vanligtvis är de flera: debug (för utveckling med felsökning), release (för produktion med optimering), staging (för testning med produktionsdata) och olika flavors (demo, full, företagsversion).

Enligt undersökningen Gradle Build Tool Survey (2025) använder ett genomsnittligt Android-projekt 3.2 olika byggkonfigurationer och ett iOS-projekt — 2.8. Varje konfiguration kan ha egna kompileringsflaggor, signeringscertifikat och server-URL:er.

Huvuduppgiften för Build Config är att automatisera växlingen mellan dessa konfigurationer. I stället för att manuellt ändra serverns URL eller felsökningsflaggan väljer utvecklaren önskad Build Variant i IDE, och byggsystemet sätter in motsvarande parametrar.

Korrekt konfigurering av Build Config påverkar appens säkerhet kritiskt: i debug-bygget är detaljerade loggar, databasinspektor och felsökningsslutpunkter aktiverade, som måste uteslutas fysiskt från release-binärfilen. Gradle löser detta genom Build Types: i debug kan flaggan debuggable true ställas in, i release — minifyEnabled true med ProGuard. iOS uppnår samma resultat genom Swift Active Compilation Conditions, där koden inuti #if DEBUG inte kompileras i release-konfigurationen.

Build Config i Android: Gradle och BuildConfig

Android använder byggsystemet Gradle med två nyckelbegrepp: Build Types och Product Flavors. Deras kombination skapar Build Variants — varje variant har en egen fullständig byggkonfiguration.

Build Types: debug och release

Build Type — är konfigurationen som avgör hur appen byggs. Som standard skapar Gradle två typer: debug (med felsökning, utan obfuskering) och release (med ProGuard/R8, signerad för publicering). Utvecklaren kan lägga till egna typer: 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: appens versioner

Product Flavors gör det möjligt att skapa olika versioner av en app från en enda kodbas. Till exempel: gratisversion med reklam, betalversion utan reklam och företagsversion med ytterligare funktioner. Varje flavor kan ha ett eget applicationId, egna resurser och SDK-beroenden.

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

Klassen BuildConfig: åtkomst från koden

För varje Build Variant genererar Gradle klassen BuildConfig med konfigurationsfält. Utvecklaren lägger till egna fält via buildConfigField, medan standardfälten (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) skapas automatiskt.

// Använda BuildConfig i koden
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig gör det också möjligt att aktivera eller inaktivera funktioner i byggfasen. Man kan till exempel lägga till fältet FEATURE_CHAT_ENABLED och aktivera chatten endast i appens fullständiga version, utan körningskontroller och villkorsoperatorer i koden.

För felsökning av nätverksförfrågningar gör BuildConfig med fältet DEBUG det möjligt att automatiskt ansluta HttpLoggingInterceptor i OkHttp endast för debug-byggen. Detta garanterar att ingen HTTP-förfrågan loggas i produktionen, även om utvecklaren av misstag glömmer att ta bort loggningen före release-bygget.

Build Config i iOS: Xcode och Build Settings

I iOS-ekosystemet hanteras Build Config genom Xcode Build Settings — en parametertabell där varje parameter kan ha olika värden för olika konfigurationer (Debug, Release, Staging).

Xcode Build Configurations

Som standard skapar Xcode två konfigurationer: Debug (för utveckling, utan optimering) och Release (för produktion, med optimering -Os). Utvecklaren kan lägga till egna konfigurationer via menyn Project > Info > Configurations.

För varje konfiguration ställs Build Settings in: kompilatorflaggor (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), signeringskod (CODE_SIGN_IDENTITY), provisioning-profiler och entitlements. Xcode sparar dessa inställningar i filen project.pbxproj.

xcconfig: externa konfigurationsfiler

För bekväm hantering av Build Settings använder iOS-utvecklare .xcconfig-filer — textfiler med parametrar i formatet KEY = VALUE. Detta är motsvarigheten till .env för Xcode: värdena kopplas till projektet och skriver över inställningarna i 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: konfigurering vid körning

En del av Build Config-parametrarna hamnar i Info.plist — manifestfilen för iOS-appen. Genom Info.plist konfigureras URL-scheman, behörigheter (kamera, mikrofon), bakgrundslägen och konfigurering av inloggning via tredjepartstjänster.

Värden från xcconfig kan sättas in i Info.plist genom syntaxen $(VARIABLE_NAME). Till exempel expanderas $(API_BASE_URL) i Info.plist enligt den aktiva byggkonfigurationen. Detta centraliserar hanteringen av miljöparametrar för alla Apple-plattformar.

Build Config i CI/CD-pipelines

I moderna projekt integreras Build Config med system för kontinuerlig integrering: GitLab CI, GitHub Actions, Bitrise, CircleCI. Varje pipeline kan skriva över Build Config-parametrar genom miljövariabler i CI/CD-systemet.

Gradle Build Config i CI

För Android startar CI-pipelinen Gradle med angivande av Build Variant: ./gradlew assembleFullRelease. Signeringsparametrar överförs genom CI-variabler: STORE_PASSWORD, KEY_ALIAS. Gradle läser dem från körningsmiljön och sätter in dem i build.gradle.kts.

// build.gradle.kts — läsning från CI-variabler
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 i CI

För iOS använder CI xcodebuild med konfigurationsflaggor: -configuration Release. Signeringscertifikat levereras genom CI-secrets och profiler — genom Apple Developer Portal API eller Fastlane match.

Verktyget Fastlane automatiserar hanteringen av Build Config: det genererar xcconfig, uppdaterar versioner i Info.plist, signerar byggda IPA-filer och laddar upp dem till App Store Connect. Fastlane gym (byggande) och match (signering) — är standarden för iOS CI-pipelines.

Enligt Bitrise Build Report (2025) minskar projekt med konfigurerad Build Config i CI tiden för manuell byggkonfigurering med 73% och minskar antalet signeringsfel med 89%. Automatiserad Build Config — är ett obligatoriskt element i en production-ready-pipeline.

En annan viktig aspekt — parametrisering av versionshantering genom Build Config. Gradle gör det möjligt att läsa versionCode och versionName från CI-variabler och dynamiskt sätta in dem i build.gradle.kts, vilket eliminerar versionsobalans mellan utvecklare. I iOS löses en liknande uppgift genom agvtool (Apple Generic Versioning Tool), som kan öka byggnumret baserat på git-taggar eller byggnumret i CI.