Is there any alternative then Push Notifications on iOS - ios

Push notification has some drawback eg:
1. It doesn't revert if its delivered or not
2. If device was off the push notification arrives in bunch. (I don't need the old push notifications if device was off)

For the purposes of displaying messages to users who do not currently have your app open, there is no alternative to Push Notifications.
However, each of the drawbacks you mention does have a solution.
Determining delivery status
There are 2 possible reasons a notification will not be immediately delivered.
The device has uninstalled your app
If the device has uninstalled your app or opted-out of notifications, Apple will return the failed recipient device token through their Feedback Service protocol. In the newest HTTP/2 version of APNS, the failed recipient token will be returned as a response to your HTTP/2 connection.
The device is turned off or does not have a network connection.
Apple will attempt to deliver your most recent notification to the device when the device comes back online. If determining delivery status is essential to you, then you can supply the Content-Available flag and have your application report any successful deliveries of notifications.
Managing notifications when devices are turned off
By default, Apple will deliver only the one most recent notification per application when a device is turned on. This prevents the possibility of a user receiving a deluge of notifications from any single app when they turn on their device.
You can also prevent Apple from delivering old notifications by setting a TTL value. If the TTL expires before Apple is able to successfully send the notification to a device, the notification will be discarded.

Related

Silent remote notifications treatment on iOS, when there is no internet connection

I have seen this post What happens to push notifications after losing internet access?
but I am not 100% sure it applies to silent notifications, as Apple indicates they are low priority. What I want to ask is, for silent notifications, (for app use, not for showing to user), will the silent notifications get cached if the device has no internet connection, and then once device reconnects, the APNs will retry to send it to the device.
Silent notifications are important for us because we want to deactivate some sdks we use in our app once the user has deleted their account from our website.

Push notification is not being delivered when iPhone comes back online

I'm testing Apple push notifications for our iPhone app. The app deployment target is 6.1 and the iPhone is running 7.1.1. We use Apigee as our push notification provider. The phone receives notifications when it's online via cellular and wi-fi, confirming that registration is correct on the app side and Apigee side. I turn on Airplane mode, push a notification from Apigee, wait 3 minutes, take the phone out of Airplane mode, and the phone never receives the push notification. I wait a few minutes (up to 30), then push another notification from Apigee and the phone receives the notification.
I've read Apple's Local and Push Notification Programming Guide and I've read Technical Note TN2265 Troubleshooting Push Notifications.
According to the troubleshooting guide, "Any push notification that isn't delivered immediately was queued for future redelivery because your device was not connected to the service. "Immediately" of course needs to take latency for your connection into account. Outlying cases would be beyond 60 seconds as APNs will time out at that point." This is why I wait 3 minutes. I also know that APNS queues a single message and I think I know that I'm not overwriting that message - unless latency/throughput with the APNS QoS queue is much worse than a few minutes.
In Apigee, in Message History, I see the notification that was sent when the phone was offline. It has a status of Finished with total sent: 1, total errors: 0. I also see a receipt under Data/receipts. This seems to indicate Apigee successfully sent the notification to APNS (but I'm not 100% sure). I verified that the notifierId from Apigee is the same for all notifications sent when online and offline.
Is there any technique I can use to see why the notification is not being delivered from APNS? Is there anything else I can check?
You are correct, if the Notification is showing no errors and a Receipt has been created, the message was properly delivered to APNS.
The only thing I can think of outside of any vagaries of APNS itself that can affect your delivery is if you set the "expire" property on your Notification. Have you tried to see if that makes any difference to your result?

Sending 10000+ push notifications but not all devices receive it

For our iOS news apps we send out more than 10000 push notifications to registered devices, but somehow not all devices seem to receive the notification. We have been doing this for years but recently we received user feedback stating they did not receive a push notification while they did register their device to receive them.
Our logs show that these specific devices registered successfully and that there were no errors sending the push notification, but somehow the APNS does not deliver the notification. We have seen that removing the app from the device and reinstalling it sometimes solves the problem but we are still concerned.
We think it must be Apple's service that fails to deliver the push notification sometimes, especially when it comes to sending large amounts of notifications. Any of you experienced this?
The Apple docs says this:
Important: Delivery of notifications is a “best effort”, not
guaranteed.
Have you checked the payload size? As per Apple's documentation, the maximum size allowed for a notification payload is 256 bytes.

APNS (Apple Push Notification Service) reliability

Our app uses APNS to receive Push Notifications. However, our client claims that some of their devices were not receiving notifications and argues to they 'must' make sure the notifications to be delivered 100%. But I have read somewhere that APNS is not 100% reliable and there should be cases which the notifications are not delivered.
I'm currently panic at how we could make sure APNS to received anytime. I have read that a case which may APNS not delivered (device may offline). But our test showing that even the device is online (Wifi or 3G), sometimes APNS were not delivered.
Is there any specific case which may APNS will not delivered? Or is there anything we (developers) can do with codes to make sure to receive all notifications? What I have done in the code is just registering the app to remote notification and write didRegisterForRemoteNotificationsWithDeviceToken, then throw the device token to our server.
Any help would be appreciated, for our client almost kill us if ALL of their devices not receiving APNS!
APNS is based on Apple Servers, and Apple doesn't give any guarantee on successful message delivery.
If the app is open (i.e. the user is using the app) while the notification arrives, iOS doesn't show a notification message, you need to handle it.
Notification shows up only when the app is backgrounded or killed.
Also implement feedback service on your server side; will help you get rid of old unwanted tokens (users who deleted the app or disabled notifications through settings).
Don't send too many notifications to a device within a short span of time, because APNS caches only 1 message/device (if the device is offline). So it can deliver the message when the device comes online. Am not sure how long the message is cached though.
Or just implement Pusher... http://pusher.com
We're facing the same problem. As everybody said, APNS is a best effort service so you can't be sure every notification will be delivered, but what you can do is to be sure of which ones have been received. This is what we're about to do. We register in our backend each notification que ship and the mobile app reports back each notification it receives. Then we set a maximum time of waiting for a notification to be received, if we don't receive the report back we try again.
I hope it might be helpful to someone (even 2 years later)
It says it quite clearly in the Apple Docs that it is not 100% gauranteed and nor should it be used as so. Its sent with "best effort".
As per Apple's guidelines, APNS is not 100% reliable service which means your app may not get push notifications from Apple servers due to some of the following reasons:
Device is offline
Your app is in the foreground state, you need to manage the push notification.
Note: Apple rejects apps which make compulsion to use notification services. (I have faced it in one of my App)
For more information, you can look into this answer
https://stackoverflow.com/a/25830955/3278326

iPhone - App Uninstallation notification

How can I get a notification from App Store or APNs when my iOS App gets uninstalled?
Also, if I send a push notification for the device where my App is uninstalled, what happens? Will Apple ban for such rogue Push notifications?
There isn't a way that your app will know if it is uninstalled. Also I do not believe there is anyway Apple will tell you if your app is uninstalled.
Apples Push Notification Service's FeedBack Service does provide a way to know if a device cannot receive a notification. However this does not guarantee that the device was uninstalled, only that it, for whatever reason, can not receive push notifications.
If a provider attempts to deliver a push notification to an application, but the application no longer exists on the device, the device reports that fact to Apple Push Notification Service. This situation often happens when the user has uninstalled the application. If a device reports failed-delivery attempts for an application, APNs needs some way to inform the provider so that it can refrain from sending notifications to that device. Doing this reduces unnecessary message overhead and improves overall system performance.
For this purpose Apple Push Notification Service includes a feedback service that APNs continually updates with a per-application list of devices for which there were failed-delivery attempts.

Resources