Build Config у мобільних додатках — що це, налаштування та принцип роботи

Що таке Build Config у мобільній розробці

Build Config — це сукупність налаштувань, що визначають процес компіляції, збірки та пакування мобільного додатка. Конфігурація збірки включає вибір цільової платформи, мінімальної версії SDK, прапорців оптимізації, ключів підпису та змінних середовища.

Сучасні мобільні проекти рідко мають єдину конфігурацію збірки. Зазвичай їх декілька: debug (для розробки з налагодженням), release (для продакшену з оптимізацією), staging (для тестування з бойовими даними) та різні флейвори (демо, повна, корпоративна версії).

За даними опитування Gradle Build Tool Survey (2025), в середньому Android проект використовує 3,2 різні конфігурації збірки, а iOS проект — 2,8. Кожна конфігурація може мати свої прапорці компіляції, сертифікати підпису та URL серверів.

Основне завдання Build Config — автоматизувати перемикання між цими конфігураціями. Замість ручної зміни URL сервера або прапорця налагодження розробник вибирає потрібний Build Variant в IDE, і система збірки підставляє відповідні параметри.

Правильне налаштування Build Config критично впливає на безпеку додатка: в debug-збірці включені детальні логи, інспектор БД та налагоджувальні ендпоїнти, які мають бути фізично виключені з release-бінарника. Gradle вирішує це через Build Types: в debug може бути встановлений прапорець debuggable true, в release — minifyEnabled true з ProGuard. iOS досягає того ж через Swift Active Compilation Conditions, де код всередині #if DEBUG не компілюється в release-конфігурації.

Build Config в Android: Gradle та BuildConfig

Android використовує систему збірки Gradle з двома ключовими поняттями: Build Types та Product Flavors. Їх комбінація утворює Build Variants — кожному варіанту відповідає своя повна конфігурація збірки.

Build Types: debug та release

Build Type — це конфігурація, що визначає, як збирається додаток. За замовчуванням Gradle створює два типи: debug (з налагодженням, без обфускації) та release (з ProGuard/R8, підписаний для публікації). Розробник може додавати свої типи: 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: версії додатка

Product Flavors дозволяють створювати різні версії одного додатка з однієї кодової бази. Наприклад: безкоштовна версія з рекламою, платна без реклами та корпоративна з додатковими функціями. Кожен флейвор може мати свій applicationId, ресурси та SDK-залежності.

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

Клас BuildConfig: доступ з коду

Для кожного Build Variant Gradle генерує клас BuildConfig з полями конфігурації. Розробник додає свої поля через buildConfigField, а стандартні поля (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) створюються автоматично.

// Використання BuildConfig в коді
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig також дозволяє вмикати або вимикати функціональність на етапі збірки. Наприклад, можна додати поле FEATURE_CHAT_ENABLED і вмикати чат лише в повній версії додатка, без перевірок під час виконання та умовних операторів у коді.

Для налагодження мережевих запитів BuildConfig з полем DEBUG дозволяє автоматично підключати HttpLoggingInterceptor в OkHttp тільки для debug-збірок. Це гарантує, що в production жоден HTTP-запит не буде залоговано, навіть якщо розробник випадково забуде прибрати логування перед збіркою релізу.

Build Config в iOS: Xcode та Build Settings

В екосистемі iOS Build Config керується через Xcode Build Settings — таблицю параметрів, де кожен параметр може мати різні значення для різних конфігурацій (Debug, Release, Staging).

Xcode Build Configurations

За замовчуванням Xcode створює дві конфігурації: Debug (для розробки, без оптимізацій) та Release (для продакшену, з оптимізацією -Os). Розробник може додавати свої конфігурації через меню Project > Info > Configurations.

Для кожної конфігурації налаштовуються Build Settings: прапорці компілятора (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), код підпису (CODE_SIGN_IDENTITY), профілі підготовки та entitlements. Xcode записує ці налаштування у файл project.pbxproj.

xcconfig: зовнішні конфігураційні файли

Для зручного керування Build Settings розробники iOS використовують .xcconfig файли — текстові файли з параметрами у форматі KEY = VALUE. Це аналог .env для Xcode: значення підключаються до проекту та перевизначають налаштування в 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: конфігурація часу виконання

Частина параметрів Build Config потрапляє в Info.plist — файл маніфесту iOS додатка. Через Info.plist налаштовуються URL схеми, дозволи (камера, мікрофон), фонові режими та конфігурація входу через сторонні сервіси.

Значення з xcconfig можна підставляти в Info.plist через синтаксис $(VARIABLE_NAME). Наприклад, $(API_BASE_URL) в Info.plist розкриється згідно з активною конфігурацією збірки. Це централізує керування параметрами середовища для всіх платформ Apple.

Build Config в CI/CD пайплайнах

В сучасних проектах Build Config інтегрується з системами безперервної інтеграції: GitLab CI, GitHub Actions, Bitrise, CircleCI. Кожен пайплайн може перевизначати параметри Build Config через змінні середовища CI/CD системи.

Gradle Build Config в CI

Для Android CI пайплайн запускає Gradle із зазначенням Build Variant: ./gradlew assembleFullRelease. Параметри підпису передаються через змінні CI: STORE_PASSWORD, KEY_ALIAS. Gradle читає їх із середовища виконання та підставляє в build.gradle.kts.

// build.gradle.kts — читання з 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 в CI

Для iOS CI використовує xcodebuild з прапорцями конфігурації: -configuration Release. Сертифікати підпису доставляються через CI secrets, а профілі — через Apple Developer Portal API або Fastlane match.

Інструмент Fastlane автоматизує керування Build Config: генерує xcconfig, оновлює версії в Info.plist, підписує зібрані IPA та завантажує їх в App Store Connect. Fastlane gym (збірка) та match (підпис) — стандарт iOS CI пайплайнів.

За даними Bitrise Build Report (2025), проекти з налаштованим Build Config в CI скорочують час ручного налаштування збірки на 73% та знижують кількість помилок підпису на 89%. Автоматизований Build Config — обов'язковий елемент production-ready пайплайну.

Ще один важливий аспект — параметризація версіонування через Build Config. Gradle дозволяє читати versionCode та versionName із змінних CI та підставляти їх в build.gradle.kts динамічно, що виключає розсинхронізацію версій між розробниками. В iOS аналогічне завдання вирішується через agvtool (Apple Generic Versioning Tool), який вміє інкрементувати номер збірки на основі git-тегів або номера білда в CI.