Appleの案内上、Xcode 27.2 RCと対応SDKを使ってビルドしたAppはApp Storeへアップロードできます。ここで確認できるのは、指定のツールチェーンで作成したビルドを提出先へ送れるという点です。あなたのプロジェクトが正しくビルドできたか、審査を通るかまでは保証されません。

提出前には、Mac上で実際に選択されているXcodeを確認します。複数のXcodeをインストールしている環境では、GUIで見ているものとコマンドラインで使われるものが異なる場合があります。xcodebuild -versionとxcodebuild -showsdksを実行し、記録した結果が対象のRCとSDKを示しているか確かめてください。

次に、Xcode Archiveが目的のApp、構成、署名で作成されたものかを見ます。アーカイブを作ったツールチェーンと、アップロード作業に使った環境が一致するかも記録しましょう。Appleのビルドアップロード手順に沿ってアップロードしても、App Store Connectでの受け付けだけをリリース可否の根拠にはできません。

RCビルドはTestFlightの内部テストと外部テストに利用できます。ただし、アップロード後に処理が完了していること、対象のテスターに配布できる状態であることは、App Store Connectで個別に確認します。TestFlightでの検証結果と、App Storeで正式公開する判断も分けてください。

• 内部テストでは、対象ビルドを適切なテスト担当者へ割り当てられるかを確認します。Appleのビルドへのテスター追加手順を見ながら、配布対象を照合してください。
• 外部テストでは、外部テスター向けの配布条件とビルドの状態を確認します。必要な設定は、Appleの外部テスター招待ガイドで照合できます。
• テストで問題が出なかった場合も、正式公開を自動的に決めないでください。RCでの検証結果、リリース対象のビルド、安定版へ戻す手順を別々に判断します。

TestFlightへアップロードできたことと、テスターがそのビルドを利用できることは同じではありません。App Store Connectに表示される処理状態と配布資格を見てから、テスト担当者へ案内してください。

本番で使っている安定版のツールチェーンがすでに検証済みなら、RCを試すためにその経路を置き換える必要はありません。独立したブランチ、または分離したビルド環境で代表的なプロジェクトをArchiveし、アップロードまで追跡します。

この分離には、問題が起きたときに既存のリリース手順を保てる利点があります。一方で、RC専用の設定や環境を管理する手間は増えます。RCでの確認を優先するか、既存の安定性を優先するかは、次の条件で決めてください。

• RCでの検証が必要で、失敗時に安定版へ切り替えられるなら、分離環境で検証を進めます。
• テスト期間が足りない、または本番の署名・依存関係を確認できていないなら、正式リリースには安定版の経路を残します。
• TestFlightだけで評価したいなら、RCビルドはテスト用途に限定し、その結果だけで正式版を公開しません。

審査へ進む操作はアップロードとは別です。Appleの審査提出手順を確認し、処理完了後に提出可能な状態か、App情報や提出内容に未確認の項目がないかを確かめてください。

遠隔デスクトップへ接続できることや、ビルドコマンドがエラーなく終了したことだけでは、提出用環境の検証は終わりません。実際に実行されたXcode、SDK、プロジェクト設定、署名方式を確認し、作成されたArchiveが対象のRCから生成されたものだと追跡できる状態にします。

たとえば、手元の画面ではRCを選んだつもりでも、ビルドスクリプトが別のXcodeを参照していれば、提出物の由来を取り違えるおそれがあります。ビルドログにXcodeのバージョンとSDKを残し、Archiveの識別情報、アップロード結果、App Store Connectの処理状態をひと続きで確認してください。Appleのアップロード状態の説明は、状態表示を読む際の照合先になります。

代表的なArchiveで確認する手順

1. 実行環境を記録します。 ビルドを実行するMacで、選択中のXcodeと利用可能なSDKを確認します。
2. プロジェクト設定を照合します。 ビルド構成、Bundle ID、署名チーム、配布先が目的のAppと一致するかを確認します。
3. Archiveを作成します。 対象のRCを使って、リリースに近い代表的な構成でArchiveします。
4. 生成物を検査します。 Archiveのアプリ識別情報、署名、対象構成をチェックし、成果物が今回のビルドに対応することを記録します。
5. 提出先へアップロードします。 App Store向けかTestFlight向けかを取り違えず、アップロード結果を保存します。
6. 処理と配布状態を確認します。 App Store Connectでビルド処理が完了したか、予定するテストまたは審査提出に進めるかを確認します。
7. 切り戻し経路を残します。 RCで問題が見つかった場合に安定版へ戻せるよう、既存の本番ビルド手順を維持します。

次のチェックリストを使い、アップロード資格だけで公開を決めていないか確認してください。

• [ ] 実際にビルドを実行したXcodeとSDKが、Xcode 27.2 RCと対応SDKであると確認しました。
• [ ] ArchiveのApp識別情報、署名、ビルド構成が目的の提出物と一致しています。
• [ ] App Store Connectでアップロード後の処理状態を確認しました。
• [ ] TestFlightの場合、対象の内部または外部テスターへ配布できる状態か確認しました。
• [ ] 正式版の場合、実際のプロジェクトテストと審査提出に必要な情報を確認しました。
• [ ] 問題が出たときに安定版のリリース経路へ戻せる状態を維持しています。

すべて確認でき、RCを使う理由と切り戻し方法が明確なら、目的に応じてTestFlight検証またはApp Store提出へ進めます。処理状態が未確定なら、テスターへの案内や審査提出を急がず、App Store Connectの表示を再確認してください。プロジェクトのテストが済んでいない場合は、RCを検証用途にとどめる判断が安全です。

Xcode 27.2 RCのAppはApp Storeへ提出できますか？

はい。AppleのApp Store Connect更新情報では、Xcode 27.2 RCと対応SDKでビルドしたAppをApp Storeへアップロードできると案内されています。ただし、これはアップロード資格の確認です。提出前にArchiveの内容、署名、アップロード先を確認し、処理完了後に審査へ進める状態かを別途確認してください。

TestFlightの外部テストにも使えますか？

Appleの案内では、対象ビルドをTestFlightの内部・外部テストに利用できます。アップロード後はApp Store Connectでビルドの処理状態を確認し、外部テストに必要な資格や配布先の設定を確認してください。アップロードが成功した時点で、テスターに配布できる状態になったとは限りません。

App Store Connectが受け付けた後、何を見ればよいですか？

まずビルドの処理状態を確認し、App Store提出またはTestFlight配布に使える状態かを見ます。そのうえで署名、配布先、プロジェクトのテスト結果を照合してください。審査へ進む場合は、アプリ情報や提出内容も確認してから別途審査に提出します。

アップロードに成功すれば、審査も通過していますか？

いいえ。アップロードの受け付け、ビルドの処理完了、審査への提出、審査結果は別々の段階です。アップロード成功だけを根拠に公開可能と判断せず、App Store Connectで処理状況を確認したうえで、審査の提出状態と結果を個別に追ってください。

本番用Macを購入して専用のビルド機にすると、初期購入に加えて保守や空き時間の管理が必要です。安定した高頻度ビルドを長く続けるなら自前環境が合う場合もありますが、RCの受け入れ確認のような一時的な作業では、専用機を維持する負担が先に立つことがあります。

macOS上でXcode 27.2 RCを試し、Archiveからアップロードまで実環境で確かめたいなら、遠隔Macを使う方法も選択肢です。物理機器への直接接続が必須の場合や、長期間にわたり高負荷で運用する場合は自前のMacも比較してください。購入案も比較したい場合は、日本でMac mini M4を購入する際の情報を確認できます。作業期間に合わせた環境を検討するなら、KVMNODEのMac環境を確認し、実際のプロジェクトで提出経路を検証してください。