諸事情があって、Apple Developer ProgramなアカウントAで作成していたAd-Hocアプリを、Apple Developer Enterprise ProgramなアカウントBで作り直すことになりました*1。
作り直すといっても署名関係だけの問題で、すんなりとProvisioning Profileを変えて In-Houseなバイナリを作ることができました。
関係者に「In-House署名したバイナリができたよ〜インストールしてみて〜」と告知して、特に問題なくインストールができていたのに安心して、サーバー担当者にプッシュ証明書を渡して、これで作業完了……の予定でした。
翌日、サーバー担当者に「In-Houseバイナリに変えてからプッシュ通知が送れない」と言われて困りました。
状況の説明
アプリ担当の僕はサーバー側のシステムにはノータッチでプッシュ証明書を渡して、あとはよしなにしてもらっていました。
| 登場人物 | |
|---|---|
| さくさん | サーバーシステムについては詳しくないが、Amazon SNSを使っているのは知ってる |
| サーバー担当者 | アプリについては詳しくないが、Amazon SNSにプッシュ証明書を組み込んで使っている |
プッシュ通知が送れなくなった原因の容疑者探し
ここ最近で5回くらい同じ作業を繰り返していて、アカウントが変わったからといって、なんでプッシュ通知が送れなくなったのかを原因を突き止める必要がでてきました。
ざっと思いつく問題の原因をピックアップしてみました。プッシュ通知が送れない理由はあまり多くなくて基本的には、バイナリと証明書が噛み合っていないケースが多いです。
- アプリのビルド方法が悪い
- 渡した証明書が悪い
- サーバーのプッシュ通知の送り方が悪い
- 旧バイナリで取得したデバイストークンに対して通知を送ろうとしている
1.に関してはUDIDなしでビルドできていることから容疑から外しました。3.はAmazon SNSを使っているので問題はないだろうと踏みました。
当初2.を疑って、再度Keychain Accessから書き出しなおしましたが問題は解決しませんでした。
サーバー側に問題がないことを切り分ける
しばらくしてから、サーバー担当者からInvalid Tokenになっているということを聞きました。このことからプッシュ証明書に問題があると考えました。
サーバーシステムに問題がないことを証明して、問題を切り分けるためにサーバーシステムで利用している同じAmazon SNSを使って、単体でプッシュ通知が送れるかテストすることを考えました。
ひとつのアプリに対してプッシュ証明書はふたつまで発行することができるので、新しい証明書を発行してプッシュ通知が送ることができるか確認したところ成功しました。
まとめ
プッシュ通知が送れない理由として一番の原因は「プッシュ証明書」です。可能であれば新しい APNsの証明書を発行しなおすのが一番簡単に解決する方法ではないかと思います。
*1:ここ最近諸事情でアプリをアカウント間で動かしているケースが多い気がするゾイ
