-
Notifications
You must be signed in to change notification settings - Fork 29
iOS - No 'DELIVERED' event for local notifications when the app is in the background #146
Comments
I can confirm this - Looking at this release status comment as a potential explanation:
|
Any updates on this? |
Here, we have the same issue when the notification is a remote notification from @react-native-community/push-notification-ios. We had to rollback to |
Just wanted to add a note here to say this is being looked into. |
Thanks for the status update :) |
Hi, looks like we have the same issue. |
@lbuljan am I correct in that the scenario is a trigger (local) notification, and you're waiting on the 'EventType.DELIVERED' to be sent when the app is in the background? I believe this isn't possible. For local notifications AFAIK, there's no listener provided by Apple to detect this. The other events are working as expected, and onBackgroundEvent does trigger for iOS. For example, if you have a notification with actions, and a user selects one, the 'ACTION_PRESS' background event will be sent, or if you receive a data-only message via RNFB |
@helenaford Yes, these are locally scheduled notifications. The issue here is that, as a workaround, the first scheduled notification is supposed to create notifications that will repeat every X amount of weeks (dynamic value based on the object the notification is being scheduled against) because Notifee does not support creating a scheduled interval notification with such flexibility. v0.12.3. can only trigger interval notifications the instant they are scheduled, not at a specific time. We have a heavy reliance on processing some things when the notification has been delivered - which works perfect on Android. Do you have any suggestions on how to go about this on iOS then? |
Sorry for the delay, the issue is we're confined to what Apple allows us to do. Let me look into this, and see if there's something custom we can do natively for iOS. @Salakar @mikehardy, not sure if you have any suggestions? 😅 Maybe there's something I've overlooked that will work "out-of-the-box", or how this can be handled on RN side. |
notifee is a local notifications package, right? It has nothing to do with cloud messaging, which is the only way you can maybe wake up your app on iOS related to messaging and notifications. So my assumption would be this is not the correct place to have any discussion of app code running on iOS when the app is not in the foreground. As soon as you leave foreground on iOS, there is a chance your app moves into quit state, and unless you have a mechanism to wake it up again, nothing runs, no handlers. Notifee is not in charge of any of those possible wakeup mechanisms. react-native-firebase/messaging module can be used to wake it up via a cloud message if implemented carefully. react-native-background-fetch module can be used to wake it up on a schedule if the user interacts with the app frequently enough for the iOS power miser to grant your app power budget. VOIP apps are woken up by calls. Background location and motion apps are woken up by physical motion. That is the list of all wakeup methods I know of. My recommendation (and what I've done) is implement react-native-background-fetch as well as react-native-firebase/messaging and also react-native-background-geolocation-android (though I have a legitmate use for location! if you don't, you can't do this). I send data-only messages on a regular schedule that fit my timing needs, and I receive other unscheduled wakeups with background-fetch and geolocation. |
Renaming this issue title because I think it could read as all background events aren't working. Not sure if this should even be closed because it's covering multiple things, which makes it hard come to any sort of resolution:
|
Thanks for the feedback, seems like there is no going around the iOS limitations in our case. However, you should definitely look into more flexible intervals as an improvement in the future. By itself, that improvement would allow at least 80% of the desired functionality on our end :) |
Hi @lbuljan - do you have any specifics on the API gap for scheduling flexibility between what exists now and what you would like to see? You may have mentioned this elsewhere - if so sorry and just say so - but if not, we'd be curious what customers perceive to be missing. Thanks! |
To explain our use case: Users can schedule reminders that repeat every X weeks or days (depending on the object the reminder is set against). After the reminder notification has been received, the user is supposed to receive repeated notifications in intervals of 30 minutes for 3 hours (so 6 more reminders). If the user does not respond to any of them, create an in-app reminder the user can action later (through AsyncStorage) on the last received repeated notification (the one 3 hours after the reminder has been received). If the user responds to the notifications (by actioning a specific thing within the app), cancel the 6 repeated notifications. For instance, if the reminder is supposed to show on Friday every two weeks, what I had to do to schedule that kind of notification is:
As you can see, the entire desired functionality depends on processing the notification when it is delivered. Works perfectly fine on Android. On iOS, however, if the first notification is delivered when the app is in background, none of the required processing is done - no interval notification is scheduled at that time. That's a bummer. The way I see it, if we could either...
...we could at least be sure that the core reminder notification will be received on both platforms every X weeks or whatever the repeat interval may be. I still see no way to schedule the 6 repeated ones without relying on processing the delivered notification, but that is not as important as making sure the core notification arrives on schedule. |
@lbuljan, we have almost the same use-case and the same issue in our app. On Android, a background notification is handled with no problems, however on iOS |
Docs now updated to reflect the limitation around 'DELIVERED' event. Please see https://notifee.app/react-native/docs/events. For any other issues mentioned here, please open a new git issue (if none exist for it). |
Hi there!
I am having a bit of trouble getting the onBackgroundEvent to work with the iOS version of our React-Native app.
The onForegroundEvent is triggered properly and executes the same onNotificationReceived callback as onBackgroundEvent.
Not only that but, on Android, both onForegroundEvent and onBackgroundEvent work perfectly fine.
It's just iOS that is not triggering the onBackgroundEvent, which is of crucial importance in our case (there is app logic tied to receiving the notification).
All the events are defined in the root of the application (index.js, imported from notification-listeners.ts) and the onBackgroundEvent callback is asynchronous, as can be seen in the code snippets below. The import is not the issue, as I have moved the code to the root index.js file with the same result - onBackgroundEvent is simply not working on iOS.
Are we missing something on the native side perhaps?
The text was updated successfully, but these errors were encountered: