Build Config v mobilních aplikacích — co to je, nastavení a princip fungování

Co je Build Config ve vývoji mobilních aplikací

Build Config — je soubor nastavení, který určuje proces překladu, sestavení a balení mobilní aplikace. Konfigurace sestavení zahrnuje výběr cílové platformy, minimální verze SDK, optimalizačních přepínačů, podpisových klíčů a proměnných prostředí.

Moderní mobilní projekty mívají jen zřídka jedinou konfiguraci sestavení. Obvykle jich je několik: debug (pro vývoj s laděním), release (pro produkci s optimalizací), staging (pro testování s produkčními daty) a různé flavory (demo, plná, firemní verze).

Podle průzkumu Gradle Build Tool Survey (2025) používá průměrný projekt Android 3.2 různých konfigurací sestavení a projekt iOS — 2.8. Každá konfigurace může mít vlastní překladové přepínače, podpisové certifikáty a URL adresy serverů.

Hlavním úkolem Build Config je automatizace přepínání mezi těmito konfiguracemi. Místo ruční změny URL adresy serveru nebo ladícího přepínače vybere vývojář požadovaný Build Variant v IDE a systém sestavení dosadí odpovídající parametry.

Správné nastavení Build Config má kritický vliv na bezpečnost aplikace: v debug buildu jsou zapnuty podrobné protokoly, inspektor databáze a ladicí endpointy, které musí být fyzicky vyloučeny z release binárního souboru. Gradle to řeší prostřednictvím Build Types: v debug lze nastavit přepínač debuggable true, v release — minifyEnabled true s ProGuard. iOS dosahuje stejného výsledku prostřednictvím Swift Active Compilation Conditions, kde se kód uvnitř #if DEBUG nepřekládá v konfiguraci release.

Build Config v Androidu: Gradle a BuildConfig

Android používá systém sestavení Gradle se dvěma klíčovými pojmy: Build Types a Product Flavors. Jejich kombinace vytváří Build Variants — každému variantu odpovídá úplná konfigurace sestavení.

Build Types: debug a release

Build Type — je konfigurace, která určuje, jak se aplikace sestavuje. Ve výchozím nastavení Gradle vytváří dva typy: debug (s laděním, bez obfuskace) a release (s ProGuard/R8, podepsaný pro publikaci). Vývojář může přidávat vlastní typy: 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: verze aplikace

Product Flavors umožňují vytvářet různé verze jedné aplikace z jednoho zdrojového kódu. Například: bezplatná verze s reklamou, placená verze bez reklamy a firemní verze s dalšími funkcemi. Každý flavor může mít vlastní applicationId, prostředky a závislosti SDK.

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

Třída BuildConfig: přístup z kódu

Pro každý Build Variant Gradle generuje třídu BuildConfig s konfiguračními poli. Vývojář přidává vlastní pole pomocí buildConfigField, zatímco standardní pole (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) se vytvářejí automaticky.

// Použití BuildConfig v kódu
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig také umožňuje zapínat nebo vypínat funkce ve fázi sestavení. Lze například přidat pole FEATURE_CHAT_ENABLED a zapnout chat pouze v plné verzi aplikace, bez kontrol za běhu a podmíněných operátorů v kódu.

Pro ladění síťových požadavků umožňuje BuildConfig s polem DEBUG automaticky připojit HttpLoggingInterceptor v OkHttp pouze pro debug buildu. To zaručuje, že v produkci nebude zaznamenán žádný požadavek HTTP, i když vývojář zapomene před sestavením release odebrat logování.

Build Config v iOS: Xcode a Build Settings

V ekosystému iOS se Build Config spravuje prostřednictvím Xcode Build Settings — tabulky parametrů, kde každý parametr může mít různé hodnoty pro různé konfigurace (Debug, Release, Staging).

Xcode Build Configurations

Ve výchozím nastavení Xcode vytváří dvě konfigurace: Debug (pro vývoj, bez optimalizace) a Release (pro produkci, s optimalizací -Os). Vývojář může přidávat vlastní konfigurace prostřednictvím nabídky Project > Info > Configurations.

Pro každou konfiguraci se nastavují Build Settings: překladačové přepínače (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), podpisový kód (CODE_SIGN_IDENTITY), provisioning profily a entitlements. Xcode ukládá tato nastavení do souboru project.pbxproj.

xcconfig: externí konfigurační soubory

Pro pohodlnou správu Build Settings používají vývojáři iOS soubory .xcconfig — textové soubory s parametry ve formátu KEY = VALUE. Je to obdoba .env pro Xcode: hodnoty se připojí k projektu a přepisují nastavení v 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: konfigurace za běhu

Část parametrů Build Config se dostává do Info.plist — souboru manifestu aplikace iOS. Prostřednictvím Info.plist se nastavují schémata URL, oprávnění (kamera, mikrofon), režimy na pozadí a konfigurace přihlašování přes služby třetích stran.

Hodnoty z xcconfig lze do Info.plist vložit pomocí syntaxe $(VARIABLE_NAME). Například $(API_BASE_URL) v Info.plist se rozbalí podle aktivní konfigurace sestavení. To centralizuje správu parametrů prostředí pro všechny platformy Apple.

Build Config v CI/CD pipeline

V moderních projektech se Build Config integruje se systémy průběžné integrace: GitLab CI, GitHub Actions, Bitrise, CircleCI. Každá pipeline může přepisovat parametry Build Config prostřednictvím proměnných prostředí systému CI/CD.

Gradle Build Config v CI

Pro Android spouští CI pipeline Gradle s uvedením Build Variant: ./gradlew assembleFullRelease. Parametry podpisu se předávají prostřednictvím proměnných CI: STORE_PASSWORD, KEY_ALIAS. Gradle je čte z běhového prostředí a dosazuje do build.gradle.kts.

// build.gradle.kts — čtení z CI proměnných
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 v CI

Pro iOS používá CI xcodebuild s konfiguračními přepínači: -configuration Release. Podpisové certifikáty se dodávají prostřednictvím CI secrets a profily — prostřednictvím Apple Developer Portal API nebo Fastlane match.

Nástroj Fastlane automatizuje správu Build Config: generuje xcconfig, aktualizuje verze v Info.plist, podepisuje sestavené IPA soubory a nahrává je do App Store Connect. Fastlane gym (sestavení) a match (podpis) — standard CI pipeline pro iOS.

Podle Bitrise Build Report (2025) projekty s nakonfigurovaným Build Config v CI zkracují čas ručního nastavení sestavení o 73% a snižují počet chyb podpisu o 89%. Automatizovaný Build Config — povinný prvek pipeline production-ready.

Dalším důležitým aspektem je parametrizace verzování prostřednictvím Build Config. Gradle umožňuje číst versionCode a versionName z proměnných CI a dynamicky je dosazovat do build.gradle.kts, což eliminuje desynchronizaci verzí mezi vývojáři. V iOS se podobný úkol řeší prostřednictvím agvtool (Apple Generic Versioning Tool), který umí zvyšovat číslo buildu na základě git tagů nebo čísla buildu v CI.