Xcode 27リリース：必要環境、デプロイメントターゲット、そして何が壊れたか

Xcode 27は2026年9月14日、ビルド27A266aとしてリリースされました。フィードにiOS 27.0 RCの項目が載ってから3日後のことで、iOS 27.0（24A437）、macOS 27.0（26A428）をはじめとする27系プラットフォームと同時のリリースです。App Store Connectは同日から27.0 GA SDKでビルドしたアプリの受け付けを始めており、RC SDKによるビルドは9月9日から受け付けていました。¹⁵ 動作にはmacOS Tahoe 26.6以降とApple siliconのMacが必要で、Swift 6.4と27系SDKを搭載し、デバッグできるデバイスはiOS 17以降、そしてデプロイメントターゲットの下限がmacOS 12、watchOS 9、DriverKit 21の3つで引き上げられています。²³ 既存プロジェクトにとっては、確実にビルドが止まる変更が3つ（@Stateマクロ、SE-0508によるソース互換性の破壊、-ld64リンカフラグ）、エラーになり得る依存関係スキャンのルールが1つ、ARCHS_STANDARDの無警告の変更が1つ、警告が2つ加わりました。スキャンのルール以外はすべて、以下で27A266a上で実際に再現しています。²⁴⁶ {.answer-block}

TL;DR

• 日付とビルド番号。 AppleのReleasesフィードには、Xcode 27（27A266a）と27.0系の6つのOSすべてが9月14日（月）付けで掲載されています。「iOS 27.0 RC (24A437)」の項目は9月11日（金）付けで、App Store ConnectがRC SDKでのアップロード受け付けを始めた2日後にあたり、GA版も同じビルド番号です。¹⁵ App Store Connect自身の9月14日付けリリースノートには、Xcode 27でビルドしたアプリをApp StoreとTestFlight向けにアップロードできるようになったと書かれています。⁵
• 必要環境と下限が動きました。 Xcode 26.6はmacOS 26.2で動き、iOS 15のデバイスをデバッグできました。Xcode 27はmacOS 26.6が必要で、Apple silicon上でしか動作せず、デバッグできるのはiOS 17、tvOS 17、watchOS 10以降で、これは実機だけでなくシミュレータにも当てはまります。最小デプロイメントターゲットはmacOS 11から12へ、watchOS 8から9へ、DriverKit 20から21へ上がり、iOS、iPadOS、tvOSは15のまま、visionOSは1のままです。²³
• 確実に失敗する3つの変更。 @Stateマクロ：Apple自身の例、つまり宣言時に初期値を持つ@Stateプロパティを他の格納プロパティより先に代入するイニシャライザが、variable 'self.title' used before being initializedで失敗します。配列または辞書リテラルの初期値とinitアクセサを持つ計算プロパティは、ゲッターが先に書かれているとコンパイルできず、AppleはこれをSE-0508によるソース互換性の破壊だとしています。そしてXcode 15でドキュメント化されていた-ld64リンカフラグは、ld: library 'd64' not foundでリンクに失敗します。²⁴⁶⁸
• 警告するか、エラーになり得るか、何も言わない4つの変更。 ld64がなくなったため、リンカは-ld_classicを警告付きで無視します。1回の依存関係スキャン内でClangモジュール名が重複すると「may report an error」（エラーを報告することがある）とされています。27.0に設定したmacOS専用ターゲットは、x86_64を自分で戻さない限りarm64のみでビルドされ、何の警告も出ません。そしてPreviewProviderには「Use #Preview instead.」という27.0の非推奨メッセージが付き、各プレビュー修飾子にはそれぞれ置き換え先のメッセージが付いていますが、デプロイメントターゲットが27.0未満だとコンパイラはどれも表示しません。²⁴
• 9月15日時点でAppleはXcode 27.1をリリースしていません。 Releasesフィードにもリリースノートの索引にも載っておらず、AppleのiPhone Duo開発者ページでは27.1ベータは今も「later this month」（今月後半）とされています。Duo開発者向けの記事で書いたSDKの空白は、まだそのままです。¹

9月14日に何がリリースされたのか？

リリースノートのOverviewにはこうあります。「Xcode 27 includes Swift 6.4 and SDKs for iOS 27, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27 supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27 requires a Mac running macOS Tahoe 26.6 or later.」（Xcode 27はSwift 6.4と各27系SDKを含み、iOS 17以降、tvOS 17以降、watchOS 10以降、visionOSでの実機デバッグに対応し、macOS Tahoe 26.6以降のMacを必要とする）² 手元のMacでは、xcodebuild -versionはXcode 27.0 Build version 27A266aを、swift --versionはApple Swift version 6.4 (swiftlang-6.4.0.34.1 clang-2100.3.34.1)を出力します。⁴

26.6と比べてXcode 27には何が必要なのか？

ビルドマシンをアップグレードする前に確認すべき文書は、Appleの互換性一覧表です。2つの行を並べると次のようになります。³

この表の裏には2つの帰結が隠れています。InstrumentsはiOS 17、watchOS 10、tvOS 17より古いデバイスを受け付けなくなったので、古いiPhoneで組んだプロファイリング環境は、アプリのコードに手を付ける前に動かなくなります。² またAppleは、Device Hubのキーボードとポインタ操作の対応範囲を一文で区切っています。「only supported on the following OS versions and newer: macOS 15.0, iOS 18.0, tvOS 18.0, watchOS 11.0, visionOS 2.0.」（macOS 15.0、iOS 18.0、tvOS 18.0、watchOS 11.0、visionOS 2.0以降でのみ対応）²

Apple silicon必須という条件については、Xcodeを動かすMac側に回避策はなく、7月にIntelの記事を読んだ方にはすでに古い話でしょう。GA版のノートも7月の文言をそのまま残しています。「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.」（Xcode 27はApple silicon Macにしかインストールも実行もできない。macOS 27 SDKはUniversalアプリのmacOS 12以降への後方デプロイに対応する。macOS 27のようにRosettaをサポートするmacOSであれば、Intel向けの開発は引き続き可能）² 3つ目の文が示す回避策は出荷先のMacのためのものであって、ビルドに使うMacのためのものではありません。

ツールチェーンでは何が変わったのか？

リンカ。 GA版のノートは一文で片付けています。”The ld64 linker has been removed and the -ld_classic option is no longer supported.”（ld64リンカは削除され、-ld_classicオプションはサポートされなくなった）² 27A266a上で実際に見るとこうなります。ツールチェーンのusr/binにあるリンカのバイナリはldの1つだけで、自身をld-27037.1、2026年8月25日ビルドと報告します。古いフラグを渡してもリンクは失敗しません。hello.cにint main(void){return 0;}の1行だけを書いてclang hello.o -o hello_classic -Xlinker -ld_classicを実行すると、ld: warning: -ld_classic is no longer supported and will be ignoredと出力しつつ、終了コード0で実行ファイルを書き出します。Xcode 15でAppleがドキュメント化していたもう1つの綴り、-ld64のほうは結果が悪く⁸、clang hello.c -o hello_ld64 -Wl,-ld64はld: library 'd64' not foundで失敗して終了コード1を返します。新しいリンカが-ld64を-l d64、つまりd64という名前のライブラリの要求として読むためです。⁴ つまりOTHER_LDFLAGSに-ld_classicを残しているプロジェクトはビルドこそ続きますが、リンクのたびに新しい警告が出て、旧リンカから得ていた挙動はすべて消えています。-ld64を残しているプロジェクトはリンクが止まり、しかもそのエラーはリンカの名前をまったく出しません。ld64の記事では、これらのフラグの出どころを調べ、両方の実行結果を記録しています。

デフォルトのアーキテクチャ。 Intel Deprecationのセクションがルールを述べています。”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.”（最小デプロイメントターゲットをmacOS 27.0またはDriverKit 27.0にしたターゲットは、デフォルトではUniversalでビルドされない。MACOSX_DEPLOYMENT_TARGETまたはDRIVERKIT_DEPLOYMENT_TARGETが27.0以上のとき、ARCHS_STANDARDにx86_64は含まれなくなる）² これをマルチプラットフォームのプロジェクト（Yawara、SUPPORTED_PLATFORMS = iphoneos iphonesimulator macosx xros xrsimulator）で、xcodebuild -showBuildSettings -sdk macosxを使って再現しました。-sdk引数なしだとこのプロジェクトはARCHS_STANDARDをまったく解決しないという癖があり、これはIntelの記事で扱っています。MACOSX_DEPLOYMENT_TARGET = 26.0ではARCHS_STANDARD = arm64 x86_64に、27.0ではARCHS_STANDARD = arm64に解決され、ARCHS_STANDARD_64_BITはどちらでもarm64 x86_64のままです。⁴ 警告は一切出ません。Universalで出荷していてターゲットを上げるなら、ARCHSにx86_64を自分で足してください。

C++標準ライブラリ。 「The minimum supported deployment target on macOS for the C++ standard library has been increased to 11.0,」（C++標準ライブラリがmacOSでサポートする最小デプロイメントターゲットは11.0に引き上げられた）とあり、ノートは「Potentially breaking changes」の見出しの下に挙動の変更を列挙しています。その先頭は、multi{map,set}::findが必ずしも最初に一致した要素を返さなくなったという項目です。² 新機能のリストは長く、std::chrono値のハッシュ化、zip、std::optional<T&>、std::views::indices(n)などが並びます。²

依存関係スキャンと、それを失敗させ得るルール。 AppleはSwiftの依存関係スキャナを「to avoid redundant setup work and header searches when looking up Clang modules during a single dependency-scan action」（1回の依存関係スキャン操作でClangモジュールを探す際、冗長なセットアップ作業とヘッダー検索を避けるため）に最適化したと述べており、この高速化には要件が伴います。「every Clang module reachable from a single Swift dependency-scan action must have a unique module name. If two module maps visible to the same scan declare a Clang module with the same name, the scan may report an error. Previously, the scanner may have tolerated duplicating names.」（1回のSwift依存関係スキャン操作から到達できるClangモジュールはすべて一意のモジュール名を持たなければならない。同じスキャンから見える2つのモジュールマップが同名のClangモジュールを宣言していると、スキャンはエラーを報告することがある。以前のスキャナは名前の重複を許容していた可能性がある）² Appleは引っかかる形を2つ挙げています。「projects or SDKs that vend the same Clang module name from more than one location on the header search path, and vendored third-party sources that ship a module.modulemap redeclaring an SDK module.」（ヘッダー検索パス上の複数の場所から同じClangモジュール名を提供するプロジェクトやSDK、そしてSDKのモジュールを再宣言するmodule.modulemapを同梱したサードパーティのソース）² リンカの削除と同じく、このルールはデプロイメントターゲットではなくツールチェーンのアップグレードで発火します。ld64の記事では、衝突する2つのモジュールマップをスキャナに通し、SDKのモジュールを隠してしまう同梱のSQLite3シムをコンパイルし、7つのプロジェクトを両方の形について監査しています。

何がコンパイルできなくなるのか？

@Stateマクロ。 この変更はXcodeではなくiOS 27のリリースノートに載っており、効いてくるのはデプロイ先のターゲットではなく、ビルドに使うコンパイラです。”Xcode 27 introduces a new @State implementation that avoids this repeated evaluation. This new behavior back-deploys to iOS 17 aligned OSes. The new @State is implemented with a Swift macro. It is largely source compatible with the property wrapper version, with a few exceptions.”（Xcode 27は、この繰り返し評価を避ける新しい@State実装を導入する。この新しい挙動はiOS 17世代のOSまで後方デプロイされる。新しい@StateはSwiftマクロで実装されており、いくつかの例外を除いてプロパティラッパー版とおおむねソース互換である）⁶ Appleは例外を4つ挙げ、そのうち2つにはコードリストを付け、残り2つには一文か二文だけを添えています。”In rare situations, the automatic inference of generic arguments of @State is less flexible with the macro implementation. Write the type with more specificity.”（まれに、@Stateのジェネリック引数の自動推論がマクロ実装では柔軟さに欠ける。型をより具体的に書くこと）と、”Composing @State with other property wrappers or macros is not supported.”（@Stateを他のプロパティラッパーやマクロと組み合わせることはサポートされない）です。⁶ 既存コードを捕まえるのは、コードリスト付きの2つのほうです。1つ目は、宣言時にすでに初期値を持つ@Stateプロパティに代入するイニシャライザで、SwiftUIはこの代入を常に捨ててきましたが、今では「some such cases no longer compile.」（そうしたケースの一部はコンパイルできなくなる）とされています。⁶ 2つ目は、すべての格納メンバーがprivateのときにコンパイラが合成するprivateなメンバーワイズイニシャライザで、「The state macro disables this synthesized initializer. So the code above no longer compiles.」（stateマクロはこの合成イニシャライザを無効にする。よって上のコードはコンパイルできなくなる）とあります。⁶ 27A266aでは1つ目の例が書かれたとおりに失敗し、pageを代入する行でerror: variable 'self.title' used before being initializedが出ます。titleが存在する前に、マクロのセッターがselfに対して走るためです。self.title = titleをその上に移すと同じファイルがコンパイルでき、@Stateへの代入は従来どおり捨てられます。⁴⁶ 2つ目の例、つまり宣言時の初期値を持たない@Stateのある構造体に対して拡張からself.init(page: page, title: title)を呼ぶものは、私の実行では変更なしでコンパイルできました。マクロ展開を見ると、それを可能にしている形が分かります。マクロは@storageRestrictions(initializes: _page)のinitアクセサの裏にprivate var _page: SwiftUICore.State<StickerPage>を生成しており、これがメンバーワイズイニシャライザにpage:を受け取らせる構文です。⁴ このノートは確認すべき形の説明として読み、それぞれを自分のコードで確かめてください。@Stateマクロの記事では、出荷中の4つのアプリで両方のパターンを数えています。あの記事は今回のGAテストより前、7月にベータ版のノートをもとに書いたもので、そこで開いたままだった疑問もここで閉じます。イニシャライザ内でバッキングストレージに直接代入する_page = State(initialValue:)は、宣言時の初期値があってもなくても27A266aでコンパイルできます。⁴

SE-0508による破壊。 Swift CompilerのKnown Issuesにこうあります。”A computed property with both an init accessor and an array/dictionary literal initial value will no longer compile if the getter is declared before the init accessor.”（initアクセサと配列または辞書リテラルの初期値を両方持つ計算プロパティは、ゲッターがinitアクセサより先に宣言されているとコンパイルできなくなる）コードリストが続き、その後に出典が示されます。”This is a known source break from SE-0508.”（これはSE-0508による既知のソース互換性の破壊である）回避策は全文でこうです。”Swap the init accessor and the getter such that the init accessor is declared first.”（initアクセサが先に宣言されるよう、initアクセサとゲッターを入れ替える）² SE-0508は”Array expression trailing closures”（配列式の末尾クロージャ）で、Swift 6.4で実装されており、提案書はまさにこのケースを予告しています。”If the getter is declared before the init accessor, we will now attempt to parse as a trailing closure,”（ゲッターがinitアクセサより先に宣言されていると、今後は末尾クロージャとして解析を試みる）に加えて、”init accessors are however considered for disambiguation, so swapping the accessors is sufficient to make this valid regardless of initial value used,”（ただしinitアクセサは曖昧さ解消の対象になるため、アクセサを入れ替えれば初期値が何であれ有効になる）、そしてこのケースは「does not appear in the source compatibility suite, or for internal Swift projects at Apple.」（ソース互換性スイートにもApple社内のSwiftプロジェクトにも現れない）と書かれています。⁷ 9行の構造体で再現できます。ゲッターを先にすると、swiftcはアクセサの行でerror: initializers may only be declared within a typeを出して失敗し、@storageRestrictions(initializes:)のinitアクセサをgetの上に移すと同じファイルがコンパイルできます。⁴

struct Container {
    private var storage: [Int] = []
    var items: [Int] = [] {
        @storageRestrictions(initializes: storage)
        init(initialValue) { storage = initialValue }   // getより前に置く必要がある
        get { storage }
        set { storage = newValue }
    }
}

PreviewProvider。 Previewsのセクションには非推奨が1つ挙がっています。”PreviewProvider and its family of preview modifiers.”（PreviewProviderとそのプレビュー修飾子ファミリー）² SDKにもそれが反映されており、プロトコルには1つのメッセージ、各修飾子にはそれぞれ別のメッセージが付いています。iOS 27 SDKのSwiftUIインターフェースでは、public protocol PreviewProviderは@available(anyAppleOS, deprecated: 27.0, message: "Use #Preview instead.")の下にあり、previewLayoutは「Use #Preview(traits: .sizeThatFitsLayout) or .fixedLayout(width:height:) instead.」、previewDisplayNameは「Use #Preview(“name”) instead.」、previewInterfaceOrientationは「Use #Preview(traits: .landscapeLeft) or other orientation traits instead.」、previewDeviceは「Use the device picker in Xcode’s canvas.」（Xcodeのキャンバスにあるデバイスピッカーを使うこと）、そしてpreviewContextはPreviewContextおよびPreviewContextKeyプロトコルとともに「Use #Preview with a Widget timeline provider or entries instead.」（代わりにWidgetのタイムラインプロバイダまたはエントリを指定した#Previewを使うこと）と言っています。⁴ これらのメッセージを目にするかどうかは、2つの事実で決まります。コンパイラは非推奨のバージョンをデプロイメントターゲットと比較するので、修飾子が警告を出すのは最小バージョンが27.0のターゲットだけです。previewLayout、previewDisplayName、previewDeviceを使うファイルは、-target arm64-apple-ios27.0-simulatorでは3つの警告を出し、17.0と26.0では何も出しませんでした。そしてPreviewProvider自体は、別の理由でまったく警告しません。SDKはこれをanyAppleOSの非推奨指定の直上に@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)を付けて宣言しており、私の検証では、この組み合わせを持つプロトコルは27.0ターゲットでも、準拠に対しても引数の型としての使用に対しても警告を出しませんでした。一方、同じプロトコルを@available(iOS, deprecated: 27.0)だけ、あるいはanyAppleOSの形だけで非推奨にすると、どちらでも警告が出ました。修飾子は自身の宣言にanyAppleOSの非推奨指定しか持たず（それらを収めるextension SwiftUICore.View側にintroduced属性があり、その継承された形は警告を抑制しません）、だから修飾子は警告し、プロトコルは警告しないのです。⁴ 出荷中のどのデプロイメントターゲットでもビルドログはどちらにせよ沈黙するので、PreviewProviderと修飾子を検索して#Previewに移行してください。キャンバスは新しい#Preview(arguments:)構文により、引数ごとにグリッド表示するようになりました。²⁴

Systemの新しいstat()。 SystemライブラリはSwift APIとしてstat、lstat、fstat、fstatatを提供するようになり、Stat型とFilePath.stat()インスタンスメソッドが加わりました。² ノートには、修飾なしのstat()を呼ぶ拡張が新しいメソッドと衝突する問題が修正済みとして載っています。その衝突が生きていた間にDarwin.の修飾を足していたなら、そのままで構いません。²

Address Sanitizerは逆方向です。 「Address Sanitizer might fail to launch on iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 when building with Xcode 26.4 or older.」（Xcode 26.4以前でビルドすると、iOS 27.0、tvOS 27.0、watchOS 27.0、visionOS 27.0でAddress Sanitizerが起動に失敗することがある）回避策はXcode 26.5以降で、CIマシンに古いXcodeを残したままデバイスだけ27.0に更新しているチームには関係のある話です。²

IDEとツールでは何が変わったのか？

• Interface Builderがシミュレータなしでビルドします。 新しいコンパイルモードtoolchainは、”for UIKit (Cocoa Touch) based documents. Enabled by default, toolchain allows compiling IB documents without the need to download a simulator, which is especially useful for build servers.”（UIKit（Cocoa Touch）ベースのドキュメント向け。デフォルトで有効なtoolchainは、シミュレータをダウンロードせずにIBドキュメントをコンパイルでき、ビルドサーバーで特に有用）とされています。²
• シミュレータの起動が速くなり、再起動もできます。 「The simulator runtimes now contain a pre-built dyld cache. This will make first launch of a simulator much faster,」（シミュレータのランタイムにビルド済みのdyldキャッシュが含まれるようになり、シミュレータの初回起動が大幅に速くなる）とあり、simctlにはrebootコマンドが加わりました。² 既知の問題が1つ残っており、Appleの言葉ではこうです。「Some simulator runtimes are not completely deleted when removed, re-appearing after a reboot.」（一部のシミュレータランタイムは削除しても完全には消えず、再起動後に再び現れる）²
• devicectlのJSONはバージョン5です。 xcrun devicectl --versionは642.16を報告し、list devices --json-outputは"jsonVersion": 5を書き出します。AppleはhardwareProperties、deviceProperties、connectionPropertiesフィールドを非推奨にしてproperties辞書に置き換え、これらをまだ含む結果には_deprecationNoticeが付きます。²⁴
• StoreKitテスト。 StoreKit構成のUIでオファーコードを定義でき、ローカルテスト用にサブスクリプションバンドルを構成でき、Transaction Managerでデバイスなしにオファーコード付きの購入を試せます。²
• Organizer。 Insights Overviewが「summarizes high-impact performance regressions」（影響の大きいパフォーマンス低下を要約する）とされ、HitchesメトリクスがScrollingメトリクスに置き換わりました。²
• コーディングアシスタント。 モデル一覧にGoogle Geminiが加わり、「Planning with agents is now first class in Xcode,」（エージェントによるプランニングがXcodeの一級機能になった）とあって、プランはエージェントが先に進む前に承認する編集可能なMarkdown成果物になっています。コーディングエージェントの記事でベータ版時点のワークフローを扱っており、GA版のノートにはまさにその成果物のためのMarkdownエディタが載っています。²
• ローカライズ。 エージェントがString Catalogのエントリを翻訳でき、ローカリゼーションのエクスポートがヘッダーファイルからNSLocalizedStringなどのマクロを抽出するようになりました。²
• Icon Composer。 ノートはこれをIcon Composer 2.0と呼び、「a new sharper rendering mode for upcoming 2027 operating systems」（来たる2027年のOS向けの、より鮮明な新しいレンダリングモード）としています。27A266aに同梱されたバンドルはバージョン27.0を報告します。²⁴
• テスト。 テストプランでUIテスト中に対象アプリがクラッシュしたときの扱いをオフから致命的な失敗まで設定でき、swift testには--maximum-repetitionsと--repeat-until [pass|fail]、そして最後に表示される失敗のサマリーが加わりました。²
• デバッグ。 ブリッジングヘッダーがある場合、LLDBは「can now directly import explicitly built Swift modules and PCH from DerivedData,」（DerivedDataから明示的にビルドされたSwiftモジュールとPCHを直接インポートできるようになった）とされ、language swift task treeコマンドがSwift Concurrencyのタスクを一覧します。²

私なら今週こうする

1. CIに触る前に互換性の行を読みます。ビルド用MacにはmacOS 26.6、Apple siliconのみ、最も古いテストデバイスはiOS 17、そしてmacOS 12、watchOS 9、DriverKit 21のうち自分の製品に当てはまるものです。²³
2. -ld_classicと-ld64をgrepして両方削除します。前者はリンクのたびに警告付きで無視され、後者は即座に失敗します。ビルド設定を開いているついでに、SDKのモジュールを再宣言している手書きのmodule.modulemap、つまりAppleが一意なモジュール名のルールで名指ししている形を探しておきます。²⁴
3. macOSまたはDriverKitのターゲットを27.0にしていてIntel向けにも出荷しているなら、ARCHSを明示的に設定します。ARCHS_STANDARDだけではarm64になり、これはmacOSについて私が再現し、Appleは両方について明言しています。²⁴
4. PreviewProvider、previewLayout、previewDisplayName、previewDeviceを検索し、それぞれのアノテーションが示すメッセージに従います。プロトコルは#Previewへ、previewLayoutは#Preview(traits: .sizeThatFitsLayout)または.fixedLayout(width:height:)へ、previewDisplayNameは#Preview("name")へ、previewDeviceはキャンバスのデバイスピッカーへ。修飾子が警告するのは27.0のデプロイメントターゲットだけで、PreviewProviderへの準拠はどのターゲットでも警告しないため、出荷中のターゲットのビルドログは沈黙したままです。⁴
5. Xcode 27で一度ビルドして、2つの診断を確認します。1つはvariable 'self.title' used before being initializedで、宣言時の初期値をすでに持つ@Stateプロパティを他の格納プロパティより先に代入するイニシャライザで出るもので、@Stateマクロの記事が順を追って説明しています。もう1つはinitializers may only be declared within a typeで、配列または辞書リテラルの初期値とinitアクセサを持つプロパティで出るもので、アクセサをゲッターの上に移します。²⁴⁶
6. App Store Connectが受け付けるようになった今、27系SDKでTestFlightビルドをアップロードします。その際、起動画面のルールとUIKitのシーン必須化を頭に入れておいてください。どちらも27にリンクした瞬間からアプリを拘束します。⁵⁶

よくある質問

Xcode 27はいつリリースされましたか？

2026年9月14日（月）、ビルド27A266aとして、iOS 27.0、iPadOS 27.0、macOS 27.0、tvOS 27.0、visionOS 27.0、watchOS 27.0と同じ日にリリースされました。フィードのiOS 27.0 RC（24A437）項目は9月11日付けで、App Store ConnectがRC SDKでのビルドを受け付け始めた2日後です。¹⁵

Xcode 27に必要なmacOSは何ですか？

Apple silicon Mac上のmacOS Tahoe 26.6以降です。Intel Macにはインストールも実行もできません。同日にリリースされたmacOS 27.0でも動作します。²³

Xcode 27の最小デプロイメントターゲットは何ですか？

iOS 15、iPadOS 15、tvOS 15、watchOS 9、visionOS 1、macOS 12、DriverKit 21です。Xcode 26.6と比べると、watchOSは8から、macOSは11から、DriverKitは20から上がりました。³

Xcode 27でもUniversalなMacアプリをビルドできますか？

はい、macOS 12までさかのぼってビルドできますが、ターゲットのMACOSX_DEPLOYMENT_TARGETが27.0になるとデフォルトではそうなりません。その場合ARCHS_STANDARDはarm64だけに解決されるので、ARCHSにx86_64を自分で追加します。²⁴

Xcode 27.1は出ていますか？

2026年9月15日時点では出ていません。AppleのReleasesフィードとXcodeリリースノートの索引にはXcode 27しか載っておらず、AppleのiPhone Duo開発者ページはXcode 27.1ベータを今も「Coming later this month」（今月後半に公開予定）としています。iPhone Duo SDKは今回のリリースには含まれません。¹

Xcode 27のリリースノートはどこにありますか？

Appleの開発者向けドキュメントサイトのXcode Release Notesの下に、このリリース用のページが1つあります。本記事で引用したセクションはOverview、Linking、Intel Deprecation、Previews、Swift Compiler、Address Sanitizer、Instruments、Device Hub、devicectl、Simulator、Interface Builder、C++ Standard Library、Organizer、Coding Intelligence、Source Editor、Icon Composer、StoreKit Testing in Xcode、Localization、Testing、Swift Package Manager、Debugging、Systemです。² @Stateマクロの変更はXcodeのノートではなく、iOSおよびiPadOS 27のリリースノートのSwiftUIの項にあります。⁶

出典