Apptentive push notification not working always

[KSugunan]

We have recently implemented push notification in our application both the platform (iOS and Android) so that users will not miss any communication from customer support team and also users get notified when a new conversation is initiated through Apptentive Message Center. But we are seeing inconsistencies in receiving the push notification in iOS but this is working as expected in Android.
We are using latest version of Apptentive "6.1.0". And in the sandbox testing everything is working as expected in iOS. But after sharing a version through Microsoft App Center when installed the build, sometimes the notifications are fired . Sometimes notifications are received after 15- 30 mints and also many times we have noticed the notifications are not received in the mobile device.
Followed the instructions in Troubleshooting. Verified using NWPusher app and notifications are received without any delay. Also made sure the valid APNS certificate is uploaded in Apptentive portal. I don't see any issue with the way we have implemented in the code. The same build installed, pushes all notifications sometimes and sometimes it will not. Can you please guide me how to understand what's going wrong here ? Or is this feature having any known issues that the team is currently working on ? Any help will be appreciated. Please get back to me incase you need any additional information. Thanks.

[frankus]

You've more than likely done this step already, but just in case, do you have the Remote Notifications background mode enabled for your app?

Are you seeing any differences in delivery reliability with the app in the foreground versus in the background? And is there any chance that your app might be crashing in the background or is being force-quit between tests (this will disable background activity until the next launch)?

The "silent push + local notification" method that we use to deliver alerts does seem to be more vulnerable to Apple throttling or batching the notifications and unfortunately it's not something that we have much visibility into.

[KSugunan]

You've more than likely done this step already, but just in case, do you have the Remote Notifications background mode enabled for your app?

• Yes its enabled.

Are you seeing any differences in delivery reliability with the app in the foreground versus in the background? And is there any chance that your app might be crashing in the background or is being force-quit between tests (this will disable background activity until the next launch)?

• No. I don't see any differences in delivery reliability in FG and BG. I didn't observe any crash while app in BG. I have performed the same test case (App in FG , App in BG, Force closing the app ) in different devices, and as I mentioned in previous communication the test results were different . It's very much inconsistent .
• If we trigger multiple notifications back to back (Eg:- 3-4 conversations from Apptentive ) only one of them is notified to the user. This could could be the last point you mentioned ?

Also , In few devices only when the app is opened am seeing the notification banner. Before that its not received even after waiting for a very long time..

[KSugunan]

@frankus Can you please provide us more information on this. Any help will be appreciated. Thanks.

[frankus]

Sorry for the long delay in getting back to you. I'm just getting back into the push notification area of the SDK.

One thing I'm planning to experiment with is always sending .newData for the background fetch result. It's my understanding that sending .noData or .failed can cause Apple to throttle the delivery of the notifications.

I can let you know how that goes, but if you have time it might be helpful of you to try as well. The easiest spot to change this would be in getMessagesIfNeeded() in Backend.swift.

[frankus]

v6.2.0 changes the behavior to always return .newData after a background push. There is still a bit of a delay (30 seconds up to a few minutes) but I've seen push be much more reliable after making the change.