Xcode 27がIntelを切り離す——止まるもの、それでも出荷できるもの

以上はすべて、Xcode 27 beta 4およびmacOS 27 beta 4のリリースノートというベータ段階の文書に基づいています。³⁶

すでに出荷済みのバイナリを変えてしまう可能性がもっとも高いIntel関連の変更を、Appleは「非推奨」ではなく「新機能」の側に記載しました。Xcode 27のリリースノートには「Intel Deprecation」という節があり、そこに含まれる項目はちょうど2つ。そしてmacOSアプリがデフォルトでUniversalビルドされなくなる方の項目は、新機能の側に置かれています。¹²

要点

• 見出しの裏には3つの別々の変更が隠れており、Apple自身の文章はそれらをきちんと区別しています。Xcode 27はApple silicon Macにしかインストールできず、そこでしか動きません。² macOS 27のSDKは、依然としてUniversalアプリをmacOS 12以降へバックデプロイできます。² そしてARCHS_STANDARDは、ターゲットのmacOSまたはDriverKitのデプロイメントターゲットが27.0に達した時点でx86_64を含めなくなります。¹
• 出荷物を変えるのは3つ目だけで、しかも何の診断メッセージも出さずに変えてしまいます。対処法はApple自身が同じ項目に書いています。「必要であれば、ARCHSビルド設定にx86_64アーキテクチャを追加できます」¹
• Xcode 26.6では新しい挙動を先取りして確認できません。macOS専用プロジェクトにMACOSX_DEPLOYMENT_TARGET=27.0を強制指定してみましたが、ARCHS_STANDARDはarm64 x86_64のまま解決されました。¹³
• 監査でやりがちな2つの習慣が、誤った答えを作り出します。-sdk macosxを渡したせいでiOS専用プロジェクトがSUPPORTED_PLATFORMS = macosxとARCHS_STANDARD = arm64 x86_64を報告し、プロジェクト単位で設定を解決したせいで、デフォルトターゲットがiOSのプロジェクトに含まれる2つのmacOSターゲットが見えなくなりました。¹⁴
• 手元の11個のXcodeプロジェクト（計44ターゲット）を調べたところ、macOS向けにビルドされるのは21ターゲット、その中で最も高いmacOSデプロイメントターゲットは26.5、そしてARCHSやEXCLUDED_ARCHSを設定しているものは1つもありません。¹⁴ ディスク上にある51個のmacOSアーカイブはすべてx86_64 arm64です。¹⁴
• Intelソフトウェアの終わりが訪れるのはXcode 27ではなくmacOS 28であり、Appleの一文には読み落とせない例外が付いています。「すべてのIntelベースのソフトウェアは、レガシーゲームを除き、macOS 28.0と互換性がなくなります」¹⁰

以上はすべて、Xcode 27 beta 4およびmacOS 27 beta 4のリリースノートというベータ段階の文書に基づいています。³⁶

3つの文、3つの異なる変更

AppleのIntel Deprecationの節には項目が2つあります。これらをひとつの主張として読むと、どちらの方向にも間違った判断につながります。

非推奨の項目が扱うのは机の上のマシンで、こちらに含みはありません。「Xcode 27はApple silicon Macにのみインストールでき、そこでのみ動作します」² これを調整できるビルド設定はありません。Intel Macは現行Xcodeが動くマシンではなくなり、Appleの互換性表はハードウェアの条件に加えてソフトウェアの下限も示しています。Xcode 27 beta 4の要件はmacOS Tahoe 26.4以降です。⁴

同じ項目は続けて、出力物のほうを守ってくれます。「macOS 27のSDKは、Universal（IntelおよびApple Silicon）アプリのmacOS 12以降へのバックデプロイをサポートします」² Appleの互換性表もこれと一致しており、Xcode 27 beta 4のmacOSデプロイメント範囲は12〜27、Xcode 26.6では11〜26.5となっています。⁴ 下限がちょうど1リリース分だけ上がった格好です。Universalバイナリは生き残ります。

そして項目の締めくくりでは、開発の進め方そのものが温存されます。「macOS 27のようにRosettaをサポートするmacOSバージョンであれば、Intel向けの開発は引き続き可能です」²

続いて新機能の項目。すでに出荷している製品を変えてしまえるのは、こちらです。

最小デプロイメントターゲットがmacOS 27.0またはDriverKit 27.0に設定されたビルドターゲットは、デフォルトではUniversalとしてビルドされません。MACOSX_DEPLOYMENT_TARGETまたはDRIVERKIT_DEPLOYMENT_TARGETが27.0以上の場合、ARCHS_STANDARDビルド設定にx86_64は含まれなくなります。必要であれば、ARCHSビルド設定にx86_64アーキテクチャを追加できます。¹

ここには切り分けておくべき論点が4つあります。第一に、Appleが名指ししている設定は2つだけで、それ以外はありません。つまりIPHONEOS_DEPLOYMENT_TARGETとその仲間はこのルールの外側です。第二に、Appleが示しているのはツールチェーンのバージョンではなくしきい値です。引き金を引くのは、自分のデプロイメントターゲットが27.0に達することです。第三に、Appleは「デフォルトではUniversalとしてビルドされません」と述べています。これは既定値の説明であって、禁止ではありません。第四に、Appleは同じ記述のなかで逃げ道も示しており、x86_64を戻す場所としてARCHSを名指ししています。

エラーを出さずに変わるデフォルト

仕組み自体はごく平凡で、だからこそ静かなのです。Appleのビルド設定リファレンスはARCHSをこう説明しています。「プロダクトをビルドする対象アーキテクチャのリスト。通常はプラットフォームが提供する定義済みのビルド設定が指定されます。複数のアーキテクチャが指定された場合、universal binaryが生成されます」⁵ その定義済み設定がARCHS_STANDARDであり、Appleは同じリファレンスの別の箇所でもこの依存関係を認めています。ポインタ認証について「ARCHSがARCHS_STANDARDに基づかない形で上書きされている場合は効果がありません」と注記しているのがそれです。⁵

つまりARCHSに一度も触れていないターゲットは、プラットフォームが手渡してくるものをそのまま受け継ぎます。プラットフォームが手渡すものが変われば、バージョン管理下のどのファイルも編集していないのにプロダクトの形が変わるわけです。

この変更は失敗を生みません。コンパイラは走り、リンカも走り、アーカイブは検証を通ります。arm64単一スライスのmacOSビルドをエラーとして扱う仕組みはツールチェーンのどこにもありません。エラーではないからです。結果として得られるのは、2つあったアーキテクチャスライスが1つになった、正しく署名済みのmacOSアプリです。Apple silicon Mac上——Xcode 27の開発者が要件上いま全員使っているマシンです——では、arm64のみのビルドも同じように起動し、同じように振る舞います。この劣化が姿を現すのは、もう手元に残っていないハードウェアの上なのです。

この失敗の形を「静かだ」と表現しているのは私であってAppleではありません。Appleはデフォルトの挙動を述べるだけで、そこから先には踏み込んでいません。Appleが明言しているのは、修正が「追加」で済むということです。この言い回しは計画を立てるうえで意味を持ちます。x86_64は「必要であればARCHSビルド設定に追加できます」¹ 必要かどうかの判断は、Appleがこちらに委ねています。

Xcode 26.6が教えてくれること、教えてくれないこと

私のマシンで動いているのはmacOS 26.5.2上のXcode 26.6（ビルド17F113）なので、この記事のどこにもXcode 27の実挙動は登場しません。¹³ 前世代のツールチェーンに答えられる有意義な問いは、すでに新しい挙動になっているかどうかです。答えは「なっていない」でした。

macOS専用プロジェクトにxcodebuildを向け、デプロイメントターゲットをAppleの示すしきい値の先まで上書きしても、アーキテクチャのリストは手つかずのままです。¹³

xcodebuild -showBuildSettings -project Cels.xcodeproj \
  -configuration Release -sdk macosx \
  MACOSX_DEPLOYMENT_TARGET=27.0 2>/dev/null \
  | grep -E "^ +(ARCHS|ARCHS_STANDARD|MACOSX_DEPLOYMENT_TARGET) ="

    MACOSX_DEPLOYMENT_TARGET = 27.0
    ARCHS = arm64 x86_64
    ARCHS_STANDARD = arm64 x86_64
    MACOSX_DEPLOYMENT_TARGET = 27.0

1行目はxcodebuildが上書き指定をそのまま返しているもので、残りが解決結果です。同じコマンドを26.0で実行しても、アーキテクチャの行はまったく同じでした。¹³ Xcode 26.6はこのしきい値を実装していないので、現行ツールチェーン上でこの変更を予行演習することは誰にもできません。ビフォー・アフターの比較は、Apple silicon Mac上のXcode 27を待つことになります。

一方、プラットフォームごとの適用範囲は今日でも再現できます。同じプロジェクトをiOSのSDKに対して解決するとARCHS_STANDARD = arm64が返り、失うべきx86_64はそもそもありません。macOSのSDKに対してはarm64 x86_64が返ります。¹³ Appleの項目が名指ししているのはmacOSとDriverKitのデプロイメントターゲットだけであり、マルチプラットフォームプロジェクトのiOS側には失うものが何もないわけです。

影響範囲を、でっち上げずに監査する

自信満々の誤答を生む習慣が2つあります。私はその両方を踏みました。

1つ目は、プロジェクトがmacOS向けにビルドされるかを調べるために-sdk macosxを渡すことです。このフラグはプロジェクト自身のSDKを上書きするので、Xcodeが答えるのはプロジェクトについての問いではなくフラグについての問いになります。上書きなしで尋ねれば、私のiOS専用ブラウザプロジェクトは本当のプラットフォームを報告します。ところが-sdk macosx付きで尋ねると、同じプロジェクトがSUPPORTED_PLATFORMS = macosxとARCHS_STANDARD = arm64 x86_64を報告します。これはフラグが作り出した見かけ上の結果にすぎません。¹⁴ まずは-sdkをいっさい付けずに始めましょう。

xcodebuild -showBuildSettings -project YourApp.xcodeproj \
  -configuration Release 2>/dev/null \
  | grep -E "^ +(SUPPORTED_PLATFORMS|SDKROOT) ="

私が持つ唯一のmacOS専用アプリに対しては、2行が返ってきます。¹⁴

    SDKROOT = /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.5.sdk
    SUPPORTED_PLATFORMS = macosx

片方だけでなく、必ず両方を読んでください。このプロジェクトはSDKROOT = macosxを宣言している一方でSUPPORTED_PLATFORMSの行を一切持たないため、プロジェクトファイルをSUPPORTED_PLATFORMSでテキスト検索するとスコアはゼロになり、私が持つただ1つのmacOS専用アプリが見落とされます。¹⁴ 解決済みの設定ならSDKから欠けた分が補われますが、grepにはそれができません。この段階ではMACOSX_DEPLOYMENT_TARGETは無視してください。Xcodeは無関係でも値を用意してしまうからです。実際、私のiOS専用プロジェクトのうち3つが、いまだにmacOSデプロイメントターゲットを報告します（2つが26.5、1つが26.2）。¹⁴

2つ目の習慣は、プロジェクト単位で設定を解決することです。-targetなしのxcodebuild -showBuildSettingsは1つのターゲットについて答えるだけで、混成プロジェクトでは残りが埋もれてしまいます。私のSafari機能拡張プロジェクトはSUPPORTED_PLATFORMS = iphoneos iphonesimulatorとARCHS_STANDARD = arm64に解決され、Intelとは無縁のiOS専用プロジェクトのように見えました。ところがターゲットを列挙すると4つあり、うち2つはmacOS向けで、いずれもarm64 x86_64に解決されました。¹⁴

xcodebuild -list -project YourApp.xcodeproj
for t in TargetA TargetB; do
  xcodebuild -showBuildSettings -project YourApp.xcodeproj \
    -target "$t" -configuration Release 2>/dev/null \
    | grep -E "^ +(SUPPORTED_PLATFORMS|MACOSX_DEPLOYMENT_TARGET|ARCHS_STANDARD) ="
done

想定しておくべき癖がひとつ。SDKROOT = autoを持つターゲットは、SDKを明示するまでARCHS_STANDARDを解決しません。そのため私の21個のmacOSターゲットのうち15個は、コマンドに-sdk macosxを加えるまでこの行に何も表示せず、加えた時点で各プロジェクトがarm64 x86_64に解決されます。¹⁴ 空欄は「未解決」であって「空」ではないのです。

そこまで来たら設定を信用するのをやめて、バイナリを読みましょう。ビルド設定が語るのは意図であり、lipoが語るのは実際に出荷した成果物です。

lipo -archs YourApp.xcarchive/Products/Applications/YourApp.app/Contents/MacOS/YourApp

x86_64 arm64

アーカイブ自身のメタデータよりもlipoを優先してください。私のアーカイブのうち2つはInfo.plistにApplicationPropertiesのアーキテクチャ一覧をまったく持っておらず、アーカイブに対してplutilで問い合わせても何も返らない一方、中のバイナリに対するlipoはx86_64 arm64を返します。¹⁴ メタデータに記載がないのは、アーカイブの書かれ方が違っただけであって、アプリがスライスを失った証拠ではありません。

11個のプロジェクトの実態

11個のXcodeプロジェクト、計44ターゲットを監査しました。少なくとも1つのmacOSターゲットを含むプロジェクトが8個、macOS向けにビルドされるターゲットが21個、そして新しいデフォルトの影響を受けるものは現時点でゼロです。¹⁴

全体で最も高いmacOSデプロイメントターゲットは26.5、最も低いのは13.0で、後者はしばらく誰も手を入れていないSafari機能拡張のものです。27.0に達するターゲットは1つもないので、誰かが手作業で数字を上げないかぎり、デフォルトが変わる領域に入るターゲットも1つもありません。ARCHSを設定しているターゲットはゼロ、EXCLUDED_ARCHSもゼロ、そして全体に.xcconfigファイルが1つも存在しないため、44ターゲットすべてのアーキテクチャ決定はARCHS_STANDARDから来ていることになります。¹⁴

アーカイブという証拠は設定という証拠より強力です。アーカイブには実際に出荷されたものが記録されているからです。私のマシンには2026年4月から7月にかけてビルドされたアーカイブが79個あります。7つの異なるプロダクトにまたがる51個のmacOSアーカイブは、すべてx86_64 arm64を報告します。iOS系の28個はすべてarm64です。¹⁴ これらのプロジェクトで誰かがUniversalを選んだことは一度もありません。毎回、デフォルトがそれを生んできたのです。Appleの変更が作用するのはまさにこの母集団であり、だからこそ誰も気づかないのです。

正直に認めておくべき穴もひとつ。デプロイメントターゲットを27.0に上げるのは意図的な行為であり、私のプロジェクトにはまだそうする理由がありません。今回のきれいな結果が測っているのは、ある時点であって方針ではありません。

Intelソフトウェアが実際に終わる場所

Xcodeの変更が扱うのはビルド内のアーキテクチャです。カテゴリとしてのIntelソフトウェアの終わりはmacOS 28にあり、Appleはそれを自社のRosettaドキュメントとmacOS 27リリースノートの両方に書いています。両者の内容は一致しています。

AppleのRosettaドキュメントは、期限をはっきり示しています。Rosettaは「Apple siliconへの移行を容易にするために設計されたもので、Intelアプリ向けの汎用ツールとしてmacOS 27まで提供されます」。そして「この期間を過ぎた後は、Intelベースのフレームワークに依存する、メンテナンスされていない古いゲームタイトルのサポートを目的として、Rosettaの機能の一部を維持します」⁷ macOS 27のリリースノートは、同じ例外付きでその帰結を述べています。「すべてのIntelベースのソフトウェアは、レガシーゲームを除き、macOS 28.0と互換性がなくなります」¹⁰ 同じリリースノートの別の箇所にあるベータ限定のコマンドが、この例外に具体的な形を与えています。sudo game-test-tool enableでレガシーIntelゲームのサポートが有効になりますが、Appleは「レガシーゲームサポートを有効にするとRosettaが無効になります」と警告しています。¹⁵

macOS 27は、この猶予期間を「何が生き残らないか」を名指しすることに費やしています。Appleの非推奨情報の節には「macOS 28.0で動作しなくなるIntelベースのアプリケーションが、情報ウインドウ（Get Info）で表示されるようになりました」とあり、別の項目では「設定 > 一般に、macOS 28.0と非互換になるIntelベースのアプリが一覧表示されるようになりました」と加えられ、そこには「システム上で見つかった、使われていないIntelベースのソフトウェア」も含まれます。⁸⁹

Mac向けプロダクトを出荷している人にとっては、もっと目立たない3つの項目のほうが重要です。

まずRosetta自体が居座らなくなります。「以前にRosettaがインストールされていた場合でも、macOS 27.0へのアップグレード後に自動的には復元されません」¹¹ Appleのドキュメントが背景を補っており、macOS 27は「Rosettaをインストールしなくても、Intelバイナリ変換のサポートを直接統合しています」と述べています。狙いはARM仮想マシン上のIntel LinuxバイナリとIntel Linuxコンテナのサポートです。⁷ ユーザーが固定していたアプリの挙動も変わります。以前に「Rosettaを使用して開く」に設定されていたアプリケーションは「ネイティブに起動するようになり」、Appleは「過去にRosettaを必要とした互換性の問題は、macOS 27で再評価すべきです」と助言しています。¹²

インストーラのデフォルトも変わります。「hostArchitectureを指定していないインストーラパッケージは、arm64がデフォルトになります」とされ、Appleは「インストール前およびインストール後のスクリプトがarm64で意図どおりに動作することを確認してください」と求めています。¹¹ App Store外で配布されるMacプロダクトは、アプリがUniversalかどうかに関係なくこの影響を受けます。

もっとも厄介なのはプラグインのホストです。Appleは「Intelベースのプラグインおよびローダーは設定に表示されず、非互換の通知も発生しない場合があります」と警告し、手作業で確認すべきディレクトリとして~/Library/Audio/Plug-Ins/、~/Library/Printers/、~/Library/ColorPickers/などを挙げています。¹⁰ プラグイン1つがネイティブなアプリを足止めしうる理由は、AppleのRosettaドキュメントに書かれています。「システムは、同一プロセス内でarm64コードとx86_64コードを混在させることを禁止します。Rosettaによる変換はプロセス全体に適用され、そのプロセスが動的に読み込むすべてのコードモジュールを含みます」⁷ つまりIntelプラグインは、ホストを丸ごと変換実行に追い込みます。メンテナンスされていない部品ひとつが、アプリ全体をAppleが縮小予定の仕組みへの依存に変えてしまうわけです。

Universalが存在する理由は、macOS 12から27までを動かすIntel Macに届くためです。これはAppleがXcode 27向けに公表している互換性表の範囲そのものです。⁴ AppleはIntelソフトウェアの終わりをmacOS 28に定め、デプロイメント範囲には手を付けませんでした。したがってmacOSチームにとっての本当の問いは、自分たちのユーザーのうち何人が、そのスライスを必要とするMacをいまだに使っているか、です。

確認したうえで見つからなかったものが2つあります。Xcode 27とmacOS 27のどちらのリリースノートにも、Mac App StoreのUniversal Purchase要件の変更について記述はありません。また、どちらもmacOS 28の暦日を示していません。³⁶ どこかで日付を見かけたら、それは推測だと考えてください。

FAQ

Xcode 27ではIntelアプリを出荷できなくなりますか？

いいえ。Intel Macを開発機として非推奨にしたのと同じ項目で、Appleはむしろ逆のことを述べています。「macOS 27のSDKは、Universal（IntelおよびApple Silicon）アプリのmacOS 12以降へのバックデプロイをサポートします」² Appleの互換性表もこの範囲を裏づけており、Xcode 27 beta 4のデプロイメントターゲットとしてmacOS 12〜27を挙げています。⁴ 変わるのはデフォルトです。macOSデプロイメントターゲットが27.0に達したターゲットはARCHS_STANDARDからx86_64を受け取らなくなり、Appleが示す対処は自分でARCHSにx86_64を追加することです。¹ Intel向けの出荷は、自然に受け継ぐものから、自分で宣言する選択へと変わります。

ARCHS_STANDARDからx86_64が外れると、ビルドは失敗しますか？

Appleの記述には、エラーも警告も、いかなる診断も出てきません。Appleが述べているのはデフォルトの変更です。macOSまたはDriverKitの27.0以上のターゲットは「デフォルトではUniversalとしてビルドされません」¹ 2つではなく1つのアーキテクチャスライスでコンパイルされ、リンクされ、署名されるビルドは、正当なビルドです。しかもXcode 27が使用を必須とするApple silicon Mac上では、その違いは実行時には見えません。² Appleはデフォルトを述べるだけで帰結は書き残していないので、「静か」という言葉はAppleではなく私のものです。ビルドログがこの話題を持ち出すのを待つのではなく、アーカイブ済みバイナリに対してlipo -archsを確認してください。

新しい挙動をXcode 26で試せますか？

いいえ。Xcode 26.6（ビルド17F113）で直接確かめました。macOS専用プロジェクトでMACOSX_DEPLOYMENT_TARGETを27.0に上書きしてもARCHS_STANDARD = arm64 x86_64に解決され、同じコマンドを26.0で実行した場合と同一でした。¹³ 前世代のツールチェーンはこのしきい値を実装していないので、Xcode 26上でビルド設定をいくらいじっても、この変更の予習にはなりません。Xcode 26.6でも再現できるのは適用範囲のほうです。同じプロジェクトがiOSのSDKに対してはARCHS_STANDARD = arm64、macOSのSDKに対してはarm64 x86_64に解決され、macOSとDriverKitのデプロイメントターゲットだけを名指しした記述と一致します。¹¹³

いまApple silicon Macは必須ですか？

Xcode 27を動かすなら、条件なしで必須です。「Xcode 27はApple silicon Macにのみインストールでき、そこでのみ動作します」² Appleはハードウェアの条件に加えてソフトウェアの下限も設けており、Xcode 27 beta 4にはmacOS Tahoe 26.4以降が必要です。⁴ Intel向けの開発は古いツールチェーン上で生き延びます。Appleの表現もそうなっています。「macOS 27のようにRosettaをサポートするmacOSバージョンであれば、Intel向けの開発は引き続き可能です」² ただしAppleのRosettaドキュメントは、その道にも境界を引いています。Rosettaは汎用ツールとしては「macOS 27まで提供され」、その後はメンテナンスされていない古いゲーム向けの縮小された一部機能が残るとされています。⁷

押さえておくべき点

macOSアプリ開発者へ: - まずは-sdkフラグなしで監査し、SUPPORTED_PLATFORMSとSDKROOTを必ず併せて読み、そもそもそのターゲットがmacOS向けにビルドされるかを問う段階ではMACOSX_DEPLOYMENT_TARGETを無視してください。XcodeはiOS専用プロジェクトにもmacOSデプロイメントターゲットを書き込みます。私のプロジェクトでも3つがMac向けに何もビルドしないまま値を報告しています（26.5、26.5、26.2）。¹⁴ - 設定を解決する前に、xcodebuild -listでターゲットを列挙してください。私のSafari機能拡張へのプロジェクト単位のクエリは、iOS専用プロジェクトだと報告し、2つのmacOSターゲットを隠しました。¹⁴

ユーザーにIntel Macが含まれるチームへ: - x86_64は受け継ぐのではなく、明示的に決めてください。macOSデプロイメントターゲットを27.0に上げるときはARCHSを設定しましょう。Appleの記述が示す対処はまさにそれであり、飛ばしても警告は出ません。¹ - 検証はビルド設定でもアーカイブのInfo.plistでもなく、アーカイブ済みバイナリに対するlipo -archsで行ってください。私のアーカイブのうち2つは、バイナリがUniversalであるにもかかわらずアーキテクチャのメタデータをまったく持っていません。¹⁴

リリース管理者へ: - ハードウェアの期限と出荷の期限を切り分けてください。Xcode 27は初日からApple silicon Macを要求しますが、Universalの出力はmacOS 12以降に届き続けますし、AppleはmacOS 28の暦日を公表していません。²⁴ - アプリだけでなく、Intelプラグインとインストーラパッケージも棚卸ししてください。AppleはIntelプラグインが「設定に表示されない場合がある」と警告しており、Intelプラグインはホストプロセス全体を変換実行へ追い込みます。⁷¹⁰

27のサイクルは、重大な変更を目立たない場所に隠し続けています。リンカの削除とモジュール名のルールはツールチェーンを上げた瞬間にビルドを丸ごと壊し、@Stateマクロはソースレベルで壊し、起動画面のキーは申請をブロックします。Intelのデフォルト変更は何も壊さないまま、それでもプロダクトを変えてしまいます。だからこそ、アップグレードした後ではなく前に監査する価値があるのです。シリーズ全体のハブはAppleエコシステムシリーズにあります。

参考文献