iOS 12で劇的に変わるPush通知の全貌

今更ですがWWDC2018のkeynoteを仕事と銘打って業務中に見まくっています。

数ある新機能の中でもiOS 12で劇的に変わりかつ影響範囲が大きい機能といえば「Push通知」ではないでしょうか。

今回はそんなiOS 12のPush通知についてまとめてみます。

他にもCritical Alertや通知のUI周りのトピックなどありますが今回は割愛します。

Provisional Authorization

今回紹介する3つの新機能の中でも目玉機能かと個人的には思っています。

今までPush通知の送信許可をユーザに要求する方法といえば、アプリを初めて開いた途端にダイアログを表示して要求したり、何かしらPush通知の内容紹介をしてから要求したりといったケースが一般的でした。

この今までの方法では実際にどんな通知が送られてくるか分からないのにユーザが判断を迫られるというある意味無謀な要求をしていました。

ところがiOS 12ではとうとうこの旧態依然とした機能にメスが入りました。

Provisional Authorizationはユーザにダイアログで許可を要求するのではなく、1通目のPush通知を勝手に送信してその時点で今後も通知を受け取りたいかどうか判断してもらうことができるようになる機能です。

f:id:tofucodes:20180906010511p:plain

この方法ならばユーザが実際に通知を見てから判断するためとても理にかなっています。

もしかしたらPush通知の認可率も今までに比べて向上するかもしれませんね。

UNUserNotificationCenterのrequestAuthorization(options:)のオプションに.provisinalを追加するだけです。

UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound, .provisional])

Push通知がグルーピングされて表示されるようになります。

f:id:tofucodes:20180906010509p:plain

Push通知のペイロードに任意のデータとしてthread-idが追加され、グルーピングはこのID単位で行われます。

thread-idを指定しない場合はアプリ単位でグルーピングが実行されます。

ユースケースとしては例えば重要な通知がグルーピングされて隠れないようにするために別のthread-idを指定したり、通知の種類ごと（メッセージの受信といいね等）にthread-idを分けたりでしょうか。

ただ注意点として、たとえthread-idを指定して通知を送信したとしても、ユーザのiOS設定で「通知のグループ化：App別」になっている場合はアプリ単位でグルーピングされてしまいます。デフォルト設定は「自動」になっているみたいです。

前述した通り、Push通知のペイロードにthread-idパラメータを指定することで実現できます。

iOSの設定アプリもしくは実際の通知からアプリ内の通知設定画面を開けるようになります。

例えば通知の種類がいくつかありそれぞれに対してON/OFFを選択できるようなサービスにおいて、OFFにするための画面（iOS設定アプリや実際の通知）にアプリ内設定画面への導線を置くことで全ての通知をOFFにされるのを避けられることが期待されます。

keynoteではDelegateメソッドさえ実装していればあとはOSが勝手に導線を作ると言っていますが、嘘ですlol

まずはUNUserNotificationCenterのrequestAuthorization(options:)のオプションに. providesAppNotificationSettingsを追加します。

UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound, .providesAppNotificationSettings])

そしてUNUserNotificationCenterDelegateのuserNotificationCenter(_:openSettingsFor:)を実装して該当のアプリ画面を表示します。