It’s my understanding that the mobile operating system is supposed to automatically handle the display of incoming push notifications as a banner or as an alert prompt, but no banner or alert appears, even though permissions are set to “granted”. Incoming push notifications are however being received by Expo’s Notifications.addListener … so I’m confused why the expo app’s listener is working but the operatingSystem’s listener is not???
expo v25
ios 11.1
expo ios client app @ latest
Could it be that you have the app open?
When the app is open, you have to handle the notification yourself and display a banner.
I think the OS banner and alert only appear when the app is closed.
This is just the way iOS works. You don’t see any UI for push notifications from the app that is currently foregrounded. If you want to display something you have to do it yourself.
This isn’t a thing about the way Expo works; it’s just the way that iOS works.
https://docs.expo.io/versions/v25.0.0/guides/push-notifications.html#notification-handling-timing
according to the docs at the link above, the iOS banner/alert is supposed to appear even when the app is closed, but to clarify on your question, i tested on all scenarios, spanning 2 days:
foregrounded and backgrounded scenarios successfully trigger expo’s addListener method (expected), but all 3 scenarios fail to trigger iOS’s listener and display a banner or alert prompt notification (not expected)
However, around 2am last night while I was sleeping, iOS did finally display a very small percentage of the number of requests I sent out. So either these requests were queued up and backlogged by Expo, or they were queued/backlogged by Apple. I suspect it was Apple though, not Expo. I suspect Apple was doing some throttling, but 1 or 2 days late? That seems excessive, especially when I am setting ‘priority’ to ‘high’. I am now setting TTL to 48 hours to account for this, but for many push notifications, if they are not timely, they lose their importance and relevance. This still does not address the issue that only a small percentage of requests are triggering iOS’s notification listener.
didn’t matter whether the app was foregrounded, backgrounded, or closed… it still failed on all scenarios. I get that it’s not expected when foregrounded, but when closed or backgrounded, it is expected. for example, when backgrounded, expo’s listener receives the notification just fine, but iOS’s listener does not, and on the rare occasion that it does, it’s sometimes 1 or 2 days later, even when ‘priority’ is set to ‘high’. I am now setting TTL to 48 hours to account for this, but for many push notifications, if they are not timely, they lose their importance and relevance.
The way Expo currently handles push notifications is that we immediately deliver the notification to Apple and Firebase. For iOS, Apple tells us whether they have received the notification and then we send you back “status”: “ok” in the receipt for that notification; this means Apple has successfully acknowledged receipt of the notification and everything from there on out is in Apple’s control and responsibility and delivery behavior you see is how iOS and APNs just work.
So just to clarify, since Expo sends notifications to Apple as fast as possible it’s likely that the queue backlog was in Apple’s infrastructure, and if you got back “status”: “ok” then you did everything right and Apple got your notification (and they will try to deliver it).
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.