Unity 6.3 LTS iOS ビルド：2026 Windows でどうパッケージ化する？

WindowsでUnity 6.3 LTS iOS ビルドを行う場合、UnityでXcode工程を生成する段階と、macOS上のXcodeでコンパイル、Archive、コード署名、App Store Connectへアップロードする段階を分けて設計します。低頻度なら生成済み工程を一時的なリモートMacへ渡し、毎週のように公開するなら、リモートMacでソースから工程生成まで自動化する構成を選ぶのが現実的です。

この手順は、Windowsで主な開発を済ませて初めてUnity製iOS版を公開する個人開発者、TestFlight用ビルドを繰り返す小規模チーム、手動書き出しを再現可能なビルド処理へ移行したい担当者向けです。Apple Developerの権限、プロジェクト識別子、バージョン管理をすでに用意できることを前提にします。

注意：2026年8月29日時点のUnity 6.3 LTS、Xcodeの対応範囲、アップロード条件は今後変更される可能性があります。公開前には、Unityのリリース情報とAppleの最新配布要件を必ず再確認してください。

UnityのiOSビルドは、UnityがXcode工程を生成し、その工程をXcodeがアプリとして構築する二段階です。Unity公式の iOSアプリケーション構築手順でも、Unity側の書き出しとXcode側のビルドが分けて説明されています。

したがって、Windowsだけで署名済みのIPAまで完成させることはできません。Windowsではコード、アセット、設定、バージョン管理を担当し、macOSではXcode、署名、Archive、TestFlight送信を担当させます。

公開頻度で経路を決める

• 月に数回以下の公開なら、Windowsで生成したXcode工程を圧縮してリモートMacへ転送します。
• 頻繁な公開や複数人での開発なら、リモートMacがUnityソースを取得し、同じ手順でXcode工程を再生成します。
• Apple DeveloperのTeam権限、Bundle ID、証明書の秘密鍵、Provisioning Profile、App Store Connect上のアプリ記録を先に確認します。
• パスワードやAPIキーはリポジトリ、Xcode工程、ログへ直接書き込みません。

Unity 6.3 LTSを使う場合、Windows側とリモートMac側でUnityのパッチ、パッケージのロック状態、iOS Build Supportの有無を記録します。Unity 6のシステム要件は公式のシステム要件で確認し、Mac側のCPUアーキテクチャと、利用可能なXcodeの組み合わせも公開前に照合します。

Unity 6.3のリリース番号を確認するだけでなく、次の値をリポジトリのビルドメモへ残します。

• Unity Editorの正確なバージョン
• Packages/manifest.json とロックファイルの状態
• Xcodeの選択パス
• iOSのビルドターゲット
• Bundle ID、Team ID、Marketing Version、Build Number
• 使用するネイティブプラグインとCocoaPodsの処理

まず空のプロジェクトでiOS Build Supportによる書き出しを行い、リモートMacでXcodeのコマンドライン実行まで確認します。いきなり本番プロジェクトを投入せず、Unityの iOS構築方式の説明と同じ二段階が動くことを確認してから正式プロジェクトへ進みます。

低頻度向け：Windowsで工程を生成する

WindowsでUnityのBuild SettingsからiOSを選び、Xcode工程を書き出します。生成後は、工程本体だけでなく、ライブラリ、ネイティブプラグイン、設定ファイル、PostProcessBuildの結果が含まれているかを確認してから転送します。

Unity公式の旧来のiOS構築フローの説明を参照する際は、古いバージョンの前提をそのまま現在の固定条件とは扱わないでください。UnityのパッチやXcodeの要件が変わるため、実際の公開時点の組み合わせで確認します。

高頻度向け：ソースを同期してMac側で工程を生成する

常駐運用では、GitなどでUnityプロジェクトをリモートMacへ取得し、コマンドラインから書き出しを実行します。概念的な処理は次のように分離します。

/Path/To/Unity \
  -batchmode -quit \
  -projectPath "/Path/To/PROJECT" \
  -executeMethod <BUILD_METHOD> \
  -logFile "/Path/To/BUILD_LOG"

<BUILD_METHOD>、PROJECT、ログの場所は実際の環境に置き換えます。生成されたXcode工程を別の担当者が同時に手編集すると、次回の書き出しで変更が消える可能性があるため、設定はUnity側、署名や配布設定はXcode側という境界を保ちます。

Xcode工程が生成できても、Archiveが成功するとは限りません。まず署名を後回しにして、ネイティブプラグイン、CocoaPods、Objective-CまたはSwiftコード、PostProcessBuildスクリプトがリモート環境で正しく処理されるかを確認します。

その後、XcodeでTeam、Bundle ID、Entitlements、証明書の秘密鍵、Provisioning Profileを設定します。証明書の問題をUnityの書き出し失敗と混同しないため、失敗ログを「工程生成」「Xcodeコンパイル」「署名」「Archive」に分類します。

xcodebuild \
  -workspace "/Path/To/WORKSPACE.xcworkspace" \
  -scheme "<SCHEME>" \
  -configuration Release \
  -archivePath "/Path/To/APP.xcarchive" \
  archive

ここで<SCHEME>、WORKSPACE.xcworkspace、パスはプレースホルダーです。Appleの配布用アプリ準備ガイドに沿って設定を点検し、Archiveが生成された時点を最初の工程完了とします。

Archive後はXcodeのOrganizerから検証とアップロードを行います。AppleのXcodeによるベータ版・正式版の配布手順では、検証、配布、アップロードが別の処理として扱われています。

実務では、次の状態を分けて記録します。

• Windows側でUnity工程の生成が成功した
• Xcodeでビルドと署名が成功した
• App Store Connectへのアップロードが完了した
• App Store Connect側の処理が完了し、TestFlightで利用可能になった

Appleのビルドアップロード手順に従って送信し、App Store Connectのアプリ記録、Bundle ID、バージョン番号、Build Numberが一致するか確認します。アップロード後に表示されない場合は、アップロード状態の定義と配信ログを確認し、証明書を無計画に交換したり、同じビルドを繰り返し送信したりしないようにします。

一度成功した手順を、次の変更で壊れないか確認します。Unityのソース変更、ネイティブプラグイン変更、署名資格情報が利用できない状態をそれぞれ再現し、どの段階から再開できるかを記録します。

• Unity工程生成、Xcode Archive、署名、アップロードを個別のジョブに分ける
• キャッシュはUnityライブラリ、依存パッケージ、Derived Dataごとに削除範囲を定義する
• 証明書、秘密鍵、Provisioning Profile、APIキーの保管場所と有効期限を管理する
• Archiveとログを保存し、失敗時に同じ入力で再実行できるようにする
• Xcode工程を手編集した場合は、次回のUnity書き出しで消える変更かどうか確認する

Appleのリリースビルドのテスト手順も参照し、Archive成功だけで公開完了と判断しない運用にします。

WindowsでUnity開発を続けながら、公開時だけ生成工程を渡す方法は、公開頻度が低ければ合理的です。しかし、毎回の転送、環境差、プラグイン処理の再確認が負担になり、頻繁なTestFlight配布では再現性の問題が積み上がります。反対に、長期の高負荷処理や物理デバイス接続が中心なら、自前のMacを含めて比較すべきです。

Unity 6.3 LTS iOS ビルドを今週試すなら、まずWindowsで実際のプロジェクトをXcode工程まで生成し、JEXCLOUDのMacレンタル環境でArchiveとTestFlight送信まで一度通してください。低頻度なら一時利用、毎回の公開で転送が発生するなら常駐環境という順に判断すれば、不要な端末購入を避けながら、Windows開発とmacOS専用工程を分離できます。利用地域を比較する場合は、日本向けのMacレンタル案内も確認できます。