WindowsのVisual StudioではMacに接続済みと表示されるのに、.NET MAUI 10のiOSビルドだけが失敗します。

最短の切り分けは、同じ最小プロジェクトをリモートMac本機で先にビルドすることです。本機でも失敗する場合は.NET for iOSワークロードとXcode 26.6を修復し、本機では成功してWindows経由だけ失敗する場合は、Pair to Mac、アカウント、SSH、遠隔SDK、キャッシュを確認します。

最終更新：2026年9月5日。対応状況は、.NET MAUI 10の公式ドキュメント、dotnet/maciosのリリース記録、.NET MAUIの公式リリース記録を基に確認しています。

対象となる担当者

Visual StudioからMacへ接続してiOSアプリを構築する開発者は、接続済みという表示だけで、コンパイルまで成功したと判断しないことが重要です。Mac本機のビルド、Windowsからの遠隔ビルド、署名付きアーカイブは、それぞれ別の成功条件を持ちます。

遠隔Macの構築を管理するDevOps担当者は、ネットワーク、Pair to Mac、SDK、キャッシュを分離して確認します。移行やアップグレードを決める責任者は、単一プロジェクトの失敗なのか、ノード全体の環境漂移なのかを見て、修復、回避、二重環境、再構築を選びます。

失敗証拠の固定

最初に、WindowsとMacの双方から次の情報を同じ時点で保存します。

  • .NET SDKの実際の選択結果
  • MAUIワークロードとワークロードマニフェスト
  • .NET for iOSのリリース系列
  • Xcodeのインストール場所と選択状態
  • xcode-select、DEVELOPER_DIR、IDE側の設定
  • ターゲットフレームワーク、構成、RuntimeIdentifier
  • Pair to Macの接続先、アカウント、ポート
  • 完全なバイナリログと、最初に発生した有効なエラー

.NET MAUI 10.0.100の公開状況や、Xcode 26.6対応として記録されている.NET for iOSの情報は、公式リリース記録で確認できます。ただし、同じ名前のMAUIパッケージがインストールされていても、実際のビルドで選択されるSDKやワークロードが一致するとは限りません。

この段階では、キャッシュ削除、ワークロードの再インストール、鍵の削除を急がないでください。変更前のログ、設定、接続情報が残っていれば、失敗が再現しなくなった場合でも原因を戻って確認できます。

開発者向けのMac本機確認

まず、空の.NET MAUI iOSプロジェクト、または依存関係を最小限にした再現用プロジェクトをリモートMac上で直接ビルドします。ここで確認するのはアプリの機能ではなく、Appleのビルドツール、SDK、ターゲットフレームワークが成立しているかどうかです。

Mac本機でも失敗する場合は、Pair to Macを修正しても解決しません。Xcode 26.6の選択先、.NET for iOSワークロード、SDKの解決結果をそろえ、公式の.NET MAUIトラブルシューティング手順に沿って、最初の有効なエラーから修正します。

逆にMac本機で最小プロジェクトが成功する場合、ツールチェーン全体を再インストールするのは早すぎます。次の段階で、Windows経由の接続と遠隔ビルドに対象を絞ります。

Pair to Mac接続の確認

Pair to Macは、単にMacが一覧に表示される機能ではありません。SSHを使って遠隔のビルドホストを呼び出すため、発見、認証、サービス初期化、SDK利用の各段階を区別する必要があります。Pair to Macの公式説明でも、遠隔ビルドホストとの接続方式とSSH利用が説明されています。

次の順序で確認します。

  • ホスト名またはアドレスが正しいか確認する
  • Windowsから対象ポートへ到達できるか確認する
  • 接続に使うMacのユーザー名が正しいか確認する
  • SSH鍵のパス、権限、対応する公開鍵を確認する
  • Mac側のログインユーザーと、鍵を登録したユーザーが一致するか確認する
  • 空のMAUI iOSプロジェクトで接続後のサービス初期化を確認する

「Macが見つからない」は発見またはネットワークの問題、「認証を繰り返す」はユーザー名や鍵の問題、「接続後にビルドサービスが失敗する」は遠隔SDKやセッション初期化の問題である可能性があります。

Visual Studioに保存されたホスト記録だけが壊れている場合は、対象の接続情報を控え、該当する鍵をバックアップしたうえで対象ホストだけを再登録します。全接続情報や鍵をまとめて削除すると、別プロジェクトの復旧手順まで失われるため、削除は最後の選択肢です。

CI担当者向けの遠隔SDKとキャッシュ

IDEからのビルドとWindowsのコマンドライン、CIからのビルドでは、同じMacを指しているように見えても、アドレス、ユーザー、ポート、SDKディレクトリ、プロジェクト入口が異なることがあります。まず、成功する経路と失敗する経路の環境情報を横並びにします。

MicrosoftのiOSコマンドライン公開手順を基準に、構成とターゲットを固定します。クリーンなクローンから実行し、開発者PCだけに存在する環境変数や、IDEが自動生成した設定をCIの前提にしないことが大切です。

objや遠隔キャッシュが異なるSDK系列から生成されている疑いがある場合だけ、対象プロジェクトに限定してクリーンアップします。全ユーザーのキャッシュやノード全体を消す前に、復元に必要なSDK情報、ログ、接続設定を保存します。

検証経路 成功した場合に分かること 失敗した場合の優先確認 次の判断
Mac本機の最小ビルド Xcodeと.NET for iOSの基礎が成立 Xcode選択、SDK、ワークロード ツールチェーンを修復
WindowsからPair to Mac 接続と遠隔サービスが成立 SSH、ユーザー、鍵、遠隔SDK ノードを維持して接続層を修復
Windowsコマンドライン IDE依存を排した再現性 引数、環境変数、キャッシュ CI設定を固定
署名なしのReleaseビルド コンパイルと構成が成立 ターゲット、依存関係 署名問題と分離
署名付きアーカイブ 公開工程まで成立 証明書、プロファイル、キーチェーン 資格情報を修復

リリース担当者の署名分離

Debugやシミュレーター向けビルドが成功しても、実機向けの署名やアーカイブが成功したことにはなりません。遠隔ビルド成功後に公開だけが失敗する場合は、Pair to Macの問題として扱わず、署名工程を独立させます。

次の順で確認します。

  • 署名IDが対象アプリと一致しているか
  • プロビジョニングプロファイルの対象、チーム、期限が適切か
  • キーチェーンへアクセスする実行ユーザーが想定どおりか
  • RuntimeIdentifierが対象端末や公開方式と一致しているか
  • 遠隔Macから実機または必要なデバイスが見えているか
  • 署名なしコンパイル、最小署名、正式アーカイブの順で成功するか

資格情報を入れ直す前に、どのユーザーセッションでビルドが実行されているかを記録します。GUIログイン時だけ見えるキーチェーンと、CIの非対話セッションから見えるキーチェーンが異なる場合、証明書を再発行しても同じ失敗が続きます。

プラットフォーム責任者の修復判断

判断は、次の状態を別々に記録してから行います。

  • Pair to Macで接続できる
  • Mac本機で最小ビルドが通る
  • Windows経由の遠隔ビルドが通る
  • 署名付き公開タスクが通る

Mac本機も失敗するなら、Xcode 26.6と.NET for iOSワークロードの対応を再確認し、ツールチェーンを修復します。Mac本機は成功し、Windows経由だけが失敗するなら、ノードを残してPair to Mac、SSH、アカウント、遠隔SDKを修復します。

複数のプロジェクトが同じノードで不定期に失敗し、再起動やクリーンビルドでも状態が戻らない場合は、既存ノードの再構築を検討します。ただし、ワークロードとXcodeを固定でき、最小プロジェクト、遠隔ビルド、署名が再現可能なら、全交換よりもバージョン別ノードまたは作業単位のXcode分離が安全です。

再構築前には、署名情報の復旧経路、SSH鍵の再登録方法、プロジェクトの固定バージョン、CIシークレットの保管場所を確認します。最終受け入れでは、切断後の再接続、Mac再起動後の復旧、クリーンなクローンからのビルド、実際の公開タスクまで確認します。

Xcodeの全体選択を変更すると、別プロジェクトや別CIジョブの前提まで変わる場合があります。複数バージョンを運用する場合は、作業単位で選択先を固定するか、役割を分けたノードに隔離してください。

FAQ

FAQでは、接続成功とビルド成功を同一視しないこと、Mac本機とWindows経由の結果を比較すること、署名を最後に独立検証することが共通の判断軸になります。公開Issueに似た症状があっても、環境差が大きいため、最小プロジェクトで再現できるまでは一般的な修正策と断定しません。

現行のMacを長期運用する場合は、リモートMacの料金と利用条件を確認する前に、Xcode選択、ワークロード、署名情報を固定できるかを評価してください。短期の検証や分離ノードが必要なら、RUVCLOUDのMacレンタル申込みを候補にできます。

現在のWindows開発機や共有Macを使い続ける方法は、既存の設定を活用できる一方、Xcodeの全体切り替え、他案件とのキャッシュ混在、再起動後の復旧確認、署名用キーチェーンの共有が負担になりやすい方法です。物理デバイス接続や長期間の高負荷処理が常に必要なら専用実機の購入が適しますが、Xcode 26.6と.NET MAUI 10の組み合わせを隔離して検証したい場合は、完全な権限を持つRUVCLOUDのMacを一時ノードとして使い、Pair to Mac、クリーンビルド、署名の閉じた流れを確認してから正式なCIへ移すのが安全です。