.xcconfig — यह क्या है, सिंटैक्स और Xcode में वेरिएबल्स

.xcconfig क्या है?

.xcconfig (Xcode कॉन्फ़िगरेशन फ़ाइल) एक सादा टेक्स्ट फ़ाइल है जिसमें PARAMETER_NAME = value प्रारूप में Build Settings होते हैं। .xcconfig फ़ाइलों का उपयोग Xcode बिल्ड कॉन्फ़िगरेशन के केंद्रीकृत प्रबंधन के लिए किया जाता है: वे Build Settings UI में फ़ील्ड्स के मैनुअल एडिटिंग को बदल देती हैं। प्रत्येक .xcconfig एक Build Configuration (Debug, Release) या पूरे प्रोजेक्ट से जुड़ा होता है और किसी भी build setting को ओवरराइड कर सकता है: SWIFT_VERSION, IPHONEOS_DEPLOYMENT_TARGET, PRODUCT_BUNDLE_IDENTIFIER, CODE_SIGN_STYLE, PROVISIONING_PROFILE_SPECIFIER।

.xcconfig के आने से पहले, बिल्ड सेटिंग्स केवल project.pbxproj में संग्रहीत होती थीं — एक बाइनरी/plist फ़ाइल जिसे diff में पढ़ना मुश्किल है और जिस पर टिप्पणी करना असंभव है। .xcconfig ने इस समस्या को हल किया: डेवलपर्स पैरामीटर पर टिप्पणी कर सकते हैं, उन्हें अर्थ के अनुसार समूहित कर सकते हैं, विभिन्न वातावरणों के लिए वर्शनेबल फ़ाइलें बना सकते हैं, और फ़ाइलों के बीच पैरामीटर इनहेरिट कर सकते हैं। इसने .xcconfig को iOS प्रोजेक्ट्स में कॉन्फ़िगरेशन प्रबंधन के लिए वास्तविक मानक बना दिया।

.xcconfig फ़ाइलें प्रोजेक्ट के अंदर स्थित होती हैं, आमतौर पर Configurations/ या BuildConfig/ फ़ोल्डर में। प्रत्येक फ़ाइल एक Build Configuration से मेल खाती है: Debug.xcconfig, Release.xcconfig, Staging.xcconfig। इसके अतिरिक्त, एक सामान्य Shared.xcconfig फ़ाइल बनाई जाती है, जो #include के माध्यम से सभी कॉन्फ़िगरेशन में शामिल होती है। यह सामान्य पैरामीटर को एक बार परिभाषित करने और कॉन्फ़िगरेशन फ़ाइलों में विशिष्ट पैरामीटर को ओवरराइड करने की अनुमति देता है।

UI Build Settings पर लाभ

Diff पठनीयता: .xcconfig में परिवर्तन Git diff में सामान्य पंक्तियों के रूप में दिखाई देते हैं। project.pbxproj के विपरीत, जहाँ फ़ील्ड क्रम बदलने पर एक पैरामीटर संपादित करने पर diff 50 पंक्तियाँ दिखाता है। टिप्पणियाँ: .xcconfig में आप बता सकते हैं कि प्रत्येक पैरामीटर की आवश्यकता क्यों है। इनहेरिटेंस: आप सामान्य सेटिंग्स के साथ एक बेस कॉन्फ़िगरेशन बना सकते हैं और केवल Debug और Release के लिए आवश्यक पैरामीटर ओवरराइड कर सकते हैं।

.xcconfig का सिंटैक्स और संरचना

वेरिएबल्स और प्रतिस्थापन

.xcconfig का सिंटैक्स जितना संभव हो उतना सरल है: प्रत्येक पंक्ति एक पैरामीटर है, नाम और मान बराबर के चिह्न से अलग किए गए हैं। = के आसपास के स्थानों को अनदेखा किया जाता है। मान $(VARIABLE_NAME) या ${VARIABLE_NAME} प्रारूप में वेरिएबल्स शामिल कर सकते हैं। टिप्पणियाँ // या # से शुरू होती हैं और पंक्ति के अंत तक लागू होती हैं। पंक्तियाँ बैकस्लैश \ का उपयोग करके अगली पंक्ति पर जारी रहती हैं। खाली पंक्तियों को अनदेखा किया जाता है।

.xcconfig में वेरिएबल्स अन्य वेरिएबल्स को संदर्भित कर सकते हैं, जिससे समग्र मान बनते हैं। उदाहरण के लिए: PRODUCT_NAME = MyApp, PRODUCT_BUNDLE_IDENTIFIER = com.example.$(PRODUCT_NAME)। Xcode बिल्ड समय पर मान का मूल्यांकन करता है, वेरिएबल्स के वास्तविक मानों को प्रतिस्थापित करता है। AGP सिस्टम वेरिएबल्स का भी समर्थन करता है: ARCHS, SDK_NAME, CONFIGURATION, PLATFORM_NAME, जो बिल्ड वातावरण द्वारा सेट किए जाते हैं।

सशर्त कॉन्फ़िगरेशन के लिए, वर्गाकार कोष्ठक में प्लेटफ़ॉर्म निर्देशों का उपयोग किया जाता है: PARAMETER[sdk=iphoneos*] = value। उदाहरण के लिए, SUPPORTED_PLATFORMS[sdk=iphoneos*] = iphoneos केवल iOS बिल्ड के लिए पैरामीटर सेट करता है। वाइल्डकार्ड समर्थित हैं: * (कोई भी वर्ण), ? (एक वर्ण)। सशर्त निर्देश कई प्लेटफ़ॉर्म के लिए एक .xcconfig रखने और एक फ़ाइल में iOS और macOS के लिए अलग-अलग मान सेट करने की अनुमति देते हैं।

// Shared.xcconfig — सामान्य प्रोजेक्ट सेटिंग्स
SWIFT_VERSION = 5.0
IPHONEOS_DEPLOYMENT_TARGET = 16.0
SDKROOT = iphoneos
TARGETED_DEVICE_FAMILY = 1,2

// बंडल आइडेंटिफ़ायर — प्रीफ़िक्स और नाम से बनता है
BUNDLE_ID_PREFIX = com.example
PRODUCT_NAME = MyApp
PRODUCT_BUNDLE_IDENTIFIER = $(BUNDLE_ID_PREFIX).$(PRODUCT_NAME)

// macOS के लिए सशर्त सेटिंग
SUPPORTED_PLATFORMS[sdk=macosx*] = macosx
PRODUCT_BUNDLE_IDENTIFIER[sdk=macosx*] = $(BUNDLE_ID_PREFIX).$(PRODUCT_NAME).mac

// वर्शनिंग
MARKETING_VERSION = 2.4.1
CURRENT_PROJECT_VERSION = 37

#include के माध्यम से कॉन्फ़िगरेशन इनहेरिटेंस

#include एक .xcconfig प्रीप्रोसेसर निर्देश है जो किसी अन्य .xcconfig फ़ाइल की सामग्री को शामिल करता है। निर्देशों को नेस्ट किया जा सकता है: Shared.xcconfig "Base.xcconfig" को #include कर सकता है, Debug.xcconfig "Shared.xcconfig" को #include कर सकता है। इनहेरिटेंस श्रृंखला कॉन्फ़िगरेशन का एक पदानुक्रम बनाने की अनुमति देती है, जहाँ प्रत्येक स्तर पिछले स्तर के पैरामीटर को ओवरराइड करता है। #include अंतिम लेखन के सिद्धांत पर काम करता है: यदि एक ही पैरामीटर शामिल और मुख्य फ़ाइल दोनों में परिभाषित है, तो मुख्य फ़ाइल से मान को प्राथमिकता दी जाती है।

एक सामान्य iOS प्रोजेक्ट के लिए सही पदानुक्रम: Base.xcconfig (सबसे सामान्य पैरामीटर) → Shared.xcconfig (प्रोजेक्ट सेटिंग्स) → Debug.xcconfig या Release.xcconfig। Base.xcconfig मानकों को परिभाषित करता है (SWIFT_VERSION, DEPLOYMENT_TARGET), Shared.xcconfig — प्रोजेक्ट विशिष्टताएँ (PRODUCT_NAME, PREPROCESSOR_DEFINITIONS), Debug/Release — वातावरण (DEBUG_INFORMATION_FORMAT, OPTIMIZATION_CFLAGS)। #include चक्रों की अनुमति नहीं देता — Xcode चक्रीय निर्भरता का पता चलने पर त्रुटि देगा।

उदाहरण: Config/Base.xcconfig → Config/iOS/Shared.xcconfig → Config/iOS/Debug.xcconfig। यह संरचना Base को iOS, macOS और tvOS प्रोजेक्ट्स के लिए और Shared को केवल iOS के लिए पुनः उपयोग करने की अनुमति देती है। ध्यान दें: #include रूट .xcconfig के स्थान से फ़ाइल नाम या सापेक्ष पथ का उपयोग करता है। निरपेक्ष पथ अनुशंसित नहीं हैं — वे अन्य मशीनों और CI/CD में बिल्ड को तोड़ देते हैं।

// --- Config/Base.xcconfig ---
SWIFT_VERSION = 5.0
ENABLE_MODULE_VERIFIER = YES
CLANG_ENABLE_MODULES = YES

// --- Config/iOS/Shared.xcconfig ---
#include "../Base.xcconfig"
IPHONEOS_DEPLOYMENT_TARGET = 16.0
PRODUCT_BUNDLE_IDENTIFIER = com.example.myapp

// --- Config/iOS/Debug.xcconfig ---
#include "Shared.xcconfig"
OPTIMIZATION_CFLAGS = -O0
DEBUG_INFORMATION_FORMAT = dwarf
SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG
ENABLE_TESTABILITY = YES

// --- Config/iOS/Release.xcconfig ---
#include "Shared.xcconfig"
OPTIMIZATION_CFLAGS = -Osize
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym
SWIFT_COMPILATION_MODE = wholemodule

Xcode प्रोजेक्ट में .xcconfig जोड़ना

प्रोजेक्ट-स्तर और टार्गेट-स्तर कॉन्फ़िगरेशन

.xcconfig को प्रोजेक्ट से जोड़ना Project Info → Configurations में किया जाता है। प्रत्येक Build Configuration (Debug, Release, AdHoc) के लिए, "Based on Configuration File" ड्रॉपडाउन से संबंधित .xcconfig चुना जाता है। यदि कॉन्फ़िगरेशन किसी फ़ाइल से लिंक नहीं है, तो Xcode project.pbxproj से मानों का उपयोग करता है। .xcconfig चुनने के बाद, फ़ाइल के सभी पैरामीटर उस कॉन्फ़िगरेशन के लिए सक्रिय हो जाते हैं।

प्रोजेक्ट-स्तर और टार्गेट-स्तर कॉन्फ़िगरेशन के बीच अंतर करना महत्वपूर्ण है। प्रोजेक्ट-स्तर .xcconfig सभी टार्गेट्स के लिए डिफ़ॉल्ट पैरामीटर सेट करता है। टार्गेट-स्तर .xcconfig उन्हें एक विशिष्ट टार्गेट के लिए ओवरराइड करता है। यदि कोई पैरामीटर टार्गेट-स्तर .xcconfig में सेट नहीं है, तो प्रोजेक्ट-स्तर से मान का उपयोग किया जाता है। यदि वहाँ भी सेट नहीं है, तो project.pbxproj से मान का उपयोग किया जाता है। व्यावहारिक नियम: सामान्य पैरामीटर (बिल्ड, वर्शन) प्रोजेक्ट-स्तर में रखें, और टार्गेट विशिष्टताएँ (बंडल आइडेंटिफ़ायर, प्रोविज़निंग) टार्गेट-स्तर में रखें।

.xcconfig और UI Build Settings के बीच विरोध की स्थिति में, UI से मान को प्राथमिकता दी जाती है (यह .xcconfig को ओवरराइड करता है)। इससे भ्रम हो सकता है: एक डेवलपर UI में Build Setting बदलता है, यह नहीं जानते हुए कि .xcconfig एक अलग मान निर्दिष्ट करता है। यह अनुशंसा की जाती है कि पूरी तरह से .xcconfig पर स्विच करें और UI Build Settings को न छुएँ। यह जाँचने के लिए कि कौन सा पैरामीटर लागू हो रहा है, xcrun xcodebuild -showBuildSettings का उपयोग करें — यह कमांड सभी स्तरों को हल करने के बाद सभी पैरामीटर के अंतिम मान दिखाएगा।

उदाहरण: Dev, Staging, Production वातावरण

तीन-स्तरीय कॉन्फ़िगरेशन पर विचार करें: Dev (स्थानीय विकास), Staging (परीक्षण सर्वर), Production (रिलीज़)। प्रत्येक वातावरण के लिए एक अलग .xcconfig बनाया जाता है, जो अलग-अलग API_URL, लॉगिंग और प्रमाणपत्र मानों को परिभाषित करता है। Dev localhost का उपयोग करता है, Staging staging.api.example.com का, Production api.example.com का। तीनों #include के माध्यम से सामान्य Shared.xcconfig को इनहेरिट करते हैं।

वातावरण के बीच अंतर करने वाला प्रमुख पैरामीटर PRODUCT_BUNDLE_IDENTIFIER है। Dev के लिए: com.example.myapp.dev, Staging के लिए: com.example.myapp.staging, Production के लिए: com.example.myapp। अलग-अलग बंडल ID एक ही डिवाइस पर एक साथ तीनों वर्शन इंस्टॉल करने की अनुमति देते हैं। CODE_SIGN_IDENTITY (Dev के लिए Apple Development, Production के लिए Apple Distribution) और PROVISIONING_PROFILE_SPECIFIER भी अलग-अलग होते हैं।

कोड में मान पास करने के लिए, INFOPLIST_PREFIX_HEADER या -D प्रीप्रोसेसर के साथ OTHER_SWIFT_FLAGS का उपयोग किया जाता है। Swift में प्रीप्रोसेसर नहीं है, इसलिए Active Compilation Conditions का उपयोग किया जाता है: SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEV। कोड में: #if DEV; #elseif STAGING; #else; #endif। Objective-C के लिए GCC_PREPROCESSOR_DEFINITIONS का उपयोग किया जाता है। यह स्रोत फ़ाइलों को बदले बिना विभिन्न वातावरणों के लिए अलग-अलग कोड संकलित करने की अनुमति देता है।

// --- Config/Dev.xcconfig ---
#include "Shared.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(BUNDLE_ID_PREFIX).$(PRODUCT_NAME).dev
CODE_SIGN_IDENTITY = Apple Development
PROVISIONING_PROFILE_SPECIFIER = Dev Profile

SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG DEV
OTHER_SWIFT_FLAGS = -D DEV

// Info.plist के माध्यम से API URL — मान प्रतिस्थापित होता है
API_BASE_URL = http://localhost:3000/api

// --- Config/Staging.xcconfig ---
#include "Shared.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(BUNDLE_ID_PREFIX).$(PRODUCT_NAME).staging
CODE_SIGN_IDENTITY = Apple Development
PROVISIONING_PROFILE_SPECIFIER = Staging Profile

SWIFT_ACTIVE_COMPILATION_CONDITIONS = STAGING
OTHER_SWIFT_FLAGS = -D STAGING
API_BASE_URL = https://staging.api.example.com/v2

// --- Config/Production.xcconfig ---
#include "Shared.xcconfig"

PRODUCT_BUNDLE_IDENTIFIER = $(BUNDLE_ID_PREFIX).$(PRODUCT_NAME)
CODE_SIGN_IDENTITY = Apple Distribution
PROVISIONING_PROFILE_SPECIFIER = AppStore Distribution

SWIFT_ACTIVE_COMPILATION_CONDITIONS = RELEASE
API_BASE_URL = https://api.example.com/v3

.xcconfig और Info.plist: मान पास करना

.xcconfig से मानों को Info.plist में वेरिएबल्स $(PARAMETER_NAME) के माध्यम से पास किया जा सकता है। यदि कोई पैरामीटर .xcconfig में परिभाषित है (उदाहरण के लिए, API_BASE_URL), तो इसका उपयोग Info.plist में किया जा सकता है: <key>ApiBaseUrl</key><string>$(API_BASE_URL)</string>। बिल्ड समय पर, Xcode $(API_BASE_URL) को .xcconfig के मान से बदल देता है। यह कोड बदले बिना एप्लिकेशन को कॉन्फ़िगर करने की अनुमति देता है — बस स्कीम स्विच करें।

Info.plist में उपयोग किए जाने वाले .xcconfig पैरामीटर सार्वजनिक होने चाहिए — वे बाइनरी में समाप्त होते हैं और डीकंपाइल किए गए एप्लिकेशन में दिखाई देते हैं। गुप्त मानों (टोकन, पासवर्ड) के लिए .xcconfig का उपयोग न करें — सर्वर पर चलने वाली Firebase Remote Config जैसी सेवाओं का उपयोग करें। Info.plist के लिए .xcconfig इसके लिए उपयुक्त है: सर्वर URL, एंटिटी नाम, ट्रैकर आइडेंटिफ़ायर, feature flags।

कोड में Info.plist मानों तक पहुँच: Objective-C/Swift के लिए Bundle.main.object(forInfoDictionaryKey: "ApiBaseUrl")। यदि मान .xcconfig के माध्यम से सेट किया गया है, तो इसे प्रतिस्थापित किया जाएगा और Bundle main.infoDictionary में उपलब्ध होगा। यह विधि BuildConfigField (जैसा कि Android में है) से बेहतर है, क्योंकि Info.plist एक मानक iOS तंत्र है, और इसके मान सिस्टम के सभी घटकों के लिए उपलब्ध हैं, जिनमें extensions, widgets और Siri Intents शामिल हैं।