ऐप डेवलपमेंट में 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 से अधिक सक्रिय शर्तें नहीं। प्रत्येक फ़्लैग जटिलता का एक बिंदु है।
• नामकरण परंपरा — सभी फ़्लैग UPPER_CASE में, प्रोजेक्ट उपसर्ग के साथ: MYAPP_BETA, MYAPP_ANALYTICS।
• कोड समीक्षा — #if या buildConfigField का प्रत्येक जोड़ अलग समीक्षा से गुजरना चाहिए।
• परीक्षण — CI को दिन में कम से कम एक बार फ़्लैग के सभी संभावित संयोजन बनाने चाहिए।