Xamarin／.NETのiOS配布で出る「Unable to validate archive」完全解決ガイド｜Transporter・アプリ用パスワード・証明書チェックでVisual Studioの公開失敗を突破する方法

Xamarin／.NET で iOS の IPA を App Store Connect に上げると「Publishing Failed – Unable to validate archive（アーカイブを検証できません）」で止まり、詳細が掴めない――そんな状況から最短で抜け出すための実践ガイドです。まずは“通る”ワークフローを提示し、その後に原因別の深掘り、Transporter のログの読み方、チェックリストまでまとめてあります。Visual Studio からの直送が難しい場合でも、ここに沿えば高い確率で突破できます。

症状と背景

Visual Studio（Windows／Mac、Xamarin／.NET 6/7/8）で Archive → Distribute を実行し、App Store Connect へ公開しようとすると、ダイアログに 「Publishing Failed – Unable to validate archive」 の一行だけが表示され、原因の特定ができないケースがあります。これは Visual Studio 側で詳細な検証ログが十分に提示されないことがあり、実際の失敗理由（パスワード、プロビジョニング、アイコン不足、ビルド番号重複、Entitlements など）が隠れてしまうためです。

解決のコツは、「アップロード経路を切り替えて詳細ログを得る」「iOS 配布の前提条件を機械的に潰す」の二点。以下で再現性の高い順に手順と対処を整理します。

最短解決ルート（まずはこれだけ）

環境を最新化：macOS、Xcode、Visual Studio、Xamarin.iOS（.NET for iOS）を更新。古いツールチェーンは証明書チェーン更新や検証仕様変更に追従できず失敗しがちです。
Release/App Store 用で IPA を再アーカイブ：構成が Debug や Ad Hoc になっていないかを確認。
Build Number（CFBundleVersion）を必ずインクリメント：前回と同じだと検証で弾かれやすいです。
Apple ID の App‑Specific Password（アプリ用パスワード）を新規発行：テキストエディタに一度貼って余計な空白や改行が混ざっていないか確認。
Transporter（Mac App）で IPA をアップロード：失敗したら Delivery Logs で具体的なメッセージを確認し、該当箇所を修正。
App Store Connect のビルド受信を確認：受信後は TestFlight 配信または提出へ進む。

原因別の解決策（俯瞰）

分類	具体的な対処	補足説明
アップロード方法の切り替え	Visual Studio ではなく Apple Transporter または Xcode Organizer で IPA を送信	Transporter は詳細ログが見られ、同じ IPA でも通ることが多い。Xcode Organizer は Validate App で事前検証が可能。
App‑Specific Password	新しく発行するクリップボード経由の文字化け・空白混入を防ぐためプレーンテキスト編集で貼り付け確認	Apple ID の通常パスワード変更後は既存のアプリ用パスワードが自動失効。連続失敗時は真っ先に再発行。
プロビジョニング & 証明書	App Store 配布用プロファイルを選択Team／Bundle ID／Entitlements が一致期限切れやチーム切替の影響を確認	Development/Ad Hoc の誤選択、Entitlements 不一致（Push、iCloud 等）が定番の落とし穴。
ビルド番号・バージョン	`CFBundleVersion` を毎回増やす。`CFBundleShortVersionString` の整合も確認。	同一ビルド番号や逆戻り（ダウングレード）は検証失敗の原因。
アプリアイコン／リソース	すべてのサイズを Asset Catalog に用意し、`CFBundleIconName` が実体と一致	足りない解像度が一つでもあると検証エラー。1024×1024 の App Store 用アイコンも必須。
IDE／SDK のバージョン	最新の Visual Studio、Xamarin.iOS（または .NET for iOS）と Xcode に更新	過去の仕様変更（証明書チェーン、検証ルール）に古い IDE が追随できず失敗することがある。

詳細ガイド：各項目の詰め方

Transporter／Xcode Organizer でのアップロード

Transporter：IPA をドラッグ＆ドロップ → Apple ID と App‑Specific Password を入力 → Deliver。失敗時は View Logs（Delivery Logs）でテキストログを開き、原因箇所を特定します。
Xcode Organizer（代替）：Xcode で作った .xcarchive がある場合、Distribute App → App Store Connect → Upload。Validate App を挟むと検証だけ先に実行できます。

Visual Studio からの直送で失敗し、Transporter では通る――というのは珍しくありません。まずは 経路を切り替えて詳細ログを得ることが近道です。

App‑Specific Password（アプリ用パスワード）の注意点

Apple ID の「サインインとセキュリティ」→「App‑Specific Passwords」で新規作成。説明ラベルは任意で構いません。
発行直後にメモ帳などのプレーンテキストへ貼り付け、末尾に改行や全角スペースが混ざらないよう確認。
パスワードを キーチェーンや VS の資格情報に保存している場合、古いものが参照され続けることがあるため、削除→入れ直しが有効です。
通常パスワードを変更したら、既存のアプリ用パスワードは自動失効します。連鎖的に失敗する典型パターンです。

プロビジョニングプロファイル／証明書の整合性

次の順で確認するとミスに気づきやすくなります。

種類の一致：iOS App Development／Ad Hoc／App Store のうち、配布は必ず App Store を選びます。
チーム／Bundle ID の一致：複数チームに所属していると別の Team ID で署名しがちです。com.example.app のような Bundle ID も一致必須。
Entitlements の一致：Push（aps-environment）、iCloud、Sign In with Apple、Keychain など、プロファイル側に「有効化」されていないと Provisioning Profile does not match entitlements で落ちます。
期限：証明書（Distribution）やプロファイルの期限切れ。自動更新されないものもあるため、疑わしければ再発行が手っ取り早いです。

ビルド番号とバージョンのルール

CFBundleVersion（Build Number）は毎回インクリメント（例：100 → 101）。
CFBundleShortVersionString（Version）はセマンティックに昇順（例：1.3.2 → 1.3.3）。
同じバージョン＋ビルドで再提出すると、duplicate 扱いで検証失敗や処理待ちのままになることがあります。

&lt;key&gt;CFBundleShortVersionString&lt;/key&gt;
&lt;string&gt;1.4.0&lt;/string&gt;
&lt;key&gt;CFBundleVersion&lt;/key&gt;
&lt;string&gt;104&lt;/string&gt;

アプリアイコン／起動画面（Launch Screen）

Asset Catalog の AppIcon に iPhone／iPad 全サイズが揃っているか。
1024×1024 の App Store 用アイコン（透明不可）を忘れがちです。
CFBundleIconName が Asset 名（通常は AppIcon）と一致しているか。
古い LaunchImage ベースは非推奨。Storyboard 方式（LaunchScreen.storyboard）にしておくと審査前の警告を減らせます。

アーキテクチャ／Bitcode／リンカ

Arm64 のみ：App Store は 32bit を受け付けません。i386/armv7 を含めない設定にします。
Bitcode 無効：現在の iOS 配布では Bitcode は不要です。Xamarin でも「Enable Bitcode = No（False）」にしておくと不要なエラーを避けられます。
リンカ設定：Xamarin の Linker behavior は「Link Framework SDKs Only」から始め、Native Bindings を多用している場合は除外アセンブリを追加（AOT 最適化時の欠落防止）。

Info.plist／ビルド設定の見直し

CFBundleIdentifier がプロファイルの App ID と完全一致。
MinimumOSVersion（Deployment Target）を実機・フレームワーク要件と矛盾させない。
ローカライズ済みの Display Name（CFBundleDisplayName）が長すぎて切れないか。
外部フレームワークやリソースに日本語名や全角スペースが混在すると、まれにパス解決で失敗することがあります。ASCII のみを推奨。

Transporter のログを読み解く

Delivery Logs の代表的な行と原因・対処をひと目で分かるよう整理しました。

ログ抜粋（例）	原因	対処
`ERROR ITMS-90161: "Invalid Provisioning Profile."`	プロファイルの種類・期限・Entitlements 不一致	App Store 配布用に切替／再発行。Entitlements（Push 等）を含める。
`ERROR ITMS-90164: "Invalid Code Signing Entitlements."`	ビルドの entitlements とプロファイルが噛み合っていない	`aps-environment` 等を確認。不要なら削除、有効化するならプロファイル側も更新。
`ERROR ITMS-90189: "Invalid Icon."`	アイコン欠落／透過付き／サイズ不一致	1024×1024（非透過）を含む全サイズを Asset に追加。`CFBundleIconName` を確認。
`ERROR ITMS-90124: "The binary is invalid."`	アーキテクチャや Bitcode、署名全般	Arm64 のみ、Bitcode 無効、配布署名を再確認。サードパーティの静的／動的ライブラリも点検。
`ERROR ITMS-90158: "Invalid Bundle. The value for key CFBundleVersion is invalid."`	ビルド番号が同一／逆戻り／形式不正	整数でインクリメント。過去に存在する値を避ける。
`Authentication failed because of invalid credentials`	App‑Specific Password の失効／コピーミス	アプリ用パスワードを新規発行し、プレーンテキストで貼り付け確認。

Visual Studio から“直接アップロード”したい場合の見直し

アカウント資格情報：古い Apple ID キャッシュを削除して再保存。二要素認証利用時は必ずアプリ用パスワードを設定。
アーカイブ構成：Release／iPhone／App Store を選択。Ad Hoc と取り違えない。
署名構成：Automatic が不安定なら Manual に切り替え、証明書とプロファイルを明示。
クリーンビルド：bin/obj の残骸で署名断片が残ることがあります。キャッシュ削除→再ビルド。
dSYM／オンデマンドリソース：サイズや配置が異常だと失敗要因に。最小構成で一度通すのも有効です。

よくある落とし穴と回避策

チーム切り替えの影響：企業アカウントに招待された直後は無効化されたプロファイルが混在します。手元のキーチェーン／VS の証明書一覧を整理。
複数ターゲット／拡張（Notification Service、Share Extension など）：各ターゲットに個別の Bundle ID、プロファイル、Entitlements が必要。ひとつでも欠けると全体が失敗。
Embedded Frameworks：動的フレームワークの埋め込み・署名設定（Xcode なら Embed & Sign）。Xamarin の Native References でも扱いを確認。
シンボルファイル：dSYM の生成をオフにしているとクラッシュ解析で困るだけでなく、ビルド工程で不整合が出ることがあります。基本はオン。
アセットの命名：@2x/@3x の取り違えや PNG ではない形式（JPEG）混在に注意。

チェックリスト（送信前の最終確認）

CFBundleIdentifier がプロファイルの App ID と完全一致している
CFBundleVersion を前回より大きい整数に更新した
CFBundleShortVersionString が昇順（セマンティック）になっている
App Store 配布用のプロファイル／Distribution 証明書で署名している
Push／iCloud 等の Entitlements がプロファイルと一致している
Asset Catalog の AppIcon がすべて埋まっており 1024×1024 も用意した
CFBundleIconName と Asset 名が一致している
アーキテクチャは Arm64 のみ、Bitcode は無効
日本語や全角スペースのパス／ファイル名がビルドに混ざっていない
Apple ID のアプリ用パスワードを“新規発行”して使っている（改行・空白なし）
Transporter で Delivery Logs を確認し、エラーが残っていない

ケーススタディ（再現性の高いワークフロー）

最新環境へ更新：macOS／Xcode／Visual Studio／Xamarin.iOS（.NET for iOS）をアップデート。
IPA をアーカイブ：Release／iPhone／App Store でアーカイブ。
ビルド番号を増やす：Info.plist の CFBundleVersion を前回より大きい整数に。
アプリ用パスワードを生成：Apple ID の管理ページ → App‑Specific Passwords →「＋」で発行。プレーンテキストへ貼り付けチェック。
Transporter でアップロード：IPA を投入 → Apple ID とアプリ用パスワードを入力 → Deliver。エラー時は Delivery Logs の行番号・項目名で修正箇所を特定。
App Store Connect で受信確認：ビルドが取込済みになったら TestFlight へ流すか、メタデータを整えて提出へ。

トラブル別の即応表（クイックリファレンス）

現象	まず疑うポイント	一手目
VS だけ落ちる／Transporter は通る	VS 側の資格情報キャッシュ、古い SDK	アプリ用パスワードを再発行し直入力、VS と Xamarin.iOS を更新
Authentication 失敗	無効化されたアプリ用パスワード	新規発行 → テキストで貼付確認 → 再入力
Invalid Provisioning Profile	種類／Entitlements／期限	App Store 用に再作成、Entitlements 一致確認
Invalid Icon	1024 アイコン不足／透過／名前不一致	Asset を埋め直し、`CFBundleIconName` を `AppIcon` に統一
Binary is invalid	アーキテクチャ／Bitcode／署名	Arm64 のみ、Bitcode 無効、署名を配布用に固定

CI/CD（Azure Pipelines／GitHub Actions）での注意

秘密情報の分離：App‑Specific Password は Secure File／Secret Variables に保存し、ログへ出力しない。
ビルド番号の自動化：パイプライン番号やコミット数で CFBundleVersion を自動インクリメントして重複を防止。
署名の安定化：証明書／プロファイルをキーチェーンにインポートしてからビルドし、codesign の出力を必ずログ保存。
Transporter CLI の活用：GUI でなく CLI（xcrun iTMSTransporter）でも Delivery Logs を取得でき、原因追跡に向きます。

FAQ

Q. Visual Studio からのアップロードを続けたいのですが？
A. 可能です。ただしエラー原因の切り分けは Transporter が圧倒的に速いので、まずはそちらで通してから VS の設定（資格情報・署名・構成）を合わせ直すのが効率的です。

Q. 以前は通ったのに突然失敗します。
A. Apple ID の通常パスワード変更→アプリ用パスワード失効、証明書の期限切れ、Xcode の更新に伴う検証仕様変化が主因です。まずはアプリ用パスワードを再発行、次にプロファイルと証明書を再作成してみてください。

Q. 同じエラーでも Transporter のログに別の文言が出ます。
A. VS の「Unable to validate archive」は包括エラーです。Transporter の ITMS‑9xxxx などの具体的なコードで対処を決めましょう。

まとめ

Transporter に切り替えるだけで通るケースが多く、詳細ログで原因が即判明します。
いちばん多い原因はアプリ用パスワードの無効化／コピーミス。次点でプロファイル・証明書の不一致、Build Number 未更新、アイコン欠落です。
Visual Studio から直接アップロードしたい場合でも、上記のチェックを一巡させてから再試行すると成功率が大きく上がります。

付録：トラブルシューティングの深掘りポイント

Entitlements の具体例

Push：aps-environment（development／production）。本番配布では production。
iCloud：容器 ID と権限の整合。不要なら無効化して差分を減らす。
Keychain Sharing：グループ識別子の表記ゆれに注意。

サードパーティ SDK／フレームワーク

静的ライブラリ（.a）とヘッダのバージョン不整合が署名時に露呈することがあります。依存バージョンを固定。
動的フレームワーク（.framework）は埋め込みと署名を忘れない。不要なアーキテクチャ（x86_64 シミュレータスライス）が残っていると弾かれます。

ビルドログの保存

VS／msbuild のログを diagnostic レベルで出力し、codesign ステップの引数と結果を保全。再現不可の不具合に強くなります。

この記事の使い方

まずは「最短解決ルート」の 6 ステップを上から順に実行し、Transporter の Delivery Logs で固有のエラーコードを掴んでください。その後、本記事の「詳細ガイド」「クイックリファレンス」「チェックリスト」で該当箇所を潰していけば、Unable to validate archive からの脱出速度は確実に上がります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Xamarin／.NETのiOS配布で出る「Unable to validate archive」完全解決ガイド｜Transporter・アプリ用パスワード・証明書チェックでVisual Studioの公開失敗を突破する方法

症状と背景

最短解決ルート（まずはこれだけ）

原因別の解決策（俯瞰）