もしかすると、公式ドキュメントがおかしい(?)かもしれません。
# https://firebase.google.com/docs/cloud-messaging/ios/client#method_swizzling_in_firebase_messaging
if #available(iOS 10.0, *) {
// For iOS 10 display notification (sent via APNS)
UNUserNotificationCenter.current().delegate = self
let authOptions: UNAuthorizationOptions = [.alert, .badge, .sound]
UNUserNotificationCenter.current().requestAuthorization(
options: authOptions,
completionHandler: {_, _ in })
} else {
let settings: UIUserNotificationSettings =
UIUserNotificationSettings(types: [.alert, .badge, .sound], categories: nil)
application.registerUserNotificationSettings(settings)
}
application.registerForRemoteNotifications()
このような記述がありますが、調査を行ったところ
let center = UNUserNotificationCenter.current()
center.requestAuthorization(options: [.alert, .badge, .sound]) {granted, error in
if let error = error {
print(error)
return
}
if granted {
DispatchQueue.main.async {
UIApplication.shared.registerForRemoteNotifications()
}
}
}
このように requestAuthorization 内で
registerForRemoteNotifications を呼び出す仕様に思えました。
またswizzlingと呼ばれるメソッドを差し替えるテクニックにより
device tokenのセットをFirebase側で行っているが
それがiOS13周りで壊れたのかもしれません(?)
swizzlingをoffにする設定もあります。
swizzlingは出来れば避けたほうが良さそうな雰囲気もあるためOFFにした。
※ 今回あげた2つの原因に対して同時に2つの対策を行ったため切り分けは行っていません。
上記の2点の対策を実行したところ無事にPUSH通知が飛ぶようになりました。
こちらはプログラミング相談サイトMENTAでご相談頂いた内容です。
PUSH通知が飛ばないなどのにお困りでしたら気軽にご相談ください。
https://menta.work/?nic=owAl5EbX7N3uIo7i&ref=ni
https://menta.work/plan/88