Swift 6へのアプリの移行

Swift 6へのアプリの移行

既存のサンプルアプリを更新するデモで、Swift 6への移行の実際の流れを確認しましょう。モジュールごとに段階的に移行する方法や、データ競合のリスクのあるコードの特定に役立つコンパイラの機能について解説します。隔離の境界を明確に定義し、共有されたミュータブルステートのコードへの並列アクセスを排除するための、各種の手法もご紹介します。

関連する章
- 0:00 - Introduction
- 0:33 - The Coffee Tracker app
- 0:45 - Review the refactor from WWDC21
- 3:20 - Swift 6 and data-race safety
- 4:40 - Swift 6 migration in practice
- 7:26 - The strategy
- 8:53 - Adopting concurrency features
- 11:05 - Enabling complete checking in the watch extension
- 13:05 - Shared mutable state in global variables
- 17:04 - Shared mutable state in global instances and functions
- 19:29 - Delegate callbacks and concurrency
- 23:40 - Guaranteeing data-race safety with code you don’t maintain
- 25:51 - Enabling the Swift 6 language mode in the watch extension
- 26:35 - Moving on to CoffeeKit
- 27:24 - Enabling complete checking in CoffeeKit
- 27:47 - Common patterns and an incremental strategy
- 29:55 - Global variables in CoffeeKit
- 31:05 - Sending an array between actors
- 33:53 - What if you can’t mark something as Sendable?
- 35:23 - Enabling the Swift 6 language mode in CoffeeKit
- 35:59 - Adding a new feature with guaranteed data-race safety
- 40:43 - Wrap up and the Swift 6 migration guide
リソース
関連ビデオ

WWDC21
- Swiftの並行処理: サンプルAppの更新
ダウンロード

こんにちは SwiftチームのBenです本セッションでは既存のアプリで Swift 6の言語モードを有効にする手順を説明します競合に対する安全性を Swift 6がどのように実現するかを確認しこの変更をアプリに段階的に導入するための手法や Swiftの並列処理に関する保証をまだ認識していないフレームワークとのやり取りに対処する方法も確認します今回使用するのは一日に飲むコーヒーの量をトラッキングするシンプルなアプリと現在のカフェイン摂取量を文字盤に表示するコンプリケーションです WWDC21で Swiftの並列処理を初めて発表した時 Swiftの新しい並列処理モデルをこのアプリで採用する方法を説明しましたその解説では一見すっきりとしたアプリアーキテクチャが実際には複雑な並列処理が行われている場合があることを確認しましたビューやモデルを見るとすべてがきれいに整理されていますが並列処理がどう行われているか調べると別の様相が見えてきます元のアプリにはコードが随時実行される 3つの並列キューがありました UIとモデルでの操作はメインキューで実行されていましたまたバックグラウンドの処理を行うディスパッチキューもありましたさらに HealthKitから結果を返すコールバックのような完了ハンドラへの特定のコールバックを実行する任意キューもありましたこのように型はきれいに整理されていましたがアプリ全体での並列処理のあり方はそこまで明確ではありませんでした
どのキューがコードを実行しているのかそれはなぜなのかといった処理の全体をいくつもの型によって様々な場所で不明瞭な形で構成していました
Swiftの並列処理を採用することでこの場当たり的な並列処理アーキテクチャからご覧のような形へと移行しました UIビューとモデルはメインアクターで実行されるように設定されバックグラウンドの処理は専用アクターで実行されるようになりましたアクターは Swiftの async/await機能を使用してスレッドセーフな値型で互いに通信しますこれにより並列処理のアーキテクチャは型アーキテクチャと同じくらい明確で説明しやすくなりましたただ問題が1つありましたアーキテクチャを改善するためにこのリファクタリングを行う際プログラマーである私にはデータ競合を回避するという大きな責任がありましたすべてのガイドラインに従いアクター間の通信には値型を使いましたが必ずしもそうする必要はありませんでした例えばクラスなどの参照型を取りあるアクターから別のアクターに渡すこともできました参照型を使用すると共有のミュータブルステートを渡せますただしそうすると両方のアクターが共有されたステートに同時にアクセスできるようになるためアクターによる相互排他が機能しなくなりますつまりクラスのインスタンスをあるアクターから別のアクターに送信するとデータ競合が発生してプログラムのクラッシュさらにはユーザーデータの破損さえ生じかねませんそこで重要になるのが Swift 6の利点です
Swift 6の言語モードではデータ分離を全面的に適用できますコンパイラにより先述のようなタスク間やアクター間での不適切なステートの共有が防止されるのでリファクタリングの実行やアプリへの新機能の追加の際に並列処理のバグを新たに生じさせる心配がなくなります
Swift 6の言語モードは新規と既存の両方のプロジェクトで利用できますこのモードを導入するとアプリの品質が大幅に向上します並列コードにおけるミスをコンパイル時に検出できるからですこの機能が特に役立つのは再現が難しいクラッシュが発生している場合にデータ競合のリスクを詳しく把握して体系的に排除したいような時ですまた応答性とパフォーマンスを向上させるために並列処理の統合に積極的に取り組んでいる場合は Swift 6モードを導入すれば変更により新たなデータ競合が生じるリスクを確実に排除できます
Swiftの公開パッケージを管理している場合はコードベースを移行したいと考えているユーザーを支援するためにできるだけ早くSwift 6を導入することをお勧めします同様にSwift 6を導入済みの依存関係に基づいて開発できるためユーザーにとってもメリットになります人気のあるパッケージでの Swift 6の導入状況は swiftpackageindex.comで誰でも確認できます本セッションでは Swift 6が実際にどう機能するかをご紹介します CoffeeTrackerアプリで Swiftのデータ分離機能を有効にします手順を追いながらコンパイラから提供されるガイダンスに沿って CoffeeTrackerにおいてデータ競合が発生しないことを Swiftで保証できるよう変更を加えるべき箇所を見ていきます今のところ私のアプリにはデータ競合が含まれていないと確信していますそしてきっとみなさんのコードも同じ状況だと思います長年の改良やバグレポートを通じてまたメインスレッドチェッカーやスレッドサニタイザーなどを使用して既存のコードに含まれるデータ競合の大半をすでに解消している場合もあるでしょうデータ競合安全の真の価値は新しくコードを記述する際にバグの混入を防げることです新しい機能を追加する際や並列処理を有効に活用するためにコードをリファクタリングする際もですデータ競合安全によりアプリで並列処理を活用できます新たなデータ競合が生じるリスクを恐れることなく後で追跡したり推測に基づく修正を加える必要がありませんクラッシュを再現できないからです
前回ご紹介した時から CoffeeTrackerアプリはとても好評なためチームを拡大して新機能の追加を開始しました
その一環としてアプリの一部を新フレームワークのCoffeeKitに組み込みコードの一部が現在そこにあります新機能をアプリに追加することにチームは意欲的ですがその前にアプリを Swift 6に更新するつもりですそうすれば新機能の追加を進めても並列処理のバグが生じることはありません今 Xcode 16をダウンロードして開いたところですつまり新しいSwift 6コンパイラと watchOS 11用の最新のSDKがありますアプリをビルドしてみましょう
うまくビルドできました更新の必要はありませんただしそれはデータ競合の恐れがないからではありません単にSwift 6の言語モードをまだ有効にしていないだけです以前のリリースと同様に Swift 6ではソース互換性が保証されますごくわずかな変更を除きアプリは常に新しいコンパイラでビルドできるはずです
アプリを最新のXcodeでビルドできることが分かったので次のステップに進み Swift 6モードを有効にしてデータ分離を全面的に適用しましょうそのための準備としてコンパイラ診断を有効にする前に MainActorとSendableの監査を行ってみることもできますただしその場合は新しいSwiftコンパイラがもたらすメリットを活用できませんコンパイラ診断により修正が必要な箇所がわかりますパートナーがコードのバグを指摘してくれるペアプログラミングのようなものですこれにより一定の構造を移行プロセスに追加できます段階的な手順に沿ってコード内の各ターゲットを移行していきます各ターゲットについて次の手順を実行しますまず並列処理の完全なチェックを有効にしますこれはモジュールごとの設定でプロジェクトはSwift 5モードのままですが Swift 6の強制的なデータ分離ではエラーとして検出されるすべてのコードに警告が表示されるようになりますこれらのターゲットに表示された警告をすべて解決していきます完了したら Swift 6モードを有効にしますこれにより変更がすべてロックされ将来のリファクタリングで安全でない状態に戻ることが防止されますその後次のターゲットに移り同じプロセスを繰り返しますこの機能を有効にしたあと改めてアプリ全体をリファクタリングすることもできますそれによりアーキテクチャを変更して安全でないオプトアウトを取り消したりコードを改良するためのリファクタリングを実行したりできますリファクタリングに関するアドバイスを 1つ紹介します大幅なリファクタリングとデータ競合安全の有効化を一緒に行うことはできるだけ避けてください 1つずつ進めてください両方を同時に実行しようとすると多くの場合は一度に変更するものが多くなりすぎて後戻りしなければなりません
ここでは Swiftの並列処理を使うようすでにリファクタリングしたアプリで Swift 6を有効にする手順のみに焦点を当てますではまず完全なチェックを有効にします完全なチェックで何が可能になるでしょう Swiftの並列処理をアプリですでに使用している方は Swiftの並列処理機能の導入時に発生した並列処理の問題に関する Swiftコンパイラの警告やエラーを見たことがあるでしょう例えばここでは新しいデリゲートを追加していますカフェインレベルが心配なほど少ない時に CoffeeKitから通知してもらうために追加しているコールバックを受け取ることが目的ですこのデリゲートは SwiftUIビューに値を公開するのでメインアクターに分離する必要があります @MainActorを先頭に追加すると
そのすべてのメソッドとプロパティのアクセスをメインスレッドで行うように指示できますただしこのようにするとプロトコルの実装に関するコードの下部でエラーが発生します
次のような内容です「Main actorで分離されたインスタンスメソッド'caffeineLevel(at:)'は非分離のプロトコル要件を満たすために使用することができません」このCaffeineThresholdDelegate プロトコルについては
どのように呼び出されるか現時点では何の保証もしていません CoffeeKitに含まれていますがこれはまだ Swift 6に更新されていませんただしここでは Recaffeinater型をそれに準拠させてメインアクターに制約していますそのメソッドはメインアクターで実行されるためメインアクターで呼び出されることが必ずしも保証されないプロトコルに準拠させることはできませんこの問題は後ほど改めて解決しますがこれは Swiftコンパイラで生成されるエラーの一例でメインアクターで型が呼び出されているかをチェックするよう選択したために発生します以前のセッションでも説明したように Coffee Trackerに Swiftの並列処理を導入するとこうした問題が色々と発生することになりますアプリ内の様々な箇所に並列処理が導入されるためです
ターゲットのビルド設定で厳密なチェックを有効にすると競合状態が生じる可能性があるかモジュール全体でチェックされますではこれを有効にしてどうなるか見てみましょう Swiftのデータ分離はターゲットごとに有効にしますこのアプリには主なターゲットが2つあります
1つはUIレイヤーが存在する WatchKit Extensionでもう1つはカフェインをトラッキングし HealthKitに保存するビジネスロジックが存在するフレームワークのCoffeeKitです
まず WatchKit Extensionで完全なチェックを有効にしましょうこれには2つの理由があります 1つ目は通常こちらの方がより簡単に並列処理チェックを有効化できることです UIレイヤーの大部分はメインスレッドで実行され SwiftUIやUIKitなどの APIを使いますがこれらのAPI自体はメインスレッドで操作を実行することが保証されています理由の2つ目は厳密な並列処理を有効にする際多くの場合 Swiftの並列処理に対応するための更新が済んでいないほかのモジュールを操作する必要があることです更新されることのない Cライブラリを使っているかもしれませんまたは Swift 6にこれから更新する予定のフレームワークやパッケージモジュールかもしれませんそしてもちろん今回の CoffeeKitフレームワークも含まれますこうしたトップダウン方式がなぜ良いのか実際に始めてみるとわかりますでは最初のステップとして Extensionを選択しその設定に移動しましょうそして Swiftの並列処理チェック設定を検索し
完全なチェックとなるようにに設定します
このように設定すると並列処理の安全性が確認できないコードについてコンパイラが警告を出すようになりますこれらは単なる警告でプロジェクトのビルドと実行は可能ですビルドしてみましょう
すると先ほど見た警告のほかにいくつかの警告が表示されます確認してみましょう
さて最初の問題は Swift 6で対処しなければならないよくある問題の1つでこの「logger」変数に関するものです
このように loggerインスタンスはグローバル変数として宣言されていますグローバル変数は共有されたミュータブルステートのソースでありプログラム内のすべてのコードが実行スレッドに関係なくこの同じ変数を読み書きできますつまりこれはデータ競合の原因になりやすいので安全にする必要がありますその方法は複数あります実際に問題を開いてみると
推奨の方法がいくつか示されています
最初の方法が最も簡単で読み取り専用にするだけです loggerはSendable型ですつまり let変数として宣言されている場合は複数のスレッドから使用してもデータ競合は発生しません varからletに置き換えてみましょう再ビルドします
この問題は解決ですこれは適切な修正ですがほかにも方法があります
イミュータブルにしたくないとしましょう後で値を更新したいなどの理由で letではなくvarのままにしたい場合です
この場合使えるのはこのグローバル変数をグローバルアクターに紐づける方法ですこれはUIレイヤー内であるためすべてのログ記録はメインアクターで行われるでしょうそこでこのグローバル変数に @MainActorという注釈をつけます
これですべてのログ記録の使用がメインアクターからとなりやはり警告が消えます
最後の例としてコンパイラでは強制できないほかの外部メカニズムでこの変数を保護する場合もあります例えばディスパッチキューですべてのアクセスを保護しているとしますこの場合 nonisolated(unsafe)キーワードを使えます
Swiftのほかの箇所で「unsafe」という語を使う場合と同様にこの変数の安全性を確保することはユーザーの責任になりますこれは最後の手段であるため通常は Swiftによるコンパイル時の保証を使うことをおすすめしますしかしコンパイラがすべてを把握することはできないのでそのような場合には 1つの方法として nonisolated(unsafe)を使用できますこの方法は後からもう一度コードのリファクタリングが必要になるケースの例かもしれませんこの変数をアクターに移動し変数が安全に使われていることをコンパイラで検証可能にするためにですただこの時点ではこれをnonisolated(unsafe)としてマークし次の警告に進むこともできます今回はそのようなケースではないので元に戻してこの変数をletとして宣言します
これが最善の方法ですさてグローバル変数を初期化するこのイニシャライザについて
次のような疑問が生じるかもしれませんいつ実行されるのかという点やそれを知ることはスレッドの安全性の理解のために重要ではないかという点です
Swiftのグローバル変数は遅延初期化されます値が初期化されるのは最初の使用時つまり CoffeeTrackerが初めてログを記録する時ですこれはCやObjective-Cと比べた場合の非常に重要な違いですこれらの言語ではグローバル変数は起動時に初期化されますこれは起動時間に大きな悪影響を及ぼします Swiftの遅延初期化ではこうした問題を避けてより早くアプリが使える状態になりますしかし遅延初期化は競合の原因ともなる可能性があります 2つのスレッドが同時にこのグローバル変数を使用して初めてログを記録しようとしたらどうなるでしょうか loggerを2つ作成できるでしょうか Swiftではそのような心配は不要ですグローバル変数がアトミックに作成されることが保証されているためです 2つのスレッドがloggerに同時にかつ初めてアクセスしようとした場合一方だけがこの変数を初期化しもう一方はブロックされて待機しますこれで問題は解決したので次の問題を見てみましょう
こちらは WKApplicationの共有インスタンスにアクセスするコードですこのグローバルインスタンスメソッドはメインアクターに分離された要素の一例です
ここで最初に注意すべき点はアクターに分離されたステートの呼び出しは暗黙的に非同期であることですつまりこれが非同期関数の場合 awaitを使用してメインアクターのこのグローバル変数にアクセスできますこの関数は非同期ではないので非同期としてマークするか新しいタスクの開始が必要ですただしコンパイラは別の修正法を提案しています
この関数をメインアクターに配置するだけです
これはビューのメソッドではなくフリー関数なのでデフォルトではメインアクターに配置されませんこの修正を適用してみましょう
これでこのメソッドはメインアクターに分離されましたビルドしてみると成功します
成功した理由を確認するために呼び出し元を簡単に見てみましょう
2回呼び出されていて 2回ともメインアクターにあるメソッドから呼び出されていますメインアクター以外の場所でこの関数が呼び出されていたならそのことを通知するコンパイラエラーが発生しその呼び出し元を調べて呼び出し時のコンテキストを確認できたでしょう 1つはSwiftUIビューですもう1つは WKApplicationDelegateの実装内ですこちらを見てみましょう
WKApplicationDelegateを Optionキーを押しながらクリックするとメインアクターに関連づけられたプロトコルであることがわかりますこれによりメインアクターでのみ呼び出されることが保証されます WatchKitフレームワーク経由か Swift 6モードを有効にしたあとコード経由で呼び出されます
メインアクターでのみ動作するように設計されたデリゲートや SwiftUIビューなどのほかのプロトコルはこのような注釈がよくついていますが Xcode 16に付属する最新のSDKでは特にそうですそして何よりもこれには SwiftUI Viewプロトコルが含まれていますこれまでは厳密な並列処理チェックを有効にした場合新しいSDKで必要となるよりも多くのメインアクターの注釈を追加する必要がありそうした注釈の一部を削除できることもありました次にデリゲートコールバックと並列処理について少しお話ししましょうご存じと思いますがデリゲートまたは完了ハンドラからコールバックを受信する時は常にそのコールバックでの並列処理についてどのような保証があるかを最初に把握する必要があります一部のコールバックには保証がありすべてのコールバックが常にメインスレッドで実行される旨がドキュメントに記載されている場合があります多くのUIフレームワークがこの保証を提供していますそうした理由もありコールバックをメインアクターとしてマークしている場合 Watch Extensionのビューレイヤーにそれほど多く警告が表示されません
一方デリゲートの一部ではその逆でコールバックの方法について保証はなく任意のスレッドやキューで実行されると記載されていますこの場合に大きなメリットを得られるのはアプリのバックエンドで処理されることが多いコールバックです CoffeeTrackerでHealthKitから受け取るコールバックは主にこのタイプですそのような場合ユーザーは適切なキューやアクターに再ディスパッチするかスレッドセーフな方法で処理を行う必要がありますこの方法の問題点はドキュメントでしか確認できないルールが各デリゲートにあり適切な処理を行うためにユーザーに大きな負担がかかることですコールバックがどこで行われるのかやロジックの次の部分をどこで行うのかをユーザーが考えなくてはなりませんそして確認を忘れたり適切な場所への再ディスパッチを忘れたりすると簡単にデータ競合が発生しかねませんさらに悪い状況としてコールバックがすでに配置され動作しておりたまたまいつもメインキューで実行されていただけで必ずしもそれが保証されているわけではないとしましょうその後このフレームワークに何か変更が加えられると別のキューでコールバックが実行されることになりますしかし UIレイヤーはこのコールバックのメインキューでの実行を前提としていますここで欠けているのはローカルな推論ですこれは UIレイヤーで作業している時にアプリ内のほかの場所のコードで処理を行うキューを変えるような変更が加えられても簡単には齟齬が生じないという保証です
Swiftの並列処理ではこの問題に対処するためにこうした保証が行われるかまたは保証がないことが明示されますあるコールバックについてコールバックの方法が指定されていない場合非分離と見なされ特定の分離を必要とするデータにはアクセスできません一方コールバックで分離が保証される場合例えば常にメインアクターでコールバックされる場合そのデリゲートプロトコルまたはコールバックについて常にメインアクター上にあると注釈をつけることができるのでコールバックの受け取り側ではその保証により懸念を解消できますそれでは最初に見た警告に戻りましょうメインアクター上のデリゲートの型が nonisolatedプロトコルに準拠していないというものですここではいくつかの方法をコンパイラが提案しています 1つ目はメソッドを nonisolatedとして宣言する方法ですこれによりこのメソッドはメインアクターに分離された型のメソッドであるにも関わらずメインアクターに分離されなくなりますこれはコールバックの実行場所について意図的に保証しないコールバックに適した方法ですこれはビューなので当然ながらすぐにでもメインアクターの作業を始めたいところですそうしないとこのコードをコンパイルする時に新しいエラーが発生しますメインアクターによって保護されているビューのプロパティにアクセスしているからです
これを修正するにはメインアクターでタスクを開始します
ただしこの場合のコールバックはメインアクター上にあると想定されていてメインアクターで実行されている CoffeeKit内のモデルの型から送られてくることがわかっています
コードベース全体を保守している場合に使用できる 1つの方法は今すぐ修正することです定義に移動するとこのように CoffeeKit内にプロトコルがあります @MainActorの注釈をつければメインアクターで呼び出されることを保証できますしかし誰もがコードベース全体を保守しているとは限りません別のチームが CoffeeKitを保守している場合やほかの担当者が保守するフレームワークやパッケージを利用している場合もあります今回はこれが当てはまるとしてデリゲートの実装に戻りましょう
さてこのメソッドはメインアクターで呼び出されるとわかっていますコードを確認済みであるかこのデリゲートのドキュメントで確かめたのかもしれません
特定のアクターで呼び出しが行われると確実にわかっている場合はそれをコンパイラに知らせるための方法があります assumeIsolatedというものです
コードの先頭をTaskにする代わりに MainActor.assumeIsolatedと記述しますこれで新しいタスクをメインアクターで非同期で開始することなくメインアクターでコードが実行されていると Swiftに知らせるだけになります
コードの一部がメインアクター以外からこの関数を呼び出す可能性は依然として十分にあることに注意してくださいこれはメインスレッドから呼び出されることを前提とする現在のSwift関数と同じですこれを防ぐ方法はその関数が実際にメインアクターにあるというアサーションを関数内に追加するというものですがそれこそがassumeIsolatedの機能ですこの関数の呼び出し元がメインアクターでなかった場合トラップが発動しプログラムの実行が停止しますトラップの使用は望ましくありませんが競合状態によってユーザーデータが破損するよりはましです
メインアクターでの呼び出しを前提とするデリゲートプロトコルに準拠させるこのパターンは一般的であるためもっと簡単な方法が用意されていますそこで変更を元に戻し
代わりにプロトコルへの準拠について @preconcurrencyと記述しましょう
これは先ほど記述したことのすべてに相当しますこのビューの分離先であるアクターで呼び出されていると想定しそうでない場合トラップを発動します
並列処理に関する警告をすべて解消したのでこのターゲットで Swift 6を有効にする準備ができました設定に移動します今度はSwift言語モードを検索します
Swift 6に設定します
コンパイルしますエラーや警告なしでビルドできますデータ分離の完全なチェックが Extensionに組み込まれました今後は変更を加えてもデータ分離の完全なチェックがコンパイラで実行されるのでデータ競合を誤って発生させることはありませんこれで ExtensionがSwift 6モードになったので続いて CoffeeKitターゲットに注目しましょう今度はこのターゲットに取り組みます @MainActorの注釈をデリゲートプロトコルに追加しましょう検索してメインアクターの注釈を追加し再ビルドすると新しい警告が表示されます
警告は再びExtension内であり先ほど追加した @preconcurrency属性に関するものです
このプロトコルがメインアクター上にあることが保証されているとコンパイラが認識できるようになったため @preconcurrency属性は必要なくなったと警告していますでは削除しましょう
これでこの問題は解決したので先ほどと同じ手順に従って並列処理の完全なチェックを有効にしますプロジェクトの設定に移動し
CoffeeKitターゲットでチェックを有効にします
ビルドします
今度は警告が増えて 11個表示されていますごくシンプルなプロジェクトでも結構な数の警告が出ます
この程度の警告はよくあることです並列処理の完全なチェックをプロジェクトで有効にすると数百や数千もの警告が生成されることもあります何か大変なことをしたのではと心配になるかもしれませんが慌てないことが大事です
ちょっとした問題が原因で大量の警告が表示されるのは珍しくありませんそして多くの場合こうした問題はすぐに修正できます
並列処理の警告を最初に片づける時はメソッドをメインアクターに配置するグローバル変数をイミュータブルにするなどいくつかの簡単な変更によりこのような多数の警告をすばやく減らせますおすすめの戦略は厳密なチェックを初めて有効にした時はすぐに成果を得られる点を見つけて対処しまず最も簡単な修正で警告を減らすことです多くの問題の根本原因となっている問題を探すことも大切です場合によっては 1つの行を変更するだけで関連する数百の問題を解決できます以前のバージョンのXcodeで完全なチェックを試している場合は最新のXcodeベータ版を試してみる価値もあります新しいSDKには移行に役立つ追加の注釈が含まれているからです例えば現在はすべてのSwiftUIビューがメインアクターに関連づけられているため MainActorの注釈をビューの型に自分で追加する必要がなくなりました実際こうした注釈は削除できる場合がありますすでに推論されているからです
それが完了するとたいていは対処が難しい警告の数が大幅に減っていますもう1つのポイントはすべての問題に一度に対処する必要はないということですリリースを公開する必要がある場合や差し迫った変更を行う必要がある場合は設定に戻って厳密なチェックを再び無効にできますこれらの警告を減らすために行ったすべての変更はコードベースに対する有効な改善となるので保存しておけば一時的にチェックを最小限に戻した場合でも後から確認できます後ほど準備ができたらこの設定に戻り改めて対処できます
今回のケースでは警告を確認してみると先ほど見たパターンがあるのがわかりますこれらのグローバル変数のいくつかは varとしてマークされていますがこれらはすべて定数であるかミュータブルである必要のないものです先ほど見たloggerと同様ですこれらはすべて簡単に解決できますちなみにこれは複数行編集のスキルが役立つ場面です
varをハイライトし
Cmd+Option+Eキーですべて選択して
letに変更します
ビルドします
これでこれらの警告が消えます
以上の例では実際より簡単に見せるためにわざと楽なものを用意したのではありませんこれはあくまでサンプルプロジェクトで実際のプロジェクトではより多くの警告が表示されますしかし私たちの経験では実際の本格的なプロジェクトでもこれはよくあることで簡単に解決できるものが大半でありそれが片づけば残りの困難な問題は少数です最後のエラーを見てみましょうこれらの問題の原因は様々なアクター間で Drinkの配列を渡していることです例えばこの1つ目が示しているのは self.currentDrinksをこのsaveメソッドに送るとデータ競合が生じ得るということです saveは別のアクターのメソッドであることに注意してください CoffeeDataはメインアクターにありますこれはSwiftUIの ObservableObjectなのでそうである必要があります
一方 saveは別のアクター上つまり
このCoffeeDataStoreアクター上にありますこのアクターはバックグラウンドでディスクからの保存と読み込みを行います警告に戻るとメインアクターに分離されたモデル内に保持しているDrinkの配列と同じものを saveに送信していることがわかります
Drinkが参照型の場合メインアクターと保存アクターの両方が共有されたミュータブルステートに同時にアクセスできるためデータ競合が発生する可能性がありますこの問題に対処するために Drinkを見てみましょう定義に移動してみると
構造体であることがわかりイミュータブルなプロパティがありますがそれらはすべて値型ですこれに基づいて判断すると明らかにSendableにすることができまったく問題なく Drinkをあるアクターに保存してからその同じ配列を別のアクターに送信できます
これがinternalの型であった場合は Swiftは自動的にこの型をSendableと見なしますしかしこれはpublicの型なので CoffeTracker Extensionを使用して CoffeeKitの外部で共有します
Swiftでは publicの型がSendableかどうかは自動的に推論されませんこれが行われない理由は型をSendableとしてマークすることはクライアントへの保証になるからです現時点ではこの型にミュータブルステートはありませんが後から変更したくなるかもしれないので Sendableかどうかを焦って確定したくはありませんそのため Swiftでは publicの型には Sendableへの準拠を明示的に追加する必要があります
この場合もそうしたいと思いますちなみにこれは 1つの行を変更するだけで複数の警告を一度に解消できる例です 3か所で Drinkの型を Sendableに変更する必要があります大規模なプロジェクトでは3つでは済まず複数のプロジェクトで数十の警告が発生することもありますそれではこの型をSendableとしてマークしましょう
再コンパイルします
すると Sendableではない別の型があることがわかります
これは単なる列挙型なので Sendableとしてマークすることもできますしかしそうでない場合例えば Objective-C型でミュータブルステートを参照型に格納するため Sendableではない型であった場合はどうでしょうかこの時点で安全性について選択をする必要があるかもしれません 1つの方法はその型について推論しそれがミュータブルな参照型であっても例えば NSCopyingで生成された新しいコピーなので安全だと見なすことです考えられる方法としては Sendableではなくてもそのクラスを保護し例えば変数をprivateにして Sendableな型に格納することもできますそうするためにこの場合も nonisolated(unsafe)キーワードを使えます
これを行うと Sendableの注釈を使用して Drinkの型がコンパイルされます今回はこの必要はないので変更を元に戻し
代わりに DrinkTypeに移動して
これもSendableとしてマークします
CoffeeKitでの並列処理に関する警告をすべて解消したのでこのターゲットで Swift 6モードを有効にできますもう一度設定に移動します
今度はSwift言語モードを検索します
Swift 6に設定します
コンパイルします
ビルドできますこの時点で CoffeeTrackerアプリ全体が Swiftの並列処理で保護されています
保護されるようになったので CoffeeTrackerに新しい機能を追加してみましょうユーザーが求めているのはコーヒーを飲んだ時の位置情報を追跡しそのデータを活用してカフェイン摂取習慣について役立つ情報を得ることですそこで CoreLocationをアプリに追加しますでは CoffeeKitのaddDrinkメソッドに移動しましょう Drinkを追加する直前に CoreLocationを使用してユーザーの現在位置を取得します CoreLocationには現在位置をストリームする非同期シーケンスがありますこれは Swiftの並列処理に適していますここではその機能を使い位置情報の結果をループ処理して適切な水準の精度が得られた時点でカフェインのサンプルに位置情報を割り当てることができますこのコードにはタイムアウトを追加したほうがいいと思いますがこれには Swiftの構造化された並列処理とキャンセルで対応できますこの方法には1つだけ問題があります
CoffeeTrackerの最小の配備ターゲットを引き上げる必要があるのですそしてその準備がまだできていません一部のユーザーは watchOS 10にまだ更新したくないけれどコーヒーをどこで飲んでいるか追跡したいと考えていますそのためデリゲートコールバックに基づく古いCoreLocation APIを代わりに使用する必要がありますこれはSwiftの並列処理より前のものなので使うのに少し技巧を要します先ほど紹介した新しい方法の本当に優れた点はこのコードが通常の同期コードのように見えることです位置情報を要求して位置情報更新の受信ストリームをループ処理し十分な精度が得られるまで反復するというプロセスをすべてこの関数内で行い新しいDrinkを配列に追加できます一方デリゲートAPIでは何らかのステートを保存しておきデリゲートメソッドが作動するのを待ち作動したあとさらに Drinkの値を位置情報とともに保存する必要がありますしたがって新しいAPIを活用できるように配備ターゲットを引き上げる価値はあります
しかしそれを望まないとしましょうそこでこの新しいコードを削除し
このファイルの一番下まで移動して
CoreLocationデリゲートオブジェクトを作成します
これはデリゲートクラスの基本的な実装で CoreLocationから位置情報の更新を受け取ることができます CoreLocationのこの部分は Swiftの並列処理よりも前のものですそのためルールを守れるようにさらに作業が必要になります今回の解説でご紹介したほかのコールバックとはこのCLLocationデリゲートは少し異なりますどのスレッドで呼び出されるかについて静的な保証がありません
ここまで説明してきたのは常にメインスレッドで呼び出されるデリゲートか任意のスレッドで呼び出されるデリゲートでした CoreLocationManagerのドキュメントを見るとこのデリゲートが呼び出されるスレッドは CLManagerを作成したスレッドで決まると保証されていることがわかりますこれは動的なプロパティであり Swiftで自動的に適用するには手を加える必要があります
今回の場合はメインアクターからモデルの型でこの情報を使っていますしたがって最も簡単な方法はこのデリゲートもメインスレッドに配置することです Swiftでそれを適用できるようにするモードに戻すのは簡単ですこの型を完全にメインアクターに配置します
これにより位置情報マネージャはメインスレッドで作成されるようになります
場所はイニシャライザ内ですそしてデリゲートもメインアクターに配置されることになります
もちろんこれを行うとおなじみのエラーがコンパイラから表示されますこのデリゲートコールバックはメインアクターに分離されていないからですこれに対処する方法のパターンはすでに見てきました
デリゲートを nonisolatedとしてマークします
次にメインアクターで実行する必要があるコードを MainActor.assumeIsolatedの呼び出しでラップします
これでビルドが成功します Swift 6で構築しながらアプリで現在の位置情報を取得できるようになりました今回はSwift 6の言語モードにアプリを移行するための手法をいくつか簡単にご紹介しましたここでは取り上げなかったシナリオが多数ありますがご利用いただけるリソースがほかにもあります最初にご覧いただきたいのは過去のセッションです Swiftの並列処理機能で既存のアプリを最新の状態にする方法について説明していますこのコードをSwift 6に移行するためのプロセスの大部分がその解説で取り上げたリファクタリングでより簡単になりました過去の移行から得た教訓に基づいて Swift 6の言語モードへの移行は Swiftエコシステム全体で段階的に進められるようになっていますつまりコードの変更を1つずつ行いデータ競合を排除することができます静的データ競合の安全性と動的データ競合の安全性の間を橋渡しする手法について今回少しだけお話ししましたが私たちはコミュニティとしてこの移行に取り組んでいますこれらすべての戦略とその他の内容をまとめたガイドを Swift.org/migrationでご覧いただけますご自身のコードを作成する際にこれらのリソースがお役に立てば幸いですご視聴ありがとうございました

9:08 - Recaffeinater and CaffeineThresholdDelegate

//Define Recaffeinator class
class Recaffeinater: ObservableObject {
    @Published var recaffeinate: Bool = false
    var minimumCaffeine: Double = 0.0
}

//Add protocol to notify if caffeine level is dangerously low
extension Recaffeinater: CaffeineThresholdDelegate {
    public func caffeineLevel(at level: Double) {
        if level < minimumCaffeine {
            // TODO: alert user to drink more coffee!
        }
    }
}

9:26 - Add @MainActor to isolate the Recaffeinator

//Isolate the Recaffeinater class to the main actor
@MainActor
class Recaffeinater: ObservableObject {
    @Published var recaffeinate: Bool = false
    var minimumCaffeine: Double = 0.0
}

9:38 - Warning in the protocol implementation

//warning: Main actor-isolated instance method 'caffeineLevel(at:)' cannot be used to satisfy nonisolated protocol requirement
public func caffeineLevel(at level: Double) {
      if level < minimumCaffeine {
          // TODO: alert user to drink more coffee!
      }
}

9:59 - Understanding why the warning is there

//This class is guaranteed on the main actor...
@MainActor
class Recaffeinater: ObservableObject {
    @Published var recaffeinate: Bool = false
    var minimumCaffeine: Double = 0.0
}

//...but this protocol is not
extension Recaffeinater: CaffeineThresholdDelegate {
    public func caffeineLevel(at level: Double) {
        if level < minimumCaffeine {
            // TODO: alert user to drink more coffee!
        }
    }
}

12:59 - A warning on the logger variable

//var 'logger' is not concurrency-safe because it is non-isolated global shared mutable state; this is an error in the Swift 6 language mode
var logger = Logger(
    subsystem:
        "com.example.apple-samplecode.Coffee-Tracker.watchkitapp.watchkitextension.ContentView",
    category: "Root View")

13:38 - Option 1: Convert 'logger' to a 'let' constant

//Option 1: Convert 'logger' to a 'let' constant to make 'Sendable' shared state immutable
let logger = Logger(
    subsystem:
        "com.example.apple-samplecode.Coffee-Tracker.watchkitapp.watchkitextension.ContentView",
    category: "Root View")

14:20 - Option 2: Isolate 'logger' it to the main actor

//Option 2: Annotate 'logger' with '@MainActor' if property should only be accessed from the main actor
@MainActor var logger = Logger(
    subsystem:
        "com.example.apple-samplecode.Coffee-Tracker.watchkitapp.watchkitextension.ContentView",
    category: "Root View")

14:58 - Option 3: Mark it nonisolated(unsafe)

//Option 3: Disable concurrency-safety checks if accesses are protected by an external synchronization mechanism
nonisolated(unsafe) var logger = Logger(
    subsystem:
        "com.example.apple-samplecode.Coffee-Tracker.watchkitapp.watchkitextension.ContentView",
    category: "Root View")

15:43 - The right answer

//Option 1: Convert 'logger' to a 'let' constant to make 'Sendable' shared state immutable
let logger = Logger(
    subsystem:
        "com.example.apple-samplecode.Coffee-Tracker.watchkitapp.watchkitextension.ContentView",
    category: "Root View")

17:03 - scheduleBackgroundRefreshTasks() has two warnings

func scheduleBackgroundRefreshTasks() {

    scheduleLogger.debug("Scheduling a background task.")

    // Get the shared extension object.
    let watchExtension = WKApplication.shared() //warning: Call to main actor-isolated class method 'shared()' in a synchronous nonisolated context

    // If there is a complication on the watch face, the app should get at least four
    // updates an hour. So calculate a target date 15 minutes in the future.
    let targetDate = Date().addingTimeInterval(15.0 * 60.0)

    // Schedule the background refresh task.
    watchExtension.scheduleBackgroundRefresh(withPreferredDate: targetDate, userInfo: nil) { //warning: Call to main actor-isolated instance method 'scheduleBackgroundRefresh(withPreferredDate:userInfo:scheduledCompletion:)' in a synchronous nonisolated context
        error in

        // Check for errors.
        if let error {
            scheduleLogger.error(
                "An error occurred while scheduling a background refresh task: \(error.localizedDescription)"
            )
            return
        }

        scheduleLogger.debug("Task scheduled!")
    }
}

17:57 - Annotate function with @MainActor

@MainActor func scheduleBackgroundRefreshTasks() {

    scheduleLogger.debug("Scheduling a background task.")

    // Get the shared extension object.
    let watchExtension = WKApplication.shared()

    // If there is a complication on the watch face, the app should get at least four
    // updates an hour. So calculate a target date 15 minutes in the future.
    let targetDate = Date().addingTimeInterval(15.0 * 60.0)

    // Schedule the background refresh task.
    watchExtension.scheduleBackgroundRefresh(withPreferredDate: targetDate, userInfo: nil) {
        error in

        // Check for errors.
        if let error {
            scheduleLogger.error(
                "An error occurred while scheduling a background refresh task: \(error.localizedDescription)"
            )
            return
        }

        scheduleLogger.debug("Task scheduled!")
    }
}

22:15 - Revisiting the Recaffeinater

//This class is guaranteed on the main actor...
@MainActor
class Recaffeinater: ObservableObject {
    @Published var recaffeinate: Bool = false
    var minimumCaffeine: Double = 0.0
}

//...but this protocol is not
//warning: Main actor-isolated instance method 'caffeineLevel(at:)' cannot be used to satisfy nonisolated protocol requirement
extension Recaffeinater: CaffeineThresholdDelegate {
    public func caffeineLevel(at level: Double) {
        if level < minimumCaffeine {
            // TODO: alert user to drink more coffee!
        }
    }
}

22:26 - Option 1: Mark function as nonisolated

//error: Main actor-isolated property 'minimumCaffeine' can not be referenced from a non-isolated context
nonisolated public func caffeineLevel(at level: Double) {
    if level < minimumCaffeine {
        // TODO: alert user to drink more coffee!
    }
}

23:07 - Option 1b: Wrap functionality in a Task

nonisolated public func caffeineLevel(at level: Double) {
    Task { @MainActor in
      if level < minimumCaffeine {
        // TODO: alert user to drink more coffee!
    	}
    }
}

23:34 - Option 1c: Explore options to update the protocol

public protocol CaffeineThresholdDelegate: AnyObject {
    func caffeineLevel(at level: Double)
}

24:15 - Option 1d: Instead of wrapping it in a Task, use `MainActor.assumeisolated`

nonisolated public func caffeineLevel(at level: Double) {
    MainActor.assumeIsolated {
        if level < minimumCaffeine {
            // TODO: alert user to drink more coffee!
        }
    }
}

25:21 - `@preconcurrency` as a shorthand for assumeIsolated

extension Recaffeinater: @preconcurrency CaffeineThresholdDelegate {
    public func caffeineLevel(at level: Double) {
        if level < minimumCaffeine {
            // TODO: alert user to drink more coffee!
        }
    }
}

26:42 - Add `@MainActor` to the delegate protocol in CoffeeKit

@MainActor
public protocol CaffeineThresholdDelegate: AnyObject {
    func caffeineLevel(at level: Double)
}

26:50 - A new warning

//warning: @preconcurrency attribute on conformance to 'CaffeineThresholdDelegate' has no effect
extension Recaffeinater: @preconcurrency CaffeineThresholdDelegate {
    public func caffeineLevel(at level: Double) {
        if level < minimumCaffeine {
            // TODO: alert user to drink more coffee!
        }
    }
}

27:09 - Remove @preconcurrency

extension Recaffeinater: CaffeineThresholdDelegate {
    public func caffeineLevel(at level: Double) {
        if level < minimumCaffeine {
            // TODO: alert user to drink more coffee!
        }
    }
}

29:56 - Global variables in CoffeeKit are marked as `var`

//warning: Var 'hkLogger' is not concurrency-safe because it is non-isolated global shared mutable state
private var hkLogger = Logger(
    subsystem:
        "com.example.apple-samplecode.Coffee-Tracker.watchkitapp.watchkitextension.HealthKitController",
    category: "HealthKit")

// The key used to save and load anchor objects from user defaults.
//warning: Var 'anchorKey' is not concurrency-safe because it is non-isolated global shared mutable state
private var anchorKey = "anchorKey"

// The HealthKit store.
// warning: Var 'store' is not concurrency-safe because it is non-isolated global shared mutable state
private var store = HKHealthStore()
// warning: Var 'isAvailable' is not concurrency-safe because it is non-isolated global shared mutable state
private var isAvailable = HKHealthStore.isHealthDataAvailable()

// Caffeine types, used to read and write caffeine samples.
// warning: Var 'caffeineType' is not concurrency-safe because it is non-isolated global shared mutable state
private var caffeineType = HKObjectType.quantityType(forIdentifier: .dietaryCaffeine)!
// warning: Var 'types' is not concurrency-safe because it is non-isolated global shared mutable state
private var types: Set<HKSampleType> = [caffeineType]

// Milligram units.
// warning: Var 'miligrams' is not concurrency-safe because it is non-isolated global shared mutable state
internal var miligrams = HKUnit.gramUnit(with: .milli)

30:19 - Change all global variables to `let`

private let hkLogger = Logger(
    subsystem:
        "com.example.apple-samplecode.Coffee-Tracker.watchkitapp.watchkitextension.HealthKitController",
    category: "HealthKit")

// The key used to save and load anchor objects from user defaults.
private let anchorKey = "anchorKey"

// The HealthKit store.
private let store = HKHealthStore()
private let isAvailable = HKHealthStore.isHealthDataAvailable()

// Caffeine types, used to read and write caffeine samples.
private let caffeineType = HKObjectType.quantityType(forIdentifier: .dietaryCaffeine)!
private let types: Set<HKSampleType> = [caffeineType]

// Milligram units.
internal let miligrams = HKUnit.gramUnit(with: .milli)

30:38 - Warning 1: Sending arrays in `drinksUpdated()`

// warning: Sending 'self.currentDrinks' risks causing data races
// Sending main actor-isolated 'self.currentDrinks' to actor-isolated instance method 'save' risks causing data races between actor-isolated and main actor-isolated uses
await store.save(currentDrinks)

32:04 - Looking at Drink struct

// The record of a single drink.
public struct Drink: Hashable, Codable {

    // The amount of caffeine in the drink.
    public let mgCaffeine: Double

    // The date when the drink was consumed.
    public let date: Date

    // A globally unique identifier for the drink.
    public let uuid: UUID

    public let type: DrinkType?

    public var latitude, longitude: Double?

    // The drink initializer.
    public init(type: DrinkType, onDate date: Date, uuid: UUID = UUID()) {
        self.mgCaffeine = type.mgCaffeinePerServing
        self.date = date
        self.uuid = uuid
        self.type = type
    }

    internal init(from sample: HKQuantitySample) {
        self.mgCaffeine = sample.quantity.doubleValue(for: miligrams)
        self.date = sample.startDate
        self.uuid = sample.uuid
        self.type = nil
    }

    // Calculate the amount of caffeine remaining at the provided time,
    // based on a 5-hour half life.
    public func caffeineRemaining(at targetDate: Date) -> Double {
        // Calculate the number of half-life time periods (5-hour increments)
        let intervals = targetDate.timeIntervalSince(date) / (60.0 * 60.0 * 5.0)
        return mgCaffeine * pow(0.5, intervals)
    }
}

33:29 - Mark `Drink` struct as Sendable

// The record of a single drink.
public struct Drink: Hashable, Codable, Sendable {
  //...
}

33:35 - Another type that isn't Sendable

// warning: Stored property 'type' of 'Sendable'-conforming struct 'Drink' has non-sendable type 'DrinkType?'
public let type: DrinkType?

34:28 - Using nonisolated(unsafe)
```
nonisolated(unsafe)
public let type: DrinkType?
```
34:45 - Undo that change
```
public let type: DrinkType?
```

35:04 - Change DrinkType to be Sendable

// Define the types of drinks supported by Coffee Tracker.
public enum DrinkType: Int, CaseIterable, Identifiable, Codable, Sendable {
  //...
}

36:35 - CoreLocation using AsyncSequence

//Create a new drink to add to the array.
var drink = Drink(type: type, onDate: date)

do {
  //error: 'CLLocationUpdate' is only available in watchOS 10.0 or newer
  for try await update in CLLocationUpdate.liveUpdates() {
    guard let coord = update.location else {
      logger.info( "Update received but no location, \(update.location)")
      break
    }
    drink.latitude = coord.coordinate.latitude
    drink.longitude = coord.coordinate.longitude
  } catch {
    
  }

38:10 - Create a CoffeeLocationDelegate

class CoffeeLocationDelegate: NSObject, CLLocationManagerDelegate {
  var location: CLLocation?
  var manager: CLLocationManager!
  
  var latitude: CLLocationDegrees? { location?.coordinate.latitude } 
  var longitude: CLLocationDegrees? { location?.coordinate.longitude }

  override init () {
    super.init()
    manager = CLLocationManager()
    manager.delegate = self
    manager.startUpdatingLocation()
  }
  
  func locationManager (
    _ manager: CLLocationManager, 
    didUpdateLocations locations: [CLLocation]
  ) {
      self.location = locations. last
  }
}

39:32 - Put the CoffeeLocationDelegate on the main actor

@MainActor
class CoffeeLocationDelegate: NSObject, CLLocationManagerDelegate {
  var location: CLLocation?
  var manager: CLLocationManager!
  
  var latitude: CLLocationDegrees? { location?.coordinate.latitude } 
  var longitude: CLLocationDegrees? { location?.coordinate.longitude }

  override init () {
    super.init()
    // This CLLocationManager will be initialized on the main thread
    manager = CLLocationManager()
    manager.delegate = self
    manager.startUpdatingLocation()
  }
  
  // error: Main actor-isolated instance method 'locationManager_:didUpdateLocations:)' cannot be used to satisfy nonisolated protocol requirement
  func locationManager (
    _ manager: CLLocationManager, 
    didUpdateLocations locations: [CLLocation]
  ) {
      self.location = locations. last
  }
}

40:06 - Update the locationManager function

nonisolated func locationManager (
  _ manager: CLLocationManager, 
  didUpdateLocations locations: [CLLocation]
) {
    MainActor.assumeIsolated { self.location = locations. last }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

関連する章

リソース

関連ビデオ

WWDC21