WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
What's new in Xcode 16

What's new in Xcode 16

WWDC 2024
元の動画を見る

ハイライト

このセッションは開発ワークフロー全体にわたる Xcode 16 の更新をカバーします。編集面では、コード補完がデバイス上で訓練された Swift/Apple SDK モデルを使用し、関数名とコメントの文脈からより適切な提案を提供。Apple Silicon のローカル計算能力に完全依存しています。

主要内容

Xcode 16 の更新はコーディング、ビルド、デバッグ、テスト、プロファイリングの 5 段階をカバーします。Preview で @State を使う際の課題：Binding が必要なビューごとに @State プロパティだけを持つラッパービューを書き、Preview で参照する必要があり、コード量が倍増し保守コストも上がりました。@Previewable マクロがこれを解決 — Preview ブロック内で @Previewable @State var currentFace = ... と宣言すれば、プレビューシステムが裏でラッパーを生成。2 行で済みます。

もう一つの課題：複数 Preview が環境データ（SwiftData の ModelContainer など）を共有する場合、各 Preview が個別に初期化 — 重複かつ遅い。PreviewModifier プロトコルで共有データを一度だけ初期化し、プレビューシステムがキャッシュします。

ビルド面では、モジュール依存スキャンとモジュールコンパイルがソースファイルコンパイルに暗黙的にネストされていました。ビルドログは “Compile xxx.swift” のみ表示され、モジュール問題かソース問題か特定しにくい状態でした。Explicit Modules はコンパイルを 3 つの明示的フェーズに分割：依存関係スキャン、モジュール構築、ソースコンパイル。各フェーズがビルドログと Timeline で独立表示され、並列性が向上、モジュール関連エラーも明確になります。C/Objective-C はデフォルト有効、Swift は Build Settings で opt-in が必要です。

詳細

Previewable マクロ（03:37）で @State などのプロパティラッパーを Preview ブロック内で直接使用：

#Preview {
    @Previewable @State var currentFace = RobotFace.heart

    RobotFaceSelectorView(currentFace: $currentFace)
}

キーポイント:

  • @Previewable は @State を修飾し、プレビューシステムが裏でラッパービューを作成 — 手書き不要
  • currentFace は $currentFace で Binding を渡せ、通常の @State と同じ動作
  • Binding が必要なビューを 2 行で Preview 可能

PreviewModifier プロトコル（04:40）で Preview 間の共有データ問題を解決：

struct SampleRobotNamer: PreviewModifier {
    typealias Context = RobotNamer

    static func makeSharedContext() async throws -> Context {
        let url = URL(fileURLWithPath: "/tmp/local_names.txt")
        return try await RobotNamer(url: url)
    }

    func body(content: Content, context: Context) -> some View {
        content.environment(context)
    }
}

キーポイント:

  • makeSharedContext() は async throws で非同期データロード可能、同種 Modifier では 1 回だけ呼ばれプレビューシステムが自動キャッシュ
  • body(content:context:) で共有データをビュー階層に注入、ここでは .environment() を使用
  • PreviewTrait 拡張で呼び出し側を .sampleNamer トレイト 1 つに圧縮

Swift Testing フレームワーク（13:42）が一部 XCTest 用途を置き換え：

import Testing
@testable import BOTanist

@Test
func plantingRoses() {
    let plant = Plant(type: .rose)
    let expected = Plant(type: .rose, style: .graft)

    #expect(plant == expected)
}

キーポイント:

  • @Test マクロでテスト関数をマーク、関数名は自由 — test プレフィックス不要
  • #expect は任意のブール式を受け入れ、失敗時に値の差分を自動出力
  • テスト関数に .tags() でカスタム Tag を付け、Tag 別実行や Test Plan からの除外が可能

Explicit Modules ビルド（06:26）はコンパイルを依存関係スキャン、モジュール構築、ソースコンパイルの 3 フェーズに分割。ビルドログに “Scan dependencies”、“Compile Swift module” など独立エントリが表示され、Timeline でも各フェーズの所要時間を確認可能。C/ObjC はデフォルト有効、Swift は Build Settings で “Enable Explicitly Built Modules” を有効化。Xcode 16 は Swift Package 解決完了前にビルド開始もサポート（07:15）。

デバッグ改善：DWARF5 が macOS Sequoia / iOS 18 デプロイメントターゲットのデフォルトデバッグシンボル形式 — dSYM が小さく、シンボル検索が高速。Thread Performance Checker にスロー起動と過剰ディスク書き込み診断を追加。Unified Backtrace View（10:56）は Debug Bar 有効化後、スタック各フレームのコードと変数値を連続スクロールで確認 — フレームごとのクリック不要。RealityKit デバッガー（12:16）は空間 app の Entity 階層スナップショットをワンクリックで取得し、Xcode 内 3D ビューで閲覧。

Instruments Flame Graph（19:42）はコールスタックの面積可視化 — 左側が最もコストの高いパス。セッションでは Flame Graph で直列 asset.load() ループを特定し、並列 Task Group に変更して起動時間を大幅短縮するデモ：

await withDiscardingTaskGroup { group in
    for asset in allAssets {
        group.addTask {
            asset.load()
        }
    }
}

重要ポイント

  • やること：プロジェクトで Swift 6 Upcoming Features を段階的に有効化。なぜ価値があるか：データ競合が実行時の偶発的問題からコンパイル時の確実な検出へ — 早く直すほどコストが低い。始め方：Build Settings の “Swift Compiler - Upcoming Features” で 1 つずつ有効化（Isolated Global Variables、Strict Concurrency など）、1 カテゴリの警告を修正してから次へ。

  • やること：PreviewModifier でプレビュー共有環境をカプセル化。なぜ価値があるか：SwiftData ModelContainer、Mock ネットワーク層などが複数 Preview で再初期化 — 冗長かつプレビュー更新が遅い。始め方：PreviewModifier を定義し makeSharedContext() で ModelContainer や Mock データを初期化、PreviewTrait を拡張して .myModifier を追加、全 Preview が同一トレイトでキャッシュデータを共有。

  • やること：新規テストファイルで Swift Testing を XCTest の代わりに使用。なぜ価値があるか：@Test マクロ + #expect がより簡潔、パラメータ化テストは自然に並列、Tag メカニズムは XCTest フィルタより柔軟。始め方：新規テストファイルで Testing を import、@Test func xxx() でマーク、#expect でアサーション。既存 XCTest は影響なし — 共存可能。

  • やること：Swift ターゲットで Explicit Modules を有効化。なぜ価値があるか：明示的コンパイルフェーズで並列度向上、モジュールエラーが明確、lldb 式評価がモジュールビルド成果物を再利用してデバッグ高速化。始め方：Build Settings で “Enable Explicitly Built Modules” を有効化、ビルドログと Timeline の “Scan dependencies” / “Compile Swift module” エントリを確認。

関連セッション

コメント

GitHub Issues · utterances