Intel Macでアプリが起動するか判断できず、Xcodeの設定だけを見て出荷してよいか迷っていませんか。
最短の確認方法は、最低対応OSと利用者の範囲を決め、最終成果物のアーキテクチャを調べて、対象プロセッサごとに実機検収することです。macOS 27を最低対応OSにする場合は、Xcode 27の既定の架構設定も必ず確認してください。CIの構築ホストと、アプリが対応するCPUは別の判断事項です。
macOSデスクトップアプリの対応範囲とIntel利用者への告知を見直す開発者向けです。
Appleプラットフォームのリリース担当者が、設定・成果物・テスト結果を一続きの証拠として残す際にも役立ちます。
CI担当者は、ビルドノードの要件をアプリの対応範囲と混同しないために活用してください。
最終更新:2026年10月27日。Xcode 27のリリースノート、macOS 27に関するAppleの案内、UniversalバイナリおよびRosettaの技術資料を照合しています。設定値の判断では、プロジェクトで実際に解決されたビルド設定も確認してください。
macOS 27のIntel互換性は、何を基準に判定する?
まず決めるのは、ビルドするMacではなく、アプリを使う人に約束する対応範囲です。macOSのバージョン、最低Deployment Target、CPUアーキテクチャ、Rosettaによる実行、Universalバイナリは、それぞれ別の条件として扱います。
AppleはmacOS 27をApple silicon向けとして案内しています。一方、Xcode 27のリリースノートは、macOS 27 SDKを使って、より古いmacOSに対応するUniversalアプリを構築できることも説明しています。したがって、「macOS 27がApple silicon向け」という情報を、旧OSで動くアプリも一律にApple silicon専用だと読み替えてはいけません。(macOS 27に関するAppleの案内、Xcode 27リリースノート)
| 製品の対応方針 | 検収するアーキテクチャ | 判断時の確認事項 |
|---|---|---|
| macOS 27とApple siliconの利用者に限定 | arm64を候補にする | Xcode 27の既定値、依存ライブラリ、配布条件を確認 |
| より古いmacOSのIntel利用者も対象 | Universalを候補にする | 各対象OSでの動作と、全バイナリのアーキテクチャを確認 |
| 製品の対応OSや利用者が未確定 | 出荷方針を保留する | サポート声明を決めるまでIntel対応の削除を確定しない |
Rosettaの案内やIntel専用アプリに関するAppleの説明も、対象となる条件を読んでください。特定の案内を、すべての旧macOSにおける互換性の保証や、将来の利用可能期間に関する一般則として扱うことはできません。(Rosettaの技術説明)
設定を変更する前に、ターゲットごとの値をそろえる
アプリ本体だけを確認して終わると、Extensionやヘルパーなど、別ターゲットに残った設定の食い違いを見落としやすくなります。まず、リリースに含めるターゲットごとに、最低Deployment Targetとアーキテクチャ関連の値を照合します。
| 設定項目 | 検収で確認すること | 見落とした場合のリスク |
|---|---|---|
| macOS Deployment Target | 製品の最低対応OSと一致しているか | 対応範囲の表示と実際のビルド条件がずれる |
ARCHS |
解決後の設定に必要なアーキテクチャが含まれるか | 意図しないCPU向けのスライスが欠ける |
EXCLUDED_ARCHS |
不要な除外がターゲットごとに残っていないか | 必要なアーキテクチャまで除外される |
VALID_ARCHS |
古い上書き設定が残り、現在の設定を妨げていないか | 設定画面の想定とビルド結果が一致しない |
手順1:すべての配布対象ターゲットを洗い出す
アプリ本体に加え、配布物へ同梱するExtension、Helper、Frameworkなどを一覧にします。ターゲットごとに設定を見て、アプリ本体の値を他のターゲットにもそのまま当てはめないでください。
手順2:解決後のビルド設定を記録する
Xcodeの画面に表示された設定だけで判断せず、利用するSchemeと構成で解決された値を出力します。たとえば、次のように確認できます。
xcodebuild -showBuildSettings -scheme "App"
出力からMACOSX_DEPLOYMENT_TARGET、ARCHS、EXCLUDED_ARCHS、VALID_ARCHSを確認し、ターゲットや構成によって値が異なる場合は、その理由を記録します。Xcodeのターゲット設定は構成や上書きの影響を受けるため、設定の継承関係も合わせて確認してください。(ターゲットのビルド設定を構成するAppleの資料)
手順3:macOS 27向けの既定値を確認する
Xcode 27のリリースノートでは、macOSのDeployment Targetが27以上の場合、ARCHS_STANDARDの既定値にx86_64が含まれないと説明されています。macOS 27を最低対応OSにするターゲットは、この挙動を前提に実際の解決値を調べ、Intel利用者を対象に残すなら必要な設定を検討してください。(Xcode 27リリースノート)
注意:
ARCHS_STANDARDという設定名だけでは、配布物に必要なCPU向けバイナリが含まれるとは証明できません。対象ターゲットの解決値と、ビルド後のアプリ本体・同梱ライブラリを両方確認してください。
設定の変更後は、クリーンビルドと通常の配布工程を通し、アーカイブに入った成果物を調べます。Appleの技術資料にあるように、Apple siliconとIntelの両方を対象にするアプリでは、Universalバイナリの構成を確認する必要があります。(Universal macOSバイナリを構築するAppleのガイド)
ビルド後は、配布するファイルそのものを調べる
プロジェクト設定に両アーキテクチャが表示されていても、最終的な配布物に両方が含まれるとは限りません。アーカイブやエクスポート済みアプリを検査し、アプリ本体だけでなく、実行時に読み込むFrameworkや同梱ライブラリも確認します。
手順4:最終成果物のアーキテクチャを確認する
アプリ内の実行ファイルを指定し、次のコマンドで構成を調べます。パスと実行ファイル名は、対象のアプリに合わせて変更してください。
lipo -archs "/path/to/App.app/Contents/MacOS/App"
Intel利用者にも配布するUniversalアプリなら、検査対象にarm64とx86_64の両方があることを確認します。アプリ本体の確認だけで終えず、埋め込みFrameworkや、アプリが依存するバイナリにも同じ観点を適用してください。
手順5:検収の証拠を成果物と結び付ける
検査結果は、リリース対象の成果物を識別できる情報と一緒に保存します。どのアーカイブを確認したのか、各バイナリに何のアーキテクチャが含まれていたのかを記録すれば、設定変更後や再リリース時に同じ確認を再現できます。
AppleのTN3117は、Apple silicon向けのアーキテクチャ構築で発生するエラーの切り分けを扱っています。Universal化の設定を変えた後にビルドが失敗する場合は、対象アーキテクチャや依存バイナリの条件を照合する資料として参照できます。(TN3117:Apple siliconのビルドエラーを解決する資料)
公開前に、対象プロセッサごとに動作を確かめる
Universalバイナリができたことと、各環境で製品として動くことは別の検収項目です。Apple siliconとIntel Macのそれぞれで、配布予定の成果物を使って起動と主要機能を確認します。
手順6:Apple siliconでネイティブ動作を確認する
実際に配布するアプリを起動し、起動処理と製品で重要な操作を確認します。OSのバージョン、アプリの識別情報、使用した成果物、確認結果を記録し、開発用ビルドと出荷物を混同しないようにします。
手順7:Intel MacでIntel向けの経路を確認する
Intel利用者を対応対象に含める場合は、対象OSを満たすIntel Macで、配布予定のアプリを実行します。起動だけではなく、重要機能や外部コンポーネントの読み込みも確かめてください。Intel Mac上で確認できるのはその環境で実行される経路であり、単一のMacでビルドが通ったことを、両プロセッサの動作証明として扱わないでください。
実機をすぐに用意できない場合は、Apple siliconの開発環境だけでIntel対応の完了と判断せず、Intel環境での検収を未完了として管理します。CIの実行結果には、使用したホストと成果物の検査結果を分けて記録してください。CIワークフローの条件整理が必要なら、PRビルドの起動条件を見直す記事も参考になります。
公開方針は、対応ユーザーと検収証拠がそろってから決める
リリース前は、以下を順に確認してください。
- [ ] 最低対応OSと、Intel Mac利用者をサポートするかを製品の案内で明確にした
- [ ] 配布対象の各ターゲットで、Deployment Targetとアーキテクチャ設定を確認した
- [ ] macOS 27を対象にする場合、Xcode 27で解決された
ARCHSを確認した - [ ] 最終アーカイブと同梱バイナリを調べ、必要なアーキテクチャを確認した
- [ ] Apple siliconとIntel Macのそれぞれで、対象成果物の動作結果を記録した
Intel利用者や古いmacOSの利用者も対応対象なら、Universalの配布経路を残し、成果物と両環境でのテストを検収条件にします。macOS 27とApple siliconにサポート範囲を限定するなら、依存ライブラリと配布条件を確認したうえで、arm64のみの構成を評価できます。後者を選ぶ場合も、製品の対応表記と実際の配布物を一致させてください。
ローカルのMacだけで検収すると、検証対象を増やすたびに実機の確保や環境の切り替えが必要です。一方、LinuxのCIだけではmacOS専用のビルドやIntel Mac上の実行確認を完結できず、借用した端末では継続的な再検証の予定を組みにくいことがあります。異なるMac環境でビルドやアーキテクチャ検査を再現したい場合は、リモートMacの利用場面を確認し、掲載されている環境・接続・提供条件が自分の検収要件に合うかを判断してください。
公開前のFAQ
よく確認される点を、対応範囲・設定・成果物・実機検証に分けて整理します。前述の確認結果と食い違いがないか、出荷判断の前に照合してください。
macOS 27向けのアプリでもIntel Mac対応を残す必要がありますか?
macOS 27だけを対象にするのか、より古いmacOSを使うIntel利用者もサポートするのかで判断します。macOS 27がApple silicon向けという案内だけで、旧OSのアプリ要件まで決まるわけではありません。製品の対応OSと利用者への告知を先に確認してください。
macOS 27を最低対応OSにすると、Xcode 27はx86_64も自動でビルドしますか?
Xcode 27のリリースノートでは、Deployment Targetが27以上の場合、ARCHS_STANDARDの既定値にx86_64は含まれません。ターゲットごとの上書きで結果が変わることがあるため、リリースノートと実際の解決値、最終成果物を照合してください。
配布するアプリがarm64とx86_64の両方を含むか、どう確認できますか?
配布予定のアプリ本体をlipo -archsで調べ、両方のアーキテクチャが表示されるか確認します。同梱Frameworkやライブラリも個別に検査し、結果を対象アーカイブと結び付けて記録してください。設定画面の表示だけでは、出荷物の構成を確認したことにはなりません。
Apple siliconとIntel Macの両方で、何を分けて検収すべきですか?
Apple siliconではネイティブのarm64経路を、Intel Macではx86_64経路を確認します。それぞれでOSのバージョン、成果物の識別情報、起動と主要機能の結果を残してください。ビルド成功と各プロセッサでの実行確認は、別の証拠として扱います。
ローカル環境だけで進める方法は、既存のMacをすぐ使える場合に適していますが、検収先の切り替えや端末確保が制約になりやすく、Linux CIだけではmacOS固有の確認を補えません。別のMac環境を一時的に用意する必要があるなら、KVMFLUXの料金・利用条件で公開内容を確認し、必要なOS・Xcode環境や接続条件が満たされる場合に限って、レンタルを検収計画へ加えてください。
よくある質問
macOS 27向けのアプリでもIntel Mac対応を残す必要がありますか?
必要かどうかは、macOS 27を使う利用者だけを対象にするのか、より古いmacOSを使うIntel Mac利用者も対象にするのかで決まります。Appleの案内ではmacOS 27はApple silicon向けとされていますが、それだけで旧OS上のアプリ要件まで決まるわけではありません。製品の対応OSと利用者への告知を先に確認してください。
macOS 27を最低対応OSにすると、Xcode 27はx86_64も自動でビルドしますか?
Xcode 27のリリースノートによると、macOSのDeployment Targetが27以上の場合、ARCHS_STANDARDの既定値にx86_64は含まれません。ただし、プロジェクト独自の設定やターゲットごとの上書きがあれば結果は異なります。リリースノートを確認したうえで、対象ターゲットの実際のビルド設定と成果物を照合してください。
配布するアプリがarm64とx86_64の両方を含むか、どう確認できますか?
ビルド設定だけではなく、配布予定のアプリ本体をlipo -archsで調べ、arm64とx86_64が表示されるか確認します。アプリ内のFrameworkや同梱ライブラリも別々に調査し、必要な構成が欠けていないか確認してください。最終アーカイブやエクスポート済み成果物の検査結果を、リリース記録に残すと再確認しやすくなります。
Apple siliconとIntel Macの両方で、何を分けて検収すべきですか?
Apple silicon側ではネイティブのarm64実行を、Intel Mac側ではx86_64の実行をそれぞれ確認します。各環境でOSのバージョン、検査した成果物の識別情報、起動結果、重要機能の結果を記録してください。ビルドが成功したことだけでは、両方のプロセッサでアプリが動作する証拠にはなりません。
macOSアプリの実機検証環境を、必要な期間だけ
KVMFLUXなら、M4搭載の専有Mac miniを借りて、実機でのビルドや動作確認に活用できます。 SSHでのビルド実行にも、VNCでのデスクトップ操作にも対応し、検証内容に合わせて使い分けられます。 他の利用者と共有しない専有環境で、継続的なビルドやリリース前の確認を進められます。 日・週・月・四半期から利用期間を選べるため、短期の検証にも常設のビルド環境にも導入しやすいです。