Silent push while user disabled PN settings?

[tinder-sgong]

Couldn't find it documented so asking here - according to this SO answer OneSignal wasn't able to deliver silent push if user disabled PN settings, although iOS allows it (https://stackoverflow.com/questions/36250931/how-to-send-a-silent-push-notification-if-the-user-disables-them)
Has this been changed? If not, could we make it so that silent pushes ignore PN settings?
I'm trying to use silent push to notify clients for data updates so this is a critical feature. Thanks!

[jkasten2]

@tinder-sgong The SDK does not have an option to keep the device subscribed to OneSignal if notification permission were declined at this time.

One solution that would work today if is if you created a 2nd OneSignal app to register the pushTokens with. You can get it the token from the addSubscriptionObserver even if the user did not accept notifications. You can use the OneSignal Add a device REST API call to register the device to your secondary OneSignal app_id for your silent notifications.

For SDK support, I believe we can add a .plist flag to still mark the device as subscribed even if they don't accept or disable notifications.

[hyouuu]

(lol used wrong account to ask the question)
Thanks for the quick reply! The solution looks pretty hacky - are there any plan to make silent pushes ignore device settings in the future?

[jkasten2]

@hyouuu The solution I noted is more of a current work around you can use today. I can expanded a bit more SDK modifications I suggested above.

By default the device should not be marked as subscribed if the user did not accept notifications. However for the silent notification use case apps who need to support this could add a .plist key. Something like OneSignal_content_available which would be a Boolean type. This would then need to be read in the getNotificationTypes function. A Unit test should also be created to ensure this works correctly in UnitTests.m.

I won't be able to get to this feature anytime soon however I would be open to reviewing a pull request implementing the above.

[hyouuu]

Thanks for the elaborations @jkasten2 !

[SMFloris]

Hello,

Has this been solved yet?

[krodak]

@jkasten2 any update on this one?

[rgomezp]

Closing issue. Note: request still under consideration

EDIT: you should use VOIP here

[hyouuu]

Does this mean OneSignal is not considering adding silent push support? VOIP is not the answer as the majority of apps are not VOIP apps by nature.

[jkasten2]

Limitations of content-available

content-available without VOIP won't start the app if the user has swiped it away from the recent apps list. So in this case the data message will be lost, this is why in general we don't recommend using content-available. Apple's intent was to allow app developers download a small data update in the background so any new information is available in the app right away. So it shouldn't be used for anything critical to your app.
https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CreatingtheNotificationPayload.html#//apple_ref/doc/uid/TP40008194-CH10-SW8

Recommendations

1. Let users know what is new / available

Most of the time you will want to display a notification, this way users know there is new information available in your app and should check it out.

2. Non-Interruptive Notifications

Depending on your app and use case you may want to enable Provisional / Direct-To-History push notifications by default so users silently get notifications shown to the notification center. These don't show as a banner or buzz the phone so they won't interrupt the user. Also iOS does NOT require the user to be prompted for this Provisional / Direct-To-History notification permission since they are silently added to the notification center.
More details here
https://documentation.onesignal.com/docs/ios-12-features

3. mutable-content Instead of content-available

mutable_content can be set on notifications to trigger a UNNotificationServiceExtension target which works for all visible notifications. Keep in mind this is it's own process separate from your app starget and some iOS APIs are not available, however this works even if the app is swiped away where content-available does not!
https://documentation.onesignal.com/reference#section-notification-content

Summary

In summary we recommend always setting a message body with a short message about your update with content-available on the push notification. If you also enable Direct-To-History all users will be marked as subscribed on OneSignal without needing to prompt them, notifications will just be shown in history only. You can combine this with collapse_id so you don't fill up the notification center with update notifications for your app.

@hyouuu The above is best practice so users are aware of updates, if the above doesn't fit your use case can you describe it in more detail?

[hyouuu]

Thanks for the elaborations @jkasten2 !

My goal is to send visible notifications with data payload so as the users see a notification, new data is available to the app at the same time so that: 1. The app badge is updated as well, 2. When user opens the app they can get the new data immediately. This fits your recommendation #1. However, the reason why I opened the issue in the first place is that when user taps disallow when the app prompts for PN, I still want to be able to send data to the app so it can update badge & data, but OneSignal would treat them as unsubscribed and not send anything to the app currently.

Just got to know #2 for iOS 12 - if that box is checked, would it work as a fallback automatically if I still ask PN permission and users disallow it? And if user allows PN then they will send as normal?

For #3, it seems like even if the app is still running in background, it won't be able to read data from the PN because only the UNNotificationServiceExtension is triggered?

[jkasten2]

@hyouuu To set badge values the user has to accept the notification prompt, or they have to turn on badges on for your app in iOS Settings if you haven't prompted or declined the prompt.

For 2. no, if you decide to prompt for notifications and they decline then they will be marked as unsubscribed since this will remove even the Direct-To-History permission. Before showing the iOS native prompt you can pre-prompt with your own custom dialog to, this way if they decline your custom prompt it won't opt them out of the Direct-To-History permission.

For 3. both mutable-content and content-available can be set on a push however I really recommend you just use mutable-content since this will be need to handle the cases when the user swipes away your app any way.
So since UNNotificationServiceExtension is it's own target and runs in it's own process you have to use an App Group to get the data shared to your main app process. See this Apple guide to do so.
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple_ref/doc/uid/TP40014214-CH21-SW6

[hyouuu]

Thanks again @jkasten2 ! Regarding #3, I saw Apple's doc noted You cannot modify silent notifications or those that only play a sound or badge the app’s icon. - it looks like it's really designed to modify the visual appearance of a notification rather than transferring data, so sounds kind of hacky? When user taps on the modified notification, will the main target's handleNotificationAction block still be called?

[silentninja]

Let's say i have a transaction page and a user makes a transaction with push notifications turned off, it looks awkward when the page doesn't update to notify that the transaction has taken place.

We do send an sms to keep a record. In our case we don't need to send an alert notification nor wake the app up as an sms has been sent already and the page gets refreshed in case when the user reopens the app, but we would like to keep the app updated too incase the user is looking at the screen. Silent push notifications seems to be the best option for us because even if you disable app background refresh and disable allow notifications, you can still receive silent notifications if your app is in FOREGROUND.

[TwunTee]

@jkasten2 I came across a similar situation as @silentninja. I wanted to send notification for new content updates on a list view, using sockets for a single page seemed like a overkill so i thought of using silent push and encountered this issue. An alternate way would be to send notification overriding the subscription status.