ネットワーキングの最新情報（パート1）

(音楽)

(拍手) “Advances in Networking”へようこそ 私はジョシュア･グレスリー Internet Technologiesの 同僚たちと― ネットワーキング分野における 今年の進展についてお話しします

Part 1ではLow Data Modeの話をします 必要な場面で 通信データを節約する新機能です URLSessionにおいて Combineを使った― 洗練された非同期的 ネットワーキングコード紹介や―

WebSocket APIのお話も これは去年 ラボで多くの 要望があったもので― 解決策を提供でき うれしく思います 最後にモビリティの改善です デバイスが― ネットワークを移る際にも シームレスな体験が提供できます

Part 2では 追加のトピックを紹介します 今日の５時からです　ぜひご参加を

Low Data Modeの話に進む前に 我々のネットワーキングAPIについて

ベストなAPIは URLSessionとNetwork.frameworkです このセッションと Part 2でお話しする― 今回の進展は― これらのフレームワークで利用可能です ソケットをお使いなら利用できません 残念ながら ソケットには 必要なrichnessがありません VPNやコンテンツフィルタリングには NetworkExtensionが便利です こちらの改善も明日お話しします

ではLow Data Modeの話を これはiOS 13の新しい機能です

ちなみに皆さんは WWDCにどうやって来ましたか？ おそらく サンノゼまで飛行機で来たでしょう 機内にはWi-Fiネットワークがあり― おそらくそれは コストが高いか混雑していたでしょう そしてデバイスに データ使用量を節約するよう― 指示できればと 思ったのではないでしょうか？ Low Data Modeで解決できます

このモードならユーザが アプリケーションのデータ使用量を― 抑えるよう 制御することが可能になります

SSIDのWi-Fiネットワークや― SIMのセルラーネットワークで可能です

Low Data Modeの大きな影響は２つ システムポリシーの変更と― Low Data Modeを導入した アプリケーションへの変更です システムポリシーでは― 任意のバックグラウンドタスクを 保留します 機内でこのモードにすれば― バックグラウンドタスクが保留されます そして飛行機を降り― ホテルに着き Wi-Fiネットワークにつながれば タスクが再開 継続されます

またBackground App Refreshは 無効になります 不要なアプリケーションが バックグラウンドで― ネットワークデータを 消費することを避けられます これはとても有益ですが 最も有益な変更点は皆さんの アプリケーションに導入できることです 皆さんが使用可能な方法を いくつか紹介します

まずはアプリケーションが ネットワークデータをどう扱うか

覚えておいてください ユーザ体験に影響がない範囲なら いつでもデータを節約するべきです 当たり前に見えますが 最適化で― 驚くほど節約できるかもしれません

それらの比較的 容易な変更が 済んだら― 次は妥協点を探さねばなりません 大量のデータで これ以上ない体験を提供するか？ データを減らし そこそこいい体験を提供するか？ Low Data Modeでユーザは アプリケーションに指示できます データ使用量を抑えて― 最高ではなくとも それなりの体験にはするようにと

いくつか使用可能な 技術を紹介しましょう まずは画質を落とすことです

画像が重要なアプリケーションで ないなら 画質を落とし― データを抑えて ユーザの目的を果たすことができます

次にプリフェッチを抑えること プリフェッチにより動作速度が 向上しますが― ユーザに不要なリソースを読み込む 欠点もあります 結果的にプリフェッチが 邪魔になることもあります

そこでプリフェッチを無効にして データを節約し― 読み込みが 少し遅くなるのを我慢してもらいます

次に同期を減らすこと データが少し新鮮でなくても― ユーザは目的を果たせます

同期頻度を減らせば 長時間ではかなりの節約になります

次に任意制御の バックグラウンドタスクです 驚くかもしれませんが 多くのタスクは ただちに行う必要はありません 任意制御にすることで― システムが 柔軟に実行のスケジュールを組めます 機内でLow Data Modeにすれば― システムは タスクを保留することができます

他には自動再生の無効があります 興味あるコンテンツの 再生を妨げるわけではなく― 興味のないものを 見なくて済むということです

ここでもう１つ 導入に際し 大事なことがあります ユーザ発の作業を止めないこと Low Data Modeは データ使用量をなるべく抑えつつ― 目的を果たせることが主旨です 作業によっては仕方なく― かなりのデータ使用量に なることがあります それでも 使用量を減らせるなら理想的ですが― こんな質問はしたくありません “大量のデータを使用しますが いいですか？” ユーザ次第です 自分でLow Data Modeにしたのですし 躊躇はいりません

ではLow Data Modeを導入するのに 役立つAPIの話を

APIをURLSessionと Network.frameworkに追加しました

Low Data Modeでネットワークは― constrainedプロパティが設定されます よってAPIもそれが前提になります allowsConstrainedNetworkAccessを URLSessionでは追加しました デフォルトでtrueです アプリケーションはデフォルトで Low Data Modeネットワークが使えます falseにして モードの排除も可能です これはURLSessionのリクエストや設定で 変えられます フェッチやプリフェッチを試し― allowsConstrainedNetworkAccessを falseにすることを強く推奨します ネットワークがconstrainedで エラーになるなら Low Data Modeが原因だと分かります その場合 Low Data Modeの設定を 見直します フェッチの場合は より小さなリソースにすること プリフェッチは 必要になるまで待つことです キャッシュにあるものを 活用することにもつながります Network.frameworkでは prohibitConstrainedPathsをtrueにして 接続をブロックし Low Data Modeを避けることができます

Network.frameworkでは もう１つ方法があります Low Data Modeであってもなくても 同じホストに接続し― 一旦 接続が確立されれば 現在のパスを取得可能です そしてパスがconstrainedか確認します これにより Low Data Modeの接続か分かります

この場合 パスのアップデートが重要です constrainedプロパティが 変わることも考えられるからです

他にも皆さんのアプリケーションが― ネットワーク上で判断する際 使えるプロパティがあります 例えばexpensiveプロパティ 去年 Network.frameworkに導入し 今年はURLSessionにも導入します

セルラーやWi-Fiなど インターフェイスのチェックもあります まだどれも導入していない方は Low Data Mode導入のチャンスです Low Data Modeではユーザが―

constrainedプロパティを制御できます 逆にexpensiveは システムによってセットされます 通常はセルラーに設定され― Personal Hotspotなら Wi-Fiに設定されます

セルラーもチェックできますが ユーザは制御できません 現在セルラーや expensiveプロパティでチェック中なら ぜひconstrainedに移行して Low Data Modeを活用してみてください

それでもexpensiveか セルラーで判断したいという場合は― expensiveを推奨します expensiveのほうが柔軟で― 将来も使い続けられるでしょう 今はセルラーネットワークがほぼ expensiveですが― 将来はどうなるか分かりません expensiveプロパティを使っておけば 心配ありません 別のインターフェイスが現れても 対応できます

ぜひLow Data Modeを導入ください ありがとうございました 続いては グオイェがCombineについて話します (拍手) ありがとう　ジョシュ おはようございます グオイェ･チャンです 今日は新しいSwiftフレームワーク URLSessionのCombineのサポートと その使い方をご紹介します

CombineはSwiftでの 非同期的プログラミングを実現します

説明のために― 検索フィールドの構築を例として お見せします

ユーザが何かを打ち込むたびに― 値が発行され URLを受け取り検索が始まります 合間にmapオペレータにより 値がURL内にマッピングされます

では十分なコンテンツがある時のみ 検索を始めるには？

filterオペレータを使います このfilterは ３文字以下の文字列を排除します

これにより “Ｈ”１文字の検索などは避けられます

しかしまだ検索頻度が高すぎます ユーザが打ち込みをやめた時に 検索するには？

debounceオペレータを使います

(拍手) debounceは 遅延がある場合のみ値を送ります ここでは0.2秒です

しかし ユーザが何か打ち込み削除すると― 同じ値が何度も 検索されてしまうかもしれません

その解決策は removeDuplicatesオペレータです

これは最後に受け取った値を記憶して 新しい値のみを送ります

これで検索フィールドの完成です オペレータをつなげることで コードが構成可能でリニアになります

Combineは 時間をかけて値を処理します

パブリッシャとオペレータと サブスクライバで構成されます

サブスクライバからリクエストが まず送られ―

それに対し パブリッシャが値を送ります これがCombineの仕組みです

詳しく知りたい方は― “Introducing Combine”の 動画が近々公開されます そして今日の午後の “Combine in Practice”もどうぞ

ネットワーキングは 元々 非同期的なので― Combineにぴったりです

今年 URLSessionで DataTaskPublisherを発表します 単一値のパブリッシャで― 既存のclosure based convenience methodsと似た仕組みです つまり共有または独自の URLSessionからそれを作成し デリゲートで 認証やメトリックを受け取ります

これがインターフェイスです

パブリッシャのプロトコルに 準拠します 成功ならば DataとResponseを送ってきます 失敗ならばURLErrorです

ではURLSessionで Combineのデモをお見せしましょう

デモのために URLキャッシュは無効にしました リソースはすべてネットワーク上で フェッチされます またNetwork Link Conditionerで 3G環境を再現しました

PubSocketというバーのAppです

バーの品目の 名前と画像と値段が示されています

ジョシュの話を参考に― 高解像度の画像とLow Data Mode用に 低解像度の画像を用意しました

今はLow Data Modeで 白黒画像が見えますね

Low Data Modeを切ると―

高解像度の画像に切り替わります

Combineなしの場合を見ましょう

UITableViewが使われています データソースメソッドは cellForRowAtindexPathです これで 再利用可能なセルを取り出し― セルで品目の名と値段を構成します

そしてURLリクエストを始め― 高解像度の画像をフェッチし 制限された通信へのアクセスを無効に

pubSessionは このAppで使う共有セッションで― リクエストからdataTaskを作成します

タスクが済むと statusCodeが200かどうかチェックし データを画像に変換しセルに置きます

モードが原因でタスクが失敗すれば― 低解像度の画像をフェッチするよう 新しいタスクを作成します

ここでも同じです statusCodeを調べ 画像を変換してセルに置きます

これらのタスクの再開を忘れずに

これでネットワーキングの方法は 問題ありません プリフェッチは避けました ただしコードには満足していません 重複が多いからです statusCodeを調べ 画像を２度 変換しています

そしてよくあるミスですが― セルをキャプチャーし 非同期的に画像をセルに置いています

この時セルはUIKitで 先に使われているかもしれません

バグを見せましょう 下にスクロールするので 最後の数品目を見ていてください

間違った画像が２つ映りましたね

もう１度 スクロールするので 最上部の数品目を見ていてください

変更される前に ２つ間違った画像が表示されました

これらの問題を Combineで修正しましょう

まずこのコードを削除します

これはMenuItemTableViewCellです セルが画像を受け取ります サブスクライバを置くのに適してます

キャンセル可能な プロトコルに準拠しています サブスクライバをキャンセルします

再利用メソッドです すぐにキャンセルされ― 間違ったセルに 画像が置かれることはありません

では続いて cellForRowAt indexPathに戻りましょう

ここも同じく― URLリクエストを作成し 高解像度の画像をフェッチさせます ただデータタスクではなく DataTaskPublisherを作成します

そして新しい tryCatchオペレータを使います tryCatchは DataTaskPublisherのエラーをキャッチ Low Data Modeが原因なら― 新しいパブリッシャで 低解像度の画像をフェッチします

違うならエラーをそのまま渡します

次にtryMapオペレータで― 成功の場合 データとレスポンスを受け取ります statusCodeを調べ データから画像を作成します このマップが高低 どちらの解像度の画像も扱うため― コードの重複が避けられます

最後にエラーを プレースホルダ画像と置き換え― メインキューを切り替え サブスクライバでセルに画像を置く

これでより短く リニアなコードに置き換えられました 他に何ができるでしょう？ もう１つオペレータがあります retryと呼ばれるものです

retryをサポートするには その前に何をしなくてはいけないか？ データタスク･クリエイターを 再起的に呼ぶか― ステートマシンを維持します Combineでは― エラー変換前にここに retryオペレータを置くだけです

(拍手) retryがエラーを受け取り― 一連の流れをやり直し 再度画像をフェッチします 今回は１度だけリトライします

ネットワーキングAPIは基本的に 信用度が高く― 基本的にリトライは必要ありません しかしAppが serverエラーを500回も吐くような― serverとつなぐこともあるでしょう

その場合は― invalidServerResponseエラーを tryMapオペレータが吐きます

しかしネットワーキング作業は コストが高く― リトライは なるべく避けなくてはいけません するなら低い数字で始めましょう

それから リクエストの冪等性に気をつけましょう 画像を２度ダウンロードするのも― 遅延トランザクションがある場合は 危険かもしれません

Low Data Modeに戻して―

またAppを動かしてみましょう

以前のように 低解像度の画像をフェッチしてます

Low Data Modeを切ると―

高解像度の画像に 間違った画像も置かれません

(拍手)

スライドに戻りましょう

まとめです Combineでネットワーキングコードが 簡潔になりエラーも減らせました

Combineオペレータが どのように構成可能かというと コードを１つ足すだけで済みます ただしリトライ数は少なくして 冪等リクエストに限りましょう

最後にLow Data Modeで プリフェッチのチェックをせずに― Combineを使う方法を見せました

こちらのコードは 私のデモから抜き出したものです

通常のURLと Low Data ModeのURLを受け取り― パブリッシャのデータを返します

まずregularURLをフェッチする リクエストを作り― 制限された通信を無効にします リクエストで dataTaskPublisherを作成します

次にLow Data Modeによる エラーを処理します 新しいパブリッシャに置き換えて lowDataURLをフェッチさせます

そして両方の成功ケースで― statusCodeを調べてデータを返します

このコードを CombineとLow Data Modeの土台にし カスタマイズしてください

現行のSDKでは 対応していないAPIもあります いずれ対応できるよう努めています

次はジテンがWebSocketについて お話しします ありがとう　グオイェ おはようございます　ジテン･メタです iOS 13とmacOS Catalinaの 新しいフレームワークにおける― WebSocketプロトコルについて お話しします

近年 多くの開発者から WebSocketのサポートを求められました 去年 行ったアンケートの中で 最も多いリクエストでした

WebSocketを使えば HTTP接続上で双方向通信ができます チャットやマルチプレーヤーゲーム リアルタイムアプリケーションが 可能になります

WebSocketはよく知られた HTTPポートで使えて― 既存のインフラと互換性があります プロキシやCDN ファイアウォールと接続できます

これまで WebSocketプロトコルは― ブラウザでJavaScript APIとして 利用可能でした しかしWebアプリケーションにも 非常に有効です そこで我々は― このAPIを我々のフレームワークに 拡張しました 既存のWebインフラを利用し― Appleのプラットフォームで使えます

WebSocketの話の前に 双方向通信によく使われる― 一般的な手法を見てみましょう チャットのAppを例にします

クライアントは応答が欲しい場合 serverにリクエストを送ります serverは ステータスコードで応答します しかし まだレスポンスボディは ありません その後レスポンスが用意できた時点で クライアントに送ります するとクライアントが新しい リクエストで次のメッセージを求めます ロングポーリングです しかしこれには欠点があります メッセージを送りたい時に― HTTPリクエストかレスポンスを送る 必要があります オーバーヘッドが大きいという問題です serverがムダな作業をしなくては なりません

WebSocketで どのように解決できるでしょう

WebSocketハンドシェイクの ファーストステップとして― 接続をWebSocketに更新したいと クライアントがリクエストを送ります serverは プロトコル切り替えで応答し― この時点で 双方向性のストリームができます

どちら側も 自由にメッセージを送れます

データや文字列を HTTPオーバーヘッドなしで送ることが 可能になるのです

URLSessionが HTTPにおけるAppleの推奨APIです そして今年 URLSessionWebSocketTaskを発表します Foundationフレームワークの 新しいAPIです (歓声と拍手) URLを渡しresumeを呼ぶだけで WebSocketタスクが作成可能です ステータスコードの処理については 心配ご無用です

まず最初は HTTPセマンティクスを使います つまり― URLSessionWebSocketTaskは 既存の構成オブジェクトを使います またネットワークストレージから 認証情報を得て― デリゲートのチャレンジも受けます 接続されれば データや文字列を送れるようになります 完了ハンドラを渡し メッセージを受け取ることもできます serverからメッセージ全体を受け取ると ハンドラは非同期的に呼ばれます

ここでのAPIは完全なメッセージと コールバックに基づいており― JavaScript APIに似ています しかしserverサポートや― メッセージの部分読み込みを 求める人もいるでしょう そこでNetwork.frameworkでの WebSocketサポートを発表します NWConnectionとNWListenerで― クライアントとserverをサポートします

(拍手) これにより― P2Pに拡張可能な メッセージ転送プロトコルが使えます バイト数の最小と最大を指定し 部分的なメッセージも受け取れます

WebSocketを追加するには― TLSが有効なパラメータを作成します 次にWebSocketOptionsを 作成し― パラメータの defaultProtocolStackに設定します

パラメータを作成したら― NWConnectionコンストラクタに 渡して オブジェクトを作成します リスナーを作るなら リスナーのコンストラクタに渡します 送受信のAPIは 去年から変わっていないので― これからも メッセージの送受信に使ってください

ではWebSocketの実演を見ましょう

グオイェのAppを使います PubSocketです ただ少しビジネスモデルを変えます

品目の値段が オンデマンドに変わるようにします 飲食物版の株式市場です

左側はPubServer バーテンダーが 品目や値段を編集できるAppです 右側がPubMenuで― バーに来たお客さんが見るAppです

新しい機能は PubSocket+と呼ぶことにします 価格変動制を うまく実行できるか見てみましょう

ルートビアを 6.99ドルに上げるとしましょう アップデートをクリック クライアントは引き下げて更新

ルートビアの新しい価格が表示されます 悪くはないですね でもさらに改善しましょう プルダウンせず ライブで価格が変わるようにし― シームレスな体験を 提供したいと思います

WebSocketを活用しましょう

Xcodeに移動し― 先に serverとクライアントを停止します

そして― TCB serverとして機能している NWListenerを開きます tlsOptionsを付けたパラメータが あります ここを変更し WebSocketOptionsを作成 それをパラメータの プロトコルスタックにセットします これでserverは― クライアントと WebSocketハンドシェイクができます 次に変更を加えるのは― sendPriceChangesという関数です server側で品目の価格が変わるたびに この関数が WebSocketメッセージを― 各クライアントに送ります

今はdefaultStreamのコンテキストで sendになっています

これは sendメソッドに渡すデータが― TCBコネクションにただのバイトの塊 として送られるということです そこでこれを変更し―

WebSocketメタデータと共に 新しいコンテキストを作成します これでデータが メッセージフレームとして送られます WebSocketメッセージが この２つの変更で送られるはずです それでは… クライアント側も見てみましょう クライアント側では まずconnect関数から変更します connectで新しいserverに接続します URLSessionWebSocketTaskを使います URLを渡してresumeを呼べば― ハンドシェイクを始めることができます 次にreadMessageを呼びます serverからメッセージを受信します どう実装するか見てみましょう

readMessage内で task.receiveを呼び出して― 完了ブロックを渡します 成功の場合― UIを価格変更でアップデートします そしてすぐ後に serverからの次のメッセージを読みます クライアント側も変えたら― serverに接続し WebSocketメッセージを受け取れるはず ではserverと クライアントを走らせてみましょう まずserverを走らせます

クライアントが 新しくなったPubSocket+を読み込みます 今はハッピーアワーで― バーテンダーが ルートビアの値段を1.99ドルにします 変えてみましょう

アップデートを押すと… ご覧のとおり クライアント側が更新されました (拍手) 見逃した人のためにポテトも下げます 大サービスですね

アップデートを押すと ポテトの価格が変わります いきますよ ポテトの価格が変わりました

(拍手) これがWebSocketです HTTPオーバーヘッドなしの 双方向通信です 右上のStatsボタンが気になる方も いるでしょう クリックします URLSessionのメトリックAPIで 収集している新しいデータです

一番下のRTTは serverとクライアント間の往復時間です PingとPongを使って計算されます Network Link Conditionerで 混雑を再現しています コネクションの状態を監視するのに 利用できます メトリックAPIの新しい機能や Network Link Conditionerの詳細は― 本日５時からのセッションへどうぞ スライドに戻りましょう

PubSocket+のおさらいをします

serverではWebSocketOptionsを 設定したNWListenerを使いました

クライアントでは― WebSocketTaskで serverと接続しメッセージを読みました

転送には双方向の WebSocketメッセージを使いました これにより わずかなオーバーヘッドで― 双方向通信が可能になりました

WebSocket導入に利用できるAPIを 見てみましょう 既存のJavaScript APIでも WebKitで― WebSocketsを追加すれば Webアプリケーションや ビューに使えます

Network.framework上で作られた URLSessionWebSocketTaskは― URLSessionにつなげます 既存の構成オブジェクトで動き― 自動でデータ保存や 認証サポートをします PingとPongを使い 往復時間を計測することもできます

またNWConnectionやNWListenerを 通じて得られるWebSocketSupportなら serverとクライアント 双方をサポートし 完全な または部分的なメッセージに 直接アクセスできます WebSocketOptionsで クッキーや認証などのカスタムヘッダを 設定することもできます 開発者の皆さんが これらの技術を活用するのが楽しみです 次はクリストフが モビリティの改善について話します (拍手) ありがとう　ジテン 皆さん こんにちは

私はクリストフ モビリティの改善についてお話しします ユーザは普段 よくこんな場面に遭遇します 家から出て Wi-Fiのアクセスポイントを離れると 電波が悪くなります そしてアプリケーションも 回線速度と共に遅くなってしまいます 使えなくなる時もあるでしょう こんな状況には慣れています 家から出ると スワイプしてWi-Fiを切るでしょう

誰もが経験していると思います これを我々は変えたかったのです 家を出る時 Wi-Fiを切らずに済むようにしたい 電波が悪くともアプリケーションが ちゃんと動くようにしたい ここにいる誰もが そう思っているでしょう その方法を紹介します

これはよくあるWi-Fiの表示です 中央にWi-Fiアクセスポイント 周囲に同心円があり― 弱くなる電波を表しています 遠ざかるほど電波が弱くなります こういう状況なら Wi-Fiを使うかセルラーに切り替えるか 判断しやすいでしょう しかし問題は Wi-Fiは実際はこのような図から― ほど遠いということです 実際はこんな感じです

アクセスポイントが中央にあり 周囲の電波はまばらです 周囲の物が 電波を邪魔しているからです 家も 壁も 何もかもが Wi-Fiの電波をとても不安定に― してしまっているのです 少し動くだけで 電波状態が劇的に変わることもあります だから携帯側は Wi-Fiの状況を判断しづらいのです ビーコンは届いていても― データを受け取れるだけの電波が ないかもしれません こういった状況で 携帯側は判断しなくてはなりません この不確実性が モビリティの難しいところなのです

Appleでは かなり前から この問題に気づいていました これまで我々が― どう改善してきたかを紹介します

始まりはiOS 7のSiriでした

iOS 7では Siri用のMultipath TCPを発表 Wi-Fiとセルラーを同時に使えます iOS 7 以降 Siriを起動して家から出れば― Multipath TCPが Wi-Fiかセルラーで通信を確保 遅延を抑え エラー率を減らしてきました Multipath TCPは すばらしい成果を出しています Multipath TCPは エンド･ツー･エンドプロトコルなので serverとクライアント 互いに認識することが必要となります 協力しなくてはいけません Wi-Fiとセルラー どちらを使うか協力して決めます そこで考えました モビリティの改善を― serverとクライアントが協力せずに できないか？ serverの設定を変えずに済む方法は？ その答えが iOS 9のWi-Fi アシストでした

これはあらゆるアプリケーションや フローに適用されます まずWi-Fiからスタートします 電波が悪くなり 十分な速度が得られなくなると― セルラーのコネクションを起動します Wi-Fi アシストが登場してからは ほとんどのアプリケーションが― その恩恵を受けています ユーザがモバイルの時― よりよい体験を得られています インターネット上のどのserverでも 機能します

ただしそれでも接続できないことも 接続できても 徐々に電波が悪くなった場合は― フローが詰まります その対策には やはりSiriのように エンド･ツー･エンドのマルチパスが 必要になります そこで４年の経験を経て― Siri用のMultipath TCPを すべての人に解放することにしました iOS 11からは URLSessionやNetwork.frameworkで ハンドオーバーやinteractiveモードを 使えるようになりました serverが確認できれば― Siriと同じく Multipath TCPが使用可能に

iOS 7と9と11 これらの開発ではいつも― １つの分野に集中して改善しました

Multipath TCP Siri そしてWi-Fi アシストにです そして今回 iOS 13では― 改善が多すぎて スライドに入りきらないほどです

iOS 13ではモビリティが… (拍手) ありがとうございます 改善はシステム全体に及びます フレームワーク デーモン アプリケーション ファームウェアにドライバ すべてのモビリティが向上しました ここでは２つ Wi-Fi アシストと マルチパストランスポートの話を

まずWi-Fi アシストについて これまでは 限られた情報を元に Wi-Fiの状態を― 判断していました iOS 13では そこを変えました システム内のあらゆるコンポーネントが 情報を提供し― クロスレイヤでモビリティを探知します 低レイヤでは Wi-Fiとセルが電波状況の情報を― iOS 12より さらにきめ細かく提供します 高レイヤでは Network.frameworkやURLSession デーモンなどが― それぞれのフローの状況について 情報を提供します

Wi-Fi アシストはこれらを元に― 状況を把握し セルラーに切り替えるかを判断します

Wi-Fi アシストは すべての情報を元に判断すると― それをシステムに返します 低レイヤには 電波状況をよくするよう伝えます そして高レイヤには― フローを回復するよう伝えます

これがフローの回復を改善します Wi-Fiでフローが確立されて データが交換され始めても― 後から電波が悪くなってきた場合 次のリクエストを― Wi-Fiから セルラーに移行することができます だからアプリケーションが Wi-Fiで詰まることは少なくなります

そして問題は 皆さんにどんな恩恵があるかです 多様な改善の恩恵を どう受けることができるでしょう？ 恩恵を受けるには URLSessionやNetwork.frameworkなど 対応するAPIが必要です これらのAPIは Wi-Fi アシストを念頭に作られ― その恩恵を受けています それらのAPIを アプリケーションでも使ってください

SCNetworkReachabilityなどで― インターフェイスの管理を している方もいるでしょう プリフライトチェックで リクエストの行方を調べるかもしれない Wi-Fiかセルラーかと ただ問題があります コネクションを使う時 インターフェイスが変わる可能性がある Wi-Fi アシストは セルラーを選ぶかもしれないし― Wi-Fiが改善されるかもしれません なのでプリフライトチェックは 当てになりません あまり使わないことを推奨します ラボに来てくれれば― 話を聞いて 他の選択肢を一緒に考えてみます

もしフローを セルラーに向かないようにしたい時 例えばデータが大きすぎるとか トラフィックがユーザ体験に不可欠な時 allowsExpensiveNetworkAccessを falseに設定するなどの方法があります そうすれば リクエストはセルラーに送られない

これがWi-Fi アシストです iOS 13ではさらに改善しました その恩恵を ハイレベルAPIを使って受けましょう そして次は マルチパストランスポートについてです

以前からSiriで使われていました APIは２年前に開放しました 皆さんにはAppのフローで― Multipath TCPが どこに役立つか見直しを推奨しました

そして今年は 我々も自分たちのAppを見直して― Multipath TCPが どれに一番役立つかを考えました モバイルで使われ フローがユーザ体験に重要なものは？ その１つはマップです ナビの際は ほとんどが外を歩いている時で 検索を使います iOS 13では Apple MapsにMPTCPを導入しました (拍手) Mapsを使って外を出歩く時 方角を確認し店を探す時― MPTCPが使われ フローはセルラーに切り替えられます 月曜から導入しており― Apple Mapsで よりよい応答性が見られています

そしてもう１つ ユーザ体験に大きく影響するのは― 音楽のストリーミングです これもよく外で使われます ストリーミングでは 大きなファイルをダウンロードします 音楽は止めたくない 止まると台無しになります iOS 13では Apple MusicにMPTCPを導入しました (拍手) ストリーミングが改善しました 音楽が止まりそうになると― MPTCPがセルラーに切り替えます ユーザ体験は大きく向上するでしょう

Appleでは SiriとMapsとMusicに導入しましたが 皆さんもできます ぜひ見直してみてください どれが外で使われるか？ いいユーザ体験にフローが 不可欠なのはどのアプリケーションか？ 相性がいいものがあります URLSessionやNetwork.frameworkで― ハンドオーバーか インタラクティブを選ぶことができます マルチパスでは serverとクライアントの協力が必要です こちらのサイトで 設定が正しいか確認しておいてください

以上でモビリティの話も終わりです

何より覚えていてほしいことは１つ ユーザが家から出る時は― Wi-Fiを切らずに済むべきです アプリケーションを開発し テストする時は気をつけてください 家を出ながら 悪いWi-Fi環境でテストする際も― アプリケーションは遅くならないはず 止まることも 時間がかかることもないはずです 基本的に動きます もし動かないなら ハイレベルAPIを使ってるかご確認を これらのAPIはWi-Fi アシストの 恩恵をフルに受けることができます

アクティブ管理をするなら― ラボで相談するか バグ報告を 事例を共有し 一緒に解決策を探しましょう アクティブ管理は― なるべく避けて Wi-Fi アシストを活用しましょう

最後にフローが Wi-Fiで詰まり困っているようなら― マルチパスを活用しましょう Apple MusicやMapsやSiriと 同じ恩恵にあずかりましょう 以上でセッションは終わりです Low Data Modeでは― ネットワークでの データ使用量を減らすことができます 新しいAPIで皆さんの アプリケーションも恩恵が受けられます

出版-購読型の アプリケーションを作るなら― Combineを使えば簡潔にできます 今日 グオイェが見せてくれました 最後にWebSocket iOS 13で 最も導入の要望が多かった機能です 双方向通信をアプリケーションで 簡単に構築することができます

iOS 13では モビリティの改善に力を入れました ハイレベルAPIで― 皆さんのアプリケーションに 活用することができます

今日の午後 このセッションのPart 2があります いろいろと 便利で新しいAPIが紹介されます 明日はmacOSで開発する人に― ネットワーク拡張の新しいAPIを そして朝９時からラボがあるので 質問に来てください 喜んで力になります

以上です 楽しんでいただけたでしょうか？ (拍手) ありがとうございました