موبائل ایپس میں Build Config — یہ کیا ہے، سیٹ اپ اور کام کرنے کا اصول

موبائل ڈویلپمنٹ میں Build Config کیا ہے

Build Config ترتیبات کا ایک مجموعہ ہے جو موبائل ایپلیکیشن کے کمپائلیشن، بلڈ اور پیکیجنگ کے عمل کو طے کرتا ہے۔ بلڈ کنفیگریشن میں ہدف پلیٹ فارم کا انتخاب، کم از کم SDK ورژن، اصلاحی فلیگز، دستخطی کنجیاں اور ماحولیاتی متغیرات شامل ہیں۔

جدید موبائل پروجیکٹس میں شاذونادر ہی ایک ہی بلڈ کنفیگریشن ہوتی ہے۔ عام طور پر ان کے پاس متعدد ہوتی ہیں: debug (ڈیبگنگ کے ساتھ ڈویلپمنٹ کے لیے)، release (اصلاح کے ساتھ پروڈکشن کے لیے)، staging (حقیقی ڈیٹا کے ساتھ جانچ کے لیے) اور مختلف فلیورز (ڈیمو، مکمل، انٹرپرائز ورژن)۔

Gradle Build Tool Survey (2025) کے مطابق، اوسط Android پروجیکٹ 3.2 مختلف بلڈ کنفیگریشنز استعمال کرتا ہے، جبکہ iOS پروجیکٹ 2.8 استعمال کرتا ہے۔ ہر کنفیگریشن کے اپنے کمپائلیشن فلیگز، دستخطی سرٹیفکیٹس اور سرور URLs ہو سکتے ہیں۔

Build Config کا بنیادی کام ان کنفیگریشنز کے درمیان سوئچنگ کو خودکار بنانا ہے۔ سرور URL یا ڈیبگ فلیگ کو دستی طور پر تبدیل کرنے کے بجائے، ڈویلپر IDE میں مطلوبہ Build Variant منتخب کرتا ہے اور بلڈ سسٹم متعلقہ پیرامیٹرز کو خودکار طور پر لاگو کرتا ہے۔

Build Config کی مناسب ترتیب ایپلیکیشن کی سلامتی کو شدید متاثر کرتی ہے: debug بلڈز میں تفصیلی لاگز، ڈیٹابیس انسپکٹر اور ڈیبگنگ اینڈپوائنٹس شامل ہوتے ہیں جنہیں release بائنری سے جسمانی طور پر خارج کیا جانا چاہیے۔ Gradle اسے Build Types کے ذریعے حل کرتا ہے: debug میں debuggable true فلیگ ہو سکتا ہے، release میں — ProGuard کے ساتھ minifyEnabled true۔ iOS Swift Active Compilation Conditions کے ذریعے ایک ہی مقصد حاصل کرتا ہے، جہاں #if DEBUG کے اندر کا کوڈ release کنفیگریشن میں کمپائل نہیں ہوتا۔

Android میں Build Config: Gradle اور BuildConfig

Android دو کلیدی تصورات کے ساتھ Gradle بلڈ سسٹم استعمال کرتا ہے: Build Types اور Product Flavors۔ ان کا امتزاج Build Variants بناتا ہے — ہر ویرینٹ کی اپنی مکمل بلڈ کنفیگریشن ہوتی ہے۔

Build Types: ڈیبگ اور ریلیز

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 کے لیے، Gradl کنفیگریشن فیلڈز کے ساتھ ایک 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 فیلڈ شامل کر سکتے ہیں اور رن ٹائم چیکس اور کوڈ میں مشروط آپریٹرز کے بغیر صرف ایپلیکیشن کے مکمل ورژن میں چیٹ کو فعال کر سکتے ہیں۔

نیٹ ورک کی درخواستوں کو ڈیبگ کرنے کے لیے، DEBUG فیلڈ کے ساتھ BuildConfig صرف debug بلڈز کے لیے OkHttp میں HttpLoggingInterceptor کو خودکار طور پر منسلک کرنے کی اجازت دیتا ہے۔ یہ ضمانت دیتا ہے کہ پروڈکشن میں کوئی HTTP درخواست لاگ نہیں ہوگی، چاہے ڈویلپر غلطی سے ریلیز بلڈ سے پہلے لاگنگ ہٹانا بھول جائے۔

iOS میں Build Config: 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 فارمیٹ میں پیرامیٹرز والی ٹیکسٹ فائلیں۔ یہ Xcode کے لیے .env کے مشابہ ہیں: قدریں پروجیکٹ سے منسلک ہوتی ہیں اور 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 کی قدروں کو $(VARIABLE_NAME) نحو کے ذریعے Info.plist میں تبدیل کیا جا سکتا ہے۔ مثال کے طور پر، Info.plist میں $(API_BASE_URL) فعال بلڈ کنفیگریشن کے مطابق پھیلے گا۔ یہ تمام Apple پلیٹ فارمز کے لیے ماحولیاتی پیرامیٹرز کے نظم کو مرکزیت دیتا ہے۔

CI/CD پائپ لائنز میں Build Config

جدید پروجیکٹس میں، Build Config مسلسل انضمام کے نظاموں کے ساتھ ضم ہوتا ہے: GitLab CI, GitHub Actions, Bitrise, CircleCI۔ ہر پائپ لائن CI/CD نظام کے ماحولیاتی متغیرات کے ذریعے Build Config پیرامیٹرز کو اووررائڈ کر سکتی ہے۔

CI میں Gradle Build Config

Android کے لیے، CI پائپ لائن مخصوص Build Variant کے ساتھ Gradle چلاتی ہے: ./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") ?: ""
        }
    }
}

CI میں Xcode Build Config

iOS کے لیے، CI کنفیگریشن فلیگز کے ساتھ xcodebuild استعمال کرتا ہے: -configuration Release۔ دستخطی سرٹیفکیٹس CI رازوں کے ذریعے اور پروفائلز 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) کے مطابق، CI میں Build Config سیٹ اپ والے پروجیکٹس دستی بلڈ کنفیگریشن کا وقت 73% کم کرتے ہیں اور دستخطی غلطیوں کو 89% تک کم کرتے ہیں۔ خودکار Build Config پروڈکشن کے لیے تیار پائپ لائن کا لازمی عنصر ہے۔

ایک اور اہم پہلو Build Config کے ذریعے ورژننگ پیرامیٹرائزیشن ہے۔ Gradle CI متغیرات سے versionCode اور versionName پڑھنے اور انہیں build.gradle.kts میں متحرک طور پر تبدیل کرنے کی اجازت دیتا ہے، جس سے ڈویلپرز کے درمیان ورژن کی غیر ہم آہنگی ختم ہو جاتی ہے۔ iOS میں، agvtool (Apple Generic Versioning Tool) کے ذریعے اسی طرح کا کام حل کیا جاتا ہے، جو git ٹیگز یا CI میں بلڈ نمبر کی بنیاد پر بلڈ نمبر بڑھا سکتا ہے۔