Transporter 1.4.5 アップロードがProcessingで止まる：2026年はどう対処する？

Transporter 1.4.5 アップロードがProcessingで止まる：2026年はどう対処する？

Transporterは交付完了なのに、数時間たってもTestFlightにビルドが表示されません。

最短の解決策は、すぐに再送せず、Transporterの交付記録、App Store Connectの受信状態、サーバー処理を分けて確認することです。24時間を超えてProcessingが変わらない場合に、ログを添えてAppleへ問い合わせます。

Transporter 1.4.5 アップロードがProcessingで止まる場合の結論

Transporterの「交付完了」は、ファイルがApple側へ渡ったことを示す段階です。TestFlightで利用できる状態になったこととは別です。Appleは、アップロード後のビルドがApp Store Connect内で処理されると説明しており、Processingが24時間を超えて変化しない場合は問題の可能性があります。Appleのビルドアップロード手順とBuild Upload Statusesの定義を基準に判断してください。

本稿は、TransporterでIPAまたはPKGを送る独立開発者、遠隔Macから発行する小規模チーム、アップロードログと再送基準を整備したい担当者向けです。Xcodeの署名設定や完全なApp Store上架手順ではなく、「送信後に見えない」問題に絞ります。

2026年9月8日に公開されたTransporter 1.4.5のリリースノートは、安定性向上と不具合修正を示しています。ただし、Appleはこの版がProcessing遅延を一般的に引き起こすとは確認していません。Transporter 1.4.5の公式リリースノートだけを根拠に、すべての遅延をクライアントの欠陥と断定することはできません。

3つの状態を分けると、再送の誤判断を防げます

まず、次の三層を別々に記録します。

  • ローカル転送：Transporterがファイルを読み込み、Appleへ送信している段階です。
  • Apple側の受信：Transporterの交付記録やApp Store ConnectのBuild Uploadsに、対象ビルドが登録された段階です。
  • サーバー処理：Appleが署名、メタデータ、バイナリなどを処理し、TestFlightで利用可能にする段階です。

Transporterの画面が閉じた、遠隔Macの画面が切れた、TestFlightに表示されない。この3つだけでは失敗とは判定できません。Appleのビルドとメタデータの表示方法に従い、対象アプリ、プラットフォーム、バージョンを確認します。

状態 先に確認する場所 基本判断
交付処理中、または明確な失敗なし Transporterの履歴、ログ プロセスと通信を確認し、証拠を保存します
交付完了、App Store ConnectでProcessing Build Uploads、通知メール、サービス状況 24時間未満なら待機します
Failed Transporterのエラー、交付ログ 原因を修正してから再送します
24時間超でProcessingが不変 上記すべて 交付IDとログを添えてAppleへ相談します

記録する値は、[VERSION]、[BUILD]、[BUNDLE_ID]、交付時刻、状態の変化、交付IDです。アカウント名、App名、Bundle ID、Team ID、ファイルパス、ログ本文は、共有前に明確なプレースホルダーへ置き換えます。

交付前の失敗と、交付後のProcessingを切り分ける

Transporter側で完了していない場合

交付履歴に「完了」「警告」「失敗」のいずれかが明確に残っているかを見ます。ログイン認証の期限切れ、通信切断、ファイル読み込みエラー、クライアント終了は、サーバー処理の遅延とは別問題です。

遠隔Macのデスクトップ接続が切れただけなら、アップロードプロセスまで終了したとは限りません。SSHで同じ環境へ入り、プロセス、ログ、Transporterの履歴を確認します。

ps aux | grep -i transporter
grep -Ei "complete|warning|failed|processing" "[REDACTED_LOG]"

出力例です。

[REDACTED_TIME] delivery complete
delivery_id=[REDACTED_DELIVERY_ID]
build=[REDACTED_BUILD]

このような記録があれば、画面が消えたことだけを理由に再起動しません。Transporterを再起動したり、別アカウントでログインし直したりする前に、ログを保存し、既存の交付記録を確認します。Appleのアップロード方式では、Transporter以外の方法も案内されていますが、別の送信手段へ切り替えても、Apple側のProcessingを自動的に回避できるわけではありません。Appleのアップロード方法は、クライアント障害の切り分けに使う資料として扱います。

交付完了後にTestFlightへ現れない場合

Transporterで交付完了と表示されたのに、TestFlightにビルドがない場合はどうするべきでしょうか。

まず同じビルドを再送せず、Build Uploadsで対象のApp、プラットフォーム、バージョン、[BUILD]を確認します。次に、処理状態、通知メール、Appleのサービス状況を同じ時刻情報で照合します。交付完了はクライアントの送信結果であり、TestFlightでの利用可能状態を意味しません。

Processingが24時間未満なら、状態の画面やログを保存したまま待ちます。24時間を超えて状態が変わらない場合は、交付ID、処理開始時刻、対象ビルド、Transporterログ、画面の記録をそろえ、Appleへの問い合わせへ進みます。AppleのFeedback Assistantも、再現条件と証拠を整理してから利用します。

App Store ConnectのProcessingは、どの時点で異常と考えるべきでしょうか。

本稿で採用する判断線は、Appleが示す24時間です。経験上の「通常は数分」「夜間は遅い」といった目安ではなく、公式の異常判断窓を使います。Processingを理由なくTransporter 1.4.5の不具合へ結び付けることも避けます。

ビルドが消えたように見える原因は、識別子の不一致にもあります

処理遅延ではなく、別のAppや別のチームを見ているケースもあります。Archiveまたは交付ログの最終値と、App Store Connectで開いている対象を次の順で照合します。

  1. Bundle IDが対象Appの登録値と一致しているか確認します。
  2. [VERSION]と[BUILD]をArchiveの値と照合します。
  3. iOS、macOSなど、プラットフォームの表示を確認します。
  4. App Store Connectへログインしているチームを確認します。
  5. 複数アプリを管理している場合は、App名とApp IDを再確認します。
  6. 交付IDをログとBuild Uploadsの記録で照合します。

同じ名前に見えるアプリでも、Bundle IDやチームが違えば、目的のTestFlightには表示されません。確認用の共有ログには、実際の値を残さず、次のように置き換えます。

app=[REDACTED_APP]
bundle_id=[REDACTED_BUNDLE_ID]
team_id=[REDACTED_TEAM_ID]
version=[REDACTED_VERSION]
build=[REDACTED_BUILD]
delivery_id=[REDACTED_DELIVERY_ID]

待機、修正、再送、問い合わせを分ける判断基準

Processing中に同じ構築物をすぐ再送することは、最初の選択肢にしません。App Store Connect側に受信記録があるなら、重複した作業で証拠を隠さないことが重要です。

Processing中に同じBuild stringを再アップロードしてもよいでしょうか。

Processing中は、まず待機と記録を優先します。同じBuild stringを再利用できるか、また再送が必要かは、現在の状態とAppleの案内に依存します。ProcessingをFailedと同じ扱いにせず、明確なFailed表示がない限り、別ビルドの作成や再送を急がないでください。

判断は次の4分岐に分けます。

  • Processingかつ24時間未満：ログ、交付ID、画面を保存して待機します。
  • Failed：エラー原因を修正し、再送条件を確認します。
  • ローカル転送が未完了：ネットワーク、認証、ファイル読み込み、プロセス終了を修復します。
  • Processingが24時間を超えて不変：証拠を添えてAppleへ相談します。

Xcode、Transporter、コマンドライン、CIツールを切り替える作業は、クライアント側の問題を分離するためのものです。送信経路を変えても、Apple側の非同期処理が正常化する保証にはなりません。

遠隔Macを発行環境にする場合の最終確認

遠隔Macでは、デスクトップの表示よりもプロセスとログを基準にします。接続が切れた後に再接続し、次の順で同じ脱敏済みの構築物を確認します。

  1. IPAまたはPKGのファイルハッシュを記録します。
  2. Transporterの交付履歴とログを保存します。
  3. App Store ConnectのBuild Uploadsで対象ビルドを確認します。
  4. Processing、Failed、Completeなどの状態変化を時刻付きで記録します。
  5. TestFlightで対象ビルドの可視性を確認します。
  6. セッション切断後もプロセスが完了したか、再接続後に検証します。

Apple App Store Connectの通知を自動化する場合は、App Store Connect Webhooksの公式説明も参照できます。ログを常時残す設計、SSH切断後も処理を継続できる実行方法、交付IDの保存を組み合わせると、画面表示だけに依存しない運用になります。

個人PCがスリープする、回線が切り替わる、ログを長期保存できないという問題が多い場合は、遠隔Macの利用環境を一度の実案件で検証する方法があります。継続運用を検討する場合は、Mac miniレンタルの案内も比較対象になります。ただし、物理機器への直接アクセスや長期間の高負荷処理が必須なら、自前のMacの方が適する場合もあります。

Transporter 1.4.5でProcessingになったときの判断は、クライアントの表示だけでは決まりません。ローカル転送が未完了なら復旧、Failedなら原因修正後に再送、交付完了後のProcessingなら24時間を基準に保留し、超過後にAppleへ相談します。遠隔Macを使う場合も、接続の見た目ではなく、交付記録、状態変化、TestFlightの可視性まで一つの発行チェーンとして確認することが重要です。