ユニバーサルリンクの新機能

(音楽)

Universal Linksのセッションへ ようこそ 私はジョナサンです Coreフレームワークチームの一員です Universal Linksの使い方を 解説します Universal Linksは Webやアプリケーションで コンテンツの充実化を図るため iOS 9にて導入 今回は新機能について説明します iOSであれmacOSであれ 使用を検討中の方は 変更点にご注目ください

まずはUniversal Linksの 概要についてです

Universal Linksとは HTTPやHTTPSのURLで WebやAppのリソースを示すものとして AppleのOSが認識します アプリケーションの インストール状況に関係なく １つのURLでコンテンツを示せます ユーザーエンゲージメントの 向上に有効です iOS 9とtvOS 10に導入済みですが この度 macOS 10.15にも 導入されました AppKitやUIKitの使用は 問いません 詳細は のちほどお伝えします Universal LinksはAppとWeb間を 関連付けます AppはXcode上で エンタイトルメントするドメインを選び Web Serverは JSONファイルを通じて ドメインのどの部分を Appに表示させるかを選びます 双方向の密な連結で 第三者によるリダイレクトが防げます

カスタムURLスキームを お使いの方には Universal Linksへの移行を お勧めします カスタムURLスキームは 悪用されかねないので 使用しない方がいいでしょう

次はUniversal Linksの 組み立て方です まずはWeb Serverです

Serverには有効なHTTPS証明書が 必要です HTTP通信は安全ではなく AppとWebの関連付けに 使用できません HTTPS証明書に署名する ルート証明書は OSの認識が必要です カスタムルート証明書は使えません

証明書を作成し Serverを設定したら Apple App Site Associationファイルを 追加しましょう このJSONファイルは あとで説明します Appがインストールされると このファイルで Appが使うサービスが決まります ファイルは定期的に更新され― Universal Linksも ここに含まれます ファイルのパスはこうなります https://ドメイン名/ .well-known/ apple-app-site-association 他のパスは使えません ファイルには署名が必要だと 伝えてきましたが Universal Linksには不要なので 廃止しました 署名付きや別のパスのJSONファイルは 今後 廃止予定です

その話はさておき― Apple App Site Associationファイルを 見ていきましょう 使用中の方は おなじみだと思いますが いくつか変更点があります 最上位はキーがサービスの Dictionaryです Universal Linksでは applinksキーですが 他のサービスも使用可能です 今回はapplinksとします その下に appsキーとdetailsキーを置きます iOS 13やtvOS 13 macOS 10.15向けであれば appsキーは不要です しかし iOS 12やtvOS 12 それ以前の場合は 必要です Universal Linksでは appsキーを空の配列にします detailsキーは Dictionaryの配列を含み 各Dictionaryは 特定のAppを意味します Dictionary構造にも 対応していましたが 廃止となりました

この下にはappIDキーを置き App IDを記入します Apple支給の 10桁の英数字のあとに ピリオドとバンドルIDを加えます チームIDと異なる場合もあるため デベロッパポータルで 確認してください 同じUniversal Linksを 複数のAppで使う場合 コードの反復は不要です 今年のリリースであれば 複数形のappIDsキーが使えます 複数のApp IDが入ります 旧リリースの場合は 単数形のappIDキーを使います 次のpathsキーには パスパターンの配列を書きます パターンマッチングは 端末と同じです “*”は複数のワイルドカード文字 “?”は１文字を表します 今年から componentsキーに変わりました 値はDictionaryの配列で ゼロ以上の URLコンポーネントを含みます pathsキー同様に“/”で マッチングさせることが可能です 旧リリース用には pathsキーが使えます iOS 13やtvOS 13 macOS 10.15では componentsキーがあれば pathsキーは無視されます URLフラグメントのマッチングには 値に“#”を使用します クエリの場合は“?”を使います URLの多くはクエリを― キーと値からなる クエリアイテムに分割します クエリでは 値にDictionaryを指定し パターンマッチングが可能です 各クエリアイテムのインスタンスは パターンが一致しなければなりません 存在しない または 値のないクエリアイテムは 空の文字列と見なされます

Dictionaryと 候補のURLのマッチングには 全コンポーネントの一致が必須です 指定がなければ OSはそのコンポーネント 無視します URLのフラグメントが 不要なアプリケーションの場合は 指定も不必要です App側にないセクションが あるかもしれません それらサブセクションは excludeキーでtrueとし除外します pathsキーでは “NOT”を使いましたが Dictionaryには非対応です

ではパターンマッチングの例を ご紹介します Universal Linksで 食事が注文できるAppへ ユーザを誘導するとします 左側にはJSONファイル 右側にはURLがあります まず注文フォームを一致させます すべてパス上にあり １つ目は何でも構いません ２つ目はorderで それ以降はなしです 右側のURLと一致しますね 続けましょう

タコスにチーズ追加の注文が 予想されます パスがtacoで始まるURLを 一致させます クエリアイテム名は cheeseとします パターンとして“?”と“*”を 指定していますよね “*”からなるパターンは 空を含むどの文字列とも一致します クエリアイテムがなければ 空と見なされます １文字以上の文字列との一致には “?”と 追加文字用に“*”と指定 ３番目のURLと一致しました

４番目と５番目が似ているのには 理由があります ４桁のクーポンコードが 使えるサイトですが １で始まるものは ブラウザ側にとどまらせます OSはパターンをくまなく探すため １で始まるものを除外させておきます これで一致が見つかっても リンク先のURLは開かれません 他のコードは 最後のDictionaryで一致させます

Appの解説の前に 海外ユーザへの対応の話をします URLと同様に マッチングにもASCIIを使います Unicodeでの一致には URLエンコードしてください Unicodeの文字は ASCIIで１文字以上の 場合があります “?”を使う時は注意しましょう JSONファイルを組み立てる時 国別にパターンを作りたくなります しかしそれでは サイズが膨らみます パターンマッチングが同じなら JSONを簡略化し 通信量を減らせます 例えば２文字の国別コードを使う場合 代わりに“?”を ２つ指定するだけで済みます 他の複雑なパターンも 簡単に一致できます 無効な国別コードなどがあるURLは ユーザのロケールとして扱います

今回のリリースからは ブラウザロケールを想定し ダウンロード順が決まります 優先順位を付けて ダウンロードするのです トップレベルドメインが “.com”“.net”“.org”の場合 多く使われているので 優先度が高くなります ccTLDという国別コードや 国際化国別コードも ユーザロケールと一致すれば 優先されます 例えば中国のユーザは イタリアやロシアのccTLDよりも 中国のドメインを訪れるはずです

では次にアプリケーションを 更新しましょう

プロジェクトをXcodeで開き 設定画面に進み Associated Domainsを 追加しましょう 新たにエンタイトルメントを 与えるドメイン先は この画面で変更できます

エンタイトルメントの値は “サービスタイプ:ドメイン名”です Universal Linksでは サービスタイプはapplinksです OSは 値の順を無視します ではwww.example.comの― Universal Linksに対応と 宣言します Appがインストールされると OSがこのドメインを訪れ Apple App Site Associationファイルを 探します Appの情報を含むファイルがあれば 関連付けが確定します 例のようなサブドメインには ワイルドカードが使えます その場合 OSはwwwなしの example.comを訪れます 正確なドメインの方が ワイルドカードのものより 優先されます www.example.comを開くと 親ドメインから得たパターンより こちらから得たものから先に マッチングされます 親ドメインのパターンの一致は サブドメインで一致がない時のみです 最後に国際化ドメインの例を ご紹介します URLにはASCIIを使うため 国際化ドメイン名はPunycodeでの エンコードが必要です 詳細はRFC 3492をご確認ください

ドメイン対応の宣言の次は URLのパースが必要です Universal Linksは NSUserActivityクラスがベースで Appデリゲートが処理します ユーザアクティビティには ハンドラが必要です Handoffなどの機能がある場合は すでにメソッドがあるかもしれません ブール値を返すため ページを開ければtrue 失敗だとfalseになります UI Sceneにも 類似のメソッドが使えます AppKitをお使いの場合でも UIをNSに置換するだけです 例ではUIApplicationを使います 次はactivityTypeが NSUserActivityTypeBrowsingWebに なっているか確認します 他のアクティビティと Universal Linksを区別するためです 他のactivityTypeを サポートしていなくても 今後のために確認しましょう 問題なければ webpageURLを取得します nilになることはありません ではURLコンポーネントを作ります URLのパースに使うからです 通常の式や マニュアルでパースすると セキュリティ性が低下します 次はURLのコンテンツ確認です 今回使うクエリアイテムも含め どのURLコンポーネントも使えます ドメインが複数の場合は ホストコンポーネントも確認を

設定は完了しましたが macOSでの使用には注意が必要です Universal Linksは 通常ブラウザで開かれますが リンクを押すと Appでも開けると通知が出ます その設定を選ぶと 以降はAppで開きます リモートボリュームのAppは macOSで起動できますが Universal Linksが機能するのは ローカルボリュームのAppのみです Appをダウンロードすると Apple App Site Associationファイルの ダウンロードも始まります Developer IDの署名があるAppでは 一度Appを起動する必要があります Universal LinksはApp IDと 関連付けられているため Mac上では各リンクにつき １つのAppが対応します 通常は“/applications”内のAppです エンタイトルメント変更の際は注意を Universal Linksの設定を終え リンク先を開けようとすると UIApplicationやNSWorkspaceなどが 自動的に開いてくれます ブラウザではなく Appで開く設定にする場合も これらのAPIを使うことができます リンクが開けなければ Universal Linksの設定が 間違っています macOSでのブラウザ開発用に 追加のAPIも提供される予定です

最高のAppと ユーザエクスペリエンスのために 最後にヒントをお教えします

まずは潔く失敗しましょう コンテンツが無効または 存在しないURLの場合があります Universal Linksが Appで開けない時は SafariViewControllerで開ければ ユーザも満足です それが無理な時は Safariで開くか トラブルの詳細を表示しましょう ブランク画面は避けるべきです Smart App Bannerを使って App Storeなどへのリンクを 提供しましょう Safariとスムーズに連係しますし JavaScriptやカスタムURLスキームも 不要です 最後にUniversal Linksの機能を 向上させるために フィードバックアシスタントから ご意見をお寄せください ありがとうございました