プッシュ通知とディープリンク

プッシュ通知は、アプリが閉じているときにも利用者に知らせを届けられる、アプリならではの機能です。一方で「通知が届かない」は問い合わせの多い不具合で、原因はアプリの許可・トークンの登録・サーバーからの送信・配信サービス・端末の設定のどこにでもありえます。

経路を分けて知っておくと、どこで止まったかを順に調べられます。

プッシュ通知は、アプリのサーバーから直接端末に送るのではなく、OS の会社が持つ配信の窓口を通して届けます。iOS は APNs（Apple Push Notification service）、Android は FCM（Firebase Cloud Messaging）です。iOS にも FCM を使う場合は、FCM が裏で APNs に渡します。

流れ

• iOS は UNUserNotificationCenter で許可を求め、registerForRemoteNotifications でトークンを受け取ります。サーバーから APNs へは HTTP/2 で、認証は .p8 の鍵から作るトークンが一般的です。
• Android は FCM の登録トークンを受け取り、サーバーからは FCM の HTTP v1 API（サービスアカウントの認証）で送ります。Android 13 以降は通知に実行時の許可（POST_NOTIFICATIONS）が必要です。
• トークンは変わることがあるので、起動のたびや変更の通知（onNewToken など）でサーバーに送り直します。中身の大きさは APNs・FCM とも 4KB までです。

下の「ブラウザで試す」の図では、許可をもらった端末がデバイストークンを受け取って自社のサーバーに送り、出来事が起きたらサーバーが APNs に HTTP/2 で送信を頼み、APNs から端末に届くまでを順に追えます。APNs が 200 を返しても「受け付けた」だけで、端末に届いたとは限らないこと、410 Unregistered のときは保存しているトークンを消すことに注目してください。上の「トークンは変わることがある」とあわせて、トークンの管理が届く・届かないを左右します。

デバイストークンは「この端末のこのアプリ」あての宛先です。サーバー側では利用者と端末とトークンの組で持ち、変わったら直し、使えなくなったら消します。

1人が複数の端末を持つこともあるので、トークンは利用者ごとに1つではなく、端末ごとに複数持てるようにします。開発版のアプリのトークンは開発用の APNs の窓口でしか使えないので、環境を取り違えないよう、どちらの環境のトークンかも一緒に記録します。

プッシュ通知には、利用者に見せる通知と、アプリを裏で起こしてデータを取らせる通知があります。

サイレントプッシュで同期を起こす設計は便利ですが、届く保証がないことを前提にします。アプリを開いたときにも必ず同期し、通知は「先に取っておけたら速く見える」というおまけと考えます。iOS では、見せる通知の中身を表示前に書き換える Notification Service Extension（mutable-content: 1）を使うと、画像を付けたり暗号化した本文を戻したりできます。

通知を見せるには利用者の許可が要ります（Android は 13 から）。一度断られると OS の設定画面からしか変えてもらえないので、求めるタイミングが大事です。

Android の通知チャンネルは、作った後はアプリから重要度を変えられません（利用者が変えたものが優先）。「お知らせ」「メッセージ」「キャンペーン」のように最初から分けておくと、利用者が宣伝だけ止められて、通知全体を切られにくくなります。

「通知が届かない」は、アプリでいちばん多い問い合わせの1つです。経路を3つに分けて、どこで止まったかから調べます。

サーバー・配信の窓口（APNs／FCM）・端末の3か所のどこで止まっているかを順に調べます。

まず「サーバーが送ったか」「窓口が受け付けたか」をログで確かめると、端末側の問題かどうかがすぐ分かります。アプリが前面にあるときは、iOS も Android も自分で表示の処理を書かないと通知が出ないことがあるのも、よくある見落としです。

ディープリンクは、URL からアプリの特定の画面を開く仕組みです。myapp:// のような独自のスキームは、別のアプリが同じスキームを名乗れてしまい、アプリが入っていないと何も起きません。そこで今は、普通の https:// の URL で開く ユニバーサルリンク（iOS）と App Links（Android）を使います。アプリが入っていれば開き、入っていなければそのまま Web のページが開きます。

設定ファイルと検証

ユニバーサルリンク・App Links が開かない原因は、ほとんどが設定ファイルの置き方・キャッシュ・開き方のどれかです。上から順に確かめます。

• ファイルの置き方：HTTPS で直接返していない（リダイレクトしている）、Content-Type が JSON でない、ログインが必要なページの裏にある。
• iOS のキャッシュ：ファイルを直してもすぐ反映されない。また、利用者が一度「Safari で開く」を選ぶと、そのドメインはブラウザーで開くようになる。
• iOS の開き方：アドレスバーに直接打ち込んだ URL や、同じドメインのページの中のリンクではアプリは開かない。
• Android の署名：Google Play のアプリ署名を使っていると、配られるアプリの署名は手元のアップロード鍵と違う。assetlinks.json には Play Console に出ているアプリ署名の鍵のフィンガープリントを書く。Android 12 以降は検証に失敗するとブラウザーで開く。
• アプリ内ブラウザー：SNS などのアプリの中のブラウザーでは開かないことがある。

リンクや通知から開いたときは、URL を受け取って「どの画面を、どの値で開くか」に変換し、必要な確認をしてから画面を開きます。この変換を1か所にまとめておくと、リンク・通知・ウィジェット・ショートカットのどこから来ても同じ動きになります。

iOS なら onOpenURL で受けて NavigationStack の path を組み立て、Android なら Navigation の deepLinks か、受け取った Intent からルートを作って navigate します。

アプリが入っていない人がリンクを開くと、まずストアに行き、インストールしてから開いたときには元のリンクの情報が失われています。インストールの後に目的の画面へ連れていくのがディファードディープリンクです。

アプリが入っていない人を、インストール後に目的の画面へ連れていく「ディファードディープリンク」は標準の仕組みにはなく、外部のサービスや自前の仕組みが必要です（Firebase Dynamic Links は 2025年8月25日に終了しました）。

照らし合わせの方法によってはプライバシーの規約に関わるので、iOS では ATT の扱いを確かめてから選びます。