Windows＋Visual Studio（.NET MAUI）環境でも、iOSの新しいビルドを作り直してApp Store Connectへアップロードし、TestFlightで再配布できます。重要なのは「Releaseでアーカイブ」「Apple Distribution＋App Store用プロビジョニングで署名」「アップロード経路を正しく選ぶ」こと。本記事では.ipa作成からTransporter（Windows）利用、`altool exited with code 1`の切り分けまで実務目線で整理します。
まず押さえるべき全体像（WindowsでiOSビルドする時の前提）
結論から言うと、Windows単体でiOSの最終成果物（配布用の署名付き.ipa）を完結させることはできません。iOSのビルド／署名にはAppleのビルドツールが必要で、これらはMac上で動きます。そのためWindowsのVisual Studioは、ネットワーク上のMac（ビルドホスト）に接続して、Mac側でビルド＆署名する形になります。
またTestFlightで配布していたビルドが期限切れになった場合、基本的には新しいビルド（Build番号を増やしたもの）を再アップロードすればOKです。TestFlightのビルドは一定期間で利用できなくなる仕様なので、再アップロードの流れ自体はよくある運用になります。
よくある誤解：Debugで作った.ipaを上げればいい？（→基本NG）
TestFlight／App Store Connectに上げるビルドは「配布（Distribution）」のルールで署名されている必要があります。Debugビルド（開発用署名）で作った.ipaは、TestFlight用としては不適切になりがちです。
| 目的 | 推奨ビルド構成 | 署名（証明書） | プロビジョニングプロファイル | 典型的な用途 |
|---|---|---|---|---|
| 開発中の端末実機テスト | Debug | Apple Development | Development（開発用） | 自分のiPhoneで動作確認 |
| TestFlight（内部/外部テスト） | Release | Apple Distribution | App Store（配布用） | 社内・テスターへ配布 |
| App Store公開 | Release | Apple Distribution | App Store（配布用） | 審査→ストア公開 |
要するに、質問にあった「Apple Developmentでいいのか？」は、TestFlight目的なら基本的にNG（Apple Distributionを使う）が実務上の正解です。
事前チェックリスト（ここが揃っていないと必ず詰まる）
App Store Connect側（アプリの箱）
- 対象アプリのApp Store Connect上のレコードが存在する（過去に作成済みならOK）
- Bundle Identifier（Application ID）が、プロジェクトの設定と一致している
- アップロードするたびにBuild番号が増えている（同じBuild番号は再アップロード不可）
Apple Developer側（署名の材料）
- Apple Distribution証明書が用意できている
- App Store用のプロビジョニングプロファイルを作成済み（Distribution＋該当App ID）
- App Store Connectへアップロードするには、明示的なApp ID（explicit）が必要になるケースが多い（特に機能を有効化しているアプリ）
App Store Connectにアップロードするためのプロビジョニングプロファイル作成は、Apple公式ヘルプにも手順としてまとまっています。
Macビルドホスト側（Windows移行で見落としがち）
- Xcodeをインストール済み（Pair to MacはXcodeを勝手に入れてくれません）
- Xcodeを一度起動し、必要な初期設定（ライセンス同意等）を完了
- Distribution証明書の秘密鍵がMacのキーチェーンに存在（Windows側で作成しても、ペアリング状況によってはMacへ反映されます）
Visual StudioのPair to Macは前提の準備を手伝ってくれますが、Xcode自体は手動で入れる必要がある点は要注意です。
Windows＋Visual Studioでの正攻法：Release＋配布署名でアーカイブ（.ipa生成）
ステップ1：Pair to Mac（接続が無いと始まらない）
WindowsのVisual Studioで、Tools > iOS > Pair to Mac（またはiOSツールバー）からMacビルドホストに接続します。接続後は、iOSのビルドやアーカイブが可能になります。
ステップ2：構成マネージャーでReleaseへ切り替え
ツールバーの構成をDebug → Releaseに変更します。TestFlight用はReleaseが前提です。
ステップ3：iOS Bundle Signing（署名設定）を配布用に合わせる
Visual Studioではプロジェクトのプロパティ内に、iOS署名設定（iOS Bundle Signing）が用意されています。ここで重要なのは次の3点です。
- Scheme：Manual Provisioning（手動指定）
- Signing identity：Distribution（Distribution(Automatic)でも可）
- Provisioning profile：App Store用（Automaticでも可／問題が出る場合は明示選択）
この流れはMicrosoft Learnでも「App Store配布のPublish手順」として明記されています。
ステップ4：Publish（Archive Manager）でアーカイブし、.ipaを生成
Visual Studioでは、右クリックのPublish…からアーカイブを作成し、Archive Managerで配布パッケージ（.ipa）を作れます。ざっくり以下の流れです。
- プロジェクトを右クリック → Publish…
- Archive Managerが開き、Archive（アーカイブ）が作成される
- アーカイブ選択 → Distribute…
- チャネル選択でApp Store
- 署名（Distribution＋App Storeプロファイル）を選ぶ
- Save As（.ipaをファイルとして出力）またはUpload to Store（そのままアップロード）
Save As／Upload to Storeの選択肢がある点、Upload時にApple IDとapp-specific password（アプリ用パスワード）が必要になる点も、Microsoftの手順に沿っています。
補足：CLIで.ipaを作りたい場合（dotnet publish）
GUIではなくCLIで揃えたい場合は、.NET MAUIのiOSターゲットに対してReleaseでpublishするやり方もあります。ただし環境（.NET SDKのバージョン、ワークロード、Mac側の状態）で挙動が変わりやすいため、まずはVisual StudioのArchive/Distributeで成功させてからCLIに寄せるのが現実的です。
dotnet publish -f net8.0-ios -c Release -p:ArchiveOnBuild=true -p:BuildIpa=trueCLI運用に寄せる場合でも、署名（Distribution証明書＋App Storeプロファイル）とBuild番号の管理は避けて通れません。
アップロード方法は2通り：Visual Studio直アップロード or Transporter
「作った.ipaをTransporter / Visual Studioのどちらでどうアップロードするのか」は、実務上は次の2択です。
| 方法 | メリット | デメリット | おすすめ度 |
|---|---|---|---|
| Visual Studio（Upload to Store） | IDEから完結しやすい | 失敗時に情報が少なく「altool code 1」などで止まりやすい | 普段は便利、詰まったら別手段へ |
| Transporter | アップロードと検証に強く、ログで原因を追いやすい | WindowsはGUIではなくコマンド中心になりがち | トラブルシュートに強い |
A) Visual Studioからアップロード（Upload to Store）する手順
- ReleaseでArchive作成
- Distribute… → App Store
- 署名（Apple Distribution＋App Storeプロファイル）を選択
- Upload to Storeを選択
- Apple IDとapp-specific passwordを入力してアップロード
このapp-specific passwordが必要になる点は、Microsoft Learnでも明確に案内されています。
B) Transporterでアップロードする手順（macOSとWindowsで考え方が違う）
macOS：Transporter（GUIアプリ）でアップロード
Macが手元にある（あるいはMacビルドホストをGUI操作できる）なら、macOSのTransporterアプリで.ipaをアップロードするのが直感的です。Visual StudioでSave Asして.ipaを出力 → Transporterでアップロード、が分かりやすい王道です。
Windows：Transporterは「GUIアプリ」ではなくコマンドライン中心
質問にあった「Windowsに入れたTransporterがGUIアプリとして起動できない」は、かなり典型的です。AppleのTransporter User Guideでは、Windows版はインストール先（例：C:\Program Files\itms）にツール一式が入り、コマンドで実行する前提で説明されています。
つまりWindowsでは、スタートメニューから“アプリ起動”というより、PowerShell／コマンドプロンプトでiTMSTransporterを叩く運用になりがちです。
WindowsでのiTMSTransporter実行例（.ipaアップロード）
Apple公式ガイドでは、upload modeで.ipaを送る場合、-assetFile（.ipa）を使い、Windows/Linuxでは-assetDescription（AppStoreInfo.plist）が必須とされています。
例として、インストールが既定の場所に入っている場合は次のような形になります（パスは環境に合わせて読み替えてください）。
cd "C:\Program Files\itms\bin"
.\iTMSTransporter.cmd -m upload ^
-assetFile "D:\drop\MyApp.ipa" ^
-assetDescription "D:\drop\AppStoreInfo.plist" ^
-u "[email protected]" ^
-p "xxxx-xxxx-xxxx-xxxx" ^
-v eXtreme- -v eXtreme：ログを増やして原因調査しやすくする
- -p：2要素認証を有効にしている場合は、通常のパスワードではなくapp-specific passwordを使う（Apple公式ガイドで推奨）
2要素認証とapp-specific passwordの関係はTransporter User Guideにも記載されています。
AppStoreInfo.plistはどこから用意する？
Windows/Linuxで必要になるAppStoreInfo.plistは、Transporter User Guide上「XcodeでArchiveをExportしたときに生成されるファイル」として説明されています。
現場での割り切りとしては、次のどちらかがスムーズです。
- 割り切り案1（おすすめ）：Mac側でTransporter（GUI）を使う
Windowsで無理に完結させず、Macでアップロードしてしまう（作業が短い） - 割り切り案2：Mac側で一度Export（App Store向け）してAppStoreInfo.plistを生成
生成されたAppStoreInfo.plistと.ipaをWindowsへ持ってきてiTMSTransporterで送る
アップロード後にTestFlightで配布できる状態になるまで
「アップロードしたら自動でTestFlightに出る？」という疑問はよく出ます。整理すると次の通りです。
- アップロード先はApp Store Connect
- アップロード後、Apple側でProcessing（処理）が走る
- 処理が終わると、App Store ConnectのTestFlightタブでビルドが選べるようになる
- 外部テスト（External Testing）は、状況によってTestFlight App Reviewが必要
なおTestFlightのビルドにはステータスがあり、期限切れ（Expired）なども含めてApp Store Connect上で確認できます。
Windows Transporterが「起動できない」問題の実務的な答え
Windows版Transporterは、Appleの案内上も「Windowsにインストールして実行できる」ことは明記されていますが、macOSのTransporterのような“ドラッグ＆ドロップ前提GUIアプリ”として期待するとズレます。インストール先（既定：C:\Program Files\itms）にツールが入り、そこでiTMSTransporterを実行して使うのが基本です。
もし「どうしてもGUIでアップロードしたい」なら、素直にMac側のTransporterアプリを使う（またはXcode Organizerでアップロードする）のが、トータルで早いことが多いです。
`altool exited with code 1` で失敗する時の切り分け（原因を“層”で分ける）
Visual Studioから直接Upload to Storeしたときに、`altool exited with code 1`のような抽象的なエラーで止まるケースがあります。ここで大事なのは、「Windows側」ではなく「Macビルドホスト側のXcode状態」や「署名・プロファイルの整合性」に問題があることが多い、という点です（VSは裏でMacのツールチェーンを呼び出しているため）。
| 症状 | よくある原因 | 確認ポイント | 対処 |
|---|---|---|---|
| Upload to Storeでaltool code 1 | Mac側のXcode/ツールが不整合 | Pair to Macは接続できているか／Xcodeは最新系か | Xcode更新、初回起動、必要ならCommand Line Tools見直し |
| アップロードは通るがTestFlightに出ない | Processing中／ビルド番号重複 | App Store Connectのビルド一覧と処理状態 | 処理完了を待つ、Build番号を増やして再アップ |
| 署名エラー/検証エラー | Development署名、プロファイル違い | Signing identityがDistributionか | Release＋Apple Distribution＋App Storeプロファイルへ統一 |
| Transporterで詳細なエラーが出る | パッケージ内容不備（設定/メタデータ/要件） | ログの具体的なエラー文 | エラー文に応じて修正（権限、Bundle ID、Entitlements等） |
まずやるべき「最短の確認」
- Releaseになっているか
- Apple Distributionで署名しているか
- App Store用プロビジョニングプロファイルか
- Build番号（iOSのVersion/Build）が増えているか
- MacビルドホストのXcodeが動く状態か（Pair to Macだけでは不足のことがある）
「VSのアップロードが分かりにくい」と感じたらTransporterへ切り替える
Microsoftのドキュメントでも、Transporterはパッケージエラーの特定に役立つとされています。VSからのアップロードが曖昧に落ちるときは、Transporter（特にログを増やす）へ切り替えるのが、結果的に最短になることが多いです。
運用のコツ：TestFlightが切れないために「90日」を前提にする
TestFlightは「一度上げたらずっと配れる」ものではありません。ビルドは一定期間で利用できなくなるため、継続テストするなら定期的に新ビルドを上げる運用が必要です。
- プロジェクト側でBuild番号を上げる手順を固定する（誰がやっても同じになるように）
- 配布用証明書・秘密鍵は紛失しない（失うと証明書の失効→プロファイル再作成→全体やり直しになりやすい）
- Macビルドホストは「iOSビルド専用機」的に安定運用する（OS/Xcodeを頻繁に触るほど壊れやすい）
最後に：.NET MAUI特有の“最近の審査落ち”も一応チェック
iOSの配布要件は年々更新されます。.NET MAUIのドキュメントでも、App Store向けではプライバシーマニフェストなどの要件に触れられており、条件によっては審査で弾かれる可能性があります。アップロード自体は通っても、後段で止まる場合はこの手の要件も疑ってください。
コメント