Xcode 27で古いデプロイメントターゲットがビルドエラーに。その境界線とは

macOSTahoe ·
Xcode 27で古いデプロイメントターゲットがビルドエラーに。その境界線とは

Xcode 27はmacOS 12またはiOS 15より古いバージョン向けのビルドを拒否します。Xcode 26は10.13を黙って許可していました。何が変わったのか、誰が影響を受けるのか、隠された抜け道、そして本当の期限である2027年4月について解説します。

何年も問題なくビルドできていたMacアプリのプロジェクトを開き、Xcode 27ベータに切り替えてビルドを押すと、そこで止まります。

The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.13, but the range of supported deployment target versions is 12.0 to 27.0.99.

Xcode 26では、この一文は読み飛ばせる黄色い警告でした。Xcode 27では赤いエラーとなり、ビルドは先に進みません。変化はそれだけですが、見た目より小さくもあり、大きくもあります。小さいというのは、Appleのドキュメントが何年も前からmacOS 11とiOS 15という下限を謳っていたからであり、大きいというのは、Xcodeがそれを一度も強制してこなかったため、リリース済みの実に多くのアプリが密かにその抜け道に依存しているからです。

本記事では、Xcode 27が実際に何を強制するのか（Apple自身の一覧表とリリースノートから）、Xcode 26が実際には何を許容していたのか（手元のディスク上のSDKから）、誰が影響を受けるのか、エラーを警告に戻す非公開の設定、そして本当に意味のある期限がXcode 27のリリースそのものではなく、来春のApp StoreのSDK要件である理由を明らかにします。

要点

  • Xcode 27がサポートするデプロイメントターゲットは、macOS 12〜27、iOS/iPadOS/tvOS 15〜27、watchOS 9〜27、visionOS 1〜27、DriverKit 21〜27です（ベータ6時点のAppleのXcodeサポートページによる）。これを下回るとビルドは失敗します。
  • Xcode 26はドキュメント上macOS 11を下限としていましたが、実際には10.13を受け付けていました。 macOS 26.0 SDKの設定ファイルを確認したところ、有効なデプロイメントターゲットは34種類あり、10.13から始まっていました。Xcode 27は、ドキュメント上の範囲を実際に強制する範囲にすることで、このギャップを埋めています。
  • macOSの下限はベータ期間中に変動しました。 6月時点のAppleの注記はUniversalバックデプロイメントについて「macOS 27を含めそれ以下」としており、開発者たちはこれをBig Sur（macOS 11）と解釈していました。ベータ6の注記は「macOS 12以降」となっています。計画はBig SurではなくMontereyを基準にしてください。
  • 非公開の抜け道が存在します。 __DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO というもので、エラーを警告に戻すと報告されています。これは非サポートであり、いつ消えてもおかしくなく、Appleがそれらのターゲットをテストしていないという事実を変えるものではありません。
  • 本当の期限はApp StoreのSDK要件です。 Xcode 26のSDKは2026年4月28日に提出必須となりました。Appleが同じパターンを繰り返すなら、Xcode 27のSDKは2027年4月頃に必須となり、その時点でApp StoreアプリがmacOS 11やiOS 14をサポートすることは、通常の手段では不可能になります。

公式な数字

Apple のXcodeサポートページには、各Xcodeバージョンがビルド対象にできる範囲を示す表が掲載されています。重要なのは次の比較です。

プラットフォームXcode 26.6Xcode 27 beta 6
macOS11 – 26.512 – 27
iOS / iPadOS15 – 26.515 – 27
tvOS15 – 26.515 – 27
watchOS8 – 26.59 – 27
visionOS1 – 26.51 – 27
DriverKit20 – 25.521 – 27

注意して読んでください。「Xcode 27で最小要件が引き上げられた」という見出しは半分しか正しくありません。iOSについては、ドキュメント上の下限はXcode 26を通じて15のままであり、Xcode 27でも15のままです。macOSは11から12へと1バージョン動きます。watchOSは8から9へ。書面上は控えめな引き締めです。

書面に書かれていないのは、Xcode 26の数字が一度も強制されてこなかったという事実です。

Xcode 26が実際に許容していたもの

Xcode内の各SDKには、どのデプロイメントターゲットを有効と見なすかを宣言する設定ファイルが含まれています。筆者のマシン（Xcode 26.0.1 (17A400) をインストール済み）では、そのファイルは次の場所にあります。

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json

読み出すにはコマンド一つで済みます。

python3 -c '
import json
d = json.load(open("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/SDKSettings.json"))
t = d["SupportedTargets"]["macosx"]
print(t["MinimumDeploymentTarget"], "->", t["MaximumDeploymentTarget"])
print(len(t["ValidDeploymentTargets"]), "valid:", t["ValidDeploymentTargets"][:6], "...")
'

Xcode 26.0.1での出力は次の通りです。

10.13 -> 26.0.99
34 valid: ['10.13', '10.14', '10.15', '11.0', '11.1', '11.2'] ...

つまり、Appleの表では「macOS 11」となっていた一方で、SDKは「10.13」と言っており、Xcodeはデプロイメントターゲットの欄に10.13と入力することを許し、警告を出した上でビルドしていたのです。Michael Tsaiはこの実態を率直に説明しています。開発者は「手動でより古いターゲットを入力できてきた」のであり、多くのインディーMacソフトウェアはまさにそれを行い、High Sierra、Mojave、Catalinaのユーザーを最新ビルドに留めてきました。

Xcode 27ベータをインストールしている場合は、そのSDKに対して同じコマンドを実行すれば（Xcode-beta.appに置き換えて）、新しい下限を確認できます。筆者のマシンにはベータが入っていないため、12.0という数字についてはファイルを自分で読み取るのではなく、Appleの表と開発者の報告に頼っています。

警告からエラーへ

この診断メッセージ自体は新しいものではありません。Appleのビルドシステムは何年も前から「サポートされるデプロイメントターゲットのバージョン範囲はXからYです」という警告を出してきました。Xcode 27での変化はその深刻度です。

bleepingswift.comの記事は、Xcode 27で表示されるiOS版のメッセージを次のように引用しています。

The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to xx.x, but the range of supported deployment targets versions is 15.0 to 27.0.x

macOS版も同じメッセージで、MACOSX_DEPLOYMENT_TARGETと12.0から27.0.99という範囲になります。これはターゲットごとに発生するため、拡張機能、ウィジェット、テストバンドルがすべて古いターゲットを引き継いでいるアプリでは4回表示されることになり、メインアプリだけを修正してもビルドは通りません。

Vienna RSSのメンテナーは、ベータ公開の2日後にあたる6月10日にこれに遭遇しました。彼らのターゲットは10.13で、Xcode 26では警告もエラーもなくビルドできていましたが、Xcode 27では「それは強制要件（ビルドエラー）になった」とのことです。その後彼らが抱いた懸念は、この状況にあるすべてのMac開発者に共通するものです。すなわちXcode 26はmacOS 27でサポートされる見込みがなく、「古いXcodeを使い続ける」という回避策には賞味期限があるということです。

6月からベータ6の間に何が変わったか

macOSの下限はベータ期間を通じて安定していませんでした。自分が読んでいるのがどの時点の情報なのかを知っておく価値があります。

6月時点でのIntelに関するリリースノートは、Apple Developer Forumsで引用されている通り、次のようになっていました。

Xcode 27 will only install and run on Apple silicon Macs. The macOS SDK is still Universal for back deployment up to and including macOS 27. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

これは下限について何も述べていません。Tsaiの初日の要約は、この状況を「ターゲットにできる最小値はBig Sur（Apple Silicon Macの場合はMonterey）になった」と読み取り、ViennaRSSのissueははっきりとmacOS 12だとしていました。現行のベータ6リリースノートはこれを解決しています。

Xcode 27 will only install and run on Apple silicon Macs. The macOS 27 SDK supports back deploying Universal (Intel and Apple Silicon) apps to macOS 12 and later. Intel development is still possible with macOS versions that support Rosetta like macOS 27. (162138432)

issue番号は同じですが、macOS 12と明記するよう文言が変更されています。Tsaiの9月の更新でも同じことが指摘されています。「Xcode 27 Beta 6は、現在macOS 12.0を最小デプロイメントターゲットとしてドキュメント化している」とのことです。移行計画をBig Sur基準で立てていた場合は、Montereyに修正してください。

実際に影響を受けるのは誰か

影響の大きい順に、3つのグループがあります。

High SierraからBig SurまでをまだサポートしているMacアプリ

これはTsaiの投稿が取り上げているグループであり、プラットフォームから最も同情されないグループでもあります。Eternal StormsのMatthias Gansrigler-HradはMastodonで率直にこう述べています。

I don't appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It's my decision

これらの開発者にとって、Xcode 27は強制的な二者択一を迫ります。下限を引き上げて2017〜2020年のシステムのユーザーを切り捨てるか、Xcode 26に留まってmacOS 27 SDKとそれに依存するすべてを諦めるかです。

iOSアプリ、特に15未満のiOSライブラリ

AppleのiOS向け下限はXcode 26以来15のままなので、すでに15をターゲットにしているアプリには何の影響もありません。しかしエコシステムにはそれより低い最小値を宣言しているライブラリが数多くあり、そのそれぞれが、それをインポートするすべてのプロジェクトで診断メッセージを発生させるようになりました。GitHubのissueトラッカーは6月最初の週に「Support Xcode 27: raise minimum iOS deployment target to 15（Xcode 27対応：iOSの最小デプロイメントターゲットを15に引き上げてほしい）」というほぼ同一のタイトルの要望で埋め尽くされました。Package.swiftで.iOS(.v12)を宣言していたFacebook iOS SDKや、Adjust、DataDog、SDWebImageなどが対象です。メンテナーが対応していないパッケージに依存している場合、対応されるかフォークするまでブロックされたままになります。

依存関係の奥に古いターゲットが埋もれている場合

これは見えにくいケースです。あなたのアプリは15をターゲットにしています。しかし推移的に依存しているSwiftパッケージは13をターゲットにしています。Xcode 27はあなたのツールチェーンでそのパッケージをビルドし、13を検出してビルドを失敗させます。Swift Package Managerには利用側からの上書き手段が存在しません。bleepingswiftの結論は筆者の見解と一致しており、「platforms宣言でより古い最小値を宣言しているパッケージは、新しいパッケージバージョンへのアップグレードか、フォークして要件を自分で更新するかのいずれかが必要」だとしています。

Xcodeバージョンごとのデプロイメントターゲット下限

隠された抜け道

抜け道は存在します。知っておくべきですが、扱いには注意が必要です。

Ighor Julyは7月24日付の記事（Tsaiが引用している）で、Xcode 27ベータにおいて「隠された設定によってそれらのエラーが警告に戻り、コンパイラは私がテストした古いターゲット向けのビルドを引き続き生成した」と報告しています。彼はこの設定を、ベータツールチェーンにおいて「非公開で、通常のXcodeインターフェースには存在せず、現時点ではテスト目的のみ」と説明しています。Tsaiの投稿の読者であるHarald Striepeが、その名称を明らかにしています。

__DIAGNOSE_INVALID_DEPLOYMENT_TARGET_AS_ERROR = NO

これはビルド設定なので、置き場所はビルド設定が置かれる場所と同じです。コンフィグレーションに紐付けた.xcconfigファイル、あるいはターゲットのBuild Settingsペイン下部に追加するUser-Defined設定です。これを設定すれば、デプロイメントターゲットのチェックはXcode 26の挙動に戻ります。

ここからが注意点であり、決して小さくありません。

非サポートである。 先頭の2つのアンダースコアは、Appleが内部設定に使う慣習です。どのベータでも名前が変わったり削除されたりする可能性があり、それはあなたが依存し始めた直後のベータでも起こり得ます。

戻るのは警告であって、テストではない。 この変更全体に対するTsaiの評価は、正直な捉え方として全文を引用する価値があります。

I'm frustrated, too, but it's more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn't tested that it actually worked.

エラーを無効にすることは、Appleが以前からテストしておらず、今や明示的にサポート対象外としているターゲット向けにビルドする状態へ戻ることを意味します。Xcode 26でCatalina上で壊れていたものは、そのまま壊れたままです。

App Storeの問題は解決しない。 ここで、本当に重要な期限の話に移ります。

本当の期限は2027年4月

Xcode 27がリリースされたこと自体は、誰にもその使用を強制しません。強制するのはApp StoreのSDK要件です。

Apple の今後の要件ページには、2026年4月28日以降、App Store Connectにアップロードされるアプリは Xcode 26と26系SDKでビルドされていなければならないと記載されています。Appleは何年もの間、毎年春に同じルールを新しいSDKへ適用してきました。すなわち、リリースからおよそ7か月後の4月に、現行SDKが必須になるというパターンです。

このパターンが今後も続くなら（Appleは2027年の日付を発表していないため、これは事実ではなくパターンからの推測です）、2027年4月頃からすべてのApp Store提出物はXcode 27のSDKでビルドされている必要が生じます。その時点で次のようになります。

  • Mac App Storeのアプリは、デプロイメントターゲットが12.0未満のままでは更新できなくなります。ストアが受け付ける唯一のツールチェーンがそのビルドを拒否するためです。
  • 同じ理由で、iOS App Storeのアプリは15.0未満のままでは更新できなくなります。
  • 抜け道の設定がApp Storeの検証を通過するかどうかは分かりません。これをテストしたという報告は誰からも上がっておらず、筆者ならこれを前提にビジネスを組み立てることはしません。

App Storeの外、つまりDeveloper IDによる直接配布であれば、これらは一切当てはまりません。手元のMacでXcode 26が動く限り、Xcode 26でビルドし続けることができます。ただし、それが次の問題です。

Xcode 26を残しておく方法と、それが通用しなくなる理由

分かりやすい緩和策は、両方をインストールしておくことです。xcodesのようなツールを使えば、Xcode 26.6を27ベータと並行して残し、xcode-selectで切り替えるのは簡単です。今年中に出荷が必要な10.13ターゲットのプロジェクトであれば、これは正しい判断です。

しかしこれには期限があります。Appleのサポート表では、Xcode 26.6の要件は「macOS Tahoe 26.2〜macOS Tahoe 26.x」とされています。macOS 27上で動くとはどこにも書かれておらず、Tsaiの見立ては「古いバージョンのXcodeを使うのは良い解決策ではない。Golden Gateではサポートされていないからだ」というものです。起動はするかもしれませんが、しなかったとしてもAppleが修正することはありません。さらに彼は、より分かりにくいコストを付け加えています。

Swift also makes it more difficult to call newer APIs when using an older SDK.

Xcode 26に留まるということは、macOS 26 SDKに留まるということであり、macOS 27のAPIは動的ルックアップを介してのみアクセス可能になるか、まったくアクセスできなくなります。メンテナンスモードのアプリであれば問題ありません。しかし積極的に開発を続けているものにとっては、じわじわとした締め付けになります。

Xcode 27自体がApple Silicon専用に

これは同じリリースに含まれる別の変更であり、デプロイメントターゲットの話と混同されがちなので、両者を明確に区別しておきます。

リリースノートの記述は明確です。「Xcode 27はApple Silicon Macにのみインストールでき、そこでのみ動作する」。バイナリはarm64専用であり、これは、あるIntel MacBook Proのオーナーがフォーラムで確認したとおりです。リリースノートの「macOS Tahoe 26.4以降が必要」という記述から別の期待を抱いていたところ、そうではなかったとのことです。TahoeはごくわずかなIntel Macでも動作しますが、Xcode 27は動作しません。

SDKは引き続きUniversalです。Xcode 27からx86_64のスライスやUniversalバイナリをビルドすることは可能ですが、それをApple Silicon上で行う必要があるというだけです。これは開発者側のハードウェア要件であって、アプリの配布に対する制限ではありません。

もう一つのIntel関連の変更：27.0ではUniversalがデフォルトでなくなる

ベータ6のリリースノートには、「Intel Deprecation（Intelの非推奨化）」の項目にもう一つIntel関連の記載があり、ほとんどの報道で見落とされています。

Build targets with a min deployment target set to macOS 27.0 or DriverKit 27.0 will not build Universal by default. The ARCHS_STANDARD build setting will no longer include x86_64 when MACOSX_DEPLOYMENT_TARGET or DRIVERKIT_DEPLOYMENT_TARGET >= 27.0. The x86_64 architecture can be added to the ARCHS build setting if this is needed. (161837535)

これは理にかなっています。macOS 27はどのIntel Macでも動作しないため、27.0専用のターゲットには動作させるIntelマシンがそもそも存在しないからです。しかし副作用があります。Rosettaはまだmacos 27に存在しており、Appleの9月1日付の開発者向け注記は27がその最終リリースであることを改めて確認しています。x86_64をデフォルトで含まなくなった27.0専用アプリは、Apple Silicon上のRosettaでも実行できなくなります。これが問題になるのは、Intel専用のプラグインホストなどを配布していた場合だけです。必要であればARCHSにx86_64を明示的に追加してください。

誰も言及しない3つ目の下限：libc++の11.0

同じ非推奨化リストの中に埋もれている項目があります。「macOSにおけるC++標準ライブラリの最小サポートデプロイメントターゲットが11.0に引き上げられた」というものです。これは12.0というビルドシステムの下限とは異なる、より低い下限であり、宣言するデプロイメントターゲットではなく、リンクするC++ランタイムに適用されます。実際にこれが表面化するのは、隠された設定などでビルドシステムのチェックを回避しており、なおかつC++コードで10.15以前をまだターゲットにしている場合だけです。その場合、次に立ちはだかるのはlibc++自体です。

対処法：依存関係

自分のターゲットについては、修正はテキストフィールドの数字を変えるだけです。依存関係については以下の通りです。

CocoaPods。 すべてのPodターゲットのデプロイメントターゲットを下限に書き換えるpost_installフックを追加し、pod installを実行してビルドフォルダをクリーンにします。bleepingswiftが紹介しているフックが標準的な形です。重要なのは、今日エラーになっているものだけでなく、すべてのPodターゲットに適用することです。

Swift Package Manager。 上書きする手段は存在しません。取れる選択肢は、platformsを引き上げたパッケージバージョンにアップデートする、issueを起票または賛成票を投じる、あるいはフォークしてPackage.swiftを編集し、上流が追いつくまでプロジェクトをそのフォークに向けるかのいずれかです。まずissueトラッカーを確認してください。主要なSDKについては、6月最初の週に誰かがリクエストを起票しており、たいていプルリクエストも添えられています。

ベンダー提供のフレームワークとXCFramework。 これらはInfo.plistとMach-Oのロードコマンドに独自の最小値を持っています。Xcode 27は古いバイナリフレームワークのリンク自体は拒否しませんが、リンカはバージョンの不一致について警告を出します。古いターゲットでの動作は、まさにテストされた通り、つまりテストされていません。

ここでの「正直さ」の意味

Tsaiの捉え方についてしばらく考えてみる価値があります。それによって、何に対して怒るべきかが変わってくるからです。

Xcode 26はmacOS 10.13をサポートしていたわけではありません。10.13と入力することを許し、コードを生成していただけであり、26のSDKに含まれるフレームワークが2017年のOS上で正しく動作するかをAppleがテストしていたわけではありません。そうしたビルドを出荷していた開発者は、Appleがすでに切り捨てたOSに対して自ら品質保証を行っていたことになります。フレームワークは設計上、後方互換性があるため、多くの場合はうまくいっていました。しかしこの「多くの場合」という言葉には重い意味があり、SDKとターゲットの間のギャップは年々広がっていったのです。

Xcode 27は、ドキュメント上の範囲を実際の範囲にしました。それは古いMacのユーザーと、そのユーザーに応えてきた開発者にとっての損失です。しかしそれは、Appleがかつて約束していた何かを失うことではありません。

App StoreのSDK要件のタイムラインとデプロイメントターゲットへの影響

規制面での問題

もう一つの論点があります。8月26日、TsaiはEUサイバーレジリエンス法についてのコメントをまとめました。この法律の主要な義務は2027年12月11日に発効し、少なくとも5年間のセキュリティアップデートを求めています。Frederikと名乗る読者が、App Storeとの関わりについて次のように指摘しました。

Once you update the minimum supported OS version of your app (which you might be forced to by newer Xcode versions… you can no longer provide updates for your older app versions on the App Store.

これはまさに本記事が説明している仕組みです。App Storeでは、1つのアプリにつき現行バージョンは1つしか存在しません。Xcode 27のSDKが必須となり、下限がmacOS 12に上がった場合、macOS 11のユーザーは受け取った最後のビルドを、セキュリティアップデートのないままずっと使い続けることになります。それを開発者の義務とみなすのか、Appleの義務とみなすのか、あるいは誰の義務でもないとみなすのかは法律家が判断すべき問題です。技術的な事実としては、Appleの配布モデルにはブランチという仕組みが存在せず、Xcode 27はそれをより多くの開発者にとって可視化しようとしているということです。

移行チェックリスト

古いターゲットを持つMacアプリについて、順を追って説明します。

  1. 実際のユーザーを棚卸しする。 アナリティクスで誰もmacOS 12未満にいないと分かれば、これは1行の変更とリリースノートで済みます。ほとんどのアプリはこのケースに当てはまります。
  2. すべてのターゲットでデプロイメントターゲットを12.0（macOS）または15.0（iOS）に設定する。 拡張機能、ヘルパー、テストも含めてです。Xcode 27ベータでビルドし、診断メッセージをすべて解消します。
  3. 依存関係を監査する。 下限を下回るplatforms宣言やpodspecがないか確認し、必要であればフォークします。
  4. 取り残されるユーザーへの対応を決める。 10.13〜11.0のユーザーに向けて本当に出荷を続ける必要があるなら、2027年4月より前にXcode 26での最終ビルドを計画し、App Storeの外で配布するか、凍結したレガシーバージョンとして提供し、それを公に告知します。
  5. 隠された設定を本番環境に出荷しない。 古いOS上で自ら結果をテスト済みであり、次のベータでその設定が消える可能性を受け入れられる場合を除きます。
  6. 27.0のみをターゲットにしている場合はARCHSを確認する。 気づかないうちにx86_64を落としている可能性があります。

よくある問題のトラブルシューティング

アプリのターゲットを引き上げたのにエラーが消えない

プロジェクト内の別のターゲットが、まだ古い値のままになっています。ナビゲーターでプロジェクト（ターゲットではなく）を選択し、プロジェクトレベルのデプロイメントターゲットを確認したうえで、各ターゲットと各テストバンドルも確認してください。ウィジェットとアプリ拡張機能が原因になりがちです。

直接依存していないパッケージ名がエラーに表示される

推移的な依存関係です。swift package show-dependencies（またはXcodeのパッケージグラフ）を使って、どこがそれを引き込んでいるのかを特定し、その中間パッケージをアップデートするか、末端をフォークしてください。

コマンドラインのxcodebuildは失敗するがXcodeのGUIではビルドできる

コマンドラインがどのツールチェーンを使っているか確認してください。xcode-select -pです。GUIは26、CLIは27になっている（あるいはその逆）ことがあります。

隠されたフラグを設定したのに何も変わらない

そのフラグは、チェックが実行されるレベルでビルドシステムから見える状態になっている必要があります。プロジェクトレベルのxcconfigが最も安全な置き場所です。一つのターゲットにしか設定していない場合、他のターゲットは引き続きエラーになります。それでも何も変わらない場合、使用しているベータでそのフラグがすでに削除されている可能性があります。

CIランナーがIntelです

Xcode 27はそれらにはインストールできません。これは設定の問題ではなくハードウェアの移行の問題です。ホスト型プロバイダーはすでに以前からApple Siliconランナーへ移行しています。セルフホストのIntel Mac miniは、現行ツールチェーンでのビルドについてはもう終わりを迎えています。

FAQ

Xcode 27はiOSの最小要件を引き上げますか

書面上は変わりません。Appleの表はXcode 26以来iOS 15としてきました。変わるのは強制の有無です。Xcode 26では警告付きでビルドできていた15未満のターゲットが、Xcode 27では失敗するようになります。

Xcode 27でのmacOSの最小要件は何ですか

AppleのXcodeサポートページとベータ6のリリースノートによれば、macOS 12 Montereyです。ベータサイクルの初期にはBig Surと解釈されていましたが、その解釈は現在では古いものです。

引き続きUniversal（Intel＋Apple Silicon）アプリをビルドできますか

はい、Apple Silicon Macからであれば可能です。macOS 27 SDKはmacOS 12以降へのUniversalバックデプロイメントをサポートしています。デフォルトでx86_64が外れるのは、ターゲットが27.0以降に設定されている場合だけです。

いつXcode 27に移行しなければなりませんか

直接配布であれば、Xcode 26が動くMacを持っている限り、移行の必要はありません。App Storeについては、Appleが27 SDKを必須にした時点であり、これまでのパターンから見ると2027年4月頃になると考えられます。Appleはその日付をまだ発表していません。

隠された設定はApp Store向けビルドで安全ですか

分かりません。これを使ってビルドした提出物の報告は誰からも上がっておらず、ドキュメント化されていない内部フラグです。リリースパイプラインではなく、ローカルビルドやレガシーブランチ向けのツールとして扱ってください。

まとめ

Xcode 27のデプロイメントターゲットに関する変更は、小さな修正でありながら長い尾を引きます。Appleは下限をそれほど大きく引き上げたわけではありません。macOSで1バージョン、iOSでは変化なしです。しかし、その下限があたかも任意であるかのように振る舞うのをやめました。そして10年分のインディーMacソフトウェアは、まさにその振る舞いの上に成り立っていました。今日目にするビルドエラーは、ユーザーが最新のシステムを使っているなら簡単に直せますが、そうでなければきちんと直すことは不可能です。

自分がどちらに当てはまるのかを把握してください。まだmacOS 11以前へ出荷しているなら、残された猶予はそれが動くMac上のXcode 26だけであり、App Storeアプリについてはおよそ7か月で閉じてしまいます。そうでないなら、数字を引き上げ、依存関係を修正し、27専用であればARCHSを確認して、先に進んでください。Appleはついに、いずれ必ずやるつもりだったことをドキュメント化しただけなのです。

関連記事：Rosettaが終了する前にIntelアプリを点検する、macOS 27によるIntel互換性の打ち切り、macOS Tahoeでの開発環境のトラブルシューティング、今年のベストMac開発者ツール