Push Notifications not working with iOS 13

[jbcaveman]

What did you do?

Sent messages to an iOS 13 device

What did you expect to happen?

Receive a push notification and for channelsViewController to update the channel cells with the latest messages

What happened instead?

No push notification in or out of the app, and channelsViewController stays stale with old messages until you restart the app

GetStream Environment

GetStream Chat version: stream-chat v1.1.4, StreamChatCore v1.3.20
iOS version: 13.1.2
Swift version: 5
Xcode version: 11.0
Device: iPhone X

Additional context

Observed push notifications behaving correctly on iOS 11/12 with same environment. Apple recently added a new attribute to the headers for APNS Headers, apns-push-type, which is required in iOS 13. https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns?language=objc

[jbcaveman]

UPDATE: This appears to only be an issue in a production environment. iOS 13 receives and processes the notifications as expected when testing in a development environment.

[jbcaveman]

CORRECTION: tracing back a little further, I see that it might not be an APNS issue. The failure is that the new message event isn't getting through the app. In this case ChannelPresenter calls Notifications.shared.showIfNeeded(newMessage: message, in: channel) upon a .messageNew event. This is not happening on iOS 13 in production. Is the StreamChatCore SDK intercepting notifications somewhere other than the Notifications class?

[buh]

Hi @jbcaveman
Could you check that you uploaded a production push notification certificate on our dashboard?

[jbcaveman]

Yes. I am using a .p8 key. When I noticed the issues, I also tried to revert back to our active production .p12 that we use with another service, but I didn't see a change. I also tried generating a new .p8 key, which had no effect.

[buh]

Did you check push logs in our dashboard?

[jbcaveman]

Just checked it. I guess the logs take a while to populate because I wasn't seeing any yesterday. Today I do see them and I see success for the iOS 13 user. So it would appear that the notifications are sent, but they are not populated through the app when it is active or in background.

[buh]

A push notification will be sent if the client was disconnected. When the app is going to the background the client will keep connection for a 1-5 min. Can you test when the app in the background for more than 5 min?

[buh]

Can you send to our support your issue and api key?

[jbcaveman]

I did notice the push will send if I wait for a minute or so. So I suppose the issue lies with the client handling of the event in iOS 13. I will pick this up with a support email. Thanks.

[buh]

@jbcaveman Now it looks like local notifications doesn't work for you. But now you can debug.
So, when your app in the background and the client still connected the client will send local notifications.
Try to enable logs for notifications Notifications.logsEnabled = true and test a new message when the app in the background.

[jbcaveman]

Here are some production logs where the app is not showing the updates in the ChannelsViewController. I can see the message data in the log and the tab & app badge will increment, but the ChannelsViewController does not update with the new messages.
background_log.txt
active_log.txt

[jbcaveman]

And here are development environment logs where the app is showing all updated messages normally. Notice the custom logging showing calls to "apns: Notifications: show(newMessage...)" in these logs that don't show up in the production logs.
background_log_dev.txt

active_log_dev.txt

[buh]

Are you debugging production build?

[buh]

Thanks for logs!

[jbcaveman]

Just updated the dev background log, going back a bit more to the app entering background mode.

The production app is a Release build.
The dev app is a Debug build.

[buh]

I know build types. I'm curious how you get Stream logs from production? Did you override ClientLogger log function?

[buh]

It's really weird. Did you try to compile and debug the production build? Does it have the same logs?

[jbcaveman]

I'm copying the logs from the Xcode console with

        Client.config = .init(apiKey: STREAM_KEY, logOptions: .all)
        Notifications.shared.logsEnabled = true

The behavior is the same as the live app in the app store.

[buh]

Yes, that's what I'm asking.

[jbcaveman]

I have a remote logging feature that I can put into a true production release and install through TestFlight. It will take a few minutes. I'm not sure it will catch the Stream logs, though.

[buh]

Is notifications authorization status ok at the beginning?
Can you send me full logs?

ClientLogger has a callback

public static var logger: (_ icon: String, _ dateTime: String, _ message: String) -> Void

You can override the default behavior print to something else.

[buh]

When you tested the dev build, a chat view controller was opened?

[jbcaveman]

I have the app opening a ChannelsViewController at launch because that is the only way I found to kick start all notifications properly.

My logger gets all stdout, so it is catching your logs. I'll publish a TestFlight app with this turned on to get as close to a real production experience as possible.

Meanwhile, here is a full production log when run using xcode. The notifications appear to be set right at launch.

log_stdout.txt

[buh]

In the last logs I don't see background work.

[jbcaveman]

Ok. I was able to do the same test with the same results from a production TestFlight app. I sent messages while active, in background, and while channels view is up and while chat view is up. The messages tell the state of the receiving app. Here are the logs
log_stdout.txt
log_stderr.txt

To be thorough, here is the Notifications extension I altered to get the active and background alert working. Again, this works in all cases except iOS 13 in production, apparently because the .messageNew event doesn't reach the ChannelPresenter(s) owned by ChannelsViewController.
Notifications_extension.txt

[buh]

I’ve just found an article with push notifications changes for iOS 13.
https://onesignal.com/blog/ios-13-introduces-4-breaking-changes-to-notifications/
Probably needs to update push notifications template. Needs to add: apns-push-type: alert
Could you try?

[jbcaveman]

I thought that was a header requirement rather than a part of the payload, but I will try that out.

[jbcaveman]

I actually noticed some negative effects when adding that to the payload like {"aps":{...},"apns-push-type":"alert"}. And adding it like {"aps":{...,"apns-push-type":"alert"}} had no effect. According to this document, this is a header field.

https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns

Is there a way to add headers through the CLI? I tried "--apns-push-type 'alert' " but that of course threw an error.

[buh]

No worries. Looks like we should fix it on our backend side. I told our backend team to check headers. Probably will be fixed tomorrow on CET time.

[jbcaveman]

Thanks so much for working through this!

[buh]

@jbcaveman Push notifications for iOS13 should work now.