Universal Link — 概要、動作原理、設定方法

Universal Linkとは

Universal Linkとは、iOSデバイスからタップすると、Safariの代わりにインストールされたアプリを開くhttps://example.com/pageのような標準的なHTTPSリンクです。Custom URL Schemeとの主な違い：Universal Linkはカスタムスキーム（myapp://）の登録を必要としません — 通常のドメインを使用します。これにより、任意のアプリが同じスキームを登録できるURL Schemeハイジャック問題を排除します。

AppleはWWDC 2015でiOS 9の一部としてUniversal Linkを発表しました。このメカニズムはHandoffおよびSpotlightエコシステムの一部となりました。Universal Linkはブラウザだけでなく、Spotlight検索結果、Mail、Messages、その他のシステムアプリでも機能します。さらに、Universal LinkはwatchOSとmacOSでもサポートされています — ユーザーはMacのリンクを介してiPhoneでアプリを開くことができます。

主な利点：統一URL。開発者は2つの異なるリンク（ウェブ用とアプリ用）を管理する必要がありません。Universal Linkは同じhttpsリンクです。アプリがインストールされていればアプリが開き、インストールされていなければ同じリンクがSafariで通常のウェブページとして開きます。これにより、トラフィックを失うことなく理想的なフォールバックを提供します。

Universal Linkの仕組み

Universal Linkのメカニズムは、関連付けの検証、リンク処理、ブラウザフォールバックの3つの段階で構成されています。各段階は正しい動作にとって重要です。関連付けが設定されていない場合、iOSはリンクをSafariへの通常のリダイレクトとして処理します。各段階を詳しく見ていきましょう。

関連付けの検証（Association Verification）

リンクを最初にタップすると、iOSはサーバーからhttps://example.com/.well-known/apple-app-site-associationにあるapple-app-site-associationファイルをダウンロードします。ファイルには、アプリのTeam IDとBundle IDを含むJSONと、アプリが開くべきパスのリストが含まれています。iOSはこのファイルをキャッシュし、定期的にその鮮度を確認します（アプリアップデート時、デバイス再起動時）。

JSONファイル apple-app-site-associationは、リダイレクトなしでHTTPS経由でアクセス可能でなければなりません。サーバーはContent-Type: application/jsonを返す必要があります。重要なのは、ファイルに.json拡張子がないことです — iOSはそれを厳密に/.well-known/apple-app-site-associationで探します。AppleはCDNでのUniversal Linkサポートの追加と、robots.txtによってファイルがブロックされていないことの確認も推奨しています。

// apple-app-site-association — 最小構成
{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "TEAMID.com.example.app",
                "paths": ["/product/*", "/profile/*", "/search"]
            }
        ]
    }
}

appIDはTeam ID + Bundle ID（TEAMID.com.example.app）として形成されます。pathsはアプリが処理するURLパターンの配列です。*、?、およびNOT表記を使用できます：["NOT /admin/*", "/product/*"]。パスは列挙順にチェックされ、最初に一致したものが動作を決定します。パスが一致しない場合、リンクはSafariで開かれます。

リンク処理（Link Handling）

関連付けの検証が成功すると、iOSはリンクをアプリに渡します。処理は、NSUserActivityの場合はAppDelegateのapplication(_:continue:restorationHandler:)メソッド、またはSceneDelegateのscene(_:continue:)を介して行われます。開発者はNSUserActivityTypeBrowsingWebタイプのNSUserActivityオブジェクトを受け取り、URLを抽出して対応する画面に遷移します。

// AppDelegateでのUniversal Link処理
func application(
    _ application: UIApplication,
    continue userActivity: NSUserActivity,
    restorationHandler: @escaping UIUserActivityRestorationHandler
) -> Bool {
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
          let url = userActivity.webpageURL
    else { return false }

    // URLに応じた画面への遷移
    DeepLinkRouter.navigate(to: url)
    return true
}

上記の例のDeepLinkRouterは、URLを解析して対応するナビゲーションコーディネーターを呼び出すカスタムクラスです。SwiftUIの場合、処理はonOpenURLメソッドまたはenvironment(\.openURL)修飾子を介して行われます。フォアグラウンド起動だけでなく、アプリが実行されていなかった場合（コールドスタート）も処理することが重要です。この場合、Universal Linkは起動オプションを介してアプリを開きます。

ブラウザフォールバック（Browser Fallback）

アプリがインストールされていない場合、iOSは自動的にSafariでUniversal Linkを開きます。これがCustom URL Schemeとの主な違いです：ユーザーはエラーを表示しません。フォールバックは同じドメインの標準的なウェブページです。開発者はこのページにApp Storeへのリンク、製品情報、または代替コンテンツを配置できます。

重要：フォールバックはiOSレベルではカスタマイズできません。iOSは単にSafariでURLを開くだけです。アプリがインストールされているユーザーとインストールされていないユーザーで異なるコンテンツを表示するには、Smart App Banner（アプリを開くことを提案するSafariのメタタグ）またはJavaScriptによるインストール検出を使用してください。AppleはUniversal Linkを介したインストール属性のためにSKAdNetworkも提供しています。

Universal Link vs Deep Link

Universal Linkと従来のDeep Link（Custom URL Scheme）は同じ問題を解決しますが、アーキテクチャとセキュリティにおいて根本的に異なります。Custom URL SchemeはInfo.plistに登録されるカスタムプロトコル（myapp://）です。任意のアプリが同じスキーム（myapp://）を登録でき、iOSはどれが「本物」かを判断できません。これをURL Schemeハイジャックと呼びます。

Universal Linkはドメイン検証を通じてハイジャック問題を解決します。ドメイン所有者のみがサーバーにapple-app-site-associationを配置し、特定のBundle IDとの接続を確認できます。2つのアプリが同じUniversal Linkを登録することはできません：競合が発生した場合、iOSは最後にインストールされたアプリを優先するか、Safariを開きます。

もう1つの違い：フォールバック。Custom URL Schemeにはフォールバックがありません — アプリがインストールされていない場合、ブラウザはエラーを表示します。Universal Linkはウェブサイトを開きます。統一URLにより、リンクのSEO価値が保持され（Googleがリンクをインデックス）、どのデバイスのユーザーも関連コンテンツを受け取ります。Universal Linkは、ディープリンクから統合リンクへの進化的ステップです。

Universal Linkの設定

設定にはサーバー側とクライアント側の両方が含まれます。サーバー側 — apple-app-site-associationファイルをhttps://domain/.well-known/apple-app-site-associationに配置します。クライアント側 — XcodeのAssociated Domainsにドメインを登録します（Capabilities → Associated Domains → applinks:example.com）。その後、アプリは指定されたドメインのすべてのUniversal Linkを自動的に受信します。

設定手順：

1. 作成 — 正しいappID（TeamID.BundleID）とpathsでapple-app-site-associationを作成
2. 配置 — サーバーの/.well-known/に.json拡張子なしでファイルを配置
3. 確認 — curl https://domain/.well-known/apple-app-site-associationでアクセス確認
4. 追加 — Xcode CapabilitiesのAssociated Domainsにドメインを追加
5. 実装 — NSUserActivity（AppDelegateまたはSceneDelegate）を介した処理を実装
6. テスト — 実機でテスト（シミュレーターは関連付けを検証しません）

デバッグはiOS開発者にとって一般的な悩みの種です。リンクが機能しない主な原因：apple-app-site-associationファイルがHTTPS経由でアクセス不可、appIDの誤り、Content-Typeがapplication/jsonではない、/.well-knownパスからのリダイレクト、古いバージョンのキャッシュ（Settings → Developer → Associated Domains Developmentでリセット）。AppleはApple Developer Consoleで関連付けをテストするためのValidation Checkerツールを提供しています。

Branchやその他のMMPプラットフォームはUniversal Linkの設定を簡素化します：自動的にapple-app-site-associationを生成し、自社のドメインでホスティングします。開発者はAssociated DomainsにBranchドメインを追加してSDKを統合するだけで済みます。これは特に、AASAファイルをホスティングする独自のサーバーインフラを持たないスタートアップにとって便利です。

制限事項と互換性

Universal Linkにはいくつかの制限があります。第一に：apple-app-site-associationファイルは厳密にHTTPS経由でアクセス可能でなければなりません（HTTPはサポートされていません）。第二に：リンクはAssociated Domainsで指定された同じドメインを指す必要があります。クロスドメインのUniversal Linkは機能しません — 各ドメインにCapabilitiesでの個別のエントリと個別のAASAファイルが必要です。第三に：Universal LinkはWKWebViewでは機能しません — Safariおよびシステムコンポーネントのみで動作します。

互換性：iOS 9.0+（Universal Link）、watchOS 6.0+（Handoff Universal Link）、macOS 10.15+（CatalystおよびMacアプリ）。古いiOSバージョンでは、リンクはSafariで開かれます。つまり、iOS 8（デバイスの1%未満）ではUniversal Linkは機能しません。対象ユーザーに古いバージョンのユーザーが含まれる場合は、古いデバイス用のフォールバックとしてCustom URL Schemeもサポートすることをお勧めします。

iOS 16+の変更点：AppleはSwiftUIのUniversal Link処理を改善しました。遅延処理機能を備えた新しいenvironment(\.openURL)修飾子が導入されました。iOS 16では、SFSafariViewControllerを介してもアプリでUniversal Linkを開くことができるようになりました。iOS 16ユーザーの場合は、完全にSwiftUIのUniversal Link処理に移行し、AppDelegateコードは後方互換性のためだけに残すことをお勧めします。