Scheme: Xcodeでの概要、設定、実行方法

XcodeのSchemeとは何か

XcodeのSchemeとは、アプリのビルドと解析のためのアクションの順序とそのパラメータを記述するXMLファイル（.xcscheme拡張子）です。各Schemeは1つ以上のターゲットに紐づき、各アクションをどの構成（Debug、Release、AdHoc）で実行するかを定義します。SchemeはAndroidのBuild Variantに相当しますが、より柔軟な構造を持ちます。1つのスキームでアクションごとに異なるターゲットを指定できます。

Xcodeはプロジェクトを初めて開いたときに、各ターゲットのスキームを自動的に作成します。デフォルトのスキーム名はターゲット名と同じです。プロジェクトにテストターゲットがある場合、XcodeはメインターゲットのスキームのTestアクションに自動的に追加します。複数のターゲット（メインアプリ + watchOS + 拡張機能）を持つプロジェクトでは、Xcodeはそれぞれに個別のスキームを作成しますが、すべてのターゲットをまとめてビルドする1つのスキームを作成することもできます。

スキームはxcshareddata/xcschemes/ディレクトリ（sharedの場合）またはxcuserdata/<user>/xcschemes/（privateの場合）に保存されます。sharedスキームはGitに入り、チーム全体で使用されます。privateスキームはローカルに保存され、同期されません。.xcschemeファイルはルート要素<Scheme>を持つXML形式です。内部には各アクションのブロックがあります: BuildAction、TestAction、LaunchAction、ProfileAction、AnalyzeAction、ArchiveAction。

.xcschemeファイルの構造

.xcschemeは、手動またはXcode経由で編集できるXMLファイルです。主な要素: <BuildAction>（ビルド対象のターゲットのリスト）、<TestAction>（テストターゲットへのリンク）、<LaunchAction>（起動構成）、<ProfileAction>、<AnalyzeAction>、<ArchiveAction>。各ブロックにはbuildConfiguration属性が含まれ、そのアクションにどの構成（Debug/Release）を使用するかを決定します。

Schemeのアクション: Build、Run、Test、Profile、Analyze、Archive

Schemeは6つのアクションで構成され、それぞれを独立して設定できます。Buildアクションは、どのターゲットをどの順序でビルドするかを決定します。Runアクションは、どの引数、環境変数、構成でアプリを起動するかを決定します。Testアクションは、どのテストを実行し、どのコードカバレッジオプションを有効にするかを決定します。Profileアクションは、プロファイリングのためにInstrumentsツールで起動します。Analyzeアクションは、Clang Static Analyzerで静的コード解析を実行します。Archiveアクションは、App Store公開またはAdHoc配布用にビルドします。

各アクションに対して個別のbuild configurationを設定できます。通常、RunとTestにはDebug、ArchiveにはReleaseが使用されます。build configurationは、コンパイラフラグ、最適化、デバッグ情報のセットを定義します。Xcodeには2つの標準構成があります: 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）には、アクションの数に対応する6つのタブがあります。各タブで、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）は符号付き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で使用され、少なくとも2人の開発者が使用するスキームはすべてSharedにしてください。

スキームの管理はManage Schemes（Product → Scheme → Manage Schemes）で行います。ウィンドウには、プロジェクトのすべてのスキーム、そのステータス（Shared/Private）、追加/削除用の+/−ボタンが表示されます。Sharedチェックボックスは、チームに対するスキームの表示を切り替えます。Gitの競合（2人の開発者による.xcschemeの変更）の場合、マージを慎重に解決する必要があります。XMLファイルには異なるターゲット識別子が含まれる可能性があるためです。.xcschemeをマージ中にロックされるファイル（git lfsまたは.gitattributes）に追加することをお勧めします。

起動引数と環境変数

引数とは、起動時にアプリに渡される文字列（ProcessInfo.processInfo.arguments）と環境変数（ProcessInfo.processInfo.environment）のことです。引数はフラグに使用されます: -AppleLanguages (ru)、-AppleLocale ru_RUでロシア語ロケールをシミュレートしたり、-FIRDebugEnabledでFirebaseのデバッグを有効にしたりします。環境変数は設定に使用されます: API_BASE_URL=http://localhost:3000、LOG_LEVEL=debug。

異なる環境で機能（フィーチャーフラグ）を管理するには、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としてマークされていることを確認してください。2番目のルール: CI/CDではデフォルトのスキームを使用しないでください（Xcodeは最初のスキームを自動的に選択します）。常に-schemeフラグでスキーム名を明示的に渡してください。

複数のスキームを並行してビルドする場合（たとえばアプリとwatchOS拡張機能）、xcodebuildを順次または並列で実行できます。最新のCIシステムでは、マトリックスを使用して異なるスキームのビルドを並列化できます。1つのジョブがiOSアプリをビルドし、もう1つがwatchOS拡張機能をビルドします。これにより、2つの並列エージェントで総ビルド時間が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"