Macへ接続したのに、VS Codeではコードを書けてもシミュレーターや署名の確認で止まってしまいます。
最短解は、VS Codeを遠隔編集の入口にし、Xcode 27をApple向けツールチェーンとGUI検証の担当として残すことです。VS CodeはXcode 27を完全には置き換えられませんが、Remote SSHとxcodebuildを組み合わせれば、日常の編集と自動ビルドの中心にはできます。
対象になる開発者
WindowsまたはLinuxを主力端末にしながら、iOSアプリのビルドや公開が必要な開発者向けです。
VS CodeでSwiftを書き、できるだけリモートデスクトップの操作を減らしたい人にも適しています。
常駐するリモートMacを、小規模チームの開発環境と打ち上げ用のビルドマシンに兼用したい場合も対象です。反対に、SwiftUI Previewや画面デバッグを毎日長時間行うなら、GUIへ接続できるXcode環境を最初から確保してください。
Last updated：2026年8月31日。Xcode 27の状態、対応するmacOSとSDK、Remote SSHの対応範囲、Swift拡張の機能、xcodebuildの役割を、AppleのXcodeシステム要件、MicrosoftのRemote SSHドキュメント、Swift公式のVS Code導入資料で確認しています。
能力境界の判定表
Xcode 27については、Apple公式のシステム要件ページにXcode 27 beta 6が掲載され、対応するmacOS、SDK、シミュレーターの範囲が示されています。したがって、まず遠隔MacのOSが要件を満たすかを確認し、その後に編集環境を決めます。
| 作業 | VS CodeとRemote SSH | Xcode 27またはGUI接続 |
|---|---|---|
| Swiftや設定ファイルの編集 | 得意。Mac上のファイルを直接編集できます | 可能 |
| Swift Packageの編集と基本操作 | Swift拡張で対応できます | 完全対応 |
| Xcode project / workspaceの設定確認 | 一部のファイル編集に限定されます | Scheme、Signing、Build Settingsを確認できます |
| コマンドラインビルド | xcodebuildを呼び出せます | GUIからも実行できます |
| iOSシミュレーターの起動 | simctlやコマンド実行は可能です | 画面操作、デバッグ、ログ確認に必要です |
| SwiftUI Previewと画面デバッグ | 完全な代替にはなりません | Xcodeの担当です |
| 署名、Archive、公開前の確認 | コマンド実行は可能です | 設定と結果の最終確認に向きます |
VS CodeでXcodeプロジェクトを直接開いてビルドできますか？
プロジェクト内のSwiftや設定ファイルを開くことはできます。Remote SSHでMacに接続していれば、同じMac上のxcodebuildも実行できます。ただし、VS CodeがXcode projectやworkspaceのScheme、署名設定、依存関係、実行先をXcodeと同じ画面で完全に管理するわけではありません。
Swift PackageはVS Codeとの相性を確認しやすい一方、Xcode project / workspaceを含むアプリでは、コード補完が動いたことだけで公開可能とは判定しないでください。Swift拡張の対応範囲は、Swift公式のVS Code機能説明にある範囲を基準にします。
注意：Remote SSHはWindowsやLinux側でXcodeを実行する機能ではありません。VS Codeの画面から、対応するmacOSホスト上のファイルやターミナルを扱う接続方式です。
単一ワークスペースの構成
最初に決めるべきなのは、ソースコードをどこに置くかです。ローカル端末、Mac上の作業用ディレクトリ、ビルド用の複製先に分散させると、編集した内容とビルド対象がずれます。
推奨構成は、リモートMac上にGitリポジトリを1つ置き、VS CodeのRemote SSHでそのディレクトリを直接開く方法です。ローカル側には編集用のコピーを持たず、必要な成果物だけを取得します。
変更したファイルを、VS CodeとXcodeの両方ですぐ確認できますか？
合格条件は、VS Codeで1ファイルを変更した直後に、リモートMacのターミナルとXcodeが同じ変更を表示することです。別の同期ツールや手動コピーを挟むなら、その時点で「単一ワークスペース」ではありません。
接続後は次の順で確認します。
<USER>@<MAC_HOST>へSSHログインできることを確認します。<REMOTE_REPO>を作成し、Gitの所有者と書き込み権限を確認します。- VS CodeのRemote SSHで、同じ
<REMOTE_REPO>を開きます。 git statusでブランチ、未追跡ファイル、変更差分を確認します。- Swift拡張など、リモート側で動かす拡張をMac側へインストールします。
- VS Codeで変更し、リモートターミナルとXcodeから同じ内容を読み取ります。
ここでローカル拡張とリモート拡張を混同しないことが重要です。コンパイラー、SDK、Gitフック、依存関係の解決は、実際にビルドを実行するMac側の状態に依存します。
ツールチェーンとビルド結果
Xcode 27を導入したら、バージョン表示だけでなく、アクティブな開発者ディレクトリ、SDK、Scheme、依存関係の解決入口をそろえます。Appleはxcode-selectによるコマンドラインツールの選択方法を説明しており、公式の設定資料で確認できます。
| 確認対象 | コマンドまたは操作 | 合格条件 |
|---|---|---|
| 開発者ディレクトリ | xcode-select -p |
意図したXcode 27のパスを示します |
| SDKとビルド機能 | xcodebuild -showsdks |
対象プラットフォームのSDKを確認できます |
| Scheme | xcodebuild -list -workspace <WORKSPACE> |
CIで使うSchemeが表示されます |
| 依存関係 | XcodeまたはSwift Packageの解決 | ロックした依存関係を再現できます |
| ビルド | xcodebuild -scheme <SCHEME> ... build |
Debugビルドが完了します |
xcodebuildの引数と利用可能なコマンドは、AppleのXcodeコマンドラインツールリファレンスを基準にしてください。VS CodeのTaskへコマンドを登録する場合も、パスやSchemeを固定値にせず、<PROJECT>, <WORKSPACE>, <SCHEME>, <DESTINATION>のような明示的な値で管理します。
中部の比較として、運用方法は次のように分かれます。
| 運用方式 | 編集 | ビルドとテスト | GUI作業 | 適するケース |
|---|---|---|---|---|
| ローカルVS Codeのみ | できます | Apple SDKがなければ完結しません | できません | Apple向け工程を持たない作業 |
| VS Code + Remote SSH | 主な入口にできます | リモートMacのxcodebuildで実行します | 必要時に別接続します | Windows/Linux中心の個人開発 |
| Xcode中心のリモートGUI | できます | Xcodeで一貫して実行できます | 最も扱いやすいです | Previewや画面デバッグが多い開発 |
| VS Code + 常駐Mac | 編集を効率化できます | 自動ビルド、Archiveへ拡張できます | 最終確認で使います | 小規模チームの継続開発 |
テストとシミュレーターのフィードバック
ビルドは一度で判断しません。VS CodeのTaskまたはリモートターミナルから、Debugビルド、自動テスト、シミュレーター起動を分けて実行します。xcodebuildとシミュレーター関連のsimctlはXcodeに付属するコマンドラインツールとして扱い、Appleのコマンドラインツール資料に沿って確認します。
WindowsからRemote SSHでMacへ接続した場合、iOSシミュレーターを使えますか？
シミュレーターの起動や制御をコマンドから行うことはできます。しかし、画面を操作し、タッチイベント、レイアウト、アニメーション、ログを確認するには、リモートMacのグラフィカルセッションが必要です。SSH接続だけで、WindowsのVS Code画面にXcodeのシミュレーター画面が自動表示されるわけではありません。
テスト結果は標準出力だけに残さず、CIで追跡できる形式に保存します。テスト実行後は、失敗したテスト名、実行先、ログの保存場所を記録してください。結果の読み方は、Appleのテスト結果と解釈の説明を参照します。
xcodebuildが成功した後、テスト結果はどこで確認しますか？
まずコマンドの終了結果とログを確認し、その後に生成したテスト結果をXcodeで開いて、失敗したテスト、添付ファイル、実行先を確認します。CLIでテストが通っても、シミュレーター上の画面操作やSwiftUI Previewの確認まで完了したことにはなりません。
署名と公開資格情報
署名証明書、秘密鍵、Provisioning Profile、App Store ConnectのAPIキーは、ビルドを実行するリモートMacで管理します。WindowsやLinuxのVS Codeを使うからといって、秘密鍵をローカルへコピーする設計にしないでください。
| 資格情報 | 保管場所の基本 | 分けて管理する権限 |
|---|---|---|
| SSH鍵 | 接続元とMacのSSH設定 | Macへのログイン権限 |
| 署名証明書と秘密鍵 | リモートMacのKeychain | コード署名権限 |
| Provisioning Profile | リモートMacの開発環境 | Bundle IDと対象デバイス |
| App Store Connect APIキー | 公開処理を行うMacの安全な保管場所 | アプリ公開・管理権限 |
AppleはMac向け署名済みコードの作成方法を署名に関する公式資料で案内しています。iOSアプリでも、署名状態とArchiveの結果を、実行したMac上で確認するという考え方は変わりません。
署名証明書は手元のPCとMacのどちらに置くべきですか？
原則として、署名とArchiveを実行するMacです。手元のPCにはソースコード操作用のSSH鍵だけを置き、署名秘密鍵や公開用トークンとは分離します。App Store Connect APIキーを使う場合も、権限を必要最小限にし、作成方法はAppleのAPIキー公式資料で確認してください。
脱敏した形でsecurity find-identityの結果、Provisioning Profileの対象、Archiveの生成先を確認します。Team ID、Bundle ID、証明書名、トークンはログへそのまま出さず、<TEAM_ID>や<BUNDLE_ID>へ置き換えます。
経験則：SSHでリポジトリへ入れる人と、Keychainで配布署名を実行できる人は、同じ権限にしないほうが安全です。編集権限の追加が、そのまま公開権限の追加にならない構成にしてください。
切断復旧と運用判定
長期利用では、編集できるかより、切断後に同じ状態へ戻れるかが重要です。次の確認を、単一リポジトリで順番に行います。
- SSHを切断し、再接続後も同じ作業ディレクトリを開きます。
- グラフィカルセッションを切断し、Xcodeとシミュレーターの状態を再確認します。
- Macを再起動し、
xcode-select、SDK、Schemeを再確認します。 - VS CodeのTaskから同じDebugビルドと自動テストを再実行します。
- Archiveとログを保存し、別の端末から成果物を取得します。
この結果を、次の3つに分類します。
| 判定 | 条件 | 運用方針 |
|---|---|---|
| 遠隔編集のみ | ファイル編集とGit操作まで安定 | ビルドは別のMacで実施します |
| 開発の二軌道 | CLIビルドと自動テストが再現 | VS Codeを主入口、XcodeをGUI検証にします |
| 常駐ビルド環境 | 再起動後も署名、Archive、成果物取得まで再現 | 継続開発や自動公開に利用します |
この判定を済ませる前に、常駐の打ち上げ環境として扱うのは危険です。特にXcodeの切り替え、依存関係の再解決、Keychainのロック、Mac再起動後のログイン状態は、コード補完では見えない失敗要因です。
現在のWindows/Linux中心の構成は、Apple SDKをローカルで完結できず、ソースの複製が増え、シミュレーターの画面確認が別経路になり、証明書を誤って手元へ持ち出す危険もあります。これらを毎回の手作業で補うより、MACCOMEのリモートMacへ単一リポジトリとツールチェーンを集約したほうが、継続開発や自動打ち上げでは管理しやすい構成になります。
まずはMACCOMEのMacレンタル環境で、手元のVS Codeから接続できるか、Xcode 27の要件を満たすか、実際のArchiveまで確認してください。利用頻度が低く、公開前の一度だけ検証するなら短い期間の環境で十分です。毎日開発する、または常時ビルドするなら、キャッシュ、Keychain、依存関係を保持できるリモートMacを選び、Macの利用構成を選ぶための案内へ進むのが現実的です。