Xcode 27 SDKアップロード要件：2026年CI準備チェックリスト
AppleプラットフォームのCIと公開を担当するエンジニア向けに、SDK要件に備える進め方をまとめます。実際のツールチェーンの確認、プロジェクト別の試行、テストとアップロードの受け入れ、段階切り替えの判断条件を確認できます。
目次
Appleは、2027年4月以降にApp Store Connectへアップロードするアプリについて、iOS・iPadOS 27 SDK、tvOS 27 SDK、visionOS 27 SDK、watchOS 27 SDK以降を求めると案内しています。対象となるプラットフォームと開始時期はAppleのApp Store提出要件で確認し、今週は本番の一斉更新ではなく、要件を満たすXcodeを使った隔離試行から始めてください。SDKの条件をRunnerのラベルだけで判断せず、プロジェクトごとにビルドからアップロードまでの証拠をそろえてから切り替えます。
AppleプラットフォームのCIエンジニアは、構築ノードが実際に使うXcodeとSDKを特定したい方に向いています。
リリース担当者は、Archive、署名、App Store Connectへのアップロードを含む公開経路を確認できます。
研究開発プラットフォーム責任者は、複数のアプリとチームの切り替え順を決める際に活用してください。
最終更新：2026年10月30日。データの確認先は、Apple Developer ReleasesとXcode Release Notesです。要件やツールチェーンの対応関係は更新される可能性があるため、実際の切り替え前にも各ページを照合してください。
プラットフォーム責任者：対象プロジェクトの切り分け
最初に、公開先がApp Store Connectであるプロジェクトと、社内検証、開発用ビルド、別の配布経路だけを使うタスクを分けます。Appleが示す要件の対象は、App Store Connectへ提出するアプリです。CIでmacOSを使うすべてのジョブを、同じSDK条件で一律に更新するという意味ではありません。
AppleのSDKアップロード要件はいつ適用されますか？
案内されている開始時期は2027年4月です。その時点以降のアップロードでは、対象アプリが各プラットフォームの最低SDK要件を満たす必要があります。iOS、iPadOS、tvOS、visionOS、watchOSの各SDK条件はAppleの提出要件を基準にし、告知後の変更も同ページで確認してください。
ここでいうSDKの最低要件は、アプリの最低デプロイメントターゲットとは別の条件です。デプロイメントターゲットを引き上げれば提出要件も満たせる、と短絡せず、ビルドに使ったSDKとプロジェクト設定を別々に記録します。AppleのXcodeビルド設定リファレンスを参照し、対象設定の意味を確認してください。
ツールチェーン担当者：実際のXcodeとSDKを特定
ワークフローの設定に書かれたRunnerラベルやXcode名は、実行時に選択されたツールチェーンそのものを証明しません。macOS CIの実行ログから、実際のXcodeパス、バージョン、利用可能なSDKを記録します。
現行CIのXcodeとSDKはどう確認しますか？
試行用ジョブで、次のコマンドを実行し、その標準出力をビルドログに保存してください。
xcode-select -p
xcodebuild -version
xcodebuild -showsdks
続けて、対象スキームのビルド設定も確認し、SDK指定やデプロイメントターゲットなど、プロジェクト側の値を記録します。Xcodeのバージョン番号からSDK番号を推測せず、Apple Developer ReleasesとXcodeのリリースノートで、その組み合わせが公式に確認できる場合だけ対応関係として扱ってください。
| 確認対象 | 書面上の設定だけで済ませる場合 | 試行ジョブで記録する場合 | 判定 |
|---|---|---|---|
| RunnerとXcode | ラベルや設定値を記録 | 選択されたXcodeのパスとバージョンを保存 | 実行ログがあるまで要確認 |
| SDK | バージョン名から推定 | 利用可能SDKと対象ビルド設定を照合 | Appleの公開情報と一致して合格 |
| Archive | コンパイル成功だけを確認 | Archiveの生成、署名、対象構成を確認 | 配布工程の証跡が必要 |
| アップロード | コマンドの終了だけを見る | App Store Connect側の受け入れ状態まで確認 | 受け入れ確認で合格 |
プロジェクト担当者：隔離ビルドと依存関係の検証
本番ブランチに手を加える前に、代表的なプロジェクトを選び、隔離ブランチまたは専用CIジョブで試します。アプリ本体に加えて、依存パッケージ、ビルドスクリプト、コード生成、リソース処理を含め、同じ入力から結果を再現できる記録を残してください。
Xcode更新後に再確認するビルド条件
対象スキームを明示し、新しいツールチェーンでクリーンビルドします。失敗した場合は、最初に失敗した工程、エラー全文、依存関係の解決結果を保存し、SDK由来の問題とスクリプトや依存ライブラリの問題を切り分けます。Xcodeのシステム要件とSDK条件は、AppleのXcodeシステム要件で照合してください。
ビルドが通っただけでは互換性確認は完了しません。サポート対象のプラットフォームごとに、ユニットテストや既存の検証手順を実行し、Simulatorで確認した範囲と実機での確認範囲を明確に分けます。AppleのSimulatorおよび実機での実行説明を踏まえ、Simulatorの結果だけをすべての端末や公開審査の代替にしないでください。
テスト責任者：受け入れ証跡の整備
試行結果は「成功」の一語でまとめず、確認した対象と制約をひも付けます。プロジェクト、プラットフォーム、スキーム、XcodeとSDKの情報、テスト結果、ビルドログを同じ記録にまとめれば、切り替え判断の根拠を後から追えます。
テストに合格しても、Archiveの生成、配布用署名、App Store Connectへのアップロードは別工程です。証明書と署名の扱いはAppleの証明書概要で確認し、ベータ配布やリリースの作業はAppleのアプリ配布説明と照合してください。
リリース担当者：Archiveからアップロードまでの確認
本番と同じ構成でArchiveを作成し、署名、必要な処理、アップロードを順に確認します。ビルド成功、Archive生成、アップロード受け入れ、審査通過はそれぞれ異なる状態です。一つの成功をもって公開経路全体が合格したとは扱わないでください。
App Store Connect側の処理状態とエラーも保存し、アップロードが受け入れられたことを確認します。提出データの扱いはAppleのビルドアップロード手順で確認できます。記録には使用した構成、Archiveの識別情報、署名状況、アップロード結果を含め、再試行時に差分を追えるようにします。
Runnerラベルを更新しただけでは、実際にその環境のXcodeが選択され、期待するSDKでビルドされたとは限りません。ラベル、実行ログ、生成物、App Store Connect側の状態をひと続きの証跡として照合してください。
プラットフォーム責任者：段階切り替えの判断
複数のAppleプラットフォームを扱う場合は、対象SDKと公開経路をプロジェクト単位で記録し、試行の結果に応じて移行範囲を決めます。全プロジェクトに同じ日程を割り当てるのではなく、各チームのリリース予定と検証済みの証拠をもとに調整してください。
- 試行環境でXcode、SDK、ビルド設定を確認でき、対象テストも完了した場合は、そのプロジェクトを段階的な切り替え候補にします。
- コンパイルは通るものの、Archive、署名、アップロードのどれかが未確認なら、本番切り替えを保留し、その工程の検証を追加します。
- 依存関係やスクリプトで再現性のある失敗が出た場合は、原因と回避策が記録されるまで旧ツールチェーンの経路を維持します。
- App Store Connectへ提出しないジョブは、要件対象の公開経路と分離して扱い、不要な一斉更新を避けます。
チームの切り替え計画には、プロジェクト責任者、試行結果、未解決の問題、再確認の条件を記載します。汎用的な所要時間や成功率を当てはめず、実際のリリース予定と試行結果から判断してください。
次の一手：隔離環境で証跡をそろえる
WindowsやLinuxだけのCIでは、Apple向けのXcodeビルド、Archive、署名を含む公開工程をそのまま完結できません。共有ホスト型の実行環境はツールチェーンの選択や永続的な状態の管理に制約が出る場合があり、専用Macの購入では初期費用と保守が継続します。短期間の試行や公開経路の検証なら、実機のmacOS環境を使うリモートMacのレンタルも比較対象になります。
まず隔離されたMacで対象プロジェクトを動かし、XcodeとSDKの実行記録、テスト、Archive、署名、アップロード結果をそろえてから、長期運用に必要な環境を判断してください。利用可能な環境の確認にはVPSMACのMac構成案内、リモートMacを使う開発方法の入口にはVPSMACの案内ページを参照できます。物理接続が必要な作業や、長期の安定した高負荷運用では、レンタルが適するとは限らないため、自社保有を含めて比較してください。