結論:「Safariに開いた=壊れている」と判断せず、リンク元ドメイン、AASA、Associated Domains、タップ方法、ユーザーの過去の選択、アプリ導入状態を順番に確認します。

同じドメインをSafariで見ている時

Appleは、SafariでWebサイトを閲覧中に同じドメインのUniversal Linkをタップすると、ユーザーがWeb閲覧を続けたい意図を尊重しSafari内で開く場合があると説明しています。別ドメインからのリンクではアプリへ遷移する場合があります。

そのため、自社サイト内の同じドメイン同士だけでテストして「Universal Linksが効かない」と判断しないようにします。

アドレスバーへ直接入力した場合

AppleのTN3155では、SafariのアドレスバーにURLを直接入力してもUniversal Linkとしてアプリは開かないと説明されています。これは直接ナビゲーションとして扱われます。

メモ、メール、別Webページなどにリンクを置き、実際にタップして確認します。

ユーザーが以前Safariを選んでいる場合

iOSはユーザーの過去の選択も考慮します。Universal LinkをWebで開く選択をした後、同じドメインがSafariへ開き続ける場合があります。Appleのデバッグ資料では、リンクを長押ししてアプリで開く/ブラウザで開く選択肢を確認する方法が案内されています。

AASAを確認する

自社アプリのUniversal Linksなら、対象ドメインのAASAが正しい場所でHTTPS配信され、アプリIDやpath/componentsが目的URLを含むか確認します。サブドメインごとに関連付けが必要なケースもあります。

第三者サービスのリンクの場合

Instagram、YouTube、Xなど第三者のURLは、そのサービス側がUniversal Linksやschemeを管理します。共有者がAASAを修正することはできません。通常URLとscheme候補を分け、実端末で確認します。

Custom schemeの場合

appname://... が開かない場合はUniversal Linksとは別です。対象アプリがschemeを登録しているか、ブラウザ/WebViewが外部schemeを許可するか、アプリが導入済みかを確認します。

確認順

  1. 元HTTPS URLがSafariで正しく表示される。
  2. アプリがインストール済み。
  3. アドレスバー入力ではなくリンクをタップ。
  4. 同一ドメインSafari内のテストだけに偏っていない。
  5. 自社アプリならAASA/Associated Domainsを確認。
  6. SNS内ブラウザとSafariを分ける。
  7. custom schemeならscheme自体の現行仕様を確認。

共通の原因も確認する

URL形式や製品の保存経路が原因の場合はOS以外の切り分けも必要です。

共通トラブルシューティング

確認した一次情報