Scheme: diwa, configuration at paglulunsad sa Xcode

Ano ang Scheme sa Xcode?

Scheme sa Xcode ay isang XML file (extension na .xcscheme) na naglalarawan ng pagkakasunod-sunod ng mga aksyon at ang kanilang mga parameter para sa pagbuo at pagsusuri ng aplikasyon. Ang bawat Scheme ay naka-link sa isa o higit pang target at tumutukoy kung anong configuration (Debug, Release, AdHoc) ang gagamitin sa bawat aksyon. Ang Scheme ay katulad ng Build Variant sa Android, ngunit may mas flexible na istraktura: ang isang scheme ay maaaring maglaman ng iba't ibang target para sa iba't ibang aksyon.

Awtomatikong lumilikha ang Xcode ng scheme para sa bawat target sa unang pagbubukas ng proyekto. Ang default na pangalan ng scheme ay kasabay ng pangalan ng target. Kung ang proyekto ay may test target, awtomatikong idinaragdag ito ng Xcode sa Test action ng scheme ng pangunahing target. Para sa mga proyektong may maraming target (pangunahing aplikasyon + watchOS + extension) lumilikha ang Xcode ng hiwalay na scheme para sa bawat isa, ngunit maaaring gumawa ng isang scheme na bumubuo ng lahat ng target nang sabay-sabay.

Ang mga scheme ay nakaimbak sa direktoryo ng xcshareddata/xcschemes/ (para sa shared) o xcuserdata/<user>/xcschemes/ (para sa private). Ang mga shared scheme ay pumapasok sa Git at ginagamit ng buong team. Ang mga private scheme ay nakaimbak nang lokal at hindi nagsi-sync. Ang .xcscheme file ay may XML format na may root element na <Scheme>. Sa loob ay may mga block para sa bawat aksyon: BuildAction, TestAction, LaunchAction, ProfileAction, AnalyzeAction, ArchiveAction.

Istraktura ng .xcscheme file

.xcscheme ay isang XML file na maaaring i-edit nang manu-mano o sa pamamagitan ng Xcode. Mga pangunahing elemento: <BuildAction> (listahan ng mga target na bubuuin), <TestAction> (mga sanggunian sa mga test target), <LaunchAction> (configuration ng paglulunsad), <ProfileAction>, <AnalyzeAction>, <ArchiveAction>. Ang bawat block ay naglalaman ng attribute na buildConfiguration na tumutukoy kung aling configuration (Debug/Release) ang gagamitin para sa aksyon na ito.

Mga aksyon ng Scheme: Build, Run, Test, Profile, Analyze, Archive

Scheme ay binubuo ng anim na aksyon, na ang bawat isa ay maaaring i-configure nang nakapag-iisa. Ang Build Action ay tumutukoy kung aling mga target ang bubuuin at sa anong pagkakasunud-sunod. Run Action — kung paano inilulunsad ang aplikasyon: sa anong mga argumento, environment variable at anong configuration. Test Action — aling mga test ang pinapatakbo at aling mga code coverage na opsyon ang naka-enable. Profile Action — paglulunsad gamit ang Instruments tools para sa profiling. Analyze Action — static analysis ng code gamit ang Clang Static Analyzer. Archive Action — pagbuo para sa pag-publish sa App Store o AdHoc distribution.

Para sa bawat aksyon ay maaaring itakda ang hiwalay na build configuration. Karaniwan para sa Run at Test ginagamit ang Debug, para sa Archive — Release. Tinutukoy ng build configuration ang set ng compiler flags, optimizations at debugging information. Nagbibigay ang Xcode ng dalawang standard na configuration: Debug (walang optimization, may debug symbols) at Release (may optimization, walang debugging information). Maaaring magdagdag ang developer ng custom na configuration sa pamamagitan ng project.xcconfig.

Ang aksyon na Archive ay lalong mahalaga — lumilikha ito ng .xcarchive na pagkatapos ay ie-export sa .ipa para sa App Store o AdHoc. Ang Archive Action ay gumagamit ng Release configuration bilang default, ngunit maaaring lumipat sa AdHoc o Distribution. Sa Archive Action ay magagamit din ang flag na revealArchiveInOrganizer — pagkatapos matapos ang pag-archive ay bubuksan ng Xcode ang Organiser para sa mga kasunod na aksyon sa archive.

<!-- Halimbawa ng .xcscheme para sa iOS app -->
<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>

Paglikha at pag-configure ng Scheme

Diagnostic sanitizers

Ang paglikha ng bagong scheme ay ginagawa sa pamamagitan ng Xcode menu: Product → Scheme → New Scheme o gamit ang button na “+” sa Scheme panel (sa tabi ng Run button). Sa paggawa, pipiliin ang target kung para saan ang scheme. Kung ang scheme ay napili bilang “duplicate”, awtomatikong kokopyahin ng Xcode ang mga setting mula sa umiiral na scheme. Ang mga bagong scheme ay naka-save bilang private bilang default — para ma-publish sa team, kailangang i-enable ang Shared sa Manage Schemes.

Ang window ng Edit Scheme (Product → Scheme → Edit Scheme) ay naglalaman ng anim na tab ayon sa bilang ng mga aksyon. Sa bawat tab ay maaaring baguhin ang build configuration, mga argumento sa paglulunsad, environment variable at diagnostic flags. Sa Run tab ay magagamit ang mga opsyon: executable (aling binary ang ilulunsad), wait for executable to be launched (para sa pag-debug ng mga prosesong inilulunsad), debugger (LLDB o None), launch arguments, environment variables, at mga advanced na opsyon (Address Sanitizer, Thread Sanitizer, Main Thread Checker, Memory Management).

Para sa diagnosis Address Sanitizer (ASan) — nakakakita ng paglabas sa labas ng hangganan ng array, use-after-free at iba pang memory error sa C/C++/ObjC code. Thread Sanitizer (TSan) — nakakakita ng data races sa multithreaded code. Undefined Behavior Sanitizer (UBSan) — naglalantad ng undefined na pag-uugali, halimbawa overflow ng signed int. Ang mga opsyon na ito ay magagamit sa Edit Scheme → Run → Diagnostics at gumagana lamang para sa Debug build. Ang pag-enable ng lahat ng sanitizer ay maaaring pabagalin ang paglulunsad ng 2-3 beses, kaya inirerekomenda ang piling pag-enable sa mga ito.

Pag-clone ng scheme para sa iba't ibang kapaligiran

Karaniwang praktika — paglikha ng hiwalay na mga scheme para sa bawat kapaligiran: Dev, Staging, Production. Ang bawat scheme ay gumagamit ng parehong Build Configuration (Debug para sa Dev, Release para sa Production), ngunit iba't ibang argumento sa paglulunsad: -FIRAnalyticsDebugEnabled, -com.apple.CoreData.SQLDebug 1 para sa Dev at ang kanilang kawalan para sa Production. Ang mga argumento sa paglulunsad ay ipinapasa sa UserDefaults (ProcessInfo.processInfo.arguments) at available para basahin sa pagsisimula ng aplikasyon. Ito ay nagbibigay-daan sa paglipat ng server URL, antas ng logging at mga feature nang hindi binabago ang code.

Shared at Private na mga scheme: pamamahala sa pamamagitan ng Git

Shared scheme ay naka-imbak sa <project>.xcworkspace/xcshareddata/xcschemes/ o <project>.xcodeproj/xcshareddata/xcschemes/ at pumapasok sa Git repository. Nakikita ng lahat ng developer ng team ang mga scheme na ito sa Xcode. Ang shared scheme ay ang tanging paraan upang maipamahagi ang mga scheme sa team. Kung ang developer ay gumawa ng mahalagang scheme (halimbawa “Staging Archive”) ngunit hindi ito minarkahan bilang Shared, hindi ito makikita ng ibang bahagi ng team, na nagdudulot ng kalituhan: bawat isa ay gagawa ng sariling scheme na may sariling setting.

Private scheme ay naka-imbak sa xcuserdata/<user>/xcschemes/ at hindi pumapasok sa Git. Kapaki-pakinabang ang mga ito para sa personal na configuration: halimbawa, isang scheme na may lahat ng sanitizer na naka-enable para sa isang partikular na developer. Ang private scheme ay hindi dapat maglaman ng mga kritikal na setting na nakadepende ang pagbuo ng proyekto — kung ang developer ay umalis sa proyekto, mawawala ang kanyang private scheme. Rekomendasyon: lahat ng scheme na ginagamit sa CI/CD at ng kahit dalawang developer ay gawing Shared.

Ang pamamahala ng mga scheme ay ginagawa sa pamamagitan ng Manage Schemes (Product → Scheme → Manage Schemes). Sa window ay ipinapakita ang lahat ng scheme ng proyekto, ang kanilang status (Shared/Private), at mga button na +/— para sa pagdaragdag/pag-alis. Ang checkbox na Shared ay nagpapalit ng visibility ng scheme para sa team. Sa Git conflict (mga pagbabago sa .xcscheme mula sa dalawang developer) kailangang maingat na lutasin ang merge — ang mga XML file ay maaaring maglaman ng iba't ibang identifier ng target. Inirerekomenda na idagdag ang .xcscheme sa mga file na naka-lock sa merge (git lfs o .gitattributes).

Mga argumento sa paglulunsad at environment variable

Arguments sa Scheme ay mga string na ipinapasa sa aplikasyon sa paglulunsad (ProcessInfo.processInfo.arguments) at environment variable (ProcessInfo.processInfo.environment). Ginagamit ang mga argumento para sa mga flag: -AppleLanguages (ru), -AppleLocale ru_RU para sa simulation ng Russian locale o -FIRDebugEnabled para sa pag-enable ng Firebase debugging. Inilalapat ang mga environment variable para sa configuration: API_BASE_URL=http://localhost:3000, LOG_LEVEL=debug.

Para sa pamamahala ng mga feature (feature flags) sa iba't ibang kapaligiran ay ginagamit ang kombinasyon ng Arguments + Build Configuration. Sa Dev scheme ay itinatakda ang argumento na -FeatureFlagNewOnboarding YES, at sa Production — -FeatureFlagNewOnboarding NO (o wala ang argumento). Sa code, ang pagsusuri: UserDefaults.standard.bool(forKey: “FeatureFlagNewOnboarding”). Ang pamamaraang ito ay nagbibigay-daan sa unti-unting pag-enable ng mga feature sa staging nang hindi binabago ang code at nang hindi nag-commit ng mga production value.

Mahalaga: ang mga argumento at environment variable ng Scheme ay nagpapatong sa mga value mula sa Info.plist. Kung sa Info.plist ay tinukoy ang API_URL, at sa Scheme — API_URL=http://localhost para sa Run Action, sa paglulunsad mula sa Xcode ay gagamitin ang value mula sa Scheme. Sa paglulunsad mula sa device (hindi mula sa Xcode) — ang value mula sa Info.plist. Ito ay maginhawa para sa lokal na pag-develop, ngunit kailangang tandaan na ang Scheme variable ay hindi pumapasok sa build — gumagana lamang ang mga ito sa paglulunsad sa pamamagitan ng 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")
    }
}

// Ginagamit sa pagsisimula
let env = AppEnvironment()
NetworkConfig.shared.configure(baseURL: env.apiBaseURL)

Scheme sa CI/CD: automation sa pamamagitan ng xcodebuild

Sa CI/CD (GitHub Actions, Jenkins, GitLab CI) ang Scheme ay ginagamit bilang pangunahing argumento ng utos na xcodebuild. Halimbawa: xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Release -sdk iphoneos archive. Ang flag na -scheme ay tumutukoy kung aling scheme ang gagamitin. Binabasa ng xcodebuild ang lahat ng setting mula sa .xcscheme file, kasama ang build configuration, mga target at pagkakasunud-sunod ng build. Ginagarantiyahan nito na ang CI/CD ay binuo ang aplikasyon na may parehong parameter tulad ng lokal na IDE.

Para sa CI/CD ay kritikal ang shared scheme. Kung ang scheme ay hindi Shared, hindi ito mahahanap ng xcodebuild sa repository, at babagsak ang build na may error na “Scheme not found”. Panuntunan: bago i-configure ang CI/CD, siguraduhing lahat ng ginamit na scheme ay minarkahan bilang Shared. Pangalawang panuntunan: sa CI/CD huwag gamitin ang default na scheme (awtomatikong pinipili ng Xcode ang unang scheme) — palaging ipasa nang tahasan ang pangalan ng scheme sa pamamagitan ng flag na -scheme.

Para sa parallel build ng ilang scheme (halimbawa, ang aplikasyon at ang watchOS extension) maaaring patakbuhin ang xcodebuild nang sunud-sunod o kahanay. Pinapayagan ng mga modernong CI system ang pag-parallelize ng build ng iba't ibang scheme sa pamamagitan ng matrix: ang isang job ay bumubuo ng iOS application, ang pangalawa — ang watchOS extension. Binabawasan nito ang kabuuang oras ng build mula 15 hanggang 8 minuto na may dalawang parallel agent. Sa dulo, ang mga artepakto ay pinagsama sa iisang .xcarchive gamit ang xcodebuild -exportArchive.

#!/bin/bash — CI/CD build gamit ang xcodebuild
# 1. Paglilinis at pagbuo
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. Pag-export sa IPA
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/ipa" \
  -exportOptionsPlist "ExportOptions.plist"