What’s new in Xcode 26

ハイライト

Xcode 26 ではダウンロードサイズを 24% 削減し、workspace のロードを 40% 高速化、複雑な式の入力レイテンシを 50% 低減しました。さらに #Playground マクロにより、任意の Swift ファイルでインラインに実験コードを実行できるようになっています。

主要内容

大規模な Swift プロジェクトを開いて少し複雑な式を入力すると、カーソルの後ろに文字が出るまで半秒待たされる。workspace を切り替えるたびに Xcode がすべてのインデックスを再ロードするのを待たなければならない。完全な Xcode パッケージをダウンロードするだけで数十 GB のディスクが消える――ここ数年、開発者から最も多く寄せられていた不満の代表例です。Landmarks のような SwiftUI Preview 付きのプロジェクトでは、文字列から座標を解析する正規表現をデバッグしたり、ある struct のフィールドをちょっと確認したりするだけのために、アプリ全体を起動して該当ページに遷移する必要があり、効率はお世辞にも良いとは言えませんでした。

Xcode 26 はこれに対し、「ツールを軽くする」ことと「フィードバックを速くする」ことを同じ一つの仕事として捉えました。ダウンロードサイズは 24% 削減され、2014 年の Xcode 6 よりも小さくなっています。Simulator runtime はデフォルトで Intel サポートを含まなくなり、Metal toolchain はオンデマンドダウンロードに変更されました（00:52）。workspace のロードは 40% 高速化され、複雑な式における入力レイテンシは最大 50% 低減しています（01:20）。エディタ面では、新しい #Playground マクロにより、どのファイルでもインラインに実験コードを書いて実行でき、その結果は canvas tab にリアルタイムで表示されます。セッションのデモでは、Eliza 氏がこのマクロを使って「Grand Canyon が中国に位置している」というバグを発見しましたが、その間アプリの再起動は一度も行いませんでした（05:12）。さらに Coding Assistant、Voice Control の Swift モード、Icon Composer、String Catalog の型安全な Swift シンボルが加わり、Xcode 26 は「思いついたらすぐ検証できる」というフィードバックループを一段と短くしています。

詳細

#Playground マクロは、新たに導入された Playgrounds モジュールに含まれており、任意の Swift ファイルに配置できます。SwiftUI Preview と同じく「書きながら見る」系のツールですが、対象が View ではなく任意の式である点が異なります（04:47）。最小の使い方はモジュールの import とブロックを書くだけの 2 ステップです。

import Playgrounds

#Playground {
  let landmark = Landmark.exampleData.first
  let region = landmark?.coordinateRegion
}

ポイント:

• import Playgrounds で #Playground マクロをそのファイルに取り込みます。マクロ自体は Xcode 26 に同梱されています。
• #Playground { ... } はコンパイル時に展開され、ブロック内の各式は独立した項目として canvas tab に表示されます。プロパティ値や Quick Look による可視化も含まれます。
• Landmark.exampleData.first のように、プロジェクト内の実際の型へアクセスする書き方がそのまま動作します。playground 用に専用の target を用意する必要はなく、ソースファイル上にそのまま置けます。
• ブロック内のコードを変更すると canvas が関連する式を自動的に再実行するため、「修正 → アプリ再起動 → 再現 → 観察」のループから解放されます。

Eliza 氏が座標バグを特定した際の核心は、ある正規表現でした。元のバージョンはオプションの小数部のみをマッチさせており、符号を考慮していなかったため、負の経度を正の値として解析してしまっていました（06:33）。

func scanForFloatingPointNumbers() -> [Regex<Substring>.Match] {
    return self.matches(of: /[0-9]*[.][0-9]+/)
}

ポイント:

• Regex<Substring>.Match は Swift 正規表現の新しい戻り値型で、各マッチは元文字列内の range を保持します。canvas はその range をハイライト表示してくれます。
• self.matches(of:) は String の拡張メソッドで、正規表現リテラル /.../ と組み合わせれば手動で NSRegularExpression を組み立てる必要がありません。
• このコードの問題点は canvas 上で一目瞭然です。デモでは "lon: -113.16096, lat: 36.21904" を入力した結果、マッチ範囲に - が含まれていないことがすぐに見て取れました（06:49）。

修正版は、小数部の前にオプションの [+-]? を追加するだけです（07:33）。

func scanForFloatingPointNumbers() -> [Regex<Substring>.Match] {
    return self.matches(of: /[+-]?[0-9]*[.][0-9]+/)
}

ポイント:

• [+-]? で符号位をオプション化することで、負数を正しくキャプチャできるようになります。
• canvas は変更後すぐに再実行されるため、「正規表現を直す → range に負号が含まれているか確認する」というフィードバックは秒単位で完了します。アプリの再起動は不要です。
• 最初の playground に戻ると、Grand Canyon の座標は正しい位置に戻っています。デバッグの一連の流れがすべてソースコードビュー内で完結しているのが分かります。

パフォーマンスとテスト面では、UI テストにスクロールのカクつきを計測する XCTHitchMetric が新たに追加されました（34:40）。

func testScrollingAnimationPerformance() throws {
    let measureOptions = XCTMeasureOptions()
    measureOptions.invocationOptions = .manuallyStop

    let app = XCUIApplication()
    app.launch()
    let scrollView = app.scrollViews.firstMatch

    measure(metrics: [XCTHitchMetric(application: app)], options: measureOptions) {
        scrollView.swipeUp(velocity: .fast)
        stopMeasuring()
        scrollView.swipeDown(velocity: .fast)
    }
}

ポイント:

• XCTHitchMetric(application:) は対象アプリを引数として直接受け取り、measure ブロック内での hitch（アニメーションのフレーム落ち）の総時間を計測します。
• XCTMeasureOptions().invocationOptions = .manuallyStop により手動で stopMeasuring() を呼べるようになるため、「上スワイプ」のみを計測対象に含め、「下スワイプ」は除外するなど、本当に関心のある方向だけを測定できます。
• scrollView.swipeUp(velocity: .fast) で最速のスクロールを発生させることで、アニメーション性能の問題が露呈しやすくなります。
• このメトリクスはパフォーマンスのベースラインに組み込むのに適しており、リグレッションが起きて hitch 時間が増えれば Test Report ですぐに気づけます。

そのほか押さえておきたいポイントとして、エディタ tab の挙動が Safari スタイルに変わり、特定のファイルに pin できるようになりました（01:52）。Multiple Words search は検索エンジン技術を活用し、行をまたいだ語のクラスタを近接度に基づいて検索します（02:21）。Voice Control に Swift モードが追加され、自然な読み上げ方でコードを書けるようになりました（03:22）。Icon Composer は独立した app として Xcode 26 と同時にリリースされ、1 つのファイルからマルチプラットフォーム・マルチモードの app icon を出力できます（08:15）。String Catalog は型安全な Swift シンボルを生成できるようになり、on-device モデルが翻訳用コメントを自動生成してくれます（09:48）。Coding Assistant は ChatGPT、Anthropic Claude（Opus、Sonnet）、ローカルの Ollama / LM Studio に接続でき、プロジェクトのコンテキストを認識した上でコードを直接書き換えられます（10:38）。デバッガは Swift Concurrency のスレッド切り替えに追従し、Instruments は M4 以降のデバイスで Processor Trace を提供するほか、Power Profiler も新たに追加されました。

重要ポイント

• やること: 「データの中身をちょっと見たい」というニーズを、暫定的な print から #Playground ブロックへ書き換える。

  • なぜ価値があるのか: playground ブロックはソースファイル内に置けて canvas がリアルタイムに更新されるため、struct のフィールド、正規表現、日付フォーマット処理を確認するためにアプリ全体を起動する必要がなくなります。
  • 始め方: 「UI 以外の暫定検証は一律 #Playground を使う」というルールをチーム規約に加え、よく使うサンプルデータを Landmark.exampleData のような静的プロパティに置いておくことで、playground が代表的な入力をすぐ取得できるようにしましょう。

• やること: パフォーマンス回帰テストを「主観的にカクつくかどうか」から XCTHitchMetric のベースラインへ置き換える。

  • なぜ価値があるのか: スクロールのカクつきはユーザーが最も敏感に感じる体験の一つですが、人間の目は慣れやすいため見落としがちです。メトリクスとして数値化することで、初めて PR レベルでブロックする手段を持てます。
  • 始め方: まずアプリ内で最も長く、最も複雑な 2〜3 個のリストに対して hitch テストを書き、現在の数値をベースラインとして記録しましょう。続いて CI で閾値を設け、hitch 時間が上昇したらマージをブロックするようにします。

• やること: すべての UI 文字列をハードコードから String Catalog の型安全シンボルへ移行する。

  • なぜ価値があるのか: Xcode 26 は catalog エントリから Swift シンボルを生成するため、コンパイル時にスペルミスがチェックでき、利用可能なキーが補完されます。on-device モデルが翻訳コメントを自動生成するため、翻訳担当者とのコミュニケーションコストも下がります。
  • 始め方: 設定画面のような完結したフローを持つ小規模なモジュールから移行を始め、Text("Save") を catalog 生成のシンボルへ置き換えます。翻訳フローを一通り回せたら、他のモジュールへ展開していきましょう。

• やること: 大規模プロジェクトでは Coding Assistant をデフォルトで有効にするが、「自動適用」オプションはオフにする。

  • なぜ価値があるのか: モデルはプロジェクトのコンテキストを直接読めるため、未知のコードベースを探索する用途では非常に強力です。しかし、その変更を盲目的に受け入れると、気付きにくいリグレッションを招きかねません。
  • 始め方: 最初は「この機能はどのファイルにあるか」のような純粋な検索系の質問から使い始め、段階的に playground の生成、テストの記述へと用途を広げ、最後にコードを直接修正させるかどうかを検討するのがおすすめです。

関連セッション

• Better together: SwiftUI and RealityKit — visionOS 26 で SwiftUI と RealityKit をシームレスに組み合わせる方法。
• Build a SwiftUI app with the new design — Liquid Glass が SwiftUI アプリにもたらすビジュアルとインタラクションの刷新。
• Build a UIKit app with the new design — UIKit アプリを新しいデザインシステムへ移行するためのガイド。
• Explore prompt design & safety for on-device foundation models — オンデバイスの Foundation Models で安全かつコントロールされた生成体験を設計する方法。