Scheme: Xcode-da mahiyyəti, konfiqurasiyası və işə salınması

Xcode-da Scheme nədir?

Scheme Xcode-da tətbiqin qurulması və təhlili üçün əməliyyatların ardıcıllığını və onların parametrlərini təsvir edən XML-fayldır (.xcscheme genişləndirməsi). Hər bir Scheme bir və ya bir neçə targetə bağlıdır və hər əməliyyatın hansı konfiqurasiya ilə (Debug, Release, AdHoc) yerinə yetiriləcəyini müəyyən edir. Scheme Android-də Build Variant-ın analoqudur, lakin daha çevik struktura malikdir: bir sxem müxtəlif əməliyyatlar üçün müxtəlif targetlər ehtiva edə bilər.

Xcode layihə ilk dəfə açılanda hər target üçün avtomatik sxem yaradır. Sxemin standart adı targetin adı ilə üst-üstə düşür. Layihədə test targeti varsa, Xcode onu avtomatik olaraq əsas targetin sxeminin Test əməliyyatına əlavə edir. Bir neçə targetli layihələr üçün (əsas tətbiq + watchOS + extension) Xcode hər biri üçün ayrıca sxem yaradır, lakin bütün targetləri bir anda quran bir sxem də yaratmaq olar.

Sxemlər xcshareddata/xcschemes/ kataloqunda (shared üçün) və ya xcuserdata/<user>/xcschemes/ kataloqunda (private üçün) saxlanılır. Shared sxemlər Git-ə düşür və bütün komanda tərəfindən istifadə olunur. Private sxemlər lokal saxlanılır və sinxronlaşdırılmır. .xcscheme faylı kök elementi <Scheme> olan XML formatına malikdir. İçəridə hər əməliyyat üçün bloklar var: BuildAction, TestAction, LaunchAction, ProfileAction, AnalyzeAction, ArchiveAction.

.xcscheme faylının strukturu

.xcscheme əl ilə və ya Xcode vasitəsilə redaktə edilə bilən XML-fayldır. Əsas elementlər: <BuildAction> (qurulan targetlərin siyahısı), <TestAction> (test targetlərinə istinadlar), <LaunchAction> (işə salma konfiqurasiyası), <ProfileAction>, <AnalyzeAction>, <ArchiveAction>. Hər blokda bu əməliyyat üçün hansı konfiqurasiyanın (Debug/Release) istifadə olunacağını müəyyən edən buildConfiguration atributu var.

Scheme əməliyyatları: Build, Run, Test, Profile, Analyze, Archive

Scheme hər biri müstəqil konfiqurasiya edilə bilən altı əməliyyatdan ibarətdir. Build Action hansı targetlərin və hansı ardıcıllıqla qurulacağını müəyyən edir. Run Action — tətbiqin necə işə salındığını: hansı arqumentlərlə, mühit dəyişənləri ilə və hansı konfiqurasiya ilə. Test Action — hansı testlərin icra olunacağını və hansı code coverage variantlarının aktiv olduğunu. Profile Action — profilləmə üçün Instruments alətləri ilə işə salma. Analyze Action — Clang Static Analyzer ilə kodun statik təhlili. Archive Action — App Store-da dərc və ya AdHoc paylanması üçün qurma.

Hər əməliyyat üçün ayrıca build configuration təyin etmək olar. Adətən Run və Test üçün Debug, Archive üçün isə Release istifadə olunur. Build configuration kompilyator bayraqları, optimizasiyalar və sazlama məlumatı dəstini müəyyən edir. Xcode iki standart konfiqurasiya təqdim edir: Debug (optimizasiyasız, sazlama simvolları ilə) və Release (optimizasiyalarla, sazlama məlumatı olmadan). Tərtibatçı layihə.xcconfig vasitəsilə xüsusi konfiqurasiyalar əlavə edə bilər.

Archive əməliyyatı xüsusilə vacibdir — o, sonradan App Store və ya AdHoc üçün .ipa faylına ixrac edilən .xcarchive yaradır. Archive Action standart olaraq Release-konfiqurasiyasından istifadə edir, lakin AdHoc və ya Distribution-ə keçmək olar. Archive Action-da həmçinin revealArchiveInOrganizer bayrağı mövcuddur — arxivləşdirmə başa çatdıqdan sonra Xcode arxivlə bağlı sonrakı əməliyyatlar üçün Organiser-i açır.

<!-- iOS tətbiqi üçün .xcscheme nümunəsi -->
<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-nin yaradılması və konfiqurasiyası

Diaqnostik sanitizerlər

Yeni sxemin yaradılması Xcode menyusu vasitəsilə yerinə yetirilir: Product → Scheme → New Scheme və ya Scheme panelində (Run düyməsinin yanında) “+” düyməsi ilə. Yaradılarkən sxem üçün target seçilir. Sxem “duplicate” kimi seçilibsə, Xcode avtomatik olaraq mövcud sxemdən parametrləri kopyalayır. Yeni sxemlər standart olaraq private kimi saxlanılır — komandaya dərc etmək üçün Manage Schemes-də Shared-ı aktivləşdirmək lazımdır.

Edit Scheme pəncərəsi (Product → Scheme → Edit Scheme) əməliyyatların sayına görə altı əlavə içərisinə malikdir. Hər əlavədə build configuration, işə salma arqumentləri, mühit dəyişənləri və diaqnostik bayraqlar dəyişdirilə bilər. Run əlavəsində aşağıdakı variantlar mövcuddur: executable (hansı binar faylın işə salınacağı), wait for executable to be launched (işə salınan proseslərin sazlanması üçün), debugger (LLDB və ya None), launch arguments, environment variables və genişləndirilmiş variantlar (Address Sanitizer, Thread Sanitizer, Main Thread Checker, Memory Management).

Diaqnostika üçün Address Sanitizer (ASan) — massivin sərhədlərindən kənara çıxmanı, use-after-free və C/C++/ObjC kodunda digər yaddaş xətalarını aşkarlayır. Thread Sanitizer (TSan) — çoxaxınlı kodda data race hallarını aşkarlayır. Undefined Behavior Sanitizer (UBSan) — məsələn, işarəli int-in daşması kimi qeyri-müəyyən davranışı üzə çıxarır. Bu variantlar Edit Scheme → Run → Diagnostics-də mövcuddur və yalnız Debug yığımları üçün işləyir. Bütün sanitizerləri aktivləşdirmək işə salmanı 2-3 dəfə yavaşlada bilər, ona görə də onları seçmə şəkildə aktivləşdirmək tövsiyə olunur.

Müxtəlif mühitlər üçün sxemin kopyalanması

Tipik təcrübə — hər mühit üçün ayrıca sxemlər yaratmaqdır: Dev, Staging, Production. Hər sxem eyni Build Configuration-dan istifadə edir (Dev üçün Debug, Production üçün Release), lakin müxtəlif işə salma arqumentləri ilə: Dev üçün -FIRAnalyticsDebugEnabled, -com.apple.CoreData.SQLDebug 1 və Production üçün onların olmaması. İşə salma arqumentləri UserDefaults-a (ProcessInfo.processInfo.arguments) ötürülür və tətbiqin başlanğıcında oxumaq üçün əlçatandır. Bu, kodu dəyişmədən server URL-ni, loqlama səviyyəsini və xüsusiyyətləri dəyişməyə imkan verir.

Shared və Private sxemlər: Git vasitəsilə idarəetmə

Shared sxemlər <project>.xcworkspace/xcshareddata/xcschemes/ və ya <project>.xcodeproj/xcshareddata/xcschemes/ qovluğunda saxlanılır və Git repozitoriyasına düşür. Komandanın bütün tərtibatçıları bu sxemləri Xcode-da görür. Shared sxemlər — sxemləri komanda daxilində yaymağın yeganə yoludur. Əgər tərtibatçı vacib sxem yaradıbsa (məsələn, “Staging Archive”), amma onu Shared kimi qeyd etməyibsə, komandanın qalanı onu görməyəcək və bu, qarışıqlığa gətirib çıxarır: hər kəs öz parametrləri ilə öz sxemini yaradacaq.

Private sxemlər xcuserdata/<user>/xcschemes/ qovluğunda saxlanılır və Git-ə düşmür. Onlar şəxsi konfiqurasiyalar üçün faydalıdır: məsələn, konkret tərtibatçı üçün bütün sanitizerlər aktivləşdirilmiş sxem. Private sxemlər layihənin qurulmasından asılı olan kritik parametrləri ehtiva etməməlidir — əgər tərtibatçı layihədən ayrılarsa, onun private sxemləri itəcək. Tövsiyə: CI/CD-də və ən azı iki tərtibatçı tərəfindən istifadə olunan bütün sxemləri Shared etmək.

Sxemlərin idarə edilməsi Manage Schemes (Product → Scheme → Manage Schemes) vasitəsilə yerinə yetirilir. Pəncərədə layihənin bütün sxemləri, onların statusu (Shared/Private) və əlavə/silmə üçün +/— düymələri göstərilir. Shared bayrağı sxemin komanda üçün görünmə qabiliyyətini dəyişir. Git konfliktində (iki tərtibatçının .xcscheme-də dəyişiklikləri) birləşməni diqqətlə həll etmək lazımdır — XML-fayllarda müxtəlif target identifikatorları ola bilər. .xcscheme-ni merge zamanı bloklanan fayllara əlavə etmək tövsiyə olunur (git lfs və ya .gitattributes).

İşə salma arqumentləri və mühit dəyişənləri

Arguments Scheme-də tətbiqə işə salınarkən ötürülən sətirlərdir (ProcessInfo.processInfo.arguments) və mühit dəyişənləridir (ProcessInfo.processInfo.environment). Arqumentlər bayraqlar üçün istifadə olunur: -AppleLanguages (ru), -AppleLocale ru_RU rus lokalının simulyasiyası üçün və ya -FIRDebugEnabled Firebase sazlamasını aktivləşdirmək üçün. Mühit dəyişənləri konfiqurasiya üçün tətbiq olunur: API_BASE_URL=http://localhost:3000, LOG_LEVEL=debug.

Müxtəlif mühitlərdə xüsusiyyətləri idarə etmək (feature flags) üçün Arguments + Build Configuration kombinasiyası istifadə olunur. Dev-sxemdə -FeatureFlagNewOnboarding YES arqumenti, Production-da isə -FeatureFlagNewOnboarding NO (və ya arqument yoxdur) qoyulur. Kodda yoxlama: UserDefaults.standard.bool(forKey: "FeatureFlagNewOnboarding"). Bu yanaşma kodu və production dəyərlərini dəyişmədən, commit etmədən staging-də xüsusiyyətləri tədricən aktivləşdirməyə imkan verir.

Vacibdir: Scheme-nin arqumentləri və mühit dəyişənləri Info.plist-dəki dəyərləri əvəz edir. Info.plist-də API_URL göstərilibsə, Scheme-də isə Run Action üçün API_URL=http://localhost varsa, Xcode-dan işə salınarkən Scheme-dəki dəyər istifadə olunacaq. Cihazdan işə salınarkən (Xcode-dan deyil) — Info.plist-dəki dəyər. Bu, lokal inkişaf üçün əlverişlidir, lakin yadda saxlamaq lazımdır ki, Scheme dəyişənləri yığıma düşmür — onlar yalnız Xcode vasitəsilə işə salınarkən təsir edir.

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")
    }
}

// Başlanğıcda istifadə olunur
let env = AppEnvironment()
NetworkConfig.shared.configure(baseURL: env.apiBaseURL)

Scheme CI/CD-də: xcodebuild vasitəsilə avtomatlaşdırma

CI/CD-də (GitHub Actions, Jenkins, GitLab CI) Scheme xcodebuild əmrinin əsas arqumenti kimi istifadə olunur. Nümunə: xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Release -sdk iphoneos archive. -scheme bayrağı hansı sxemdən istifadə olunacağını göstərir. xcodebuild bütün parametrləri .xcscheme faylından oxuyur, o cümlədən build configuration, targetlər və qurma ardıcıllığını. Bu, CI/CD-nin tətbiqi lokal IDE ilə eyni parametrlərlə qurmasını təmin edir.

CI/CD üçün Shared sxemlər kritik əhəmiyyət daşıyır. Sxem Shared deyilsə, xcodebuild onu repozitoriyada tapmayacaq və qurma “Scheme not found” xətası ilə çökəcək. Qayda: CI/CD qurmadan əvvəl istifadə olunan bütün sxemlərin Shared qeyd edildiyinə əmin olun. İkinci qayda: CI/CD-də standart sxemdən istifadə etməyin (Xcode avtomatik ilk sxemi seçir) — həmişə sxemin adını -scheme bayrağı ilə açıq şəkildə ötürün.

Bir neçə sxemin paralel qurulması üçün (məsələn, tətbiq və watchOS-uzantısı) xcodebuild-i ardıcıl və ya paralel işə salmaq olar. Müasir CI-sistemlər matris vasitəsilə müxtəlif sxemlərin qurulmasını paralelləşdirməyə imkan verir: bir iş iOS-tətbiqini, ikincisi — watchOS-uzantısını qurur. Bu, iki paralel agentlə ümumi qurma vaxtını 15 dəqiqədən 8 dəqiqəyə qədər azaldır. Sonda artefaktlar xcodebuild -exportArchive vasitəsilə vahid .xcarchive faylında birləşdirilir.

#!/bin/bash — xcodebuild ilə CI/CD build
# 1. Təmizləmə və qurma
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 faylına ixrac
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/ipa" \
  -exportOptionsPlist "ExportOptions.plist"