Xcode 27はIntel Mac非対応：2026年のビルドマシンをどう移行する？

2026年9月12日時点で、AppleはXcode 27をApple silicon Macでのみインストール・実行できると案内しています。Xcodeのシステム要件に照らすと、症状はIntel MacがXcode 27の主ビルド機になれないことです。最短の解決策は、Intel MacをXcode 26の回退環境として残し、Apple silicon MacへXcode 27の主線を移すことです。

Xcode 27 Intel Mac ビルドマシンの移行を検討しているなら、今すぐ旧Macを廃棄する必要はありません。ただし、iOS 27 SDKの採用、継続的インテグレーション、複数Appの無人公開を予定している場合は、少なくとも1回の実案件で新しい構築経路を検証するまで双轨運用にしてください。

この記事の対象者

Intel Macを個人用の打包機として使い続け、すぐに買い替えるべきか迷っている開発者向けです。Xcode 27やiOS 27 SDKを導入したいが、既存Appの公開を止められない小規模チーム、自前Runner・署名資産・複数プロジェクトを管理する担当者にも適しています。

注意：Xcode 27がIntel Macで動かないことと、既存Appが直ちに公開できなくなることは別問題です。Xcodeの実行条件、プロジェクトのDeployment Target、SDK、App Store Connectの提出要件を分けて確認してください。

まず分けるべき4つの互換性

Xcodeのインストール資格だけを見て移行時期を決めると、不要な緊急対応か、危険な先送りのどちらかになりやすいです。次の4項目を別々に記録してください。

• ビルドホストのアーキテクチャ：Intel MacかApple silicon Macか
• Xcodeのバージョン：Xcode 26を固定するか、Xcode 27へ移すか
• SDKのバージョン：現在のSDKを維持するか、iOS 27 SDKを採用するか
• Appの最低対応OS：Deployment Targetを変更するかどうか

AppleのXcode 27 Release Notesでは、Xcode 27の変更点と対応条件を確認できます。Xcode 27でビルドできないからといって、既存のソースコードや最低対応OSまで自動的に変更されるわけではありません。

また、2026年4月28日から有効になった最低提出要件は、執筆時点ではXcode 26と対応SDKを基準にしています。App Store提出要件の公式ページで確認できる範囲を超えて、将来Xcode 27が必須になる日付や正式版の挙動を断定しないでください。

Intel MacはXcode 27をインストールして実行できますか。
できません。Appleが示すXcode 27の実行条件はApple silicon Macです。Intel MacはXcode 26など、既存の対応範囲を使う回退用ホストとして扱います。

Xcode 26で作ったAppは2026年も提出できますか。
現時点で公開されている要件では、2026年4月28日からの最低基準はXcode 26と対応SDKです。ただし、提出要件は更新されるため、公開直前にUpcoming Requirementsを再確認してください。Xcode 26で提出できることと、iOS 27 SDKの新機能を検証できることは同じではありません。

個人開発者は旧Macの回退価値を先に採点する

年に数回だけ公開し、普段はWindowsやLinuxでコードを書くなら、Intel Macをすぐ主環境から外しても完全に廃棄する必要はありません。Xcode 26でのArchive、既存SDKのビルド、過去版の緊急修正を担わせる価値が残ります。

ただし、次の条件に当てはまるなら主環境の移行を優先してください。

• iOS 27 SDKのAPIやシミュレーターを確認する必要がある
• 新しいXcodeの機能を使う予定がある
• 公開日に手作業で環境を作り直す余裕がない
• 証明書、Provisioning Profile、APIキーを複数のAppで管理している
• WindowsやLinuxから必要なときだけMacへ接続したい

単発の公開では、購入判断だけでなく環境初期化の回数もコストになります。Xcode、依存パッケージ、署名資産、Keychain、fastlaneの設定を毎回確認する構成は、安く見えても公開日に失敗しやすい構成です。

この場合は、Apple siliconの遠隔Macを一時的な主ビルド環境として用意し、実際のプロジェクトでArchiveとアップロードまで確認する方法が現実的です。必要な期間だけMac環境を確保したい場合は、MacDateの日本語案内から接続方式と利用条件を確認し、作業頻度に合う期間を選んでください。

小規模チームは「双轨」から主線移行へ切り替える

既存Appを安定して公開しながらiOS 27 SDKを試すチームは、最初から一括切り替えをしない方が安全です。Xcode 26の本番チェーンと、Apple silicon上のXcode 27検証チェーンを分けます。

先にコードと依存関係を固定する

最初に、同じコミットを両方の環境へ投入します。依存関係のロックファイル、固定Scheme、ビルド設定、環境変数を揃えないと、ハードウェア差ではなくプロジェクト差を比較することになります。

確認する項目は次の通りです。

1. リポジトリをクリーンな状態で取得する
2. Swift Package Manager、CocoaPodsなどの依存関係を復元する
3. 固定したSchemeでDebug Buildとテストを実行する
4. Archiveを作成し、署名付き成果物を生成する
5. TestFlightまたはApp Store Connectへ実際にアップロードする

Debug Buildだけで移行完了と判定しないでください。Archive時の署名、Export時のProvisioning Profile、アップロード時の認証は別々に失敗する可能性があります。

署名資産は「証明書ファイル」だけを移さない

Intel MacからApple siliconへ移すとき、何をバックアップしますか。
証明書本体だけでなく、秘密鍵を含む署名ID、Provisioning Profile、Bundle IDとの対応、App Store ConnectのAPIキー、CI用Keychain、Runner登録情報を確認します。

Appleのチーム署名証明書共有に関する資料を参照し、秘密鍵を含む資産を安全な経路で移してください。ProfileはApple DeveloperのProfile管理手順で再取得または有効性を確認します。

署名資産を移す前に、Team ID、Bundle ID、証明書名、Profile名、APIキーの識別子を記録します。秘密鍵やAPIキーの値、リポジトリURL、ホスト名、ログ、ユーザー名は記録から脱敏してください。

CI運用者はホスト移行を完了条件で判定する

自前Runner、定時ビルド、複数Appの公開を維持している場合、Intel MacをXcode 27の主ホストにできない状態は、単なる開発環境の制限ではありません。新旧のジョブを同じホストへ流し続けると、Xcode選択、キャッシュ、Keychain権限、署名設定の混在が起きます。

まずジョブに明示的なタスクタグを付けます。

• legacy-xcode26：Xcode 26で維持する既存App
• apple-silicon-xcode27：Xcode 27とiOS 27 SDKを使う新規検証
• release：Archive、署名、App Store Connect公開を行う処理

スクリプト内では、次の文字列や前提を検索してください。

• DEVELOPER_DIRなどのXcode選択
• IntelとApple siliconを判定する分岐
• DerivedDataや依存キャッシュの固定パス
• securityコマンドによるKeychainアクセス
• Provisioning Profileの配置先
• SSH実行時のログインシェルと環境変数
• App Store Connect APIキーの保存場所

App Store Connect APIを使う場合は、AppleのAPIキー作成手順に沿って権限を確認します。APIキーを新ホストへ単純コピーするのではなく、読み込み権限、保存場所、失効時の再発行手順まで確認してください。

双轨を終える条件は「新Macで一度ビルドできた」ではありません。新環境で依存関係を復元し、テスト、Archive、署名付きExport、App Store Connectへの公開、ホスト再起動後のRunner復帰、ログ保存まで再現できた時点です。

保留・双轨・移行を人群ごとに決める

旧Macと新Macの双轨構成はどれくらい残しますか。
固定の日数で決めず、旧環境で最後に公開するAppと、新環境で最初に公開するAppを明確にしてください。新環境で少なくとも1回の実公開を完了し、旧環境を使う回退手順が文書化され、Runnerや署名資産の依存が解除された時点で縮小します。

Apple silicon環境を自前で用意するか、必要な期間だけ遠隔Macを使うかは、公開頻度、常時稼働するCIの有無、物理デバイス接続の必要性で決まります。物理USB機器や常時接続の実機テストが中心なら自前機が向きます。一方、ビルド・Archive・署名・アップロードが中心なら、ベアメタルMacと仮想Macの違いを確認したうえで、遠隔のApple silicon環境を先に試す選択肢があります。

MacDateの遠隔Macを使う場合も、いきなり全プロジェクトを移さないでください。まず脱敏した実案件または公開直前ではないAppで、依存関係の復元、テスト、Archive、署名、アップロード、再接続後の復旧を順番に確認します。新しい経路が再現できた後に利用期間を決めれば、Intel Macの退役を急ぎすぎず、公開作業だけを旧環境へ戻す判断もできます。

最後に、現在のIntel Mac運用を続けると、Xcode 27の導入停止、iOS 27 SDKの検証不可、公開日に手作業の環境切り替えが発生するという3つの弱点が残ります。新しい実機を常時購入して管理する方法もありますが、低頻度の公開や一時的な移行検証では、保守対象と署名資産を増やさずに済む遠隔Macの方が適しています。まずMacDateのApple silicon環境で1つの実案件を検証し、構築からアップロードまで復旧できることを確認してから、必要なレンタル期間とIntel Macの退役時期を決めてください。