WWDC Quick Look 💓 By SwiftGGTeam
Xcode 27 の新機能

Xcode 27 の新機能

元の動画を見る

ハイライト

Xcode 27 は Coding Agent をエディタのメインビューに組み込み、/plan コマンドによる計画優先の実行をサポートします。さらに、シミュレータと実機デバッグを統合する Device Hub、Organizer の Metric Goals と Agent 駆動のパフォーマンス修正提案、Instruments の Top Functions ビューによるボトルネック特定が加わります。

主要内容

ワークスペースの再設計:画一的な UI から個人に合う UI へ

以前 Xcode を開くと、ツールバーのレイアウトは固定されていました。Scheme 選択、実行ボタン、エディタモード切り替えは jump bar に詰め込まれ、長いブランチ名は切り詰められていました。順序を変えたいと思っても、できませんでした。

Xcode 27 はツールバーを開発者に返しました。(01:14) 履歴ナビゲーションとエディタコントロールは jump bar から上部ツールバーへ移動し、ビルド進行状況はウィンドウタイトルの下に表示され、ブランチ選択は下部ステータスバーに移ります。長いブランチ名をようやく完全に表示できます。最も重要なのは、ツールバーがドラッグによる追加、削除、並べ替えに対応したことです。よく使うコントロールを一番手になじむ場所に置けます。

テーマシステムも大きく変わりました。(02:23) Appearance パネルには2つのスライダーがあります。1つはテキスト色の強度、もう1つは背景の強度を制御します。背景強度を上げると、エディタ背景は鮮やかなグラデーションになります。プリセットが気に入らなければ、ベースの色相をカスタマイズでき、派生色は自動的に追従します。さらに、workspace ごとに独立したテーマを設定できます。会社のプロジェクトは寒色、自分の side project は Neon Noir にしておけば、ウィンドウの色だけで今どのコードベースを編集しているか分かります。

コード編集中の視覚的ノイズも減りました。(01:07) Xcode 27 の inline issues は淡いスタイルになり、ビルド後の警告やエラーと区別されます。入力中に表示される予測的な問題ヒントは控えめで、ビルド後に確定した問題だけが強い色で表示されるか、自動解消されると消えます。

開いたらすぐ書ける:独立 Swift ファイルと無題プロジェクト

以前 SwiftUI コンポーネントを素早く検証したい場合、完全な App プロジェクトを作成し、Xcode のインデックスが終わるのを待ってからコードを書き始める必要がありました。この待ち時間は数十秒になることもあり、アイデアはその間に薄れてしまいます。

Xcode 27 は「コードを書くにはプロジェクトが必要」という前提を取り払います。(06:08) File メニューから Untitled Project を直接作成できます。保存ダイアログに中断されません。まず書いて、あとから名前を付けて保存します。気に入らなければ、痕跡を残さず破棄できます。

独立した Swift ファイルはさらに軽量です。(07:13) .swift ファイルをダブルクリックすると、それがどのプロジェクトにも属していなくても、Xcode 27 は Canvas に Playground 結果と UI プレビューを表示できます。同僚からアルゴリズム実装や UI プロトタイプが送られてきたら、プロジェクト全体を clone せずに開いて結果を確認できます。

Coding Agent:コード補完からエンジニアリング協働へ

Xcode 27 の Coding Agent は、もはやサイドバーのチャットウィンドウではありません。エディタ内の一等市民になります。(07:50) 会話履歴はエディタパネルに移り、通常のコードファイルと同じようにタブや分割表示で Agent 会話を整理できます。ツールバー中央には Agent 入口ボタンが追加され、新しい会話やタスクをワンクリックで開始できます。

/plan コマンドは今回の更新の中心です。(08:31) Agent にコードを変更させる前に、/plan で実装計画を作らせることができます。Agent は必要なコンテキストを集め、sub-agent を派生させて並行作業することもできます。計画が生成されたら、各項目をレビューし、インラインフィードバックを追加し、問題なければ実行に進めます。実行中はすべてのコード変更が右側パネルにリアルタイム表示され、生成ファイルやスクリーンショットなどの成果物も確認しやすくなります。

Coding Assistant サイドバーはタスクボードになります。(09:28) 並行している Agent 会話とタスクが一覧化され、未読メッセージや入力が必要な状態が明確に表示されます。複数タスク間の切り替えが楽になります。

Device Hub:シミュレータと実機を統合するコンソール

iOS App のデバッグでは、以前は注意が分散していました。Simulator は独立したウィンドウにあり、実機デバッグには別の流れがありました。Xcode 27 は Device Hub で両者を統合します。(09:57)

iPhone 17 Pro シミュレータで App を実行すると、Device Hub はデバイスサイズにぴったり合う Compact ウィンドウを開きます。ウィンドウは展開でき、展開すると Inspector と追加コントロールが現れます。(10:26) 高コントラスト、Dynamic Type サイズ、Dark Mode を Device Hub 内で直接切り替えられます。以前のように Simulator 設定の奥深くまで探す必要はありません。

iPhone Mirroring のテストも統合されています。(11:02) macOS 27 の iPhone Mirroring ウィンドウはリサイズに対応し、Device Hub では異なるアスペクト比やコンテンツサイズでの挙動を試せます。SwiftUI ビューが iPad と Mac のリサイズ可能ウィンドウに既に対応していれば、基本的に追加作業は不要です。

最も実用的なのは実機対応です。(11:52) サイドバーにはシミュレータと実機が並んで表示されます。ペアリング済み iPad Pro 上で動く App を Device Hub 内で直接表示し、操作できます。1台の Mac で複数形状のデバイスを同時にテストできます。

ローカリゼーション:Agent が翻訳フロー全体を引き受ける

多言語ローカリゼーションはずっと手作業の多い仕事でした。文字列を抽出し、String Catalog を作成し、1つずつ翻訳し、レイアウトをテストする。どの工程も時間がかかります。

Xcode 27 では、Agent が作業の大部分を引き受けます。(13:35) Agent 会話で「プロジェクトのローカリゼーションを設定して」と依頼すると、Agent はコードをスキャンし、文字列リテラルがローカライズ可能に参照されるようにし、String Catalog を作成し、すべての UI 文字列の翻訳を埋めます。全体は数回の会話だけで進みます。

String Catalog 自体も更新されています。(15:22) 言語を選択して Generate Translations ボタンをクリックすると、Agent がバックグラウンドで翻訳を一括生成します。進行状況は Agent 会話でも String Catalog でも確認できます。翻訳が完了したらすぐ App を実行し、レイアウトの切り詰めやテキスト溢れを確認します。

TestFlight ユーザーも翻訳レビューに参加できます。(15:52) ネイティブ話者のユーザーが通常の機能フィードバックと同じように翻訳提案を送信し、レビューの循環を作れます。

Organizer:データを見る場所から問題を解く場所へ

Xcode 27 の Organizer は、単なるデータの展示棚ではありません。問題解決を能動的に助けるアシスタントになります。(17:16)

Overview ページは再設計され、診断情報と指標グラフが同じビューに置かれます。(17:58) 上部の指標グラフの spike がどこで問題が起きたかを示し、下部の診断情報がコード位置へ直接つながります。複数ページを行き来する必要がありません。

新しい指標として Storage と Hitches が追加されました。(18:21) Storage はドキュメント、データ、バイナリサイズを分けて集計し、App サイズ削減の最適な切り口を見つけやすくします。Hitches は従来のスクロールカクつき検出を超え、Liquid Glass と SwiftUI ビューのアニメーションにも対応します。以前は見えなかったアニメーション問題が見つけやすくなります。

Metric Goals は従来の Recommendations を置き換えます。(19:38) Goals は App の機能や技術スタックが似たアプリ群と比較して調整され、同時に自分の App の過去のベースラインも考慮します。対象指標は hang rate、disk writes、battery、storage、hitches など、より広くなりました。

最も実用的なのは Generate Recommendations 機能です。(20:32) Organizer で性能問題を選び、Generate Recommendations をクリックすると、Agent が診断データを分析し修正提案を出します。複数の修正方向を試しながら、コードベースに合う解決策を探せます。

Instruments:Top Functions が性能の要所を直撃する

性能デバッグで最もつらいのは、手がかりなしに探すことです。Instruments の呼び出しツリーは深く、本当のボトルネックを見つけるには時間がかかります。

Xcode 27 は Top Functions ビューを追加しました。(22:02) 時間範囲を選択して Top Functions ボタンを押すと、Instruments は最も時間を消費した関数を経過時間順に直接リストします。1回あたりは安いが頻繁に呼ばれて累積時間が大きい処理は、このビューで即座に露出します。

セッションの例は典型的です。(22:51) paperPhysics 関数が Top Functions リストを占有していました。原因はループ反復回数が高すぎたことです。デバッグ時に残した値を戻し忘れていました。反復回数をデバッグ値から 5 に下げると、アニメーションのカクつきはすぐに消えました。修正後にもう一度 Instruments を実行すると、Top Functions には App 自身のメソッドが表示されなくなり、問題が本当に解決したことを示しました。

Xcode Cloud:CI/CD をワンクリックで始める

Xcode 27 では Xcode Cloud の設定フローが大幅に簡単になりました。(25:28) Get Started をクリックし、App と開発チームを確認し、リモートコードリポジトリに接続し、Start First Build をクリックする。3ステップで完了です。その後は main や feature ブランチへのコミットごとに、Xcode Cloud が自動でビルドとテストを行えます。ビルド結果は TestFlight と App Store にシームレスに統合されます。

詳細

ツールバーのカスタマイズとエディタモード切り替え

Xcode 27 のツールバー右側には、エディタモードを制御する3方向セレクタがあります。(01:46)

  • 1つ目:Canvas にプレビューと Playground を表示する
  • 2つ目:Assistant Editor に関連内容を表示する
  • 3つ目:Source Control の変更レビュー モードに入る
// 独立した Swift ファイルで #Preview マクロを使って UI をテストする
import SwiftUI

struct AirplaneStatsView: View {
    let designName: String
    let glideRatio: Double
    
    var body: some View {
        VStack(alignment: .leading) {
            Text(designName)
                .font(.headline)
            Text("滑空比: \(glideRatio, specifier: "%.2f")")
                .foregroundStyle(.secondary)
        }
        .padding()
    }
}

#Preview("クラシック設計") {
    AirplaneStatsView(designName: "Dart", glideRatio: 3.5)
}

#Preview("高性能設計") {
    AirplaneStatsView(designName: "Nakamura Lock", glideRatio: 5.2)
}

重要な点:

  • #Preview マクロは、プロジェクトコンテキストがない独立 Swift ファイルでも動作します。
  • プレビューに名前を付けることで、Canvas 内で異なるシナリオを区別できます。
  • UI コンポーネントの素早い検証、アルゴリズムプロトタイプのテスト、コードスニペットの共有に向いています。

/plan コマンドで Agent と協働する

/plan は Xcode 27 Agent ワークフローの中核入口です。(08:31)

/plan
紙飛行機 App に統計機能を追加し、設計ごとの滑空比、
飛行距離、滞空時間を表示してください。SwiftUI のレイアウトと
Dynamic Type 対応を考慮してください。

Agent の実行フロー:

  1. コード構造や依存関係など、プロジェクトコンテキストを収集する
  2. 要件を分析し、実装計画を作る
  3. sub-agent を派生させ、異なる解決策を並行探索する
  4. 手順チェックリストを含む構造化された計画文書を生成する
  5. 開発者が計画をレビューし、インラインフィードバックを追加する
  6. 確認後、Agent が実装を開始し、変更をリアルタイム表示する

重要な点:

  • /plan は Agent にコード変更前に考えさせ、盲目的な修正を避けます。
  • 計画段階は実コードに触れず、何度でも反復できます。
  • 実装段階の変更は右側パネルにリアルタイム表示され、いつでも中断できます。

Agent 駆動のローカリゼーションワークフロー

Xcode 27 のローカリゼーションフローは2段階です。初期設定と、言語の追加です。

初期設定(Agent 会話内で実行):(13:35)

プロジェクトのローカリゼーションを設定してください。スペイン語から始めます。

Agent は自動的に次を行います。

  1. コード内の文字列リテラルをスキャンする
  2. ハードコードされた文字列を String(localized:) 呼び出しに置き換える
  3. Localizable.xcstrings ファイルを作成する
  4. スペイン語翻訳を生成する

String Catalog インターフェイスでの言語追加:(15:22)

// 文字列補間を使うと、Agent はプレースホルダー付きの翻訳を正しく抽出できる
func boardingMessage(gate: String, time: String) -> String {
    String(localized: "\(time) に搭乗するため、ゲート \(gate) へお進みください。")
}

重要な点:

  • 文字列結合ではなく文字列補間を使うことで、String Catalog が変数プレースホルダーを正しく認識できます。
  • Agent はプロジェクトコンテキストと Xcode の言語スタイルガイドを踏まえて翻訳します。
  • 翻訳が完了したらすぐ App を実行し、レイアウトの切り詰めを確認します。

Organizer Metric Goals の読み解き

Metric Goals の比較軸:(19:38)

比較軸説明
類似 AppApp の機能と技術スタックに基づく類似アプリ群
過去のベースラインApp 自身の過去バージョンの性能データ
目標しきい値上記データをもとに Apple が調整した妥当な目標

Storage 指標の内訳:(18:26)

  • Documents:ユーザードキュメントとデータ
  • Data:App キャッシュとデータベース
  • Binary:App バンドルサイズ。セルラーダウンロードと起動時間に影響します

Hitches 指標の対象:(19:11)

  • 既存のスクロールアニメーションのカクつき
  • Liquid Glass 効果のレンダリング
  • SwiftUI ビュー遷移アニメーション
  • スクロール以外で発生する UI アニメーション

Instruments Top Functions の使い方

性能ボトルネックを特定する標準フロー:(22:02)

  1. Xcode から App を実行する。シミュレータでも実機でもよい
  2. Instruments を開き、Time Profiler を選ぶ
  3. App の動作を記録し、カクつき場面を再現する
  4. タイムライン上でカクつきが起きた時間範囲を選択する
  5. Top Functions ボタンをクリックする
  6. 経過時間順に並んだ関数一覧を確認する
  7. Xcode で Cmd+Shift+O を使い、対応するコードへ移動する
  8. 修正後に再録画し、問題の関数が Top Functions から消えたことを確認する
// 修正前:デバッグから残った高頻度計算
func paperPhysics() {
    // バグ:反復回数が多すぎて、各フレームの処理時間が長くなる
    for _ in 0..<10000 {
        simulateAirflow()
    }
}

// 修正後:精度要求を下げる
func paperPhysics() {
    for _ in 0..<5 {
        simulateAirflow()
    }
}

重要な点:

  • Top Functions は「1回は軽いが呼び出し回数が非常に多い」問題の発見に強いです。
  • 修正後に Top Functions に App 自身のメソッドが出なくなれば、性能改善の強い証拠になります。
  • 修正前後の Instruments 記録を比較し、改善量を定量化できます。

実践アイデア

1. 独立 Swift ファイルで UI コンポーネントを事前検証する

  • すること:正式にプロジェクトへ組み込む前に、独立した .swift ファイルと #Preview で複雑な UI コンポーネントのさまざまな状態を素早く検証します。
  • 価値がある理由:プロジェクトのインデックス待ちや Target 依存関係の処理が不要で、編集とプレビューのサイクルが非常に速くなります。
  • 始め方:File > New > Swift File を選び、コンポーネントコードを書いて #Preview マクロを追加すると、Canvas にプレビューが自動表示されます。

2. Agent に String Catalog のメンテナンスを任せる

  • すること:UI 文言を追加するたびに、Agent に抽出、翻訳、String Catalog 更新を依頼します。
  • 価値がある理由:文字列 key の手動管理という面倒でミスしやすい作業を避けられます。Agent はコンテキストを踏まえてより正確な翻訳を出せます。
  • 始め方:Agent 会話で「ローカリゼーションを更新して」と依頼するか、String Catalog で Generate Translations をクリックします。

3. Device Hub でアクセシビリティ回帰テストを行う

  • すること:リリース前に Device Hub で高コントラスト、大きな文字、Dark Mode の3つのアクセシビリティシナリオを素早く確認します。
  • 価値がある理由:Device Hub はこれらの切り替えをすばやい操作にしており、テストコストを数分から数秒へ下げます。
  • 始め方:Device Hub ウィンドウを展開し、Inspector のアクセシビリティコントロールを探します。

4. Organizer Metric Goals でリリース品質を監視する

  • すること:各リリース後に Organizer の Metric Goals を確認し、Storage、Hitches、Hang Rate が目標を満たしているか注視します。
  • 価値がある理由:Goals は類似 App 比較と過去ベースラインに基づき、ユーザーが不満を言う前に性能劣化を見つけやすくします。
  • 始め方:Window > Organizer > App を選択 > Overview ページで指標トレンドを確認します。

5. 勘に頼る性能最適化ではなく Top Functions を使う

  • すること:アニメーションがカクついたり応答が遅くなったりしたら、まず Instruments Top Functions で本当のホットスポットを特定します。
  • 価値がある理由:直感でコードを直して何度も試す非効率を避けられます。1回の記録で原因を見つけられます。
  • 始め方:Product > Profile を選び、Time Profiler を選択し、問題を再現して時間範囲を選び、Top Functions をクリックします。

関連セッション

コメント

GitHub Issues · utterances