最近、iOSアプリ開発で自社サーバーを使ったプッシュ通知を実装しました。
今まではFCM（Firebase Cloud Messaging）使った一斉配信ばかり使っていたのであまり気にしたことなかったのですが、今回自社サーバーを使ったプッシュ通知を実装してみて、TestFlightのプッシュ通知はApns（Apple Push Notification Service）の本番サーバーに向いているっぽかったので、今後の為にメモとして残しておきます。
iOSアプリのプッシュ通知を自社サーバーで実装する方法
画像：Apple Push Notification Serviceを使ってiOSにプッシュ通知をするために必要な証明書の準備方法 - ggった結果
まず、iOSアプリのプッシュ通知を自社サーバーで実装する方法についてですが、
上記の画像でいうところの「送信元サーバー」の部分を実装する感じです。
（FCMを使ったプッシュ通知の場合だと、Firebaseが代用してくれていた）
一斉通知だけならFCMで十分事足りますが、FCMの場合は個別のプッシュ通知や、特定の条件のユーザーのみにプッシュ通知を送る場合はカスタマイズが必要になるので、いっそのこと自社サーバーでやってみようということになりました。
プッシュ通知のサーバー部分はapns-phpを使用
iOSアプリのプッシュ通知サーバー部分の開発をどうしようか調べていたら、iOSプッシュ通知のサーバー側用ライブラリである「apns-php」を使えばめちゃくちゃ簡単そうだったので、apns-phpを使うことにしました。
apns-phpを使った実装の流れ
詳しい実装方法については以下の記事がめちゃくちゃわかりやすかったです。
ざっくりとした流れとしては以下です。
上記の記事の流れで進めたらかなりスムーズにテスト配信まで行けました。
できれば、有効期限がなく・証明書の更新が不要なApnsの認証キーを使う方法でやりたかったのですが、自社サーバー+Apns認証キーを使った実装が調べても見つからなかったのでプッシュ通知証明書の方で実装しました。
懸念点としては、apns-php自体はかなり前からあるサービスですが、最近の更新はほぼ行われていない為、今後のiOSアップデートにも対応して行けるのか心配です。
（調べた感じだと、近い将来iOSデバイスの仕様変更で既存のapns-phpでは動かなくなるかもらしい）
TestFlightのプッシュ通知はApnsの本番サーバーに向いているっぽい
で、ようやく本題なのですが、TestFligtのプッシュ通知はApnsの本番サーバーに向いているらしいぞって話です。
プッシュ通知のテスト配信を行っていたら、以下のような現象を確認しました。
TestFlightからアプリをインストールした端末の方はAppleDeveloperにUDIDを登録していなかったので、もしかしたらそれが原因なのかも？と思い、UDIDの登録とプロビジョニングプロファイルの再ダウンロードを行い、再ビルド・再アップロードしてTestFlightから再度ダウンロードしましたが、結局プッシュは届きませんでした。
で、ネットを調べていたら、以下の記事を発見しました。
TestFlightというくらいなので、てっきり開発用のプッシュ通知証明書・開発用のApnsサーバーに向いていると思ってましたが、上記を参考にすると本番サーバーを向いている可能性が高いです。
実際、apns-phpのapnsの証明書設定を本番用にむけたところ、TestFlightからインストールした端末にも通知が届くようになりました。
状況を整理すると、最初の現象が発生したのは、
apns-phpにapns開発用証明書を設定した状態だったことにより、
→Xcodeで実機転送した端末は開発ビルドなので開発用のデバイストークンが発行され、プッシュ通知が届いた
→TestFlightでインストールした端末は本番用のデバイストークンになる為、apnsからの通知が届かなかった（apns-phpで開発用のapns証明書を設定している為）
ということなのかなと思います。
今後は、プッシュ通知を実装したアプリをTestFlight経由でアプリをインストールする場合は、プッシュ通知の証明書は本番に向けるように気をつけたいと思います。
（ただ、今回の場合はリリース前だから特に問題ありませんが、リリース後にTestFlightでプッシュ通知のテストをしたい場合などにはちょっと対策を考えないといけないなと思いました。）
