Build Config di aplikasi seluler — apa itu, konfigurasi, dan prinsip kerja

Apa itu Build Config dalam pengembangan seluler

Build Config — adalah kumpulan pengaturan yang menentukan proses kompilasi, pembangunan, dan pengemasan aplikasi seluler. Konfigurasi build mencakup pemilihan platform target, versi SDK minimum, flag optimasi, kunci penandatanganan, dan variabel lingkungan.

Proyek seluler modern jarang memiliki satu konfigurasi build saja. Biasanya ada beberapa: debug (untuk pengembangan dengan debugging), release (untuk produksi dengan optimasi), staging (untuk pengujian dengan data produksi) dan berbagai flavor (versi demo, lengkap, korporat).

Menurut survei Gradle Build Tool Survey (2025), rata-rata proyek Android menggunakan 3.2 konfigurasi build yang berbeda, dan proyek iOS — 2.8. Setiap konfigurasi dapat memiliki flag kompilasi, sertifikat penandatanganan, dan URL server sendiri.

Tugas utama Build Config adalah mengotomatiskan peralihan antar konfigurasi ini. Alih-alih mengubah URL server atau flag debug secara manual, pengembang memilih Build Variant yang diinginkan di IDE, dan sistem build memasukkan parameter yang sesuai.

Konfigurasi Build Config yang benar sangat memengaruhi keamanan aplikasi: dalam build debug, log terperinci, inspektur database, dan endpoint debug aktif, yang harus secara fisik dikeluarkan dari biner release. Gradle menyelesaikannya melalui Build Types: di debug dapat diatur flag debuggable true, di release — minifyEnabled true dengan ProGuard. iOS mencapai hal yang sama melalui Swift Active Compilation Conditions, di mana kode di dalam #if DEBUG tidak dikompilasi dalam konfigurasi release.

Build Config di Android: Gradle dan BuildConfig

Android menggunakan sistem build Gradle dengan dua konsep kunci: Build Types dan Product Flavors. Kombinasinya membentuk Build Variants — setiap varian memiliki konfigurasi build lengkap sendiri.

Build Types: debug dan release

Build Type — adalah konfigurasi yang menentukan bagaimana aplikasi dibangun. Secara default, Gradle membuat dua jenis: debug (dengan debugging, tanpa obfuskasi) dan release (dengan ProGuard/R8, ditandatangani untuk publikasi). Pengembang dapat menambahkan jenis sendiri: 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: versi aplikasi

Product Flavors memungkinkan pembuatan berbagai versi satu aplikasi dari satu basis kode. Misalnya: versi gratis dengan iklan, versi berbayar tanpa iklan, dan versi korporat dengan fitur tambahan. Setiap flavor dapat memiliki applicationId, sumber daya, dan dependensi SDK sendiri.

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

Kelas BuildConfig: akses dari kode

Untuk setiap Build Variant, Gradle menghasilkan kelas BuildConfig dengan bidang konfigurasi. Pengembang menambahkan bidang sendiri melalui buildConfigField, dan bidang standar (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) dibuat secara otomatis.

// Menggunakan BuildConfig dalam kode
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig juga memungkinkan mengaktifkan atau menonaktifkan fungsionalitas pada tahap build. Misalnya, dapat menambahkan bidang FEATURE_CHAT_ENABLED dan mengaktifkan obrolan hanya di versi lengkap aplikasi, tanpa pemeriksaan runtime dan operator kondisional dalam kode.

Untuk men-debug permintaan jaringan, BuildConfig dengan bidang DEBUG memungkinkan menghubungkan HttpLoggingInterceptor di OkHttp secara otomatis hanya untuk build debug. Ini menjamin bahwa di produksi tidak ada permintaan HTTP yang akan dicatat, bahkan jika pengembang lupa menghapus pencatatan sebelum membangun release.

Build Config di iOS: Xcode dan Build Settings

Di ekosistem iOS, Build Config dikelola melalui Xcode Build Settings — tabel parameter di mana setiap parameter dapat memiliki nilai berbeda untuk konfigurasi berbeda (Debug, Release, Staging).

Xcode Build Configurations

Secara default, Xcode membuat dua konfigurasi: Debug (untuk pengembangan, tanpa optimasi) dan Release (untuk produksi, dengan optimasi -Os). Pengembang dapat menambahkan konfigurasi sendiri melalui menu Project > Info > Configurations.

Untuk setiap konfigurasi, Build Settings diatur: flag kompilator (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), kode penandatanganan (CODE_SIGN_IDENTITY), profil provisioning dan entitlements. Xcode menyimpan pengaturan ini di file project.pbxproj.

xcconfig: file konfigurasi eksternal

Untuk mengelola Build Settings dengan mudah, pengembang iOS menggunakan file .xcconfig — file teks dengan parameter dalam format KEY = VALUE. Ini adalah analog .env untuk Xcode: nilai dihubungkan ke proyek dan menimpa pengaturan di 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: konfigurasi waktu eksekusi

Sebagian parameter Build Config masuk ke Info.plist — file manifes aplikasi iOS. Melalui Info.plist, skema URL, izin (kamera, mikrofon), mode latar belakang, dan konfigurasi masuk melalui layanan pihak ketiga diatur.

Nilai dari xcconfig dapat dimasukkan ke Info.plist melalui sintaks $(VARIABLE_NAME). Misalnya, $(API_BASE_URL) di Info.plist akan diperluas sesuai konfigurasi build yang aktif. Ini memusatkan pengelolaan parameter lingkungan untuk semua platform Apple.

Build Config dalam pipeline CI/CD

Dalam proyek modern, Build Config terintegrasi dengan sistem integrasi berkelanjutan: GitLab CI, GitHub Actions, Bitrise, CircleCI. Setiap pipeline dapat menimpa parameter Build Config melalui variabel lingkungan sistem CI/CD.

Gradle Build Config di CI

Untuk Android, pipeline CI menjalankan Gradle dengan menentukan Build Variant: ./gradlew assembleFullRelease. Parameter penandatanganan diteruskan melalui variabel CI: STORE_PASSWORD, KEY_ALIAS. Gradle membacanya dari lingkungan eksekusi dan memasukkannya ke build.gradle.kts.

// build.gradle.kts — membaca dari variabel 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 di CI

Untuk iOS, CI menggunakan xcodebuild dengan flag konfigurasi: -configuration Release. Sertifikat penandatanganan dikirim melalui secrets CI, dan profil — melalui Apple Developer Portal API atau Fastlane match.

Alat Fastlane mengotomatiskan pengelolaan Build Config: menghasilkan xcconfig, memperbarui versi di Info.plist, menandatangani file IPA yang dibangun, dan mengunggahnya ke App Store Connect. Fastlane gym (build) dan match (penandatanganan) — standar pipeline CI iOS.

Menurut Bitrise Build Report (2025), proyek dengan Build Config yang dikonfigurasi di CI mengurangi waktu konfigurasi build manual sebesar 73% dan mengurangi jumlah kesalahan penandatanganan sebesar 89%. Build Config otomatis — elemen wajib pipeline production-ready.

Aspek penting lainnya — parametrisasi versioning melalui Build Config. Gradle memungkinkan membaca versionCode dan versionName dari variabel CI dan memasukkannya ke build.gradle.kts secara dinamis, yang menghilangkan ketidakselarasan versi antar pengembang. Di iOS, tugas serupa diselesaikan melalui agvtool (Apple Generic Versioning Tool), yang dapat menambah nomor build berdasarkan tag git atau nomor build di CI.