Scheme: Xcode में यह क्या है, कॉन्फ़िगरेशन और रन करना

Xcode में Scheme क्या है?

Xcode में Scheme एक XML फ़ाइल (.xcscheme एक्सटेंशन वाली) है जो ऐप को बिल्ड करने और विश्लेषण करने के लिए क्रियाओं के क्रम और उनके पैरामीटर का वर्णन करती है। प्रत्येक Scheme एक या अधिक टारगेट से जुड़ा होता है और यह निर्धारित करता है कि प्रत्येक क्रिया को किस कॉन्फ़िगरेशन (Debug, Release, AdHoc) के साथ निष्पादित करना है। Scheme Android में Build Variant के समान है, लेकिन अधिक लचीली संरचना के साथ: एक स्कीम में विभिन्न क्रियाओं के लिए अलग-अलग टारगेट हो सकते हैं।

Xcode प्रोजेक्ट को पहली बार खोलने पर प्रत्येक टारगेट के लिए स्वचालित रूप से एक स्कीम बनाता है। डिफ़ॉल्ट रूप से स्कीम का नाम टारगेट के नाम से मेल खाता है। यदि प्रोजेक्ट में टेस्ट टारगेट है, तो Xcode इसे मुख्य टारगेट की स्कीम के Test क्रिया में स्वचालित रूप से जोड़ता है। कई टारगेट वाले प्रोजेक्ट (मुख्य ऐप + watchOS + एक्सटेंशन) के लिए Xcode प्रत्येक के लिए अलग स्कीम बनाता है, लेकिन एक ऐसी स्कीम भी बनाई जा सकती है जो सभी टारगेट को एक साथ बिल्ड करती है।

स्कीम xcshareddata/xcschemes/ डायरेक्टरी में संग्रहीत होती हैं (shared के लिए) या xcuserdata/<user>/xcschemes/ में (private के लिए)। Shared स्कीम Git में जाती हैं और पूरी टीम उनका उपयोग करती है। Private स्कीम स्थानीय रूप से संग्रहीत होती हैं और सिंक नहीं होतीं। .xcscheme फ़ाइल का XML फ़ॉर्मेट होता है जिसका रूट एलिमेंट <Scheme> होता है। अंदर प्रत्येक क्रिया के लिए ब्लॉक होते हैं: BuildAction, TestAction, LaunchAction, ProfileAction, AnalyzeAction, ArchiveAction।

.xcscheme फ़ाइल की संरचना

.xcscheme एक XML फ़ाइल है जिसे मैन्युअल रूप से या Xcode के माध्यम से संपादित किया जा सकता है। मुख्य एलिमेंट: <BuildAction> (बिल्ड किए जाने वाले टारगेट की सूची), <TestAction> (टेस्ट टारगेट के लिंक), <LaunchAction> (लॉन्च कॉन्फ़िगरेशन), <ProfileAction>, <AnalyzeAction>, <ArchiveAction>। प्रत्येक ब्लॉक में buildConfiguration एट्रिब्यूट होता है, जो निर्धारित करता है कि दी गई क्रिया के लिए किस कॉन्फ़िगरेशन (Debug/Release) का उपयोग करना है।

Scheme की क्रियाएं: Build, Run, Test, Profile, Analyze, Archive

Scheme में छह क्रियाएं होती हैं, जिनमें से प्रत्येक को स्वतंत्र रूप से कॉन्फ़िगर किया जा सकता है। Build क्रिया निर्धारित करती है कि कौन से टारगेट और किस क्रम में बिल्ड होते हैं। Run क्रिया निर्धारित करती है कि ऐप कैसे लॉन्च होता है: किन आर्ग्यूमेंट, एनवायरनमेंट वेरिएबल और किस कॉन्फ़िगरेशन के साथ। Test क्रिया निर्धारित करती है कि कौन से टेस्ट चलते हैं और कौन से code coverage विकल्प सक्षम हैं। Profile क्रिया प्रोफ़ाइलिंग के लिए Instruments टूल के साथ लॉन्च करती है। Analyze क्रिया Clang Static Analyzer के साथ स्टैटिक कोड विश्लेषण करती है। Archive क्रिया App Store में पब्लिश करने या AdHoc वितरण के लिए बिल्ड करती है।

प्रत्येक क्रिया के लिए अलग build configuration सेट की जा सकती है। आमतौर पर Run और Test के लिए Debug और Archive के लिए Release उपयोग होता है। build configuration कंपाइलर फ्लैग, ऑप्टिमाइज़ेशन और डीबग जानकारी का सेट निर्धारित करती है। Xcode दो मानक कॉन्फ़िगरेशन प्रदान करता है: Debug (बिना ऑप्टिमाइज़ेशन, डीबग सिंबल के साथ) और Release (ऑप्टिमाइज़ेशन के साथ, बिना डीबग जानकारी)। डेवलपर project.xcconfig के माध्यम से कस्टम कॉन्फ़िगरेशन जोड़ सकता है।

Archive क्रिया विशेष रूप से महत्वपूर्ण है — यह एक .xcarchive बनाती है, जिसे बाद में App Store या AdHoc के लिए .ipa में निर्यात किया जाता है। Archive क्रिया डिफ़ॉल्ट रूप से Release कॉन्फ़िगरेशन का उपयोग करती है, लेकिन इसे AdHoc या Distribution पर स्विच किया जा सकता है। Archive क्रिया में revealArchiveInOrganizer फ्लैग भी उपलब्ध है — आर्काइविंग पूरी होने के बाद Xcode आर्काइव के साथ आगे की क्रियाओं के लिए Organizer खोलता है।

<!-- iOS ऐप के लिए .xcscheme का उदाहरण -->
<Scheme
  LastUpgradeVersion = "1500"
  version = "1.7">

  <BuildAction
    parallelizeBuildables = "YES"
    buildImplicitDependencies = "YES">
    <BuildActionEntries>
      <BuildActionEntry
        buildForTesting = "YES"
        buildForRunning = "YES"
        buildForProfiling = "YES"
        buildForArchiving = "YES"
        buildForAnalyzing = "YES">
        <BuildableReference
          BuildableIdentifier = "primary"
          BlueprintIdentifier = "ABCD1234"
          BuildableName = "MyApp.app"
          BlueprintName = "MyApp"
          ReferencedContainer = "container:MyApp.xcodeproj">
        </BuildableReference>
      </BuildActionEntry>
    </BuildActionEntries>
  </BuildAction>

  <LaunchAction
    buildConfiguration = "Debug"
    selectedDebuggerIdentifier = "Xcode.DebuggerFoundation.Debugger.LLDB"
    enableAddressSanitizer = "YES">
  </LaunchAction>
</Scheme>

Scheme बनाना और कॉन्फ़िगर करना

डायग्नोस्टिक सैनिटाइज़र

नई स्कीम बनाना Xcode मेनू के माध्यम से किया जाता है: Product → Scheme → New Scheme या Scheme पैनल (Run बटन के पास) में "+" बटन से। बनाते समय वह टारगेट चुना जाता है जिसके लिए स्कीम बनाई जाती है। यदि किसी मौजूदा स्कीम को "duplicate" के रूप में चुना जाता है, तो Xcode उसकी सेटिंग्स स्वचालित रूप से कॉपी करता है। नई स्कीम डिफ़ॉल्ट रूप से private के रूप में सहेजी जाती हैं — टीम के साथ साझा करने के लिए Manage Schemes में Shared को सक्षम करना होता है।

Edit Scheme विंडो (Product → Scheme → Edit Scheme) में क्रियाओं की संख्या के अनुसार छह टैब होते हैं। प्रत्येक टैब में build configuration, लॉन्च आर्ग्यूमेंट, एनवायरनमेंट वेरिएबल और डायग्नोस्टिक फ्लैग बदले जा सकते हैं। Run टैब में विकल्प होते हैं: executable (कौन सा बाइनरी लॉन्च करना है), wait for executable to be launched (लॉन्च किए गए प्रोसेस की डीबगिंग के लिए), debugger (LLDB या None), launch arguments, environment variables और विस्तारित विकल्प (Address Sanitizer, Thread Sanitizer, Main Thread Checker, Memory Management)।

डायग्नोस्टिक्स के लिए Address Sanitizer (ASan) C/C++/ObjC कोड में सीमा से बाहर पहुंच, use-after-free और अन्य मेमोरी त्रुटियों का पता लगाता है। Thread Sanitizer (TSan) मल्टीथ्रेडेड कोड में डेटा रेस का पता लगाता है। Undefined Behavior Sanitizer (UBSan) अपरिभाषित व्यवहार का पता लगाता है, जैसे signed int का ओवरफ्लो। ये विकल्प Edit Scheme → Run → Diagnostics में उपलब्ध हैं और केवल Debug बिल्ड के लिए काम करते हैं। सभी सैनिटाइज़र सक्षम करने से लॉन्च 2-3 गुना धीमा हो सकता है, इसलिए इन्हें चुनिंदा रूप से सक्षम करने की अनुशंसा की जाती है।

विभिन्न एनवायरनमेंट के लिए स्कीम क्लोन करना

विशिष्ट अभ्यास प्रत्येक एनवायरनमेंट के लिए अलग स्कीम बनाना है: Dev, Staging, Production। प्रत्येक स्कीम समान Build Configuration (Dev के लिए Debug, Production के लिए Release) का उपयोग करती है, लेकिन अलग-अलग लॉन्च आर्ग्यूमेंट: Dev के लिए -FIRAnalyticsDebugEnabled, -com.apple.CoreData.SQLDebug 1 और Production के लिए उनकी अनुपस्थिति। लॉन्च आर्ग्यूमेंट UserDefaults (ProcessInfo.processInfo.arguments) में पास होते हैं और ऐप स्टार्टअप पर पढ़ने के लिए उपलब्ध होते हैं। यह कोड बदले बिना सर्वर URL, लॉगिंग लेवल और फीचर्स को स्विच करने की अनुमति देता है।

Shared और Private स्कीम: Git के माध्यम से प्रबंधन

Shared स्कीम <project>.xcworkspace/xcshareddata/xcschemes/ या <project>.xcodeproj/xcshareddata/xcschemes/ में संग्रहीत होती हैं और Git रिपॉजिटरी में जाती हैं। टीम के सभी डेवलपर इन स्कीम को Xcode में देखते हैं। Shared स्कीम टीम के भीतर स्कीम वितरित करने का एकमात्र तरीका है। यदि किसी डेवलपर ने महत्वपूर्ण स्कीम बनाई (जैसे "Staging Archive") लेकिन उसे Shared के रूप में चिह्नित नहीं किया, तो बाकी टीम उसे नहीं देख पाएगी, जिससे भ्रम पैदा होता है: हर कोई अपनी सेटिंग्स के साथ अपनी स्कीम बनाएगा।

Private स्कीम xcuserdata/<user>/xcschemes/ में संग्रहीत होती हैं और Git में नहीं जातीं। वे व्यक्तिगत कॉन्फ़िगरेशन के लिए उपयोगी होती हैं: उदाहरण के लिए, किसी विशेष डेवलपर के लिए सभी सैनिटाइज़र सक्षम वाली स्कीम। Private स्कीम में महत्वपूर्ण सेटिंग्स नहीं होनी चाहिए जिन पर प्रोजेक्ट का बिल्ड निर्भर करता है — यदि डेवलपर प्रोजेक्ट छोड़ देता है, तो उसकी private स्कीम गायब हो जाएंगी। अनुशंसा: CI/CD में उपयोग की जाने वाली और कम से कम दो डेवलपर द्वारा उपयोग की जाने वाली सभी स्कीम को Shared बनाएं।

स्कीम का प्रबंधन Manage Schemes (Product → Scheme → Manage Schemes) के माध्यम से किया जाता है। विंडो में प्रोजेक्ट की सभी स्कीम, उनकी स्थिति (Shared/Private) और जोड़ने/हटाने के लिए +/− बटन दिखते हैं। Shared चेकबॉक्स टीम के लिए स्कीम की दृश्यता स्विच करता है। Git कन्फ्लिक्ट के मामले में (दो डेवलपर द्वारा .xcscheme में बदलाव), मर्ज को सावधानी से हल करना होता है — XML फ़ाइलों में अलग-अलग टारगेट आइडेंटिफ़ायर हो सकते हैं। .xcscheme को मर्ज के दौरान लॉक किए जाने वाले फ़ाइलों में जोड़ने की अनुशंसा की जाती है (git lfs या .gitattributes)।

लॉन्च आर्ग्यूमेंट और एनवायरनमेंट वेरिएबल

Arguments (आर्ग्यूमेंट) Scheme में वे स्ट्रिंग हैं जो ऐप को लॉन्च के समय दी जाती हैं (ProcessInfo.processInfo.arguments) और एनवायरनमेंट वेरिएबल (ProcessInfo.processInfo.environment)। आर्ग्यूमेंट फ्लैग के लिए उपयोग होते हैं: -AppleLanguages (ru), -AppleLocale ru_RU रूसी लोकेल सिम्युलेट करने के लिए, या -FIRDebugEnabled Firebase डीबगिंग सक्षम करने के लिए। एनवायरनमेंट वेरिएबल कॉन्फ़िगरेशन के लिए उपयोग होते हैं: API_BASE_URL=http://localhost:3000, LOG_LEVEL=debug।

विभिन्न एनवायरनमेंट में फीचर्स (feature flags) प्रबंधित करने के लिए Arguments + Build Configuration का संयोजन उपयोग होता है। Dev स्कीम में आर्ग्यूमेंट -FeatureFlagNewOnboarding YES सेट किया जाता है, और Production में — -FeatureFlagNewOnboarding NO (या आर्ग्यूमेंट अनुपस्थित होता है)। कोड में जांच: UserDefaults.standard.bool(forKey: "FeatureFlagNewOnboarding")। यह दृष्टिकोण कोड बदले बिना और प्रोडक्शन मान कमिट किए बिना staging पर फीचर्स को धीरे-धीरे सक्षम करने की अनुमति देता है।

महत्वपूर्ण: Scheme के आर्ग्यूमेंट और एनवायरनमेंट वेरिएबल Info.plist के मानों को ओवरराइड करते हैं। यदि Info.plist में API_URL निर्दिष्ट है, और Scheme में — Run क्रिया के लिए API_URL=http://localhost, तो Xcode से लॉन्च करते समय Scheme का मान उपयोग होगा। डिवाइस पर लॉन्च करते समय (Xcode से नहीं) — Info.plist का मान। यह स्थानीय विकास के लिए सुविधाजनक है, लेकिन याद रखना होगा कि Scheme के वेरिएबल बिल्ड में नहीं जाते — वे केवल Xcode के माध्यम से लॉन्च करते समय काम करते हैं।

import Foundation

struct AppEnvironment {
    var apiBaseURL: String {
        ProcessInfo.processInfo.environment["API_BASE_URL"]
            ?? Bundle.main.object(forInfoDictionaryKey: "API_BASE_URL") as? String
            ?? "https://api.production.com"
    }

    var isDebugMode: Bool {
        ProcessInfo.processInfo.arguments.contains("-DebugModeEnabled")
    }

    var isNewOnboardingEnabled: Bool {
        UserDefaults.standard.bool(forKey: "FeatureFlagNewOnboarding")
    }
}

// स्टार्टअप पर उपयोग
let env = AppEnvironment()
NetworkConfig.shared.configure(baseURL: env.apiBaseURL)

CI/CD में Scheme: xcodebuild के माध्यम से ऑटोमेशन

CI/CD (GitHub Actions, Jenkins, GitLab CI) में Scheme का उपयोग xcodebuild कमांड के मुख्य आर्ग्यूमेंट के रूप में होता है। उदाहरण: xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Release -sdk iphoneos archive। -scheme फ्लैग निर्धारित करता है कि कौन सी स्कीम उपयोग करनी है। xcodebuild .xcscheme फ़ाइल से सभी सेटिंग्स पढ़ता है, जिसमें build configuration, टारगेट और बिल्ड क्रम शामिल हैं। यह गारंटी देता है कि CI/CD ऐप को स्थानीय IDE के समान पैरामीटर के साथ बिल्ड करता है।

CI/CD के लिए Shared स्कीम महत्वपूर्ण हैं। यदि स्कीम Shared नहीं है, तो xcodebuild इसे रिपॉजिटरी में नहीं ढूंढ पाएगा और बिल्ड "Scheme not found" त्रुटि के साथ विफल हो जाएगा। नियम: CI/CD सेट करने से पहले सुनिश्चित करें कि सभी उपयोग की जाने वाली स्कीम Shared के रूप में चिह्नित हैं। दूसरा नियम: CI/CD में डिफ़ॉल्ट स्कीम का उपयोग न करें (Xcode स्वचालित रूप से पहली स्कीम चुनता है) — हमेशा स्कीम का नाम -scheme फ्लैग के माध्यम से स्पष्ट रूप से पास करें।

कई स्कीम के समानांतर बिल्ड के लिए (उदाहरण के लिए, ऐप और watchOS एक्सटेंशन), xcodebuild को क्रमिक रूप से या समानांतर में चलाया जा सकता है। आधुनिक CI सिस्टम मैट्रिक्स के माध्यम से विभिन्न स्कीम के बिल्ड को समानांतर करने की अनुमति देते हैं: एक जॉब iOS ऐप बिल्ड करती है, दूसरी watchOS एक्सटेंशन। यह दो समानांतर एजेंटों के साथ कुल बिल्ड समय को 15 से 8 मिनट तक कम करता है। अंत में आर्टिफैक्ट xcodebuild -exportArchive के साथ एक .xcarchive में संयुक्त होते हैं।

#!/bin/bash — xcodebuild के साथ CI/CD बिल्ड
# 1. सफाई और बिल्ड
xcodebuild clean archive \
  -workspace "MyApp.xcworkspace" \
  -scheme "MyApp Production" \
  -configuration Release \
  -sdk iphoneos \
  -archivePath "build/MyApp.xcarchive" \
  CODE_SIGN_STYLE="Manual" \
  PROVISIONING_PROFILE_SPECIFIER="match AppStore"

# 2. IPA में निर्यात
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/ipa" \
  -exportOptionsPlist "ExportOptions.plist"