最新の開発者会議WWDC25で発表された Swift Approachable Concurrencyは、モバイルアプリにおけるもっとも一般的な使用例のために並行プログラミングを簡素化を目的としたSwift 6.2の新機能である。
Approachable Concurrencyの導入により、Swiftコンパイラはより予測可能になり、生成されるエラーや警告の数が減少し、これらのエラーや警告は、圧倒的な量になる可能性があり、必ずしもコードの実際の問題に関連しているとは限らない。
内部的には、Approachable Concurrencyは2つの新しいコンパイラフラグを導入する。「分離された適合性の推論」と「nonisolated(nonsending)のデフォルト強制」である。
最初の機能は「分離適合性」の概念を導入するものであり、型の適合をその型が属する同じ分離ドメインに制限した。この仕組みにより、例えば、MyModelTypeがEquatableに適合している場合を考えてみよう。
@MainActor class MyModelType: Equatable { ... } MyModelTypeは、Equatableのすべての要件への実装を提供し、それはMyModelTypeの分離ドメイン、例えば@MainActorにバインドされる。しかし、適合宣言には分離ドメインが指定されておらず、MyModelTypeはコンパイラに対してどの分離ドメインにも適合しているEquatableとして認識される。したがって、コンパイラはMyModelTypeのEquatable要件の実装への呼び出しを問題なくコンパイルするが、異なるアクターから呼び出された場合にはランタイムエラーが発生する。これを次の宣言と比較する。
@MainActor class MyModelType: @MainActor Equatable { ... この場合、適合性はそれを実装するクラスと同じ分離ドメインに制約され、コンパイラはメインアクター以外のアクターからMyModelTypeのインスタンスに対してEquatableメソッドを呼び出す試みを検出する。
新しいinfer isolated conformances機能により、プログラマーはEquatableへの適合性を明示的に制限する必要がなった。
第二の機能であるnonisolated asyncは、非分離の非同期関数がグローバル実行環境ではなく、デフォルトで呼び出し元のアクターの実行環境上で実行されると保証する。この新しい動きは、async、nonisolated関数たちの振る舞いを、一つにまとめて統一するものである。
Approachable Concurrencyは、もう一つの重要な並行性の関連機能である「デフォルトでメインアクターを使用」と共に導入される。これにより、プログラマーが明示的に指示しない限り、すべての関数がメインアクター上で実行されるという原則が強制される。
新機能は、多くのSwift開発者に歓迎されるだろうが、Swift 6の厳格な並行性モデルを採用することで多くの問題が発生し、Swiftフォーラムの長くも非常に興味深いスレッドで、Swift 6の並行性が進みすぎたのか、あるいは進むのが早すぎたのかと疑問を抱くことが多かった。
この議論は深く洞察に満ちているが、一つの要約として言えるのは、Swiftが言語、エコシステム、そしてドキュメントが完全に準備される前に、並行性を開発者に押し付ける形で進みすぎた可能性がある。また、モバイルアプリにとっては過剰だったとも言える。モバイルアプリは汎用的な並行ソフトウェアよりもシンプルである傾向がある。実際には、ほとんどのiOSおよびiPadOSアプリは主にメインスレッド上で動作し、UIの応答性を維持するために少数のタスクがバックグラウンドにオフロードされるだけだ。
著書『Practical Swift Concurrency』を含む複数のSwift関連書籍の著者であるDonny Wals氏は、次のように述べている。
「Xcode 26で作成された新しいプロジェクトでは、デフォルトでコードがメインアクター上で実行されるため、Approachable Concurrencyがその約束を本当に果たしていることがわかります。これにより、存在しない問題に対して奇妙な修正を必要とする特定の不明瞭なコンパイラエラーが解消されます。」
Approachable Concurrencyとデフォルトのメインアクター使用は、並行プログラミングを簡素化することを目的としたいくつかの新機能のうちの2つに過ぎない。これらの新機能は、今後リリースされるXcode 26のベータ版で段階的に導入される予定であると、Swiftチームの公式ビジョンドキュメントに記載されている。