app-release

アプリのリリース（iOS / watchOS → TestFlight / App Store）

iOS/watchOS アプリを「本番リリースへの準備未着手」の状態から、配布用署名済みビルドが TestFlight で処理される状態まで進めます。難しいのは個々の手順ではありません。リリースの手順が、互いに連携していない 3 つの Web ポータル（Apple Developer、App Store Connect、CloudKit Dashboard）と、CLI の署名に関する複雑な手順にまたがっており、各ゲートに潜むサイレントな失敗は、前のゲートを通過して初めて見つかることです。 一連の作業をエアロックのチェックリストとして扱い、次のゲートに進む前に、各ゲートが確実に閉じていることを確認してください。

使用する場面

iOS または watchOS アプリのリリース、公開、出荷、ビルドの TestFlight への登録、アーカイブとアップロード、CloudKit スキーマの本番環境へのデプロイ、App Privacy や輸出コンプライアンスの設定、配布用署名、または Apple によるアップロード拒否のデバッグ。

ゲート（順番に実行し、次へ進む前に各ゲートを確認してください）

プロジェクトの課題トラッカーで、すべてのゲートを管理してください。ポータルで緑色に表示されているからといって、ゲートが閉じたと決めつけないでください。必ず基になる成果物を確認してください。

1. ゲートを洗い出します。 実際に未完了の項目を列挙します（課題トラッカーを使うか、以下の手順から導き出してください）。TestFlight を妨げるゲートと App Store への申請を妨げるゲートを区別してください。両者は異なります。
2. CloudKit → Production（アプリが CloudKit を使用している場合）。明示的に Deploy Schema Changes を実行するまで、開発環境のインデックスやレコードタイプは本番環境に存在しません。ダッシュボードからデプロイし、本番環境にレコードタイプが表示されることを確認してください。元に戻せない操作です。最初にユーザーの確認を得てください。
3. 輸出コンプライアンス。 TestFlight でビルドごとに確認を求められないよう、配布可能なすべてのターゲット（アプリ本体と Watch アプリの両方）の情報源（例：XcodeGen の project.yml info.properties）に、ITSAppUsesNonExemptEncryption: false を含めてください。
4. App Privacy。 まず、コードを監査して、分析機能、サードパーティ SDK、外部ネットワーク通信の有無を確認します。開発者がユーザーデータにアクセスできない場合（例：データがユーザーのプライベートな CloudKit にのみ保存される場合）は、正確なラベルは Data Not Collected です。App Store Connect で設定してください。Publish は申請時まで行わないでください。
5. プライバシーポリシー + Impressum。 App Store では、ホストされたプライバシーポリシーの URL が必要です。EU またはドイツの事業者には Impressum も必要です。製品サイトにページを追加してデプロイし、プライバシー URL を App Store Connect に貼り付けてください。
6. 署名の監査。 自動署名を使用する場合、Xcode はアーカイブ／エクスポート時に配布証明書と App Store プロファイルを作成します。ポータルで手動作業をする必要はありません。チーム ID と CODE_SIGN_STYLE: Automatic を確認してください。
7. アーカイブ。 Watch アプリを内包する iPhone スキームを -allowProvisioningUpdates とともに xcodebuild archive でアーカイブしてください。（アーカイブには Apple Development で署名します。配布証明書はエクスポートの段階で作成されます。）
8. TestFlight 用にエクスポートしてアップロードします。 app-store-connect メソッド、自動署名、App Store Connect の API key を使用して xcodebuild -exportArchive を実行します。このキーには Admin ロールが必要です。Developer ロールのキーではクラウド署名できず、「Cloud signing permission error / no iOS Distribution cert found」というエラーが発生します。
9. デバイステストを引き継ぎます。 TestFlight での最終確認（処理済みビルドをインストールし、本番環境で実際の機能の一連の流れを試す作業）は、人間がデバイス上で行う必要があります。完了したと主張しないでください。

上記の各ゲートで使用する正確なコマンド、ExportOptions.plist、確認用のワンライナーについては、references/pipeline.md を参照してください。

Apple のエラーが分かりにくく、手順が失敗した場合は、まず references/gotchas.md を読んでください。 実際のリリースで発生したサイレントな失敗（破損した SwiftPM チェックアウト、Developer ロールの API key、CFBundleShortVersionString の不足、iPad の向きに関する 90474）と、それぞれの正確な修正方法をまとめています。

ガードレール（必ず守ること）

• 本番環境で後戻りできない操作を行う前に確認すること：CloudKit の Deploy to Production と App Privacy の Publish。これらは、リリース済みのユーザーや公開される製品ページに影響します。
• 秘密鍵の値は決して表示しないこと。 .p8 キーは ~/.appstoreconnect/ に保管し、使用後は一時コピーをすべて削除してください。
• rm は使わず、必ず trash を使うこと。
• ログイン済みポータルの操作にはブラウザー自動化を使い、Apple の認証情報は決して入力しないこと。 自動化ブラウザーで一度ログインするようユーザーに依頼してください。
• オンデバイスの機能ループテストと、最後の Publish ／審査提出は人間に任せること。
• リリース関連の変更のみを、対象を絞ったコミットに含めること。 無関係なブランチの作業途中の変更をリリースコミットに決して混ぜないでください。

ツールに関する注意事項

• ポータルでの作業（CloudKit Dashboard、App Store Connect、Apple Developer）には、ログイン状態が維持される永続的なブラウザー（browser-mate スキルなど）を使うのが最適です。これにより、ユーザーは一度ログインするだけで、セッションが維持されます。
• ビルド、署名、アップロードなどの負荷の高い作業は GUI のクリック操作ではなく、シェル（xcodebuild）で行ってください。CLI なら進捗バーではなく、実際のエラー出力を確認できます。コンピューター操作や GUI は、本当に必要な手順に限って使ってください。
• 時間のかかる xcodebuild の手順はバックグラウンドで実行し、ARCHIVE SUCCEEDED ／ EXPORT SUCCEEDED ／ Upload succeeded のマーカーをポーリングして確認してください。