結論：不特定多数へ共有するなら、通常のHTTPS URLを失わない設計が基本です。Universal Links/App LinksはWebへfallbackしやすく、custom schemeは別途fallbackを用意しないと何も起きない可能性があります。
Universal Links / App Links
AppleとAndroidの公式資料では、アプリがインストールされていない場合、Universal Links / App LinksのHTTPS URLはWeb側で開ける設計になっています。1つのURLでWebとアプリを共有できることが大きな利点です。
Custom URL scheme
myapp://... のようなcustom schemeは、そのschemeを処理するアプリが端末に存在しなければ開けません。Webページへ自動的に戻る仕組みはschemeそのものには含まれないため、ページ側・アプリ側・別URLなどでfallbackを設計します。
Android Intent URL
ChromeのIntent URIでは S.browser_fallback_url を設定し、対象アプリを解決できない時にWeb URLへ誘導する方法が公式に説明されています。ただし、Intent URIが起動される条件自体にもユーザー操作などの制約があります。
「ストアへ送る」と「インストール後に元画面へ戻す」は別
アプリがなければApp Store/Google Playへ送るだけなら比較的単純ですが、インストール完了後に元々見たかった商品・動画・投稿へ戻すにはdeferred deep linkingの仕組みが必要です。
ディファードディープリンクは通常のdeep linkとは別機能です。
第三者サービスURLではどう考える？
YouTube、Instagram、Spotify、Amazonなど自分が管理していないサービスの場合、通常のHTTPS URLはそのサービス側が用意した最も重要なfallbackです。専用schemeだけへ置き換えて元URLを捨てると、アプリ未導入端末で到達性を失う可能性があります。
おすすめの確認順
- 元のHTTPS URLが正しく開く。
- アプリ導入済み端末で目的画面へ到達する。
- アプリを入れていない端末でタップする。
- Webページまたは適切なストア導線へ到達する。
- インストール後復帰が必要ならdeferred対応を別途確認する。
避けたい設計：「アプリがある人だけ成功すればよい」と考えてcustom scheme単体をSNSへ配布すること。共有範囲が広いほどfallbackが重要です。