CloudKitの新機能

CloudKitの新機能

CloudKitは、安全で便利で信頼性の高いクラウドデータベースをAppに提供し、さらに進化しています。async/awaitのサポートと便利なAPIの追加により、どのようにスレッドを解きほぐすことができるかをご確認ください。また、データのレコードゾーン全体を共有することで、Appユーザ間のコラボレーションを促進する方法も紹介します。暗号化された値などのCloudKitの機能を利用して、App内の機密データを保護する方法についても検証します。このセッションを最大限活かしていただくためには、CloudKitおよびコンテナー上のCloudKit操作に関する知識があり、レコードとデータのタイプの基礎を理解していることが推奨されます。

リソース
関連ビデオ

WWDC23
- プライバシーの新機能
WWDC22
- メッセージAppで共同制作の体験を強化する
WWDC21
Tech Talks
- CloudKit共有の最大限の活用
ダウンロード

ようこそ「CloudKitの新機能」へ CloudKitチームのエンジニア Nihar Sharmaです後ほどQianが加わります Swiftの並行処理を活用する CloudKit APIの変更についてまずお話ししますその後 Quianがレコードの暗号化フィールドについてお話しします
そして最後にレコードゾーンを簡単に共有する機能に触れます
まずはCloudKitとSwiftについてです CloudKitはAppがiCloudのデータベースにアクセスできるフレームワークです APIのCKContainerでいくつものCKDatabasesにアクセスできます
それぞれのコンテナに全ユーザーが読み書きできるパブリックデータベースが１つずつありますデバイスがiCloudにログインしていれば AppはユーザーデータがあるプライベートデータベースにアクセスすることもできますもしAppが共有機能をサポートしていれば現在のiCloudユーザーが共有するデータに共有のCKDatabaseでアクセスすることができます CloudKitにコードを書くとき２つのAPIのエリアがありますまずは関数ですこれはCKContainerと CKDatabaseにありますこのAPIはCloudKitの導入初心者向けでコードを書きやすくしますすべての構成を提供する代わりにユーザーが操作するUI Appに最も相応しいデフォルトの動きをフレームワークが選びます次はNSOperation サブクラスである Operation APIですこのAPIはCKContainerや CKDatabase関数にない機能を提供します
それらはサーバに一往復で多数のアイテムを送受したりサーバから徐々にデータを取り寄せ莫大な結果セットを検索したりサーバからの過去のデータベースとレコードゾーンチェンジのリクエストそして異なるオペレーションのグループ化などですこれによりユニットとしてログされオペレーションの作業量をシステムに知らせることができますいずれは多くのデベロッパがこのAPIを使うでしょう Swift並行処理の新機能を使い CloudKitに改良点が加えられましたまずCloudKit APIsと共に Swift async/await機能が使えることです次にper-itemと per-operationのコールバックの違いを明確にする新しいAPIとこれらのコールバックのパラメータの役割を明確にするSwift.Resultタイプをどう利用しているか最後に今までオペレーションAPI にしかなかった機能と環境設定を実現するコンテナとデータベースの関数にどのような改善を追加したかお話しします
CloudKit APIはコンテナとデータベースで関数に非同期バリアントを追加します並行処理に関わるコードの改善に非同期関数を使用できますエラーの処理が自然になりコードの視覚的な制御フローがシンプルになります非同期関数の詳細は「Swiftのasync/awaitについて」を参照してくださいそれではその例です
これはPrivateDatabase コードのサンプルですこれは最近AppleがGitHubに掲示した CloudKit特有のサンプルでいつでもご覧になれますこの関数はデータをサーバから削除し完了時に通知するというものです
多数のオプションや条件のラップ解除が各所に見られますこの関数を理解する上で制御フローは明確ではありません
それと比べこれは CloudKitの非同期関数を使ったコードですオプションやラップ解除がなくなり制御フローが直線的で簡単に確認できます
GitHubのコードサンプルでは Swift並行処理を使ってコードをどうのようにリファクターできるのかがわかります
次にper-itemのコールバックです例としてここに CKFetchRecordsOperationがサーバーに４つの CKRecord.IDsを送り４つのCKRecord payloadsを呼び戻していますこのオペレーションには３つ可能性があります
まずオペレーションが成功することエラーもなくサーバからレコードが取得できました
２つ目はオペレーション全体のエラーですこれはオペレーション全体が失敗になるエラーですデバイスがネットワークに接続していないのが一例です networkUnavailable エラーコードが出てオペレーションは失敗です
３つ目はオペレーションが無事サーバと往復したもののサーバからは３つのCKRecordsとともに４つ目のレコードはないというエラーメッセージが戻ってきましたこのエラーでは per-itemのエラーは unknownItemで partialFailureという per-operationのエラーに含まれますコードではどう処理されるのでしょう？ CKFetchRecordsOperationが per-recordの完了ブロックと per-operationの完了ブロックを宣言しそれぞれの実装例が下部に表示されます
２つのコールバックが重複しています先程の例のようにコードは２つのper-itemのエラーを予想します per-itemコールバックの .unknownItemエラーおよび per-operationコールバックの .partialFailureエラーに含まれる形です同様にper-itemの成功もレコード取得の成功として２箇所に表示されますまずper-itemのコールバックの上位パラメータにそしてper-operation コールバックの結果の成功として recordsByRecordIDの辞書内に表示されます
Swift.Resultタイプを使い APIを明確にするため CloudKitはこれのコールバックを置き換えました
新しい結果ベースのコールバックでブロックパラメータが上位で分離しており perRecordResultBlockに CloudKitが呼び戻しているアイテムのIDがありますそしてper-itemの結果もあります結果がクリアに表示され CKRecord payloadを無事呼び出せたか per-itemエラーが発生したかがわかります
同様にオペレーション単位の完了ブロックもオペレーション単位の結果ブロックにアップデートされ per-itemの結果ブロックの成否の結果報告と重複しません
CloudKitは正式に懸念を分離しました１つのブロックはアイテム毎の報告用もう１つはオペレーション単位の報告用です
先程の例に戻ると CKRecord payloadsの取り寄せに成功した３つのper-item結果ブロックの報告と .unknownItemエラーの per-item結果ブロックの報告１つそして per-operation結果ブロックのノーエラー報告ですオペレーション全体はおおよそ成功したからです CloudKitの向上された機能の一つは per-itemとper-operationのコールバックを全体的に分離表示している点です per-itemエラーを表示する per-itemコールバックはこれまでハイライトされているオペレーションに限られていました
しかしこれからは全てのCKOperationsにおいて該当する場合 per-itemコールバックが per-itemエラーをパスバックします次はコンテナとデータベースAPIにおける向上と拡張を見てみましょう CKContainerと CKDatabaseに新機能が追加されます
これらの新機能は CKContainerとCKDatabaseの関数としてCKOperation APIsの大部分を構成しますこれはオペレーションAPIの１対１マッピングではありませんその代わりにデフォルトパラメータと Swift.Resultタイプを使い親しみやすく強力で async/awaitを使える APIを作成しました新しい関数はそれぞれ２度完了ハンドラと非同期関数として使われますこのAPIを使いコンテナとデータベースの関数は複数アイテムのバッチ処理や大量データの検索変更の取り寄せなどのオペレーションAPIの機能をサポートしますまたロギングで関数の呼び出しをグループ化したりワークロードの合計サイズをシステムに伝達できます
関数の呼び出しではタイムアウトなどの設定も可能です例を見てみましょう
それでは再びレコードを削除する非同期関数を使った GitHub PrivateDatabaseのサンプルコードです
アイテムバッチ処理でこのコードをアップデートしてみましょう向上したデータベースの関数APIを使い小さなレコード２つを削除するため関数に変更を加えます
問題が分類化されましたハイライトされた部分は関数スコープです関数を起動し関数上でのエラーを発見します
関数が無事終了すればこの部分でper-itemの成功･失敗がチェックされます GitHubのコードサンプルに各機能をカバーした例がありこのセッションのノートにそれらのリンクがありますぜひご利用くださいそれではこれからQuianが暗号化フィールドについてお話ししますありがとう Nihar Quianです　ではこれからユーザーデータのプライバシーを簡単に守る CloudKitの新機能をご紹介しますまず CloudKitがどのようにユーザーデータを守るか概要を説明しデータ暗号化の新機能を紹介そしてユーザーアカウントにおける必要条件についてお話しします Appleでは全製品の製作においてプライバシーはコアバリューです AppleのAppとサービスのフレームワークとして CloudKitは常にプライバシーテクノロジーを革新し CloudKitに保存されたデータの保護を提供しますまずCloudKitがどうデータを保護するかです CloudKitには２つのデータ保護方法がありますアカウントベースの保護と暗号法による保護です
CloudKitに保存されるデータはデフォルトでアカウントベースの認証で保護されていますこれには皆さんの CloudKit-backed Appと AppleのCloudKit-backedの全Appが含まれます保存と取得段階でCloudKitはセキュアトークンを使い認証されたユーザーのみがデータにアクセスできます Appleも第三者もアクセスできません
アカウントベースの保護はプライベートと共有データベースのデータのみですそれらのデータベースではデータは特定の iCloudアカウントに属するか共有されているかで共有データは認証が必要ですしかし公共データベースは全ユーザーがデータにアクセスできるのでアカウントベースのデータ保護はデフォルトで適用されません
それではもう一つのデータ保護技術である暗号保護です CloudKitはApple所有のAppとサービスの機密性の高いデータおよび CKAssetとして保存されるデベロッパAppの全ユーザーデータに対し暗号保護を提供していますこれらのデータはCloudKitに送られ保存される前にデバイスで処理･暗号化され呼び込まれたデータはデバイスでローカルに解読されます
この暗号化機能はデバイスでサインインされた iCloudアカウントに属する iCloud Keychainの重要材料を使いますまたCloudKitの共有機能と互換性があり CKShareのユーザーのみが関連する暗号フィールドを解読できます
暗号保護はアカウントベースの保護にさらなるレイヤーを加えます権限のない者が認証の壁を仮にすり抜けても呼び出したデータは解読できません
暗号保護はユーザーのプライベートまたは機密性の高いデータに使用されるべきです AppleのCloudKit-backed Appの多くがこの機能を取り入れています写真とメモがその例です
これまでCloudKitのノンアセットデータ保護はデフォルトでアカウントベースの保護でしたこのたびCloudKitでは鍵導出や管理・暗号化･解読に加え暗号保護を提供しこれまで以上に強いプライバシー保護で CloudKit-backed Appの構築を応援します
では新しいAPIを見てみましょう CKRecordsの新プロパティ encryptedValuesにどのようなキー・値ペアも追加でき解読されたオリジナル値を呼び戻すのに同じプロパティが使えます
encryptedValues APIが CloudKitサーバー上でどのように暗号化データを同期させるか見てみましょうここに２つのデバイスと CloudKitサーバーがあります encryptedValuesのキー・値ペアを設定すると CloudKitは自動的に CKModifyRecordsOperationでレコード値をローカルに暗号化しサーバに送ります別のデバイスでデータをサーバから引き出した後同じAPIを使って CloudKitは自動的に key value pairを解読します
このプロセスは最小限のコードで完了します最初のデバイスで encryptedValues APIを使いキー・値ペアを設定しますこの場合キーは encryptedStringFieldで値は文字列オブジェクトです CKModifyRecordsOperationをその後呼び出し新しいデータをサーバに保存します
CKFetchRecordsOperationを 2つ目のデバイスで呼び出し暗号化データを呼び出します同じencryptedValues プロパティを使いこの文字列が戻ってきます以上です１つのシンプルなプロパティが暗号化と解読処理を行います CKReferenceを除いてほぼ全てのCKRecord 値タイプを暗号化できます CKReferenceはサーバに見えねばなりません CKAssetsフィールドは前にも話した通りすでにデフォルトで暗号化していますので encryptedValueとして設定はできません
CloudKitデータベーススキーマで暗号化フィールドを視覚化できます他のフィールドと同様です「CloudKitコンソールについて」のセッションでその他の変更について知ることができますコンソールのレコード値データタイプのドロップダウンリストで全フィールドを一覧できます
Encrypted Double Encrypted Timestampの様に “Encrypted”から始まっており暗号化されていないものと区別できますまたコードの変更なくコンソール自体でフィールドを管理できます例えばご自分の開発データベーススキーマで新しい暗号化フィールドを加えられます
次に暗号化に伴うアカウントのオペレーションに関する必要条件です他のプライベート及び共有データベース同様ログインされた有効なアカウントが必要です初期化のロジックで CKContainer accountStatus (completionHandler:)を使いアカウントのステータスを確認する必要があります
プライベートと共有データベースでのオペレーションではステータスが.availableでなければなりません
それ以外のステータスは CKErrorNotAuthenticatedのエラーメッセージが出て今年から含まれる .temporarilyUnavailableはログインされているものの準備ができていずユーザーに設定Appでログイン情報を再確認してもらう必要があります
ユーザーアカウントが .availableでない場合 CKAccountChanged通知でステータスが変更され準備ができているという通知を受信できるようにします
CloudKitでのデータの暗号化に関し知るべきことは以上です独自の解決方法を実装する時間と努力を節約しユーザーデータを保護することができます続いて再びNiharがゾーンの共有についてお話ししますありがとう CloudKit共有について話します
CloudKitはユーザーのすべてのデバイスを通しユーザーデータの保存･同期に役立つ保護意識の強い iCloudデータベースです iOS 10とmacOS Sierraで他のiCloudユーザーと安全にデータを共有できる CloudKit共有が登場新機能について話す前に CloudKit共有の仕組みを見てみましょう
CloudKit共有は CKShareオブジェクトの作成で開始されますこれは誰とデータを共有しどのような許可を持っているかなど共有されるデータを共有関連情報から分別するものです水面下で CloudKitはリクエストに対しアカウントベースの認証だけでなく参加者の共有データへの暗号化アクセスを設立します
主に２つの方法で Appに共有機能のサポートを加えることができます iOSの UICloudSharingControllerか macOSの NSSharingServiceで共有管理のシステム提供UIで手早く始めるかこれらのフレームワークオペレーションを使いユーザーに共有設定をさせるカスタムUIを作るかです
先ほど話したように CKSharesは共有する物と共有する相手を分別します今日はその前半部分に注目し幾つかの違ったデータ設計と CloudKit sharing APIsの使用でそれがどう影響するかについてお話ししたいと思います
まず既存のCloudKit共有機能を利用する例を見てみましょう iCloudドライブのフォルダ共有は CloudKitで構築されていますどうやって似たようなものを Appに組み込めるでしょうかこのデータモデルはファイルシステムの階層でまず「ファイル」と「フォルダ」タイプのレコードから始めますそれらの中に含まれるファイルやフォルダとその中身を含む全てのレコードをユーザーが簡単に共有できるようにします
このCloudKit内の階層関係を表し共有に利用するには子から親レコードにおいて CKRecord.parentを使用することです
これによりCloudKitは結果となる階層を一つの共有ユニットとしますですのでここにリファレンスを足しますこれは非常に重要で親リファレンスがCloudKitで特別な理由です共有をサポートしないなら親リファレンスを使う必要はなくシンプルなCKReference フィールドでも十分です
これでフォルダの共有は CKShareの初期設定でサポートされフォルダレコードがCKShareのルートレコードとなります
フォルダをルートレコードとして使えば CloudKitは自動的に親リファレンスベースの階層の一部であるすべてのレコードを共有することになりますまた後ほどこの階層にレコードを追加したり削除すると自動的にそれが共有または共有解除されますではコードでどう設定すればいいでしょうか？
ここにプライベートデータベースのカスタムゾーンで共有する２つのファイルレコードと１つのフォルダレコードがあります
まず両ファイルに親リファレンスが設定されフォルダレコードを指していますファイルレコードが保存されましたフォルダが共有された時変更が必要なレコード数を最小限にするため親リファレンスをすぐに保存する習慣をつけましょう
フォルダをルートレコードとして CKShareを初期化しプライベートデータベースでフォルダレコードと共に CKShareを保存し３つのレコードが全て共有されます親リファレンスがこの前にサーバに保存されているため変更が必要なのはルートフォルダレコードと共有時の共有だけです
これであなたのAppはフォルダレコードとその傘下全てのレコードを共有できました CloudKitはレコード階層が重複しない限り同ゾーン内で複数のCKSharesをサポートします
では階層フォルダ共有モデルの代わりにゾーンの中に階層関係のない幾つかのレコードがあるとします
つまりゾーンはレコードの入ったバケツでそれらをすぐに共有したいとします
どのレコードも変更することなくゾーン全体を共有できるのが理想的です
ゾーンの共有でそれが可能ですコードで設定しましょう
CKShareの新しいイニシャライザを使いプライベートデータベースの既存ゾーンのレコードゾーンIDを得るだけですゾーン全体の共有レコードが保存されればサーバ上でこのゾーンにあるレコードはすべて自動的に共有されこのゾーンからレコードを追加・削除するだけで共有と共有解除が可能になりますゾーン全体の共有レコードを削除することでレコードゾーン全体の共有をいつでも解除できますゾーン全体の共有レコードをさらに見てみましょう
ゾーン全体の共有レコードは常にわかりやすい名前です CKRecordNameZoneWideShareはゾーンIDとともにフルの共有レコードIDを作成します
ゾーンの共有を使用している場合親リファレンスの設定は不要です
ゾーンの共有はゾーン毎に共有レコード１つですこのタイプの共有では同じゾーン内で階層共有は共存できませんですのでゾーン内でいくつかの階層共有をするかゾーン全体の共有レコード１つのみかのどちらかです
ゾーン全体のシェアはいずれの非デフォルトのレコードゾーンも保存でき新しいゾーン機能 CKRecordZoneCapability ZoneWideSharingで記されています
CKShareレコード作成以降の既存のCloudKit 共有方法のすべてはこれまで通りでゾーン全体のシェアをサポートしていますが１つだけ例外がありますゾーンの共有にはルートレコードがないため hierarchicalRootRecordIDや rootRecordなどCKShareMetadata の関連プロパティはゾーン共有の
受け入れ時にnilになります　カスタム共有の受入れフローのブートストラップに CKFetchShareMetadataOperation を使用すると shouldFetchRootRecordと rootRecordDesiredKeysはゾーン全体のシェアの共通メタデータを読み込み時にシステムに無視されます
皆さんのデータモデルにより２タイプのCloudKit共有があります Appのスキーマが階層を形成し階層ツリーが理に叶うのであれば CKRecordの親リファレンスでルートレコードを共有しましょう Appleではメモやリマインダー iCloud Driveフォルダ共有などを今日紹介したような形でこれを実装しています
それ以外ならゾーン全体の共有レコードで全レコードゾーンを共有し CloudKit共有をフルに利用できます Appleでは既にゾーンの共有を HomeKitセキュアビデオや HomePodマルチユーザーに活用しています
今日はper-item progressの向上やエラーレポートAPIsなど Swiftのasync/awaitを使い新しい方法でCloudKitのコードを書く方法をご紹介しました
独自に暗号化に取り組むことなく Appleのプライバシー保護を利用し暗号化フィールドを機密性の高いユーザーデータに使用する方法をご紹介しました
そしてデータモデルが階層タイプでない場合ゾーンの共有で CloudKitに素早く取り掛かる方法をお伝えしました
これらの機能についてやさらに役に立つ情報を developer.apple.comでご覧いただけます「Explore CloudKit」コレクションに関連する数々のセッションをご用意しています CloudKitを基に作られた共有機能である Core Dataもその一つです引き続きWWDCをお楽しみください [明るい音楽]

3:34 - CloudKit: Existing convenience API

// Sample code using existing Convenience API

/// Delete the last person record.
/// - Parameter completionHandler: An optional handler to process completion `success` or `failure`.
func deleteLastPerson(completionHandler: ((Result<Void, Error>) -> Void)? = nil) {
    database.delete(withRecordID: lastPersonRecordId) { recordId, error in
        if let recordId = recordId {
            os_log("Record with ID \(recordId.recordName) was deleted.")
        }
        if let error = error {
            self.reportError(error)
            // If there is a completion handler, pass along the error here.
            completionHandler?(.failure(error))
        } else {
            // If there is a completion handler, like during tests, call it back now.
            completionHandler?(.success(()))
        }
    }
}

4:04 - CloudKit: Async convenience API

// Sample code updated to CloudKit Async API

/// Delete the last person record.
func deleteLastPerson() async throws {
    do {
        let recordId = try await database.deleteRecord(with: lastPersonRecordId)
        os_log("Record with ID \(recordId.recordName) was deleted.")
    } catch {
        self.reportError(error)
        throw error
    }
}

5:39 - CloudKit: Existing completion blocks

// Error reporting in CKFetchRecordsOperation

extension CKFetchRecordsOperation {
    var perRecordCompletionBlock: ((CKRecord?, CKRecord.ID?, Error?) -> Void)?

    var fetchRecordsCompletionBlock: (([CKRecord.ID : CKRecord]?, Error?) -> Void)?
}


fetchRecordsOp.perRecordCompletionBlock = { record, recordID, error in
    // error is CKError.unknownItem. 
}

fetchRecordsOp.fetchRecordsCompletionBlock = { recordsByRecordID, operationError in
    // operationError is CKError.partialFailure.
    // operationError.partialErrorsByItemID[missingRecordID] is CKError.unknownItem.
}

6:35 - CloudKit: Result type completion blocks

// Error reporting in CKFetchRecordsOperation

extension CKFetchRecordsOperation {
    var perRecordResultBlock: ((CKRecord.ID, Result<CKRecord, Error>) -> Void)?

    var fetchRecordsResultBlock: ((Result<Void, Error>) -> Void)?
}


fetchRecordsOp.perRecordResultBlock = { recordID, result in
    // result is .failure(CKError.unknownItem) or .success(record).
}

fetchRecordsOp.fetchRecordsResultBlock = { result in
    // result is .success.
}

9:14 - CloudKit: Delete single item

// Single item delete

func deleteLastPerson() async throws {
    do {
        let recordId = try await database.deleteRecord(with: lastPersonRecordId)
        os_log("Record with ID \(recordId.recordName) was deleted.")
    } catch {
        self.reportError(error)
        throw error
    }
}

9:37 - CloudKit: Delete batch

// Batched modifications

func deleteLastPeople() async throws {
    do {
        let recordIds = [lastPersonRecordId, penultimatePersonRecordId]
        let (_, deleteResults) = try await database.modifyRecords(deleting: recordIds)
        for (recordId, deleteResult) in deleteResults {
            switch deleteResult {
            case .failure(let error):
                self.reportError(error, itemId: recordId)
            case .success:
                os_log("Record with ID \(recordId.recordName) was deleted.")
            }
        }
    } catch let operationError {
        self.reportError(operationError)
        throw operationError
    }
}

13:43 - CloudKit: Encrypted values

extension CKRecord {
    @NSCopying open var encryptedValues: CKRecordKeyValueSetting { get }
}

14:29 - CloudKit: Using encrypted values

// Device 1: Encrypt data before calling CKModifyRecordsOperation.

myRecord.encryptedValues["encryptedStringField"] = "Sensitive value"

// Device 2: Decrypt data after calling CKFetchRecordsOperation.

let decryptedString = myRecord.encryptedValues["encryptedStringField"] as? String

16:35 - CloudKit: Account status

open func accountStatus(completionHandler: @escaping (CKAccountStatus, Error?) -> Void)

16:46 - CloudKit: CKAccountStatus

public enum CKAccountStatus : Int {
    case couldNotDetermine
    case available
    case restricted
    case noAccount
    case temporarilyUnavailable
}

21:10 - CloudKit: Setup a record hierarchy

// Share a record hierarchy


let zone = CKRecordZone(zoneName: "MyZone")

// Save zone...

let fileRecordA = CKRecord(recordType: "File", recordID: CKRecord.ID(zoneID: zone.zoneID))
let fileRecordB = CKRecord(recordType: "File", recordID: CKRecord.ID(zoneID: zone.zoneID))
let folderRecord = CKRecord(recordType: "Folder", recordID: CKRecord.ID(zoneID: zone.zoneID))

fileRecordA.setParent(folderRecord)
fileRecordB.setParent(folderRecord)

// Save records...

21:41 - CloudKit: Record Hierarchy, Share

// Share a record hierarchy


let share = CKShare(rootRecord: folderRecord)

do {
    let (saveResults, _) = try await database.modifyRecords(saving: [folderRecord, share])
    for (recordID, saveResult) in saveResults { 
        // Handle per-record result.
    }
} catch let operationError { 
    // Handle operation error.
}

22:51 - CloudKit: Share a Record Zone

// Share a record zone


let zone = CKRecordZone(zoneName: "MyZone")

// Save zone... 

let share = CKShare(recordZoneID: zone.zoneID)

do {
    let (saveResults, _) = try await database.modifyRecords(saving: [share])
    for (recordID, saveResult) in saveResults { 
        // Handle per-record result.
    }
} catch let operationError { 
    // Handle operation error.
}

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

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

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21

Tech Talks