Stop the push notification - ios

My app push notification pushing from C# Application using device token.
Once user uninstall app on device, I want to stop the push notification. Yeah of course it's working fine.
Again installed same app. But it is receiving previous user notification without login.
How to solve this problem?…
I have refereed this link http://42spikes.com/post/Sending-Apple-Push-Notifications-from-a-C-Application.aspx
My Question :
1) Is it possible to call any method while uninstalling/installing time? (possible means can I hit web services and reset device token value?).
2) Any Other idea to solve this problem while installing or uninstalling time?

No, there is no method fired when a user uninstalls your app.
Yes,
Apple has a service where you can check wether tokens are still
valid.
The option you want to implement in your C# Application is The Feedback Service:
The Apple Push Notification Service includes a feedback service to give you information about failed push notifications. When a push notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device’s token to its list. Push notifications that expire before being delivered are not considered a failed delivery and don’t impact the feedback service. By using this information to stop sending push notifications that will fail to be delivered, you reduce unnecessary message overhead and improve overall system performance.

Related

VOIP token won't get invalid after uninstalling an app from a device or disconnected from the network in iOS

I am working on one VOIP-based application where one user calls another user everything works fine like calling and all.
But whenever I didn't log out from the application and directly uninstall the application at that time any another user tries to call the user who already uninstalled the application. At that time backend get a successful response from apple (i.e. 200 Success). Why won't give an error if that app is not installed
Actually, we need to give some specific alert to the user who called the person who already uninstalled the application but we are unable to find from backend too that the voip push failed.
One another thing just for testing : We tried to send FCM silent notification too which works synchronously with VOIP notification but in that too FCM gives success in backend while app already uninstalled from device.
If anyone facing same issue and having solution regarding that then please let me know.
In the short term, Apple doesn't know that the user has uninstalled the app, so it accepts the push.
Pushes are delivered asynchronously (Since a device may be offline when you send the push; it will be queued for delivery later).
The APNs cannot provide immediate feedback on the delivery of your push. The 200 status simply means that the push was successfully accepted for delivery.
Eventually Apple will determine that the push token is invalid and return a 410 response. At that time you can remove the push token from your database.
In the short term you can detect if the device doesn't respond to the VoIP push in a reasonable time frame and return a "call failed" or "recipient unavailable" response to caller.

is there a limit when sending push notifications to multiple iOS devices?

So, I have about 1000 iOS users installed my app.
I tried to send push notification to these users thru my app's backend panel, however, my devices did not receive the push notification. I also asked some users, and some of them said they did receive the push notification and some did not.
I was wondering why not all of the 1000 iOS users receive the push notification successfully.
At first, I thought it has to do with my applications, because my device has the latest update that is yet to release to public. So I went on and delete all the device tokens I got, and register my device again to test the push notification.
This time, my device received the push notification from backend panel successfully. So, I am sure there is nothing wrong with the coding part on receiving push notifications. (I ran multiple test on this and sure that push are send and receive successfully)
It only happens when I tried to send bulk push notifications to iOS users.
so, is sending push notification has a limit? like it only allows to send may be to 100 users?
or may be there are invalid device token so that pushes are stopped before finish sending to all users? but in what situation device token become invalid? will uninstalled user's device token may be a cause?
In our experience notifications have far from a 100% delivery rate, and that's with only between 50 and a 100 installs across iOS. In theory there is no cap set in place.
The only limits I'm aware of is sending an identical notification to the same device multiple times within a short window of time.

What is the best way to keep updated the info of an iOS App?

Since push notifications may not be delivered sometimes (you can lose a few of them), you can not run code after the iPhone is turned on to check if there is new information available from the server, and you can not run code if your iOS App is closed... What can you do if you want to be as more accurate as possible in for example a Chat App in iOS?
I mean, inform the user as faster as possible that he has new info available. Comparisons: WhatsApp is updated without any delay.
You can do background fetch if your App is in background. But if the App is closed and you miss a push, it's not going to be up to date until the next push arrives or user opens the App. The same with silent notifications. If the app is terminated by the user, you are not going to receive it. Is there any way to solve it? It must be because other Apps do it... If there is any "private and secret" API that they are using (I read about this answer when no one know how to do that)... Is there any way to apply to use it?
UPDATE:
I'm using push notifications. The goal is to fix when a push doesn't arrive. Example: User A send chat message to user B. User B doesn't have the App open. The system lose the push. User B is not going to receive the message until he open the App.
Push notifications seems to be your only way even if you do loose a few of them, which I don't know how you would since they are pushed to apples secure server... but what do I know. As long as the user turns on the push notifications you should be fine. They may be delayed due to apples way of handling them. Honestly push seems to be the future, having your app constantly every minute or two check for new messages is a huge battery water in conjunction with normal texting apps. Your app should provide the best live data but since apple restricts to push notifications when the app is off or not running just stick to push notifications and only push major events to the user. I believe you can set up a job scheduler using quartz or schedulator to setup your server to push notifications to your app.

How to know Push Notification delivery status

I am using push notification in an app. Everything is going fine.
Sometimes message sent from server but in app side it does not receive.
In this situation I have to know which message is missing to deliver(app did not receive).
Is there any way to know from server side which message is received by app and which are not?
Nopes, push notifications are fire-and-forget.
Apple will not tell you the following:
Will not tell whether the message was sent successfully or not
Will not tell if the user has opted out of Push Notifications
Many other things but anyways...
However
On the other hand, when the user has opted for Push Notifications then your app can handle this but to a certain extent:
Basically, you could add logic in the -didReceiveRemoteNotification: and -didFinishLaunchingWithOptions: to contact your server and tell your server that the message was received.
If it wasn't received within a particular time slot then you can resend it.
But as you see, this could lead to a possible scenario of flooding an innocent user with the same push notifications.
In a sense, harassing him to tap your stupid push notification, which in turn may lead him to switch off push notifications for your app entirely but mostly he would delete the app and maybe even give it a low rating?
Serves you right, I'll say.
Anyways, if you go ahead with this, you would need to implement an identification pattern where you insert a unique message identifier into the payload of the push notification and when your app gets this push notification, it should send this message identifier back to the server.
Your server should then log that a particular device token returned a message identifier, which means it received that particular push notification.
Your server can check on a hourly/daily/whateverly basis and resend a particular message to those device tokens that have not reported back with the relative message identifier.
Again, this means your server might need to work OT sometimes.
There are other issues with this whole approach:
User received push notification but dismisses it rather than opening your app with it
Your server will assume the user did not see the push notification and will send this push notification again
Ghost device tokens
User accepted push notifications at first but later revoked this privilege
User uninstalled the app
Basically, device tokens that once use to receive push notification but no longer do, most probably due to your message flooding reputation
User received push notification but taps it at a later time
might get same push notification multiple times (very irritating)
User received push notification but taps it when there is no internet connectivity
User received push notification but your server is down, possibly fried \m/
You can circumvent the last 3 scenarios by having even more logic in your app that queues the message id's that are to be sent to the server and removes it only when the server responds successfully.
So you see, too much work, server-side + client-side.
Plus it's a massive performance degrader on the server-side when dealing with a good volume of users as well as lowering the performance of your app by a wee bit.
The Feedback Service
The Apple Push Notification Service includes a feedback service to
give you information about failed push notifications. When a push
notification cannot be delivered because the intended app does not
exist on the device, the feedback service adds that device’s token to
its list. Push notifications that expire before being delivered are
not considered a failed delivery and don’t impact the feedback
service. By using this information to stop sending push notifications
that will fail to be delivered, you reduce unnecessary message
overhead and improve overall system performance.
Query the feedback service daily to get the list of device tokens. Use
the timestamp to verify that the device tokens haven’t been
reregistered since the feedback entry was generated. For each device
that has not been reregistered, stop sending notifications. APNs
monitors providers for their diligence in checking the feedback
service and refraining from sending push notifications to nonexistent
applications on devices.
1. If you are asking about notifications not delivered on a device which has application installed on the device and just because of notification getting expired before it is delivered or something else, notifications are not delivererd.
Then the answer is
Nope.
It does not provide support where in you can check if the Notifications is expired and not delivered on a valid device:
any option to know if apple app get the push notification?
Refer to Moshe's answer in above link. I am including his answer here so that it is useful to everyone in future even in case the link becomes dead.
The short answer, you can't, since APNS is one way. However, since an
app can execute arbitrary code upon receipt of a notification, you can
use this to say, send an http request to your own server when the
notification is recieved.
2. If you asking of the notifications not delivered as user has uninstalled the application then you can refer to meda's answer in this post.
Hope this helps you and let me know if you have any queries regarding my explanation.
You can get the the delivery report of Push notification, Not from server but from your app, using "Service Extension" and modifying little bit in your Push json. Checkout this link for detailed explanation.

Will Apple push notification feedback service report devices that call unregisterForRemoteNotifications

The documentation specifically states that the feedback service will report devices where the app has been uninstalled and won't report devices if the push merely expired.
My question is, will it report devices that have the app installed but the app called unregisterForRemoteNotifications (e.g. the user "signed out" of the app)?
Documentation:
APNs has a feedback service that maintains a per-application list of devices for which there were failed-delivery attempts (that is, APNs was unable to deliver a push notification to an application on a device). Periodically, the provider should connect with the feedback service to see what devices have persistent failures so that it can refrain from sending push notifications to them.
Source: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html#//apple_ref/doc/uid/TP40008194-CH1-SW14
The Apple Push Notification Service includes a feedback service to give you information about failed push notifications. When a push notification cannot be delivered because the intended app does not exist on the device, the feedback service adds that device’s token to its list. Push notifications that expire before being delivered are not considered a failed delivery and don’t impact the feedback service.
Source: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3
My answer is YES, APNS does have this service in place along with its feedback service, mainly because the server triggering the push service will have to be notified back to stop sending push notification to the devices which have manually opted out of push notification service.
And since there is no way this information can reach back to the server directly except through APNS, APNS manages to hold this information to provide it back to the server.

Resources