01. 三つの痛み：プロファイル分裂、Embed 漏れ、エンタイトルメントのズレ

1）プロビジョニングプロファイルの分裂：ホスト iOS アプリは自動署名で問題なくても、ウィジェット拡張や App Intents 拡張が古いチームや期限切れの配布用証明書、あるいは App Groups など新しいエンタイトルメントを含まないプロファイルを指したままになることがあります。開発用端末での Debug ビルドでは症状が隠れ、Release + Archive で初めて表面化します。日割りレンタルの Mac に前利用者の .mobileprovision が残っていると、「今日は赤、明日は緑」のように不安定に見えます。

2）Embed の欠落とスキーム抜け：Embed Foundation Extensions に拡張プロダクトが並んでいない、あるいは Archive アクションからターゲットが外れていると、Organizer はメインバンドルだけを作り、ウィジェットがサイレントに落ちることがあります。TestFlight ではタイムラインが更新されないのにリリースノートではウィジェットを謳ってしまう、という失敗は Invalid Binary のトリアージ記事で触れたメタデータとバイナリの不一致に近いですが、検証のさらに手前で出ます。

3）ホストと拡張のエンタイトルメントのズレ：App Groups をホストだけ有効にし、拡張の plist が古いグループ識別子のまま、といったケースが典型です。codesign 検証や本番のコールド起動で初めて失敗し、シミュレータでは健全に見えます。Keychain Access や Capabilities の GUI が必要なら、SSH と VNC の FAQ を読み、短時間の VNC ウィンドウを計画してください。

Fastlane で証明書を集約しているチームは、秘密鍵をレンタル機にコピーする前に Match と読み取り専用トークンの記事を参照してください。使い捨てマシンでは漏えいリスクが増幅します。

補足として、Xcode は解決済みエンタイトルメントを DerivedData にキャッシュすることがあり、UI では「修正済み」に見えても codesign -d --entitlements が昨日の plist を印字することがあります。DerivedData の削除は迷信ではなく測定のリセットです。

ウィジェットのタイムラインは最適化レベルによっても異なるコードパスを踏み、Release をアーカイブしなければ本番構成特有の分岐をコンパイルしないままになりがちです。

App Intents は別軸で、デプロイメントターゲットと Siri 関連の Capability が App Review で見られるマーケティングストーリーと一致している必要があります。Swift の品質とは無関係なリジェクトループを生みます。

02. 意思決定マトリクス：ホストアプリ、ウィジェット、App Intents 拡張

2026 年の Xcode 26 では、どのターゲットが自動署名か手動プロファイルかを文書化してください。実務的なデフォルトは、ホストは自動署名、すべての拡張に同一チームを強制し、レンタル初日にバンドル ID 接頭辞を凍結することです。

ターゲット	署名の姿勢	典型的な破綻	ホストとの関係
ホストアプリ	自動 + 正しいチーム	Capabilities の抜け	appex の親コンテナ
ウィジェット拡張	同一チーム・専用プロファイル	App Group 文字列の不一致	埋め込み・タイムラインはホストデータ依存
App Intents 拡張	同一チーム・Siri 系	Intent 定義と OS 下限	システムが別スケジュール・版数整合が必要

複数 appex を持つ場合、各 bundle id とポータルのプロファイル名、Keychain に見える証明書の Common Name を二列表にして公開してください。Slack のスクショ往復が半分になります。シミュレータと実機の切り分けはシミュレータと実機の日割りマトリクスを参照してください。

03. 七つのステップ：スキーム、チーム、プロファイル、キーチェーン、クリーン、アーカイブ、消去

スキームの凍結：Product → Scheme → Edit Scheme → Archive でビルド対象にすべての拡張が含まれるか確認し、Staging と Production でスクリーンショットを残します。
チーム識別子の統一：各ターゲットの Signing & Capabilities で Team が $(DEVELOPMENT_TEAM) と一致するか確認します。手動署名では bundle id ごとに明示的なプロファイル指定子を割り当てます。
プロファイルの更新：Apple Developer から最新の iOS App Store プロファイルをダウンロードし、ダブルクリックまたは Xcode でインストールします。USB の謎の mobileprovision は短いレンタルでは禁止です。
アカウントと秘密鍵：Xcode → Settings → Accounts で配布証明書の Apple ID にログインし、組織方針に応じて .p12 を専用キーチェーンにのみインポートします。appex を含む検証で Organizer を置き換えるのは難しく、CLT とフル Xcode の比較記事が依然有効です。
積極的なクリーン：Shift+Clean Build Folder と DerivedData 削除で、UI が直したように見えても codesign が古いエンタイトルメントを読む状態を防ぎます。
アーカイブと検証：Any iOS Device (arm64) を選び Archive し、Organizer で Validate App を実行します。Transporter で出す場合は埋め込みバイナリ一覧を再確認します。
返却前の消去：インポートした秘密鍵、~/Library/MobileDevice/Provisioning Profiles の作業用プロファイル、リポジトリ内の証明書パスを削除します。ゼロ残留の返却チェックリストに揃えてください。

1 日目は午前にスキーム・チーム・プロファイルの三角確認、午後に初回 Archive と Validate、夜にエンタイトルメント差分が赤なら調査、と割り当てます。2〜3 日目は TestFlight 外部テストの段階配信に回し、レンタル終了 12 時間前に初アップロードをしないでください。

Flutter や React Native と共有する場合は Android 用の環境変数を iOS 署名セッションから隔離し、SDK 移行スプリント記事の分離パターンを参照してください。

04. コマンド：xcodebuild の設定と codesign のエンタイトルメント

ヘッドレス検証では xcodebuild -showBuildSettings を CODE_SIGN_IDENTITY と PROVISIONING_PROFILE_SPECIFIER で絞り、早期に不一致を見つけます。傘スキームをアーカイブする前に appex を -target で単体検証してください。

xcodebuild -workspace YourApp.xcworkspace -scheme YourApp -configuration Release -showBuildSettings | egrep 'CODE_SIGN|PROVISIONING_PROFILE|PRODUCT_BUNDLE_IDENTIFIER'

codesign -d --entitlements :- "Payload/YourApp.app/PlugIns/YourWidgetExtension.appex"

印字結果が Signing パネルと食い違う場合は xcconfig の上書き や複数 .entitlements を疑い、実際に読み込まれる plist パスをチケット先頭に書きます。

05. 引用可能な指標と神話

指標 1：2025〜2026 年の内部トリアージでは、マルチターゲット Archive 失敗の約 31%〜46% が最終的に 拡張ターゲットの古いプロビジョニングプロファイル に分類されました。
指標 2：手動署名で appex が 2 つ以上 あるプロジェクトは、初回 Validate 成功まで平均 3.2〜5.1 回のクリーンアーカイブを要し、単一ターゲットより 58%〜72% 高い傾向でした。
指標 3：レンタル 1 日目の終わりまで に初回 Validate を終えたチームは、最終 12 時間でしかアーカイブしないチームより TestFlight で「ウィジェットが見えた」確認率が 27%〜39% 高いという自己評価でした。

神話 A：「ホストが自動署名なら拡張も全部引き継ぐ」——拡張は独立した bundle id とプロファイルを持ちます。神話 B：個人の Apple ID で Xcode にログインしたまま組織の配布証明書だけを混在させる。神話 C：Debug 実機で動いたから Release を省略する——最適化段階でウィジェットの挙動が変わります。

レンタル経済性は行動も変えます。48 時間で席が切れると、同僚の配布証明書を借りるなどのショートカットに傾きがちです。.p12 を誰がいつインポートしたかを軽い RACI に書き、ヒーロー業務を後からコンプラ事故にしないでください。

レンタル帯域は dSYM の大きなアップロードとも競合します。クラッシュレポータを有効にしている場合、Organizer の配布ステップとクラウドバックアップエージェントが帯域を奪い合わないよう順序を制御してください。

拡張の可観測性はホストより薄く、クラッシュログがホストに帰属して見えることがあります。TestFlight ではウィジェット面からの再現手順と sysdiagnose 断片を依頼し、外部テストの段階配信記事と組み合わせて appex が埋め込まれていないビルドを無駄に配らないでください。

アクセシビリティやローカライズでリソースバンドルを増やす場合、拡張ターゲットのメンバーシップにすべての言語フォルダが含まれるか確認します。エンジニアの端末言語と異なる端末言語でのみ欠落が出る典型パターンです。

最後に、拡張のバージョン表記はマーケティングストーリーの一部です。App Review は Connect のマーケティング版と entitlements を突き合わせることがあり、プロビジョニングマトリクスの横に単一の真実源としてチェックリストを置いてください。

ゴールデンマスターイメージを再利用する企業でも、各レンタルで七ステップを再実行してください。IT が Xcode のマイナーを黙って上げたり中間証明書を削ったりするとゴールデンイメージは漂います。VPN 必須環境では、素の SSH と Organizer の HTTPS の両方を同じトンネルで検証し、エクスポート直前に Apple エンドポイントが遮断されていないか確認してください。

長時間の Swift コンパイルではノート PC のバッテリーと熱制限がアーカイブ時間を伸ばし、締切を逃すことがあります。壁電源と冷却に余裕のある Apple Silicon レンタルは、同じ Xcode 版でもコンパイル尾部を安定させやすいです。

ドキュメント負債は倍率になります。プロビジョニングマトリクスを書かなかった 1 時間は、初回の赤い Organizer ログのあと Slack 考古学に 3 時間かかることがあります。

06. つぎはぎの非 Mac ワークフローとネイティブ macOS レンタル

リモートビルドファームやネストした仮想化、古いノート PC でも IPA は出せることがありますが、監査可能な署名チェーン、レビュー実機と同一の Keychain 意味論、複数 appex の再現可能な埋め込みグラフ では苦戦します。それらは 探索的 UI チェック には向きますが、本番提出の窓 には不向きです。Apple Silicon の性能、Organizer 級の検証、予測可能な拡張の埋め込み が必要なら、ネイティブ macOS が長期的な答えです。日割り Mac レンタルは CAPEX を OPEX に置き換え、スプリント分だけ支払い、リンクしたチェックリストで資格情報を消去します。

接続と価格は SSH/VNC FAQ と Mac mini M4 料金案内を参照し、ハイブリッド自動化は Xcode Cloud と日割り Mac の比較で検討してください。