Scheme у Xcode-у је конфигурација која одређује како саставити, тестирати, профилисати и архивирати апликацију за iOS, macOS, watchOS или tvOS. Свака Scheme садржи скуп акција (Build, Run, Test, Profile, Analyze, Archive) са сопственим параметрима, аргументима и променљивим окружења. Према Apple Developer Documentation, 2025, Scheme је главни алат за управљање build конфигурацијама у Xcode-у, замењујући ручно пребацивање параметара. Xcode аутоматски креира шему за сваки target при првом отварању пројекта.
Главно
Scheme у Xcode-у је XML датотека (екстензија .xcscheme) која описује редослед акција и њихових параметара за састављање и анализу апликације. Свака Scheme је везана за један или више target-ова и одређује са којом конфигурацијом (Debug, Release, AdHoc) извршити сваку акцију. Scheme је аналог Build Variant-а у Android-у, али са флексибилнијом структуром: једна шема може садржати различите target-ове за различите акције.
Xcode аутоматски креира шему за сваки target при првом отварању пројекта. Подразумевано име шеме се поклапа са именом target-а. Ако пројекат има тестни target, Xcode га аутоматски додаје у Test акцију шеме главног target-а. За пројекте са више target-ова (главна апликација + watchOS + extension) Xcode креира посебну шему за сваки, али се може направити једна шема која саставља све target-ове одједном.
Шеме се чувају у директоријуму xcshareddata/xcschemes/ (за shared) или xcuserdata/<user>/xcschemes/ (за private). Shared шеме улазе у Git и користи их цео тим. Private шеме се чувају локално и не синхронизују се. Датотека .xcscheme има XML формат са кореним елементом <Scheme>. Унутра се налазе блокови за сваку акцију: BuildAction, TestAction, LaunchAction, ProfileAction, AnalyzeAction, ArchiveAction.
.xcscheme је XML датотека коју је могуће уређивати ручно или кроз Xcode. Главни елементи: <BuildAction> (листа target-ова за састављање), <TestAction> (референце на тестне target-ове), <LaunchAction> (конфигурација покретања), <ProfileAction>, <AnalyzeAction>, <ArchiveAction>. Сваки блок садржи атрибут buildConfiguration који одређује коју конфигурацију (Debug/Release) користити за дату акцију.
Scheme се састоји од шест акција, од којих се свака може подесити независно. Build Action одређује који се target-ови састављају и којим редом. Run Action — како се апликација покреће: са којим аргументима, променљивим окружења и са којом конфигурацијом. Test Action — који тестови се извршавају и које code coverage опције су укључене. Profile Action — покретање са Instruments алатима за профилисање. Analyze Action — статичка анализа кода са Clang Static Analyzer-ом. Archive Action — састављање за објављивање у App Store-у или AdHoc дистрибуцију.
За сваку акцију се може задати посебна build configuration. Обично се за Run и Test користи Debug, а за Archive — Release. Build configuration одређује скуп компајлерских заставица, оптимизација и дебаг информација. Xcode пружа две стандардне конфигурације: Debug (без оптимизација, са симболима за дебаг) и Release (са оптимизацијама, без дебаг информација). Програмер може додавати прилагођене конфигурације кроз project.xcconfig.
Archive акција је посебно важна — креира .xcarchive који се затим извози у .ipa за App Store или AdHoc. Archive Action подразумевано користи Release конфигурацију, али се може пребацити на AdHoc или Distribution. У Archive Action-у је такође доступна заставица revealArchiveInOrganizer — након завршетка архивирања Xcode отвара Organiser за даље радње са архивом.
<!-- Пример .xcscheme для iOS приложения -->
<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>
Креирање нове шеме се врши кроз Xcode мени: Product → Scheme → New Scheme или дугметом „+“ у панелу Scheme (поред Run дугмета). При креирању се бира target за који се прави шема. Ако је шема изабрана као „duplicate“, Xcode аутоматски копира подешавања из постојеће шеме. Нове шеме се подразумевано чувају као private — за објављивање тиму потребно је укључити Shared у Manage Schemes.
Прозор 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) — детектује излазак из граница низа, use-after-free и друге меморијске грешке у C/C++/ObjC коду. Thread Sanitizer (TSan) — детектује стања трке (data races) у вишенитном коду. Undefined Behavior Sanitizer (UBSan) — открива недефинисано понашање, на пример прекорачење потписаног int-а. Ове опције су доступне у Edit Scheme → Run → Diagnostics и раде само за Debug верзије. Укључивање свих санитајзера може успорити покретање 2-3 пута, па се препоручује селективно укључивање.
Типична пракса — креирање посебних шема за свако окружење: Dev, Staging, Production. Свака шема користи исте Build Configuration (Debug за Dev, Release за Production), али различите аргументе покретања: -FIRAnalyticsDebugEnabled, -com.apple.CoreData.SQLDebug 1 за Dev и њихово одсуство за Production. Аргументи покретања се прослеђују у UserDefaults (ProcessInfo.processInfo.arguments) и доступни су за читање при стартовању апликације. Ово омогућава пребацивање URL-а сервера, нивоа логирања и функција без промене кода.
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 датотеке могу садржати различите идентификаторе target-ова. Препоручује се додавање .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-у без промене кода и без комитовања production вредности.
Важно: аргументи и променљиве окружења Scheme-а преписују вредности из Info.plist-а. Ако је у Info.plist-у наведен API_URL, а у Scheme-у — API_URL=http://localhost за Run Action, при покретању из 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-у (GitHub Actions, Jenkins, GitLab CI) Scheme се користи као главни аргумент команде xcodebuild. Пример: xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Release -sdk iphoneos archive. Заставица -scheme одређује коју шему користити. xcodebuild чита сва подешавања из .xcscheme датотеке, укључујући build configuration, target-ове и редослед састављања. Ово гарантује да CI/CD саставља апликацију са истим параметрима као локални IDE.
За CI/CD су критичне Shared шеме. Ако шема није Shared, xcodebuild је неће пронаћи у репозиторијуму, а састављање ће пасти са грешком „Scheme not found“. Правило: пре подешавања CI/CD-а уверите се да су све коришћене шеме означене као Shared. Друго правило: у CI/CD-у не користите подразумевану шему (Xcode аутоматски бира прву шему) — увек проследите име шеме експлицитно кроз заставицу -scheme.
За паралелно састављање више шема (на пример, апликација и watchOS екстензија) можете покретати xcodebuild секвенцијално или паралелно. Савремени CI системи омогућавају паралелизацију састављања различитих шема кроз матрицу: један job саставља iOS апликацију, други — watchOS екстензију. Ово скраћује укупно време састављања са 15 на 8 минута са два паралелна агента. На крају се артефакти обједињују у јединствени .xcarchive помоћу xcodebuild -exportArchive.
#!/bin/bash — CI/CD сборка с xcodebuild
# 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"
Често постављана питања
Обично је довољно 2-3 шеме: Development (Debug), Staging (са аргументима за тестни сервер) и Production (Release). За модуларне библиотеке — једна шема са подешавањима за тестирање. Не множите шеме — свака нова шема захтева одржавање.
Build Configuration (Debug/Release) — скуп компајлерских заставица дефинисаних у .xcconfig-у. Scheme — скуп акција, од којих свака упућује на Build Configuration. Шема каже „при покретању користи Debug“, конфигурација одређује „Debug — то је без оптимизација, са симболима“.
Аргументи доспевају у ProcessInfo.processInfo.arguments и UserDefaults (ако аргумент почиње цртицом). Променљиве окружења — у ProcessInfo.processInfo.environment. У коду: UserDefaults.standard.bool(forKey: "FeatureFlag") за аргументе облика -FeatureFlag YES.
Да, у Build Action се може додати више target-ова. На пример, шема „App + Watch + Widget“ ће састављати сва три target-а секвенцијално (ако је parallelizeBuildables=NO) или паралелно (YES). За архивирање апликације довољан је главни target — остали се састављају као зависности.
Swift Package Manager не замењује шеме — шема и даље одређује са којом конфигурацијом састављати SPM зависности, које тестове покретати и како архивирати. SPM пакети могу имати сопствене шеме које се аутоматски увозе у пројекат при додавању пакета.
Резиме
Развићемо мобилну апликацију под кључ
IT Sectr креира iOS и Android апликације за стартапе и предузећа од 2017. године. Саветоваћемо вас и предложити најбоље решење.
Прочитајте такође