I'm currently using Pushwoosh as my push notification provider for iOS push notifications. What I'm noticing is that it takes on average 10-15 seconds to receive notifications after they are sent out. What I want to know is if this number is a normal number given the amount of traffic that Apple receives to their APNS servers? What kind of speeds do you get using Pushwoosh or other services? Is it time to switch to something more reliable, or is this just the nature of APNS no matter what provider I go with?
Pushwoosh is very cheap and affordable, but I'm starting to realize you get what you pay for, and that's not quality.
There are several possible problems
Your connection to pushwoosh.Just ping Pushwoosh API gateway cp.pushwoosh.com
Some delays on pushwoosh side.Send message, then go to https://cp.pushwoosh.com/notifications and find your message in the list, it must be first from the top. Status of the message can be pending, processing or done. In pending status your message is not being sent right now. It means that pushwoosh servers are currently very busy(really rare situation). When status becomes "processing", pushwoosh starts sending notifications to APNS immediately. In normal situation you should receive notification before your message becomes "done" in pushwoosh control panel. if not, see 4
Device connection.Even if you are sure that your device is connected to the internet - check again. This is the most common problem with delays.
APNS delays.I do not know 100% way to diagnose this, but if message status in pushwoosh control panel is "done" and you are sure about (3), there are some delays on APNS.
P.S.
If my reply will not help, feel free to contact Pushwoosh support(http://www.pushwoosh.com/contact-us/). They will investigate your case more closely. But do not forget to send them messageid of delayed message(you can find it on notifications page)
It seems to depend on speed, sometimes a PHP call directly to APNS comes up right away other times it can take upto 15 seconds sometimes longer i would put this down to communication link with the handset and Apple Servers.
We are currently using a Drupal module for sending push notifications and they're delivered almost instantly. (2-5 secs). I don't know which one, but if you're interested I'll ask my colleague...
Related
We use push notifications in our app. They work, but there's some variable delivery delay (sometimes ~10seconds, sometimes more than minute).
Does anybody know what to do to minimize those delays?
I know APNS has some delay, but I've never experienced such slow deliveries.
EDIT:
I digged out some time delay between message sent date and push created date.
I have message sent at 12:40:17 (according to QB's admin panel)
and push notification log for the same message says the the push is: "created_at":"2016-05-12T12:40:28Z"
Clearly we have 11 seconds difference between the time message is sent to QB and push notification being sent to APNS from QB
Push notifications are unreliable and cannot be guaranteed that they have been delivered. It all depends on the apple APNS server, that said, usually when I send a push notification I get the result in under a few seconds.
They are not reliable! ****There is no guarantee that push notifications will actually be delivered, even if the APNS server accepted them****.
As far as your server is concerned, push notifications are fire-and-forget; there is no way to find out what the status of a notification is after you’ve sent it to APNS. The delivery time may also vary, from seconds up to half an hour.
Also, the user’s iPhone may not be able to receive push notifications all the time. They could be on a WiFi network that does not allow connections to be made to APNS because the required ports are blocked. Or the phone could be turned off.
APNS will try to deliver the last notification it received for that device when it comes back online, but it will only try for a limited time. Once it times out, the push notification will be lost forever!
For what it's worth I am running into this issue too with Quickblox. The push notifications, a critical part of the communication flow, are delayed by up to a minute or so. I use push all the time in enterprise apps and yes, they should not be considered reliable, but in practice APNS communications are remarkably reliable and near instantaneous in my experience. It seems like Quickblox is queuing (throttling?) notification requests, my guess is to conserve bandwidth - aren't they based in Russia? It's spoiling what would otherwise be a great product.
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.
I think I had once seen a way to tell the Apple Push Notification Service to re-send notifications that were unsuccessfully delivered on their first attempt. Is there a way to do this and can you point me to some information regarding this?
My goal is to send a notification to 100 people and if 10 of them fail to be delivered, have those 10 failures retry.
Unfortunately, as far as I know, no such functionality exists directly. You can check that the notification time to live is long enough, go with a persistent notification solution (Urban Airship), or do your own delivery verification and redelivery through some back end service of your own which would work with Apple's feedback service.
If a delivery failed (APNS connection is lost), APNS would attempt to deliver only the latest notification when the connection to APNS is re-established. Your other notifications would not be delivered if this is the case. If you are looking for something persistent, look at Urban Airship and similar services (Pusher may be another, though I have not used it) that offer functionality similar to an e-mail inbox for various mobile platforms including iOS.
If you're seeing issues with the latest notification not making it through, you might want to check that the TTL is not too short on that notification. That's all that comes to mind.
I want to create an iOS chatting app using APNS. If I have 10,000 active and they are continuing chatting, will apple block my developer account ? Is there any limitation regarding this?
I would discourage you from using APNS as a backbone of an "chatting app".
If you need fast chatting functionality you should write your own TCP-socket based server.
If every-few-second syncing is o.k. you can get away with a HTTP-based server backend (but all the pull-syncing can be hard on network traffic - so TCP-socket is still better choice).
You could however use APNS for fallback - when your app on certain device is not responding (i.e. is not connected to server) you can send an initial message trough APNS (to wake up your app & to notify the user there is a message waiting for him).
As soon as the user opens your app you should switch back to your TCP-socket or HTTP request based server communication.
As for your question: no, Apple would most probably (one can never know for sure) not reject your app just because of using APNS for chatting. But note (as the others said allready): messages between two users will get "lost" if they would interact too frequently - see the link Roman Barzyczak gave you.
"If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one."
more information: http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
but Apple wont block your developer account :)
You can use them for messaging but you are going to quickly find out that there is no guarantee they will arrive. This is known as the black hole of push notifications. ;-)
I like this answer here.
First try to use an APNS only solution.
Make your push notifications stateless (they only serve as "Hey you have some new stuff in the server").
So when the client gets a push notification it asks the server for new data (messages or other stuff).
Use OneSignal to simplify the code that sends push notifications (from the back-end). If a user in your app gets a message after 10 seconds he dose not care if you used TCP,socket.io or xmpp...
Even Whatsapp's messages can take couple of seconds to arrive.
A chat app is not a realtime game. A delay of couple of seconds will be acceptable by end users.
My company offers an iPhone app for day traders which basically tells them when it's a good time to buy or sell. A cluster of servers generate these BUY and SELL signals and need to be delivered to a customer's iOS device in a minute or less. For all other mobile clients we've developed, we are allowed to poll the server in the background (once per minute), to check for updates.
In iOS, however, it seems that doing anything in applicationDidEnterBackground that has to do with times or polling isn't an option.
This led me to look at push notifications, but from what I am reading, they aren't reliable. They employ a send-and-forget methodology, which there's no guarantee they will be received.
You can see the problem with this. If we issue a BUY signal and the user acts on it, then a SELL signal is generated 10 minutes later and send via push, but never arrives, they could lose a lot of money.
So, is there a good way to do this or am I out of luck? Thanks!
There are two intermediaries between your server and the user's device: a) Apple and b) the network.
Apple does not guarantee the delivery of all notifications; only the most recent is guaranteed to arrive and only for a limited period of time. For more information, check out the "Quality of Service" section in Apple Push Notification Service.
If the device is accessing the network through a mobile carrier, things may get ugly. I have experienced situations where, some notifications didn't arrive until much later, and some got lost entirely. From my experience, carriers protect -with zeal- the quality of their own services, rather than those of third parties like Apple. An SMS/MMS will not normally be lost, while a push notification might.
Polling the server would be a viable alternative for your app. Alas, Apple doesn't allow networking operations to take place for apps that have been put in the background state (except for Newsstand downloads and VoIP).
Some apps seem to do push notifications really well (GroupMe) while others don't. If you're really worried, you could use a service like Twilio to send the user an SMS message with a link that would open your app and give it some information. So the SMS could say "SELL SELL SELL yourapp://stock=APL" or something like that. This obviously won't work for iPod touch users or iPad users (although I don't know if that will be a problem for you.
Try using Apple's own push notification service: http://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
It's quite easy to implement, with just a few lines of code in the application and a bit of PHP and JSON on the server to do the sending. The good thing is that your server sends the request to Apple, and Apple's own servers handle the delivery to the device securely and reliably. Notifications are usually delivered within 10 seconds of being sent (unless the device is offline, then it will be delivered when the device comes online).
From my experience with push notifications, I haven't lost a single one, and there is a delivery option that continuously attempts to deliver it until it is successful, and there is even a server side callback API of some sort available that lets you check the status of your notifications. You could also try a service like Urban Airship to do the work for you.
You could also try using one of Apple's background modes as part of this (such as receive the 'BUY' as a notification and have the app wait for the 'SELL' in the background. The biggest limitation is that the app can only run in the background for about 10 minutes at a time, so you would have to use a workaround like playing music in the background (or making stock announcements like a music track ;P), or prompting the user to reopen the app to continue the background session.