Mobil uygulamalarda Build Config — nedir, kurulumu ve çalışma prensibi

Mobil geliştirmede Build Config nedir

Build Config, bir mobil uygulamanın derleme, oluşturma ve paketleme sürecini tanımlayan ayarlar bütünüdür. Derleme yapılandırması, hedef platform seçimini, minimum SDK sürümünü, optimizasyon bayraklarını, imzalama anahtarlarını ve ortam değişkenlerini içerir.

Modern mobil projelerde nadiren tek bir derleme yapılandırması bulunur. Genellikle birden fazla yapılandırma vardır: debug (hata ayıklamalı geliştirme için), release (optimizasyonlu üretim için), staging (gerçek verilerle test için) ve çeşitli flavor'lar (demo, tam, kurumsal sürüm).

Gradle Build Tool Survey (2025)'e göre, ortalama bir Android projesi 3,2 farklı derleme yapılandırması kullanırken, bir iOS projesi 2,8 kullanır. Her yapılandırma kendi derleme bayraklarına, imzalama sertifikalarına ve sunucu URL'lerine sahip olabilir.

Build Config'in ana görevi, bu yapılandırmalar arasında geçişi otomatikleştirmektir. Geliştirici, sunucu URL'sini veya hata ayıklama bayrağını manuel olarak değiştirmek yerine, IDE'de istediği Build Variant'ı seçer ve derleme sistemi ilgili parametreleri otomatik olarak uygular.

Build Config'in doğru yapılandırılması, uygulama güvenliğini kritik şekilde etkiler: debug derlemeleri, release ikili dosyasından fiziksel olarak çıkarılması gereken ayrıntılı günlükler, veritabanı denetleyicisi ve hata ayıklama uç noktaları içerir. Gradle bunu Build Types aracılığıyla çözer: debug'da debuggable true bayrağı, release'de ise ProGuard ile minifyEnabled true bulunabilir. iOS, Swift Active Compilation Conditions aracılığıyla aynı sonuca ulaşır; burada #if DEBUG içindeki kod release yapılandırmasında derlenmez.

Android'de Build Config: Gradle ve BuildConfig

Android, iki temel kavramla Gradle derleme sistemini kullanır: Build Types ve Product Flavors. Bunların kombinasyonu Build Variants'ı oluşturur — her varyantın kendi tam derleme yapılandırması vardır.

Build Types: Debug ve Release

Build Type, uygulamanın nasıl oluşturulacağını tanımlayan bir yapılandırmadır. Varsayılan olarak Gradle iki tür oluşturur: debug (hata ayıklamalı, karartmasız) ve release (ProGuard/R8'li, yayın için imzalı). Geliştirici kendi türlerini ekleyebilir: 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: Uygulama sürümleri

Product Flavors, tek bir kod tabanından aynı uygulamanın farklı sürümlerini oluşturmaya olanak tanır. Örneğin: reklamlı ücretsiz sürüm, reklamsız ücretli sürüm ve ek özelliklere sahip kurumsal sürüm. Her flavor kendi applicationId'sine, kaynaklarına ve SDK bağımlılıklarına sahip olabilir.

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

BuildConfig Sınıfı: Koddan erişim

Her Build Variant için Gradle, yapılandırma alanlarına sahip bir BuildConfig sınıfı oluşturur. Geliştirici buildConfigField aracılığıyla özel alanlar eklerken, standart alanlar (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) otomatik olarak oluşturulur.

// Kodda BuildConfig Kullanımı
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig ayrıca derleme zamanında işlevselliği etkinleştirmeye veya devre dışı bırakmaya olanak tanır. Örneğin, bir FEATURE_CHAT_ENABLED alanı ekleyebilir ve çalışma zamanı kontrolleri ve kodda koşullu operatörler olmadan sohbeti yalnızca uygulamanın tam sürümünde etkinleştirebilirsiniz.

Ağ isteklerini hata ayıklamak için, DEBUG alanına sahip BuildConfig, HttpLoggingInterceptor'ı yalnızca debug derlemeleri için OkHttp'ye otomatik olarak eklemeye olanak tanır. Bu, geliştirici yanlışlıkla release derlemesinden önce günlük kaydını kaldırmayı unutsa bile, üretimde hiçbir HTTP isteğinin günlüğe kaydedilmemesini garanti eder.

iOS'te Build Config: Xcode ve Build Settings

iOS ekosisteminde Build Config, Xcode Build Settings aracılığıyla yönetilir — her parametrenin farklı yapılandırmalar (Debug, Release, Staging) için farklı değerlere sahip olabileceği bir parametre tablosu.

Xcode Build Configurations

Varsayılan olarak Xcode iki yapılandırma oluşturur: Debug (geliştirme için, optimizasyonsuz) ve Release (üretim için, -Os optimizasyonlu). Geliştirici Project > Info > Configurations menüsü aracılığıyla kendi yapılandırmalarını ekleyebilir.

Her yapılandırma için Build Settings yapılandırılır: derleyici bayrakları (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), kod imzalama (CODE_SIGN_IDENTITY), provisioning profilleri ve yetkilendirmeler. Xcode bu ayarları project.pbxproj dosyasına yazar.

xcconfig: Harici yapılandırma dosyaları

Build Settings'in kolay yönetimi için iOS geliştiricileri .xcconfig dosyalarını kullanır — KEY = VALUE formatında parametrelere sahip metin dosyaları. Bunlar Xcode için .env'nin benzeridir: değerler projeye bağlanır ve project.pbxproj'daki ayarları geçersiz kılar.

// 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: Çalışma zamanı yapılandırması

Build Config parametrelerinin bir kısmı Info.plist'e — iOS uygulama manifest dosyasına gider. Info.plist aracılığıyla URL şemaları, izinler (kamera, mikrofon), arka plan modları ve üçüncü taraf hizmet oturum açma yapılandırması ayarlanır.

xcconfig değerleri, $(VARIABLE_NAME) sözdizimi kullanılarak Info.plist'te değiştirilebilir. Örneğin, Info.plist'teki $(API_BASE_URL), etkin derleme yapılandırmasına göre genişletilir. Bu, tüm Apple platformları için ortam parametreleri yönetimini merkezileştirir.

CI/CD boru hatlarında Build Config

Modern projelerde Build Config, sürekli entegrasyon sistemleriyle entegre olur: GitLab CI, GitHub Actions, Bitrise, CircleCI. Her boru hattı, CI/CD sisteminin ortam değişkenleri aracılığıyla Build Config parametrelerini geçersiz kılabilir.

CI'da Gradle Build Config

Android için CI boru hattı, belirtilen Build Variant ile Gradle'ı çalıştırır: ./gradlew assembleFullRelease. İmzalama parametreleri CI değişkenleri aracılığıyla iletilir: STORE_PASSWORD, KEY_ALIAS. Gradle bunları çalışma zamanı ortamından okur ve build.gradle.kts'e ekler.

// build.gradle.kts — CI değişkenlerinden okuma
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") ?: ""
        }
    }
}

CI'da Xcode Build Config

iOS için CI, yapılandırma bayraklarıyla xcodebuild kullanır: -configuration Release. İmzalama sertifikaları CI sırları aracılığıyla, profiller ise Apple Developer Portal API veya Fastlane match aracılığıyla sağlanır.

Fastlane aracı, Build Config yönetimini otomatikleştirir: xcconfig oluşturur, Info.plist'te sürümleri günceller, oluşturulan IPA'ları imzalar ve App Store Connect'e yükler. Fastlane gym (derleme) ve match (imzalama), iOS CI boru hatlarının standardıdır.

Bitrise Build Report (2025)'e göre, CI'da Build Config yapılandırılmış projeler, manuel derleme yapılandırma süresini %73 azaltır ve imzalama hatalarını %89 oranında düşürür. Otomatikleştirilmiş Build Config, üretime hazır bir boru hattının zorunlu bir öğesidir.

Bir diğer önemli husus, Build Config aracılığıyla sürüm oluşturmanın parametrelendirilmesidir. Gradle, versionCode ve versionName'i CI değişkenlerinden okumaya ve build.gradle.kts'e dinamik olarak eklemeye olanak tanıyarak geliştiriciler arasında sürüm senkronizasyon bozukluğunu ortadan kaldırır. iOS'te benzer bir görev, git etiketlerine veya CI'daki derleme numarasına dayalı olarak derleme numarasını artırabilen agvtool (Apple Generic Versioning Tool) aracılığıyla çözülür.