Appleは、ビルドがProcessingのまま24時間を超える場合、問題の可能性があるとして問い合わせを案内しています。まずApp Store Connectでビルドの状態と交付記録を確認し、Processingならむやみに再アップロードせず、案内された時間を超えても変化がない場合にAppleへ連絡してください。Failedなら、記録されたエラーを直してから再アップロードを判断します。(Appleのビルドアップロード状態の説明)

この記事は、アップロード後に次の操作を決められず困っている人向けです。
単独で開発とTestFlight配布を担う開発者、リリース状態を整理したい小規模チーム、リモートMac上の自動化を保守する担当者を対象にしています。

まずアップロードと処理の状態を分ける

バイナリの送信が終わったことと、App Store Connectでビルドの処理が完了したことは同じではありません。最初に「Build Uploads」でアップロード状態と交付の進行状況を確認し、続いてTestFlight側に表示されるビルド状態を別に確認します。(ビルドのアップロード方法と状態確認)

見えている状態 何を示すか 次に確認すること
アップロード失敗 送信または検証が完了していない状態です 交付記録に表示されたエラーを保存します
Processing Apple側でビルドを処理中です 送信を繰り返さず、状態とアップロード時刻を記録します
Failed ビルド処理に失敗した状態です 詳細のエラーを確認し、原因を修正してから再送を判断します
Complete アップロード処理が完了した状態です TestFlightのビルド表示と配布条件を別に確認します

「App Store Connectのビルドアップロード状態」を見る際は、画面上の単語だけで成功・失敗を決めないことが大切です。Appleの説明ではアップロードの状態とビルドの状態は異なる観点で示されるため、Build Uploadsの記録とTestFlightのビルド画面を照合してください。(ビルド状態の定義)

アップロード処理がCompleteでも、すべてのテスターがすぐにインストールできるとは限りません。処理完了とテスト配布の準備完了は、別々に確認します。

Processingの待機と問い合わせを判断する

Processingが続く場合は、いつまで待てばよいですか。
Appleの案内では、処理が24時間を超えて続く場合は問題の可能性があるため、Appleへの問い合わせが案内されています。24時間を超えても状態が変わらない場合は、再アップロードを繰り返すのではなく、記録した情報を添えてFeedback Assistantへの報告またはAppleサポートへの連絡に進みます。(Processing状態と問い合わせの案内)

状況 判断 停止条件
Processingで、Appleの案内する時間内 状態を記録して待ちます 状態が変わるか、案内された時間に達した時点で再確認します
Processingが24時間を超えて継続 記録を添えてAppleへ報告・問い合わせします 問い合わせ後は、Apple側の確認を待ち、独自の重複送信を避けます
Failedが表示されている 詳細のエラーを確認し、該当箇所を修正します エラー内容を解消してから再アップロードを判断します
CompleteだがTestFlightで利用できない ビルド表示とテスターへの配布条件を確認します 不足している設定を整え、対象テスターから見えることを確認します

問い合わせ時に説明しやすいよう、アプリのバージョン、ビルド番号、アップロードした時刻、現在の状態をまとめてください。状態が更新されない間に同じ成果物を何度も送ると、どのアップロードを調べているのか分かりにくくなるため、状況が変わるまでは重複した再送を避けます。

App Store Connectの処理が1日以上続いた場合、リモートMacから再送すれば解決しますか。
いいえ。処理がApple側で続いている場合、リモートMacを変更してもApple側の処理時間を短縮したり、状態を直接修正したりはできません。Appleの問い合わせ基準を超えているなら、環境を変えて再送する前に、状態の記録を添えてサポートへ連絡してください。

Failedの記録から再アップロードを決める

Failedになった場合は、まずビルドのアップロード詳細を開き、エラー、警告、情報のうち、具体的に確認できる最初のエラーを見つけます。エラーが示す対象に応じて、ビルド成果物、アップロード時の検証、またはほかの交付要件を切り分けてください。(アップロードしたビルドとメタデータの確認方法)

「iOSアプリのビルド処理失敗」が表示されても、原因を確認せずに設定を広く変更するのは避けます。記録されたエラーと修正内容を対応づけると、再送後に状態が変わった場合にも、何を直した結果なのか追跡できます。

Failedのビルドで使ったbuild numberは再利用できますか。
Appleのビルド状態の説明に従い、Failedとなったアップロードの状態を確認してから判断します。失敗後は問題を解決して再アップロードするのが基本ですが、番号の扱いはビルドがどの状態で失敗したかに関わるため、状態記録とAppleの案内を照合し、番号を変える必要があると確認できた場合にのみ変更してください。(Appleのビルド状態と再アップロードに関する説明)

エラーの説明が明確でない場合は、同じビルドを繰り返し送るのではなく、表示された文面と交付記録を保持して問い合わせます。修正後は、Build Uploadsで新しい送信の状態がどう変わったかを確認し、TestFlightでの表示確認までを別工程として扱います。

Complete後にTestFlightで見えない状態を切り分ける

Completeはアップロード処理の完了を示しますが、テストグループへの配布や個々のテスターの利用可能性までは示しません。ビルドがTestFlightに表示されるか、配布に関する未処理事項がないか、対象グループとテスターの設定が整っているかを順番に確認します。(TestFlightのビルド状態)

確認箇所 見る内容 次の対応
TestFlightのビルド一覧 対象アプリのビルドが表示されているか 表示がなければ、アップロード状態とアプリの関連付けを再確認します
ビルドの状態・未処理事項 配布に進む前に必要な対応が残っていないか 表示された項目を確認してから次へ進みます
テストグループ 対象ビルドがグループに追加されているか 対象グループにビルドを割り当てます
テスターの設定 対象のテスターがグループに含まれているか 招待や追加の手順を確認します

外部テスターに配布する場合は、ビルドがCompleteかだけで判断せず、外部テスターの招待条件も確認してください。Appleの案内では、外部テスターへの招待とビルドへのテスター追加がそれぞれ説明されています。(外部テスターを招待する手順、ビルドにテスターを追加する手順)

アップロードは完了したのにTestFlightでビルドが見つからない場合、何を確認すればよいですか。
まずApp Store Connect上で対象アプリとビルドを確認し、処理状態、未処理事項、テストグループ、テスターの割り当てを順に調べます。Completeという表示だけを根拠に、配布設定も完了したと判断しないでください。

再試行前に証拠をそろえる

再アップロードが必要かを判断する前に、後から同じ状態をたどれる記録を残します。特に自動化されたリリースでは、コマンドの実行結果だけではApple側の処理状態が分からないため、実行記録とApp Store Connectの表示を組み合わせて保管します。

  • [ ] 対象アプリのバージョンとbuild numberを記録します。
  • [ ] アップロードを実行した時刻と、使用したコマンドの結果を保存します。
  • [ ] Build Uploadsに表示された状態と交付記録を控えます。
  • [ ] Failedの場合は、エラーの文面と警告を修正前に保存します。
  • [ ] Completeの場合は、TestFlight上のビルド状態と配布先の設定を確認します。
  • [ ] 再送後は、アップロード状態とテスト可能な状態をそれぞれ確認します。

遠隔MacからTestFlightへアップロードした場合も、Appleへの問い合わせ前に記録を残すべきですか。
はい。リモートMacは、同じmacOSのビルド・アップロード環境を使った再現や、修正後の実行確認に役立ちます。一方で、Apple側の処理待ちを制御するものではないため、問い合わせが必要な状態なら、リモート環境での再実行より先に状態と記録を整理します。

リモートMacを使う範囲と判断のまとめ

問題がローカルのXcode環境、ビルド成果物、またはアップロード手順にあると確認できた場合は、再現可能なmacOS環境で修正後の処理を検証する価値があります。Apple側のProcessingが続いているだけなら、環境を替えても解決策にはなりません。リモートMacでiOSの構築・公開作業を行う運用を検討する場合は、RUVCLOUDの料金案内で利用条件を確認できます。

手元のMacで続ける方法は、既存の環境や物理接続を活用しやすい一方、空き容量の確保、OSやXcode環境の維持、常時稼働の管理を自分で担います。リモートMacは、別のmacOS環境でビルドやアップロードを再現したい場合に選択肢になりますが、長期間の安定した高負荷利用や、手元の物理機器への接続が欠かせない場合は、自前のMacのほうが適することもあります。

TestFlightのビルドがProcessingで止まった場合は、まずApp Store Connectの状態を根拠に、待つ・問い合わせる・修正して再送する・配布設定を確認する、のどれに当たるかを判断します。ローカルの実行環境が原因と分かった段階でリモートMacを試すなら、RUVCLOUDの利用案内を確認し、Apple側の処理遅延と環境側の問題を分けて対応してください。