App Groupsでのデータ共有が一段落し、次はブログのリンクからアプリの特定の画面へ直接遷移できるよう、Universal Linksでのディープリンクに挑戦しました。
1. カスタムURLスキームと混同していた
最初、独自のURLスキーム（myapp://のような形式）を使えばディープリンクは完成だと思い込んでいました。
カスタムURLスキーム: myapp://detail/123
Universal Links: https://example.com/detail/123カスタムURLスキームは手軽な反面、他のアプリと同じスキームを使われてしまう可能性やSafariでの警告表示など弱点があります。ウェブのURLとしてもそのまま機能する点を重視し、Universal Linksを採用することにしました。
2. apple-app-site-associationファイルの配置場所を間違えた
サーバー側に設置するapple-app-site-associationファイルを、最初/.well-known/ディレクトリの外に置いてしまい、何度リンクを踏んでもアプリが開かずSafariで表示されてしまいました。
正しい配置場所の候補（ドメインは例です）:
1. example.com/apple-app-site-association
2. example.com/.well-known/apple-app-site-associationこのファイルは上記いずれかのパスに、拡張子なし・Content-Type application/jsonでアクセスできる必要があります。サーバーの設定次第では拡張子なしのファイルがうまく配信されないことがあり、レンタルサーバーのApache設定を調整して解決しました。
3. HTTPS必須であることを見落としていた
ローカルのテスト環境でHTTP配信のまま確認しようとして、いつまでも認識されず時間を無駄にしました。
Universal LinksはHTTPS配信が必須で、証明書が正しく設定されていないドメインでは機能しません。当たり前の要件ではあるものの、開発中は見落としがちなポイントでした。
4. シミュレーターでは正しく動作確認できなかった
実装が完了したと思い、シミュレーターでリンクをタップして確認しようとしたところ、期待通りに動きませんでした。
Universal Linksの検証（apple-app-site-associationの読み込みとひも付け）は、実機でアプリを一度インストールした際にOS側で行われる仕組みのため、シミュレーターでは正しく再現できないことがありました。実機にインストールし直してから確認したところ、問題なくアプリが開くようになりました。
まとめ
- カスタムURLスキームとUniversal Linksは別物。ウェブURLとしても機能させたいならUniversal Linksを選ぶ
apple-app-site-associationは/.well-known/配下（またはルート）に、拡張子なし・JSON形式で配置する- Universal LinksはHTTPS配信が必須。証明書の状態を事前に確認する
- 動作確認は実機で行う。シミュレーターでは正しく検証できないことがある
地味な設定項目が多い機能でしたが、1つずつ潰していけば着実に動くようになる実装でした。
次は、BGTaskSchedulerでバックグラウンド処理を実装してみて分かったことをまとめます。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント