ایپ ڈویلپمنٹ میں Active Compilation Conditions: کلیدی تصورات اور اطلاق

Active Compilation Conditions کیا ہیں

Active Compilation Conditions کمپائلیشن جھنڈے ہیں جو تعمیر کے وقت فعال پری پروسیسر ہدایات کے سیٹ کا تعین کرتے ہیں۔ رن ٹائم جھنڈوں (if (isDebug) چیک) کے برعکس، کمپائلیشن شرائط غیر فعال کوڈ کو بائنری فائل سے جسمانی طور پر خارج کر دیتی ہیں، جس سے کارکردگی میں بہتری اور ایپلیکیشن کے سائز میں کمی آتی ہے۔

یہ طریقہ کار پری پروسیسر یا ابتدائی کمپائلیشن مراحل کی سطح پر کام کرتا ہے: کمپائلر فعال ناموں کی فہرست وصول کرتا ہے، اور جب اسے #if NAME ہدایت ملتی ہے، تو چیک کرتا ہے کہ NAME اس فہرست میں ہے یا نہیں۔ اگر نام موجود نہیں ہے، تو بلاک کے اندر کا کوڈ نظر انداز کر دیا جاتا ہے اور کمپائل نہیں ہوتا۔

Swift.org Blog (2025) کے مطابق، رن ٹائم جھنڈوں کے بجائے Active Compilation Conditions استعمال کرنے سے وسیع لاگنگ اور ڈیبگنگ ٹولز والے پروجیکٹس کے لیے ریلیز بائنری کا سائز اوسطاً 12-18% کم ہو جاتا ہے۔ یہ خاص طور پر انسٹالیشن فائل کے سائز کی حدود والی موبائل ایپلیکیشنز کے لیے اہم ہے۔

C/C++ پری پروسیسر سطح پر مشروط کمپائلیشن سے بنیادی فرق یہ ہے کہ Swift اور Kotlin میں Active Compilation Conditions ٹیکسٹ ریپلیسمنٹ کی سطح پر نہیں بلکہ کمپائلر کے AST (Abstract Syntax Tree) کی سطح پر کام کرتی ہیں۔ یہ انہیں زیادہ محفوظ اور قابل پیش گوئی بناتا ہے: غیر فعال #if شاخ میں کوئی بھی نحوی غلطی پارسنگ مرحلے کے دوران پکڑی جائے گی، رن ٹائم میں ظاہر نہیں ہوگی۔

ایک اور اہم فرق یہ ہے کہ Swift میں، شرط #if os(iOS) || os(macOS) کمپائل وقت پر چیک کی جاتی ہے اور پری پروسیسر میکروز کے بجائے پلیٹ فارم کے ناموں کے ساتھ کام کرتی ہے۔ یہ #define کے ذریعے غلط ٹیکسٹ داخل کرنے سے متعلق بگز کی ایک پوری کلاس کو ختم کرتا ہے، جو C/C++ پری پروسیسر میں ممکن ہیں۔ Swift کمپائلر تبدیل شدہ ٹیکسٹ کے بجائے AST دیکھتا ہے، جس سے مشروط کمپائلیشن کی ڈیبگنگ نمایاں طور پر آسان ہو جاتی ہے۔

Swift میں Active Compilation Conditions

Swift #if ہدایت کے ذریعے Active Compilation Conditions کو سپورٹ کرتا ہے، جو منطقی آپریٹرز &&، || اور ! کے ساتھ ملے ہوئے جھنڈوں کے ناموں کی فہرست قبول کرتا ہے۔ کمپائلر #if ... #endif کے اندر کوڈ کو صرف اس وقت شامل کرتا ہے جب شرط درست ہو۔

Swift میں بلٹ ان شرائط

Swift کئی بلٹ ان شرائط فراہم کرتا ہے: DEBUG (ڈیبگ بلڈ میں خود بخود فعال)، swift(>=5.0) (کمپائلر ورژن چیک)، canImport(UIKit) (ماڈیول کی دستیابی چیک) اور targetEnvironment(simulator) (ماحول چیک)۔ ان شرائط کے لیے اضافی ترتیب کی ضرورت نہیں ہے۔

// Swift میں بلٹ ان شرائط
#if DEBUG
    print("ڈیبگ بلڈ — لاگنگ فعال")
#endif

#if canImport(UIKit)
    import UIKit
    let screen = UIScreen.main.bounds
#elseif canImport(AppKit)
    import AppKit
    let screen = NSScreen.main?.frame
#endif

Xcode میں حسب ضرورت جھنڈے

ڈویلپر Xcode میں Build Setting OTHER_SWIFT_FLAGS کے ذریعے اپنے جھنڈے شامل کر سکتے ہیں۔ جھنڈا -D سابقہ کے ساتھ متعین کیا جاتا ہے، مثال کے طور پر -DBETA یا -DANALYTICS_ENABLED۔ مختلف کنفیگریشنز (Debug، Release، Staging) کے لیے جھنڈوں کے مختلف سیٹ سیٹ کیے جا سکتے ہیں۔

// کسٹم BETA جھنڈے کی ہینڈلنگ
#if BETA
    let apiEndpoint = "https://beta.api.com"
    let isLoggingEnabled = true
#else
    let apiEndpoint = "https://api.com"
    let isLoggingEnabled = false
#endif

func trackEvent(_ name: String) {
    #if ANALYTICS_ENABLED
        Analytics.log(name)
    #endif
}

پلیٹ فارم کی شرائط #if os()

Swift پلیٹ فارم کی شرائط کو سپورٹ کرتا ہے: os(iOS)، os(macOS)، os(tvOS)، os(watchOS)، os(Linux)، os(Windows)۔ یہ شرائط ہدف تعمیراتی پلیٹ فارم کی جانچ کرتی ہیں اور پلیٹ فارم کے مخصوص بلاکس کے ساتھ متعدد Apple پلیٹ فارمز پر مشترکہ کوڈ لکھنے کی اجازت دیتی ہیں۔

import Foundation

func getDeviceName() -> String {
    #if os(iOS)
        return UIDevice.current.name
    #elseif os(macOS)
        return Host.current.name ?? "Unknown"
    #else
        return "Other platform"
    #endif
}

Android اور Kotlin میں متبادل

Android ایکو سسٹم میں، Active Compilation Conditions BuildConfig سسٹم، productFlavors اور build.gradle.kts میں جھنڈوں کے ذریعے نافذ کی جاتی ہیں۔ Kotlin کے پاس زبان کی سطح پر #if ہدایت کا براہ راست متبادل نہیں ہے لیکن متبادل میکانزم فراہم کرتا ہے۔

BuildConfig فیلڈز بطور جھنڈے

سب سے عام طریقہ ہر جھنڈے کے لیے buildConfigField شامل کرنا ہے: buildConfigField("boolean", "BETA", "true")۔ یہ فیلڈز ہر Build Variant کے لیے علیحدہ طور پر BuildConfig کلاس میں تیار ہوتے ہیں۔ DEBUG فیلڈ پہلے سے بلٹ ان ہے اور ڈیبگ بلڈز کے لیے خود بخود درست ہے۔

// build.gradle.kts
android {
    buildTypes {
        debug {
            buildConfigField("boolean", "BETA", "true")
        }
        release {
            buildConfigField("boolean", "BETA", "false")
        }
    }
}

// Kotlin کوڈ میں استعمال
if (BuildConfig.BETA) {
    enableBetaFeatures()
}

Source Sets اور productFlavors

Gradle ہر ذائقے کے لیے علیحدہ sourceSets ڈائریکٹریز بنانے کی اجازت دیتا ہے۔ مثال کے طور پر، src/demo/ اور src/full/۔ مختلف sourceSets میں ایک ہی نام والی کلاسیں متعلقہ ذائقے کی تعمیر کے وقت ایک دوسرے کی جگہ لے لیتی ہیں۔ یہ جھنڈوں سے زیادہ طاقتور میکانزم ہے کیونکہ پوری کلاسز کو اوور رائیڈ کیا جا سکتا ہے۔

// src/demo/java/com/example/Config.kt
object Config {
    const val API_URL = "http://demo.api.com"
    const val IS_BETA = true
}

// src/full/java/com/example/Config.kt
object Config {
    const val API_URL = "https://full.api.com"
    const val IS_BETA = false
}

Kotlin Multiplatform (KMP) کے لیے، expect/actual ہدایت دستیاب ہے، جو مشترکہ کوڈ میں متوقع اعلانات کرنے اور پلیٹ فارم کے مخصوص نفاذ فراہم کرنے کی اجازت دیتی ہے۔ یہ اثر میں Active Compilation Conditions کی طرح ایک کمپائلر سطح کا میکانزم ہے — غیر مناسب پلیٹ فارمز کے لیے غیر فعال کوڈ کمپائل نہیں ہوتا۔

استعمال کے معاملات اور بہترین طریقے

Active Compilation Conditions چار اہم منظرناموں میں استعمال ہوتی ہیں: ڈیبگنگ (لاگز، انسپکٹر)، A/B ٹیسٹنگ (فیچر جھنڈے)، پلیٹ فارم موافقت (iOS/macOS مشترکہ کوڈ) اور لائسنسنگ (مفت/ادا شدہ ورژن)۔

ڈیبگ لاگنگ

سب سے عام منظر نامہ مشروط لاگنگ ہے۔ ڈیبگ بلڈ میں، تمام لاگز کنسول پر لکھے جاتے ہیں؛ ریلیز بلڈ میں، کچھ بھی لاگ نہیں ہوتا۔ #if DEBUG یا BuildConfig.DEBUG کا استعمال اس بات کو یقینی بناتا ہے کہ ریلیز بائنری میں ایک بھی لوگر کال موجود نہیں ہے، حتیٰ کہ ان لائن کی گئی بھی نہیں۔

func logRequest(_ url: URL, _ statusCode: Int) {
    #if DEBUG
        Logger.debug("Request to \(url.absoluteString) returned \(statusCode)")
    #endif
}

تعمیر کے وقت فیچر جھنڈے

اگر کوئی نئی فیچر ابھی پروڈکشن کے لیے تیار نہیں ہے لیکن کوڈ میں پہلے سے موجود ہے، تو اسے کمپائلیشن جھنڈے کے پیچھے چھپایا جا سکتا ہے۔ رن ٹائم فیچر جھنڈوں کے برعکس، کمپائلیشن جھنڈے ایپلیکیشن پر چیک کا بوجھ نہیں ڈالتے اور صارف کے ذریعے فعال نہیں کیے جا سکتے۔

• نئی فیچرز — کوڈ کو حذف کیے بغیر اگلی ریلیز تک نامکمل فعالیت چھپائیں
• تجزیہ — صرف بیٹا ٹیسٹرز کے لیے اضافی میٹرکس جمع کرنا فعال کریں
• تیسرے فریق کے SDK — ایپلیکیشن کے مفت ورژن سے بھاری لائبریریاں خارج کریں
• UI اجزاء — صرف اسٹیجنگ بلڈز میں تجرباتی اسکرینیں دکھائیں

بہترین طریقے

Active Compilation Conditions کو معتدل استعمال کیا جانا چاہیے۔ جھنڈوں کی ضرورت سے زیادہ تعداد کوڈ کو سمجھنا مشکل بنا دیتی ہے: ڈویلپر اس بات کا یقین نہیں کر سکتا کہ کسی لمحے کون سی شاخیں کمپائل ہوں گی۔ سفارش کی جاتی ہے کہ ہر جھنڈے کو README یا ایک مخصوص CONFIG.md فائل میں دستاویز کیا جائے۔

تقسیم شدہ ٹیموں والے بڑے پروجیکٹس میں، CI میں خودکار جھنڈے کی توثیق کو نافذ کرنا مفید ہے۔ ہر پل ریکویسٹ کو Active Compilation Conditions کے تمام ممکنہ امتزاج کے ساتھ بلڈ پاس کرنا چاہیے۔ یہ اس بات کو یقینی بناتا ہے کہ غیر فعال جھنڈے کے نیچے کا کوڈ ری فیکٹرنگ کی وجہ سے نہیں ٹوٹا ہے، اور ریلیز تک کوئی مشروط کمپائلیشن شاخ بغیر جانچے نہیں رہی ہے۔ xcresulttool (iOS کے لیے) اور Gradle Build Scan (Android کے لیے) جیسے اوزار اس عمل کو خودکار بنانے میں مدد کرتے ہیں۔

• کم سے کم جھنڈے — فی پروجیکٹ 5-7 سے زیادہ فعال شرائط نہیں۔ ہر جھنڈا پیچیدگی کا ایک نقطہ ہے۔
• نام رکھنے کا اصول — تمام جھنڈے بڑے حروف میں، پروجیکٹ کے سابقہ کے ساتھ: MYAPP_BETA، MYAPP_ANALYTICS۔
• کوڈ کا جائزہ — #if یا buildConfigField کا ہر اضافہ علیحدہ جائزے سے گزرنا چاہیے۔
• ٹیسٹنگ — CI کو دن میں کم از کم ایک بار جھنڈوں کے تمام ممکنہ امتزاج بنانے چاہئیں۔