TestFlightのビルドはアップロードから90日で有効期限が切れ、期限切れになるとテスターはそのビルドをインストールしたり実行したりできなくなります。特定のビルドの90日間を「延長」する方法はありません。テストを続けるには、新しいビルドをアップロードすると、そのビルドに新たな90日間が付与されます。まず最初にすべきことは、ビルド番号を上げた新しいビルドをアップロードし、既存のテスターに配布することです。これはAppleの仕様であり、通常はエスカレーションの必要はありません。
概要
TestFlightのビルドは90日で期限切れになる仕様で、期限切れのビルドは配布できません。AppleのTestFlightページによると、各ビルドはアップロードから90日間のみ有効です。特定のビルドの期限を延長することはできないため、テストを継続するには新しいビルドをアップロードします。新しいビルドには新たな90日間が付与され、既存のテスターはその新しいビルドをインストールできます。内部テストのビルドも90日で期限切れになります。外部テスターに配布する場合は、最初のビルドがBeta App Reviewを通過する必要がありますが、同じバージョンの後続ビルドは多くの場合そのまま配布できます。
TestFlightの90日ルールとは
TestFlightの90日ルールとは、アップロードした各ベータビルドが90日間だけテスターに提供され、その後は自動的に期限切れになるという仕組みです。これは内部テストと外部テストの両方に適用され、期限が切れたビルドはテスターのTestFlightアプリ上で「期限切れ」と表示され、インストールや起動ができなくなります。
重要なのは、これがバグや設定ミスではなく、Appleが定めたベータ配布の期限だという点です。ベータ版は正式リリース前の一時的な配布を目的としているため、Appleは各ビルドに90日という寿命を設けています。したがって、期限切れは「直す」ものではなく、新しいビルドで置き換えるものだと理解するのが正しい捉え方です。
なぜ90日で期限が切れるのか
90日で期限が切れるのは、TestFlightがあくまで一時的なベータテストのための仕組みだからです。Appleはベータ版が無期限に配布され続けることを想定しておらず、各ビルドに明確な有効期間を設けることで、テスターが常に比較的新しいビルドを使う状態を保っています。
この期限はアップロードした日を起点に数えられます。つまり、テスターがいつインストールしたかに関係なく、ビルド自体のアップロードから90日が経過すると期限切れになります。そのため、長期間テストを続けるプロジェクトでは、90日ごとに新しいビルドを用意することが前提となり、それを見越して開発とアップロードの計画を立てておくと安心です。
まず最初にすべきこと
まず最初にすべきことは、ビルド番号を上げた新しいビルドをアップロードすることです。期限切れのビルドを復活させる方法はないため、テストを続ける唯一の確実な手段は、新しいビルドを配布して新たな90日間を得ることです。新しいビルドをアップロードすれば、既存のテスターはそのままそれをインストールできます。
その際、バージョン番号かビルド番号を前のものより大きくする必要があります。Appleは同じバージョンとビルド番号の重複アップロードを受け付けないためです。内部テスターであればアップロードと処理の完了後すぐに利用でき、外部テスターの場合はそのバージョンの最初のビルドがBeta App Reviewを通過してから配布されます。
期限は「延長」できるのか
いいえ、特定のビルドの90日間を延長することはできません。TestFlightには、既存のビルドの有効期限を延ばすボタンや設定は用意されておらず、期限が来たビルドは必ず期限切れになります。これはAppleの仕様であり、回避する方法はありません。
したがって「延長」に相当する操作は、実際には「新しいビルドの配布」です。新しいビルドをアップロードすることで、そのビルドに新たな90日間が与えられ、テストを継続できます。言い換えれば、延長したいのはテスト期間であって特定のビルドではない、と考えると対応が明確になります。古いビルドは期限切れのままで問題なく、テスターは新しいビルドに移行します。
次に確認すること
次に確認すべきは、新しいビルドが正しく配布され、テスターが利用できる状態になっているかどうかです。アップロード後の処理が完了しているか、外部テストの場合はBeta App Reviewを通過しているかを確認します。また、各ビルドの残りの有効日数をApp Store Connectで確認しておくと、次の期限切れを事前に把握できます。
あわせて、テスターが新しいビルドを見つけられているかも確認します。TestFlightアプリで最新ビルドが表示され、インストールできる状態であれば問題ありません。もし表示されない場合は、テスターが正しいグループに含まれているか、招待が有効かを見直します。これらを確認しておけば、期限切れによるテストの中断を最小限に抑えられます。
エスカレーションが必要な場合
エスカレーション、つまりAppleへの問い合わせが必要になることは、通常はほとんどありません。90日での期限切れは仕様どおりの動作であり、新しいビルドをアップロードすれば解決するため、サポートに連絡する対象ではありません。まず新しいビルドを配布する、という基本の対応でほぼすべての状況に対処できます。
問い合わせが妥当なのは、新しいビルドをアップロードしたのに処理や審査が明らかに長時間止まっている場合など、期限切れとは別の問題が起きているときです。その場合は、まずAppleのシステム状況ページで障害の有無を確認し、それでも解決しなければApp Reviewやサポートに連絡します。期限切れそのものは、待つのではなく新しいビルドで置き換えるのが正解です。
状態の一覧
ビルドの状態を把握すると、次に取るべき行動が明確になります。下の表は、TestFlightでよく見る状態と対応をまとめたものです。
| 状態 | 意味 | 対応 |
|---|---|---|
| 有効（90日以内） | テスターがインストール可能 | そのまま利用する |
| 期限切れ | ビルドが利用不可 | 新しいビルドをアップロードする |
| 処理中 | 新しいビルドを検証中 | 完了まで待つ |
| 審査待ち（外部） | Beta App Reviewの途中 | 承認を待つ |
| 準備完了 | 新しいビルドが配布可能 | テスターに配布する |
表のとおり、期限切れの行だけが「新しいビルドをアップロードする」という対応を必要とします。ほかの状態は待つか、そのまま利用するかのいずれかであり、期限切れが唯一、能動的な置き換えを求める状態だと分かります。
チェックリスト
期限切れへの対応を漏れなく進めるために、短いチェックリストを用意しました。下の項目を順に確認します。
| 確認項目 | 対応 | 完了 |
|---|---|---|
| ビルド番号 | 前より大きい番号で新規アップロードする | [ ] |
| 有効期限 | 各ビルドの残り日数を確認する | [ ] |
| テスターへの配布 | 新しいビルドを配布する | [ ] |
| 外部テスト | 必要ならBeta App Reviewを通す | [ ] |
| セキュリティ | 提出前にビルドをスキャンする | [ ] |
最も重要なのは、期限が切れる前に新しいビルドを用意しておくことです。90日という期限はアップロード日から数えられるため、あらかじめ次のビルドを準備しておけば、テストを止めることなく移行できます。
提出前にスキャンする
新しいビルドをアップロードするのは、セキュリティを見直す良い機会でもあります。期限切れへの対応でビルドを差し替えるたびに、そのビルドが審査で問題を起こさないかを確認しておくと、リジェクトによる余分なやり直しを避けられます。セキュリティやプライバシーの問題は、提出前に見つけるほうがはるかに容易です。
PTKD.comのようなスキャナーは、.ipaを解析し、深刻度順に並べた結果をOWASP MASVSに対応づけて示すため、過剰な権限や平文通信、埋め込まれた秘密情報などを提出前に修正できます。境界を明確にしておくと、PTKDはビルドの期限を延長したり、審査を早めたりはしません。あくまで、差し替えるビルドのセキュリティ面を確認する役割です。
まとめ
- TestFlightのビルドはアップロードから90日で期限切れになり、期限切れのビルドはインストールも実行もできません。
- 特定のビルドの期限を延長する方法はなく、テストを続けるには新しいビルドをアップロードして新たな90日間を得ます。
- まず、ビルド番号を上げた新しいビルドをアップロードし、既存のテスターに配布します。内部テストはすぐ、外部テストは最初のビルドの審査後に利用できます。
- 90日での期限切れは仕様であり、通常エスカレーションは不要です。新しいビルドで置き換えるのが正しい対応です。
- 差し替えのたびにPTKD.comでビルドをスキャンし、セキュリティ上の問題を提出前に取り除きます。
