【WWDC】Swiftの新機能と変更点を紹介

By /

【WWDC】Swiftの新機能と変更点を紹介：Swift 6への道のりと革新の数々

AppleのWorldwide Developer Conference（WWDC）は、毎年世界中の開発者が待ち望むイベントです。特に、Swift言語の進化は、Appleプラットフォームだけでなく、サーバーサイドやクロスプラットフォーム開発者にとっても極めて重要な発表となります。WWDC23（2023年）は、Swiftにとってまさに変革期とも言える年であり、来るべきSwift 6に向けた多くの重要なステップが発表されました。

この記事では、WWDC23で発表されたSwiftの主な新機能、変更点、そしてその背景にある思想について、詳細かつ網羅的に解説します。約5000語にわたる長文記事となりますが、Swiftの最先端を深く理解し、日々の開発に役立てていただくための情報が凝縮されています。

1. 導入：Swiftの進化とWWDC23の意義

Swiftは2014年の発表以来、安全性、速度、表現力のバランスを追求し、継続的に進化を続けてきました。オープンソース化され、Swift Evolution Proposal（SE）プロセスを通じてコミュニティの意見を取り入れながら、着実にその能力を拡張しています。

WWDCは、この進化の重要な節目を毎年マークしています。新しいAPIやフレームワークが発表されると同時に、それらを支えるSwift言語自体の進歩が紹介されます。特に、Swiftのコンパイラ技術、型システム、メモリ管理、そして並行処理（Concurrency）は、アプリケーションの信頼性、パフォーマンス、そして開発者の生産性に直結するため、常に注目の的です。

WWDC23におけるSwiftの発表は、主に以下の3つの柱を中心に据えています。

  1. 安全性とパフォーマンスの向上（Swift 6への道のり）: 特に並行処理におけるデータ競合の防止と、Ownershipシステムの進化によるメモリ管理の効率化。
  2. 表現力と生産性の向上（Macros, Parameter Packs）: より高度なコード生成や抽象化を可能にし、定型的なコード記述を削減。
  3. 開発体験の向上（Observation, String Catalog）: リアクティブプログラミングやローカライズといった一般的なタスクを、より簡単かつ安全に行えるようにする新しいフレームワークとツール。

これらの新機能や変更点は、Swiftを単なるAppleプラットフォーム向けの言語から、より汎用的で強力なシステムプログラミング言語へと進化させるための重要な一歩です。本記事では、これらの柱に基づき、各機能を深掘りしていきます。

2. Swift 6への道のり：Concurrencyの厳密化と安全な並行処理

Swiftの進化における最大の目標の一つは、安全な並行処理（Concurrent Programming）を実現することです。並行処理は現代のアプリケーション開発において不可欠ですが、データ競合（Data Race）のような深刻なバグを引き起こしやすく、デバッグが困難という課題があります。

Swift 5.5で導入された async/await, Task, actor といったConcurrencyモデルは、この課題に対するSwiftのアプローチの始まりでした。しかし、Swift 5.5のConcurrencyモデルは後方互換性を維持するために、デフォルトではデータ競合に対する最も厳密なチェックを有効にしていませんでした。多くの潜在的なデータ競合は、実行時検出器（Runtime Data Race Detector）を使用しない限り見過ごされる可能性がありました。

来るべきSwift 6は、この状況を変えます。Swift 6の主要な目標は、データ競合のコンパイル時防止をデフォルトで有効にすることです。これにより、多くのデータ競合バグが実行時ではなく、開発の早期段階であるコンパイル時に検出されるようになります。これは、Swiftの「安全性がデフォルト」という哲学を並行処理の領域にも完全に適用することを意味します。

WWDC23では、Swift 6に向けて、この厳密なConcurrencyモデルを段階的に導入し、開発者が既存コードを新しいモデルに適応させるためのツールとガイダンスが提供されました。

Swift 6の主要な変更点（Concurrency関連）:

  • Sendable プロトコルの強制と推論:
    Sendable プロトコルは、並行処理（異なるTaskやActor）間で値を安全に渡せることを示すマーカープロトコルです。Swift 5.5では、Sendable のチェックは緩やかでしたが、Swift 6では厳密になります。
    コンパイラは、構造体、列挙型、タプルなどの値型、immutableなプロパティのみを持つクラス、actor、そして @Sendable としてマークされた関数型などを自動的に Sendable と推論します。手動で Sendable に準拠させることも可能ですが、その場合は準拠が安全であることを開発者が保証する必要があります（@unchecked Sendable は注意が必要）。
    Swift 6モードでは、Sendable ではない値を異なる分離コンテキスト（Isolation Domain）、例えばあるactorから別のactorへ渡そうとすると、コンパイルエラーになります。これは、非同期呼び出しの引数や戻り値、Task のキャプチャリストなどで発生します。
  • Isolation (分離) の厳密化:
    actor はその内部状態を自動的に分離し、データ競合を防ぎます。@MainActor や @globalActor も特定の実行キューやグローバル状態を分離します。
    Swift 6では、この分離の境界線がより明確になります。例えば、actorの非同期メソッドを呼び出す際には、暗黙的に await が必要になります。これは、呼び出し元のタスクがactorが処理を完了するのを待つ間に中断される可能性があるためです。
    nonisolated は、actorの分離から外れたプロパティやメソッドを示すために使用されます。nonisolated なプロパティはimmutableであるか、Atomicな型である必要があります。nonisolated なメソッドはactorの状態に直接アクセスできません。
  • SE-0404: Generic arguments to nonisolated methods:
    Swift 5.xでは、actor 内の nonisolated メソッドはジェネリック引数を持つことができませんでした。これは、nonisolated がコンパイル時に解決される必要があるのに対し、ジェネリック引数は型によっては実行時に決定される可能性があるため、コンパイラが安全性を保証しにくかったためです。
    SE-0404により、この制限が緩和され、nonisolated メソッドがジェネリック引数を持つことができるようになりました。これは、actorの外部で定義されたジェネリック関数をactor内で nonisolated に呼び出す際に特に有用です。これにより、actorが外部の汎用的なユーティリティ関数とより柔軟に連携できるようになります。
  • SE-0401: Remove sendable from the standard library:
    Swift 5.5で Sendable が導入された際、いくつかの標準ライブラリ型には sendable 属性が付与されていました。これは Sendable がまだプロトコルとして完全に確立されていなかったための一時的な措置でした。SE-0401により、標準ライブラリ内のこれらの sendable 属性は削除され、代わりに該当する型が Sendable プロトコルに準拠する形に変更されました。これにより、Sendable が言語全体で一貫してプロトコルとして扱われるようになります。
  • SE-0399: Conditional conformance for Result:
    Result 型は、成功または失敗のどちらかの値を保持します。SE-0399により、Result 型は、成功値と失敗値の両方が Sendable に準拠する場合に限り、自動的に Sendable に準拠するようになりました。同様に、成功値と失敗値が Equatable に準拠する場合に Equatable に、Hashable に準拠する場合に Hashable に準拠するようになります。これは、ジェネリック型の条件付き準拠をより柔軟に活用する例であり、並行処理やコレクション操作において Result 型をより自然に扱えるようになります。
  • データ競合検出器の改善:
    Swift 6モードでは、コンパイル時のデータ競合検出がデフォルトで有効になります。さらに、実行時データ競合検出器も改良され、より多くの競合パターンを検出できるようになりました。既存のプロジェクトをSwift 6に移行する際には、これらの検出器を活用して潜在的な問題を特定し、修正する必要があります。

Swift 6への移行:

Swift 6は破壊的な変更を含むため、既存のコードベースは修正が必要になる可能性があります。Appleは、Swift 6への段階的な移行パスを提供しています。

  1. Swift 5.10 (またはそれ以降) のコンパイラを使用: Swift 6の新機能を有効にするためのフラグが導入されます。
  2. Upcoming Feature Flags の利用: SWIFT_ENABLE_UPCOMING_FEATURE というビルド設定を使用し、特定のSwift 6の挙動（例: 厳密なConcurrencyチェック）をSwift 5.xのコンパイラで先行して有効にできます。これにより、Swift 6リリース前にコードを適応させることができます。
  3. Strict Concurrency Checking の有効化: SWIFT_STRICT_CONCURRENCY というビルド設定で、Concurrencyモデルの厳密さレベルを選択できます（例: complete はSwift 6相当の厳密さ）。段階的にレベルを上げることで、問題を少しずつ修正していくことが可能です。
  4. 移行ツールの活用: XCodeには、Swift 6移行を支援するFix-it機能や診断ツールが搭載されます。

Swift 6への移行は、特に並行処理を多用している大規模なプロジェクトにとって、ある程度の労力を伴いますが、その結果として得られるコードの安全性と信頼性の向上は、長期的に見れば大きなメリットとなります。データ競合という最も厄介なバグの一つをコンパイル時に排除できる可能性は、Swiftが安全なシステムプログラミング言語としての地位を確立する上で非常に重要です。

3. 主要な新機能・変更点：革新的な機能の深掘り

WWDC23では、Swift 6に向けた基盤強化だけでなく、開発者の生産性と表現力を飛躍的に向上させるための新しい機能も多数発表されました。特に注目すべきは、マクロ、Ownership、Observationフレームワーク、String Catalog、そしてParameter Packsです。

3.1 Ownership (所有権システム)

Ownershipは、Swiftがメモリ安全性を保証しつつ、C++のような低レベル言語に匹敵するパフォーマンスを達成するための重要な基盤です。Swiftは自動参照カウント（ARC）を使用してメモリを管理しますが、Ownershipシステムはさらに一歩進んで、コンパイル時に値のライフタイムとアクセスパターンを追跡します。これにより、不要なコピーを削減し、特に値型（構造体、列挙型）のセマンティクスを厳密に保ちながら、高いパフォーマンスを実現します。

SwiftのOwnershipシステムは、主に以下の4つの操作概念に基づいています。

  • borrowing (借用):
    これはSwiftで最も一般的な値の受け渡し方法であり、デフォルトの挙動です。関数やメソッドに値を渡す際、呼び出し元はその値の所有権を保持したまま、関数は値への一時的な参照を得ます。関数内ではその値を読み込むことができますが、直接変更したり、関数終了後も存在することを前提とするような操作（例えば、別のタスクへ渡す）はできません。borrowing はコピーを発生させません。これは、参照セマンティクス（参照渡し）に近い考え方ですが、値型に対しても適用され、コンパイラがライフタイムを保証します。明示的に borrow キーワードを使用することも可能ですが、通常は推論されます。
    “`swift
    // borrowing はデフォルトの挙動
    func process(_ data: Data) { // data は borrowing パラメータ
    print(data.count)
    // data.append(0) // コンパイルエラー：cannot use mutating member on immutable value of type ‘Data’
    }

    var myData = Data([1, 2, 3])
    process(myData) // myData の所有権は移動しない
    print(myData.count) // myData は引き続き有効
    * **`consuming` (消費)**:
    値を関数に渡す際に、呼び出し元はその値の所有権を関数に**移譲**します。関数は値を「消費」します。関数が値を消費した後、呼び出し元からはその値にアクセスできなくなります。`consuming` は、値が一度だけ使用されることを保証し、不要なコピー（特にCopy-on-Write構造体で、書き込み前に発生するコピー）を削減するのに役立ちます。これはムーブセマンティクス（ムーブ渡し）に近い考え方です。    swift
    struct LargeStruct {
    var buffer: [Int]
    // …
    }

    func processAndDeallocate(_ value: consuming LargeStruct) {
    // value を安全に使用できる
    print(value.buffer.count)
    // 関数終了後、value は deallocate されるか、
    // value 内のリソースが解放される（コンパイラによって最適化される）
    }

    var myLargeStruct = LargeStruct(buffer: Array(repeating: 0, count: 10000))
    processAndDeallocate(myLargeStruct)
    // print(myLargeStruct.buffer.count) // コンパイルエラー：use of consumed value ‘myLargeStruct’
    ``consumingは、特に大きな値型やリソースを保持する型を扱う際に、パフォーマンスを最適化するために重要です。関数が値の所有権を引き受けることで、コンパイラはその値が他の場所で使用されないことを保証でき、よりアグレッシブな最適化（例: メモリの再利用、コピーの回避）が可能になります。
    * **    copying(コピー)**:
    値を明示的にコピーしたい場合に使用します。通常は暗黙的に行われますが、 Ownership システムにおける追跡の観点から重要です。Copy-on-Write 構造体の場合、書き込み操作や    consuming以外の方法で mutable な値にアクセスする場合にコピーが発生します。
    * **    discarding` (破棄)**:
    値を明示的に無視または破棄したい場合に使用します。値を消費するが、その値自体に関心がない場合などに使われることがあります。これは、リソースを保持する値を明示的にクリーンアップする場合などに役立つ可能性があります。

OwnershipとSwift 6:

Swift 6では、Ownershipのチェックがデフォルトで強化されると予想されます。これにより、コンパイル時に値の不正な使用（例: 消費された値へのアクセス、並行処理における危険な共有）をより厳密に検出できるようになります。特に、Concurrencyモデルにおける Sendable と Ownershipは密接に関連しています。Sendable な値は並行処理間で安全に渡せますが、その際に値がコピーされるのか、あるいは所有権が移動するのかといったセマンティクスは、Ownershipシステムによって定義されます。Swift 6の厳密なConcurrencyチェックは、内部的に強化されたOwnershipシステムに依存しています。

開発者にとって、Ownershipの概念を理解することは、Swiftコードの安全性とパフォーマンスを最大限に引き出す上でますます重要になります。特に、大きな値型を扱う際や、並行処理におけるデータフローを設計する際には、borrowing と consuming の違いを意識することで、意図しないコピーを避け、より効率的なコードを書くことができます。

3.2 Macros (マクロ)

マクロは、コンパイル時にコードを生成・変換するための強力な新しいメカニズムです。Swift 5.9（WWDC23で発表）で導入されました。これまでSwiftには、Property WrapperやSynthesized conformances (Codableの自動実装など) といった限定的なコード生成機能はありましたが、マクロはより汎用的で柔軟なコード生成を可能にします。

なぜマクロが必要か？

多くのプログラミング言語と同様に、Swiftでも繰り返し現れる定型的なコードパターンがあります。例えば、Codable準拠のための init(from decoder:) や encode(to encoder:) の実装、ロギングコードの挿入、あるいは特定のインターフェースを持つオブジェクトのファクトリ関数の生成などです。これまでこれらの処理を自動化するには、外部のコード生成ツールを使用するか、SourceKitのようなコンパイラAPIをハックするか、あるいはProperty Wrapperで部分的に対応するしかありませんでした。

マクロは、これらの課題に対して、言語レベルでサポートされたクリーンで安全な解決策を提供します。開発者はSwiftでマクロを記述し、コンパイラがそれを実行してコードを生成します。

マクロの種類:

Swiftのマクロは大きく分けて2種類あります。

  1. Freestanding Macros:
    コード中の任意の場所で使用できるマクロで、 # 記号で始まります。既存の #warning や #error のようなビルドインマクロの拡張と考えることができます。

    • #stringify(expression): 与えられた式とその式を文字列化したものをタプルとして返します。デバッグや診断に役立ちます。
      swift
      let x = 10
      let y = 20
      let tuple = #stringify(x + y * 2)
      print(tuple) // 出力例: (30, "x + y * 2")
    • #URL("..."): 文字列リテラルが有効なURLであることをコンパイル時に検証します。無効な場合はコンパイルエラーになります。
      swift
      let validURL = #URL("https://www.apple.com") // OK
      // let invalidURL = #URL("invalid url") // コンパイルエラー
      その他にも、カスタムなフリースタンディングマクロを定義できます。

  2. Attached Macros:
    宣言（クラス、構造体、関数、プロパティなど）に属性として付加されるマクロで、@ 記号で始まります。これらのマクロは、付加された宣言に対して新しいコードを追加したり、既存のコードを変更したりします。付加される場所と生成するコードの種類によって、さらに以下の役割に分かれます。

    • @attached(peer): 付加された宣言と同じスコープに新しい宣言を追加します。例えば、ある構造体に MyType という名前のピアマクロを付加すると、同じファイルスコープに別の型 MyTypePeer を生成する、といったことが考えられます（現実的な例は、Codable 準拠をサポートするために、関連するプロパティを生成するなど）。
    • @attached(member): 付加された型の宣言（クラス、構造体、列挙型など）の中に新しいメンバー（プロパティ、メソッド、型エイリアスなど）を追加します。Observationフレームワークの @Observable マクロは、この機能を使って監視用の内部プロパティを追加します。
    • @attached(accessor): 付加されたプロパティのアクセサー（get と set）を置き換えたり、ラップしたりします。Observationフレームワークの @Observable マクロは、この機能を使ってプロパティの set アクセサーに監視通知コードを挿入します。
    • @attached(memberAttribute): 付加された型のメンバーに新しい属性を追加します。Observationフレームワークの @Observable マクロは、この機能を使って監視対象プロパティに @ObservationTracked 属性を追加します。
    • @attached(extension): 付加された型に新しい拡張を追加します。この拡張を使って、プロトコルへの準拠を追加したり、計算プロパティやメソッドを追加したりできます。Observationフレームワークの @Observable マクロは、この機能を使って型に Observable プロトコル準拠を追加します。

マクロの実装:

マクロ自体もSwiftで記述されます。マクロの実装は、コンパイラが提供する SwiftSyntax や SwiftCompilerPlugin といったライブラリを使用します。これらのライブラリを使うことで、マクロはソースコードの抽象構文木（AST）を操作し、新しいコードを生成できます。

セキュリティと安定性のために、マクロはコンパイラ本体とは別のプロセスで実行されます。これにより、悪意のある、あるいはバグのあるマクロがコンパイラをクラッシュさせたり、ビルドシステム全体を危険にさらしたりするのを防ぎます。

ユースケース:

マクロは非常に多様なユースケースに対応できます。

  • Codableの自動実装: 現在Synthesized conformanceで限定的に行われているCodableの実装を、より複雑なケースにも対応できるようにマクロで生成する。
  • Logging: 関数呼び出しの前後やプロパティ変更時に自動的にロギングコードを挿入する。
  • Dependency Injection: 依存性の注入に必要な定型コード（プロパティやイニシャライザ）を生成する。
  • Testing: テスト対象コードにデバッグ情報を追加したり、テスト用のモックオブジェクトを生成したりする。
  • DSL (Domain Specific Language) 構築: 特定のドメインに特化した簡潔な構文を定義し、それを標準的なSwiftコードに展開する。
  • Boilerplate Codeの削減: デリゲートパターンのメソッドスタブ生成、ビューコントローラーのライフサイクルメソッド挿入など。

マクロのデバッグ:

マクロによって生成されたコードは、通常はソースファイルには表示されません。XCodeでは、ビルド設定でマクロ展開後のコードを一時ファイルとして出力するオプションや、デバッグ中にマクロ展開結果を確認できる機能が提供される予定です。これにより、マクロが意図通りにコードを生成しているかを確認できます。

マクロはSwiftの表現力を大きく拡張し、開発者がよりクリーンで保守しやすいコードを書くことを可能にします。既存のProperty Wrapperや他のコード生成手法の限界を超え、Swiftコミュニティが多様な問題を解決するための新しいツールを提供します。

3.3 Observation フレームワーク

Observationフレームワークは、Swift Concurrencyを基盤とした新しいリアクティブなプロパティ監視システムです。WWDC23でSwift 5.9の一部として発表されました。これは、以前から存在するKey-Value Observing (KVO) や、AppleのリアクティブフレームワークであるCombineに代わる、シンプルかつ高性能な仕組みを目指しています。

なぜ新しい監視システムが必要か？

KVOはObjective-C由来の古くからある仕組みで、Swiftでの使用にはブリッジングが必要であったり、文字列ベースのキーパスによる型安全性 Lack が問題でした。Combineは強力ですが、学習コストが高く、多くの抽象化レイヤーを持つため、特にシンプルなプロパティ監視にはオーバーヘッドが大きいと感じられることがありました。

Observationフレームワークは、これらの課題を解決するために設計されました。Swiftの型システムとマクロを活用し、コンパイラのサポートを受けて動作することで、高い安全性と効率性を両立しています。

@Observable マクロ:

Observationフレームワークの核となるのは、@Observable マクロです。このマクロをクラスに付加すると、そのクラスの格納型プロパティの変更を自動的に監視可能にします。

“`swift
import Observation

@Observable
class Settings {
var username: String = “”
var isLoggedIn: Bool = false
var profileImage: Image? // SwiftUI.Image など、他の型でも良い

// 監視したくないプロパティは @ObservationIgnored を付加
@ObservationIgnored var temporaryValue: Int = 0

// 計算プロパティはデフォルトで監視される
var displayName: String {
    isLoggedIn ? username : "Guest"
}

}
“`

@Observable マクロは内部的に、そのクラスに以下のようなコードを追加します（マクロの機能を使って実現されます）。

  • プロパティの値を格納するための内部的な仕組み（例: _observer というような名前のプロパティ）。
  • 各プロパティの set アクセサーに、値が変更されたことを監視システムに通知するコードを挿入。
  • クラスが Observable プロトコルに準拠するための拡張を追加。

SwiftUIとの連携:

Observationフレームワークは、特にSwiftUIとの連携がシームレスです。SwiftUIのView内で @Observable オブジェクトのプロパティが使用されると、そのViewは自動的にそのプロパティの変更を追跡し、変更が発生した際にViewを再描画します。

“`swift
import SwiftUI
import Observation

@Observable
class UserData {
var name: String = “Anonymous”
var age: Int = 0
}

struct UserProfileView: View {
// @StateObject や @ObservedObject の代わりに直接インスタンスを持つか、@Stateを使う
@State private var user = UserData() // 値型のようにStateで管理することもできる

var body: some View {
    VStack {
        TextField("Name", text: $user.name) // @Bindable を使うと双方向バインディングが簡単になる
        Stepper("Age: \(user.age)", value: $user.age, in: 0...100)
    }
}

}
“`

WWDC23では、SwiftUIにおける @State と @Bindable の新しい役割も紹介されました。

  • @State: 値型だけでなく、@Observable オブジェクトのインスタンスをローカルな状態として保持するのにも推奨されます。Viewのライフサイクルに合わせてオブジェクトが生成・破棄されます。
  • @Bindable: @Observable オブジェクトのプロパティに対する双方向バインディング（例: TextField や Stepper）をより簡単に記述するために使用されます。以前の @ObservedObject と $user.name の組み合わせに代わり、@Bindable(user).name のように記述します。

``swift
//@Bindable` を使った例
struct UserProfileView: View {
@State private var user = UserData() // @Observable オブジェクトを @State で保持

var body: some View {
    VStack {
        // @Bindable を使用し、オブジェクトのプロパティを双方向バインディング
        TextField("Name", text: $user.name)
        Stepper("Age: \(user.age)", value: $user.age, in: 0...100)
    }
}

}
“`

withObservationTracking 関数:

Observationフレームワークのもう一つの重要な要素は withObservationTracking 関数です。この関数は、特定のコードブロック内で @Observable オブジェクトのどのプロパティがアクセスされたかを追跡し、その後に発生するそれらのプロパティの変更を監視するために使用されます。

“`swift
func observeChanges(of user: UserData) {
withObservationTracking {
// このクロージャ内でアクセスされた user オブジェクトのプロパティが追跡される
print(“Current name: (user.name)”)
print(“Current age: (user.age)”)
} onChange: {
// 追跡されたプロパティのいずれかが変更された場合にこのクロージャが呼ばれる
print(“User data changed!”)
// 再度追跡を開始するために、この中で observeChanges(of: user) を再帰的に呼び出すことが多い
observeChanges(of: user)
}
}

let myUser = UserData()
observeChanges(of: myUser)

myUser.name = “Alice” // “User data changed!” が出力される
myUser.age = 30 // 再度 “User data changed!” が出力される
“`

このメカニズムは、SwiftUIのView更新の内部で利用されています。Viewの body クロージャを withObservationTracking でラップすることで、body 内でアクセスされた状態（@State, @Environment, @Observable オブジェクトなど）を追跡し、それらが変更されたときにViewを再描画するトリガーとするのです。

Combineとの比較とパフォーマンス:

Observationフレームワークは、Combineのような複雑なオペレーターチェーンを提供しません。その代わり、Swift Concurrencyの async/await や Task との連携を重視しています。シンプルながら、追跡されるプロパティをコンパイル時と実行時の両方で特定することで、Combineよりも効率的に不要な通知や計算を削減できる可能性があります。特にSwiftUIのような宣言的UIフレームワークとの相性が良く、パフォーマンス上のメリットが期待されます。

Observationフレームワークは、Swiftにおけるリアクティブプログラミングのアプローチを刷新するものです。マクロによるシンプルなAPI、SwiftUIとの深い統合、そしてConcurrencyを基盤とした効率的な設計は、これからのアプリケーション開発において標準的な状態管理手法となる可能性を秘めています。

3.4 String Catalog (文字列カタログ)

ローカライズは、多言語に対応したアプリケーションを開発する上で不可欠なプロセスです。Swiftが登場する以前から、Appleプラットフォームでは .strings ファイルや .stringsdict ファイルがローカライズに使用されてきました。WWDC23では、これらのファイルを置き換える新しいローカライズフォーマットとして、String Catalog (.xcstrings) が発表されました。

なぜString Catalogが必要か？

従来の .strings や .stringsdict ファイルにはいくつかの課題がありました。

  • 管理の複雑さ: キーと値のペアがテキストファイルに分散しており、特に .stringsdict で複数形などを扱うのは複雑でした。
  • XCodeでの編集の限界: XCodeの基本的なテキストエディタで編集する必要があり、翻訳者にとって扱いやすいフォーマットではありませんでした。
  • エラーの可能性: キーのtypo、ローカライズされていないキーの使用、フォーマット文字列の間違いなどがコンパイル時には検出されにくく、実行時エラーや意図しない表示につながることがありました。
  • プレビューの欠如: ローカライズされた文字列が実際のUIでどのように表示されるかを確認しにくかった。

String Catalogは、これらの課題を解決するために設計されました。

String Catalog (.xcstrings) の特徴:

  • 統合された編集インターフェース: XCode内で .xcstrings ファイルを開くと、専用のGUIエディタが表示されます。ここでは、各キー、デフォルト言語の値、ローカライズされた言語ごとの値、開発者コメント、状態（新規、レビュー待ち、翻訳済みなど）、そしてプレビューを一覧で管理できます。
  • リッチなローカライズ機能:
    • 複数形: .stringsdict の機能をより使いやすく、GUI上で複数形のルールを定義できます（単数、複数、ゼロ、その他など）。
    • デバイス固有の値: Apple Watch、iPhone、iPad、Macなど、デバイスの種類に応じて異なるローカライズされた文字列を提供できます。
    • 可変部の管理: %@, %d といったフォーマット指定子に含まれる可変部（バリアブル）に対して、開発者コメントや型ヒントを追加でき、翻訳者が文脈を理解しやすくなります。
  • ワークフローの可視化: 各文字列エントリには状態（State）があり、「New」「Needs Review」「Translated」「Approved」「Stale」などを設定できます。これにより、ローカライズの進捗状況をプロジェクト内で共有・管理しやすくなります。
  • プレビュー機能: XCodeエディタ内で、定義したローカライズ文字列が実際のUIでどのように表示されるか（例: 長さによる切り詰めがないか）をプレビューできます。
  • SwiftUI/UIKit/AppKitとの連携: String Catalogは、NSLocalizedString や SwiftUIの Text 初期化子など、既存のローカライズAPIと互換性があります。

localized マクロ:

String Catalogの導入と同時に発表された localized マクロは、ローカライズ文字列へのアクセスをより安全かつコンパイル時チェック可能にします。

“`swift
// 従来のローカライズ
// Text(NSLocalizedString(“greeting”, comment: “A greeting message”))

// localized マクロを使用 (String Catalogが必要です)
Text(localized: “greeting”, comment: “A greeting message”)

// 可変部を持つ場合
let count = 5
Text(localized: “items_count”, arguments: [count]) // String Catalogで items_count の複数形ルールを定義
“`

localized マクロは、コンパイル時に与えられたキー "greeting" がString Catalog内に存在するかどうかをチェックします。存在しないキーを指定するとコンパイルエラーになります。また、arguments で渡される値の型や数も、String Catalogで定義された可変部の型情報と照合されるため、実行時エラーを防ぐことができます。

String Catalogと localized マクロの組み合わせは、ローカライズのプロセスを大幅に改善します。開発者はキーのtypoや欠落といった問題をコンパイル時に検出できるようになり、翻訳者はXCodeの直感的なGUIエディタでより効率的に作業できます。複数形やデバイス固有の対応も容易になり、より高品質なローカライズを実現できます。既存の .strings や .stringsdict ファイルは、XCodeの機能を使ってString Catalogに簡単に移行できます。

3.5 Parameter Packs (パラメータパック)

Parameter Packsは、Swift 5.9でSE-0393として導入された高度なジェネリック機能です。これにより、ジェネリックパラメータの可変個リストを型レベルで扱うことができるようになります。これは、これまでタプルや関数型で実現が難しかった、型安全な可変個引数や高度な抽象化パターンを可能にします。

なぜParameter Packsが必要か？

Swiftには、可変個引数関数（func print(_ items: Any..., separator: String = " ", terminator: String = "\n") のようなもの）は存在しますが、これはランタイムの機能であり、型安全性には限界があります（Any... は任意の型を受け付ける）。また、タプル型は要素の数が固定です。

しかし、Swiftのフレームワーク、特にSwiftUIの ViewBuilder やCombineの Publishers.Zip のようなAPIでは、可変個の要素を型安全に扱う必要があります。例えば、ViewBuilder は可変個のViewを受け取り、それらを組み合わせて一つのViewに変換します。Publishers.Zip は複数のPublisherを結合し、それらの出力値をタプルとして排出します。これらのAPIは、要素の数ごとにオーバーロードされたメソッドを多数定義することで、この機能を実現していました（例: Zip3, Zip4, …, ZipN）。これはボイラープレートコードの温床となり、拡張性に限界がありました。

Parameter Packsは、この問題を型システムレベルで解決します。

Parameter Packsの構文と概念:

Parameter Packsは、ジェネリックパラメータリスト内で <each P> のように宣言されます。ここで P はパラメータパックの名前です。

swift
// Parameter Pack P を持つジェネリック関数
func processPack<each P>(_ values: repeat each P) {
// ...
}

上記の例で、repeat each P は「パラメータパック P の各要素について繰り返す」という意味の パック展開 (Pack Expansion) 構文です。もし P が (Int, String, Bool) というようなパックだった場合、repeat each P は (Int, String, Bool) という引数リストに展開されます。つまり、この関数は (Int, String, Bool) 型の引数を受け取れることになります。

Parameter Packsは、タプル型や関数型、そして構造体やクラスのジェネリックパラメータリストでも使用できます。

  • タプル型:
    “`swift
    func getTuple(_ t: repeat each T) -> (repeat each T) {
    return (repeat each t)
    }

    let myTuple = getTuple(1, “hello”, true) // myTuple は (Int, String, Bool) 型
    ``(repeat each T)という型は、パック展開されたタプル型を示します。パックTが(T1, T2, …, Tn)に展開されると、タプル型は(T1, T2, …, Tn)` になります。

  • 関数型:
    swift
    func compose<each Input, Output>(
    _ f: @escaping (repeat each Input) -> Output
    ) -> ((repeat each Input)) -> Output {
    // ... 実装は複雑になるが、型レベルで可変引数関数を扱える
    }
    ((repeat each Input)) -> Output という関数型は、パック展開された引数リストを持つ関数型を示します。パック Input が (I1, I2, ..., In) に展開されると、関数型は (I1, I2, ..., In) -> Output になります。

ユースケース:

Parameter Packsの最も強力なユースケースは、まさにSwiftUIの ViewBuilder やCombineの Publishers.Zip のようなAPIの内部実装です。Parameter Packsを使用することで、これらのAPIを要素の数ごとにオーバーロードすることなく、単一のジェネリック定義で実現できるようになります。

例えば、複数のViewをスタックに配置するような機能は、Parameter Packsを使って型安全に定義できるようになります。

“`swift
// 概念的な例：複数の View を受け取ってまとめる
struct VStackView: View {
var content: (repeat each Content)

var body: some View {
    // パック展開を使って各 View を VStack に追加
    VStack { repeat each content }
}

}

// 使用例
VStackView(
Text(“Hello”),
Image(systemName: “star.fill”),
Button(“Tap Me”) {}
)
``
（注: これは概念的な例であり、SwiftUIのVStack` の内部実装が Parameter Packs をどのように使うかは異なりますが、このような抽象化が可能になります。）

Parameter Packsは、高度なライブラリ開発者や、複雑な型システムを持つフレームワークを構築する開発者にとって特に強力なツールとなります。Swiftの型システムに新たな次元を加え、これまでは実現が難しかった、あるいはボイラープレートコードで溢れていたパターンを、よりクリーンかつ型安全に表現できるようになります。これは、Swiftが高度なメタプログラミングやDSL構築能力を持つ言語として成熟していく上で重要な一歩です。ただし、Parameter Packsは比較的低レベルなジェネリック機能であり、一般的なアプリケーション開発者が直接使用する機会は少ないかもしれません。

4. XCodeとの連携と開発体験

新しいSwiftの機能は、XCodeとの緊密な連携があって初めて開発者にその真価を発揮します。WWDC23で発表されたXCode 15は、これらの新機能をサポートするための様々な改善を含んでいます。

  • Swift 6コンパイラモード:
    プロジェクトのビルド設定で、Swift Language Versionを「Swift 6」に設定できるようになります。これにより、Swift 6の厳密なチェック（特にConcurrency関連）が有効になります。Swift 5.xコンパイラでも、前述のUpcoming Feature Flagsや Strict Concurrency Checking 設定を使ってSwift 6の挙動を部分的に試すことができます。
  • マクロ展開ビューア:
    XCodeエディタ内で、マクロが付加されたコードの横に、マクロによって生成されたコードを確認できる機能が提供されます。これにより、マクロがどのように機能しているかを理解し、デバッグすることが容易になります。
  • Concurrencyデバッグツール:
    実行時データ競合検出器の設定がより簡単になったり、デバッグセッション中に並行タスクの状態を視覚的に確認できるツールが提供されたりする可能性があります（WWDCセッションでの紹介に基づく）。これにより、並行処理に関連するデバッグが効率化されます。
  • String Catalogエディタ:
    .xcstrings ファイルを開くと表示される専用のGUIエディタは、ローカライズプロセスを大幅に改善します。翻訳者やQA担当者もXCodeを使って直接作業できるようになるため、開発者と非開発者の間のコラボレーションがスムーズになります。
  • Build Timeへの影響:
    マクロによるコード生成はコンパイル時に行われるため、ビルド時間に影響を与える可能性があります。特に複雑なマクロを使用する場合や、多くのマクロが使用されている大規模プロジェクトでは、ビルド時間が長くなる可能性があるため、注意が必要です。XCodeのBuild Timelineツールなどを使って、ビルド時間のボトルネックを特定することが重要になります。

これらのXCodeの改善は、新しいSwift機能の学習と活用を支援し、開発者がより効率的に、より安全なコードを書けるようにするためのものです。

5. Swiftエコシステムへの影響

WWDC23で発表されたSwiftの進化は、Appleプラットフォーム上のフレームワーク（SwiftUI, Core Data, RealityKitなど）はもちろん、オープンソースのSwiftライブラリやツール、そしてSwiftPM (Swift Package Manager) エコシステム全体に大きな影響を与えます。

  • フレームワークのアップデート:
    Appleは、自身のフレームワークを新しいSwift機能に合わせてアップデートします。例えば、SwiftUIはObservationフレームワークをViewの状態管理に活用し、Concurrencyモデルとの連携を強化します。Core Dataのようなフレームワークも、安全な並行アクセスを保証するためにactorやSendableを活用するように進化するでしょう。
  • ライブラリのSwift 6対応:
    既存の多くのSwiftライブラリは、Swift 6が正式リリースされる前に、Concurrencyの厳密なチェックに対応する必要があります。特に並行処理を内部で使用しているライブラリは、Sendable 違反を修正したり、actorを適切に導入したりする作業が必要になります。ライブラリのメンテナーは、Swift 6へのスムーズな移行パスをユーザーに提供するための準備を進める必要があります。
  • 新しいAPI設計パターン:
    マクロやParameter Packsのような機能は、ライブラリのAPI設計に新しい可能性をもたらします。ボイラープレートコードを削減したり、より型安全で表現力豊かなAPIを設計したりするために、これらの機能が活用されるでしょう。Observationフレームワークは、リアクティブなAPI設計の新しい標準となる可能性があります。
  • クロスプラットフォーム開発の推進:
    SE-0403で提案されたSwift SDKs for Cross-Platform Developmentは、SwiftPMが異なるOS（Linux, Windowsなど）向けのSDKを管理し、それらをターゲットにしたビルドを容易にするものです。これは、Swiftをサーバーサイドやコマンドラインツール、あるいは他のプラットフォームでより広く使用するための重要なインフラ改善であり、クロスプラットフォーム開発のエコシステムを活性化させるでしょう。
  • オープンソースへの貢献:
    マクロのように言語内で拡張可能な機能は、Swiftコミュニティが新しいツールや抽象化を開発し、貢献するための新たな道を開きます。開発者は自身でマクロを実装し、Swift Packageとして公開することで、他の開発者の生産性向上に貢献できます。

Swiftエコシステムは常に進化しており、WWDC23の発表は、この進化を加速させ、より堅牢で表現力豊かなSwiftの未来を築くための基盤となります。

6. Swiftの将来像

WWDC23で発表された機能は、Swiftの進化の最終形ではありません。これらの機能は、Swiftの長期的なロードマップの一部です。特に、Ownershipシステムは今後さらに進化し、より明示的なメモリ管理の制御（例: C++のunique_ptr/shared_ptrのような概念のSwift的な導入）、参照セマンティクスを持つ型に対するよりきめ細かい制御などが可能になるかもしれません。

コンパイラ技術も継続的に発展します。診断メッセージはより分かりやすくなり、ビルド時間は最適化され、コンパイラプラグインとしてのマクロのような機能もさらに洗練されていくでしょう。

Swiftは、単なるアプリケーション開発言語に留まらず、システムプログラミング、サーバーサイド、機械学習、そして他のプラットフォームへの展開をさらに強化していくことを目指しています。Swift 6でのConcurrencyの厳密化とOwnershipの進化は、これらの領域で求められる高い安全性とパフォーマンスを実現するための重要なステップです。

オープンソースコミュニティの活発な議論と貢献は、Swiftの未来を形作る上で不可欠です。Swift Evolutionプロセスを通じて提案される新しいアイデアや改善が、Swiftをより良い言語へと導いていくでしょう。

7. まとめ

WWDC23は、Swift言語にとって記念碑的なイベントでした。Swift 6への道のりが明確に示され、並行処理におけるデータ競合の防止がデフォルトになるという、言語の安全性における大きな前進が発表されました。Ownershipシステムの進化は、パフォーマンスを損なわずに安全性を高めるSwiftのアプローチを強化します。

同時に、マクロ、Observationフレームワーク、String Catalog、Parameter Packsといった新しい機能は、開発者の生産性、表現力、そして開発体験を劇的に向上させる可能性を秘めています。マクロはこれまでにないレベルのコード生成を可能にし、Observationはモダンで効率的なリアクティブプログラミングを提供し、String Catalogはローカライズプロセスを刷新します。Parameter Packsは、高度な抽象化を可能にする型システムへの重要な追加です。

これらの新機能や変更点は、個別に強力であるだけでなく、Swiftの既存の機能（例: Swift Concurrency, SwiftUI, Swift Package Manager）と連携することで、その真価を発揮します。XCodeの進化もまた、開発者がこれらの最先端機能を容易に活用できるようにサポートしています。

Swiftは常に進化し続けていますが、WWDC23での発表は、特に安全性と表現力の面で大きな飛躍を示しています。Swift 6への移行は、既存のコードベースに調整が必要となる可能性はありますが、データ競合のような深刻な問題を未然に防ぐことができるというメリットは、その労力を補って余りあるものです。

Swift開発者は、これらの新しい機能と変更点を積極的に学び、自身のプロジェクトにどのように活用できるかを検討すべきです。Swiftの未来は明るく、WWDC23で示された方向性は、Swiftが今後も多くの開発者にとって魅力的な選択肢であり続けることを保証しています。Swiftコミュニティの一員として、この exciting な旅の次の章に参加できることを楽しみにしています。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール