In my iOS application, I have implemented Push Notification. All working fine except some time push comes twice.
I am using Adhoc Builds with Distribution certificate. In Back-end we send request to APNS only once. Also, we request APNS Production server for any calls
I have googled it but didn't find any solution. Can any one confirm me if this is iOS bug or not.
Also, this is random behavior. As about 80% of time I get two notifications for single event.
Any help would be appreciated
My guess is that you have two different tokens registered for the same device, which causes the server to send the notification twice (one for each token, resulting in two messages being sent to the same device).
Push tokens don't usually change, but they can. This can be a result of re-installing the app, changes in the operating system or any other consideration not fully disclosed to us as the app's developers. That is why Apple indicates that you need to send the most updated version of the token whenever the app is launched.
In your case, it's possible that the token changed for some reason and even though you are sending the notification once for each token, you are sending it once to each of the two tokens representing that device. The explanation for why you're only receiving double messages 80% of the time, is that in the remaining 20%, the messages are sent so close to one another that the operating system (or Apple's servers) are blocking them and only sending one.
Can that be the case?
Related
So I'm running into a peculiar problem that I have not been able to find much information on. Looking for any input or experience at all.
I have recorded the deviceToken of an existing app install using Urban Airship. Then deleting the app and reinstalling, I recorded the new device token as well. These tokens are different. From the UA test panel, I am able to send a test push to both of these tokens and the device receives 2 pushes, one for each token, even though the first token has since been uninstalled. But, in UA device lookup, both tokens are marked as active.
This was only caught after getting our push server running which triggers a push once every morning at most, based on a hosted file that determines the push contents and if one should happen. My development device is now getting up to 8 pushes at once from the server.
There are ways to unsubscribe or unregister for push notifications with Apple, UA, and the server, but I'm wondering on the best practices for this. There is no way to get the uninstall event either which would be the only time to unsubscribe. Is the best solution just to wait for UA to determine a token is inactive? I have found this list here for reasons a token could be inactive: http://docs.urbanairship.com/reference/troubleshooting/ios-push.html#inactive-device-token
But none seem to apply here, especially because some of these device tokens are nearly a month old and still sending to my test device. The app uses an Enterprise profile so this is happening in a production environment.
Are you getting the same channel every time? Usually reinstalls will generate the same channel which is tied to a single device token. Then when apple generates a new token it will update the channel's token. You are probably better off contacting support directly. They will be able to help gather all the device info they need and look up registration and push records to figure out whats going on.
I have an app-server process that needs to check if the device making a request is an actual iOS device. I used to do this by taking advantage of push notifications. The user first authorizes push. Each time the user makes a specific type of request, I push a code to that device with which the app uses to make a second "authenticated" request to the app server. That additional channel of going through APNS would, in a sense, prove the authenticity of the requester's device. This makes it difficult for a person to spoof the request because they would not be able to receive the push notification with the needed code.
Recently though Apple started enforcing the rule that apps cannot require the user to accept push notifications in order to use the app, even though we do not use push notifications for alerts.
Is there any comparable way for my app server to check with Apple that a request is coming from my app on an actual iOS device? Or is this an unrealistic expectation to be able to determine this.
I could not find the article now, but some guys managed to register raspberry pi as a iOS device and receive push notifications via wifi... that I believe would be concrete proof that not even your first "2 way authentication" is really safe...
Now, directly answering, NO, there's no way for your app server to check if the request did come from a iOS device because all info in a TCP/UDP package is 100% "spoofable"...
We have a (mostly) successful implementation of push notifications to iOS and Android devices through Azure Notification Hubs.
The problem is that some of the iOS devices are apparently never receiving notifications that are sent by Azure Notification Hubs.
We use templates and tags to direct the messages to the appropriate devices. The tags are interest topics, and never user-specific, so we're expecting one notification for a tag to be pushed to all devices subscribed to that tag.
The Android devices seem to receive their notifications flawlessly, but the iOS devices are not consistent. Most of them work. A couple do not.
We are well aware that push notifications are delivered with best effort and have no guarantee of reliability, but our limited testing has revealed more devices which consistently fail to receive push notifications than seems unreasonable (more than two failures from about a dozen devices).
Here's the setup:
We have a simple C# routine in the back end which connects to Azure Notification Hubs and sends notifications to Azure:
var outcome = await hub.SendTemplateNotificationAsync(properties, tag);
We have used the GetAllRegistrationsAsync method to make sure that every device we are checking has successfully registered and is using the correct template. Every device is registered, all the templates are correct.
We are not in "test mode"; the enableTestSend parameter of NotificationHubClient.CreateClientFromConnectionString is set to False.
Troubleshooting:
When we send the notification out, most devices receive the notification and, in the specific case we're testing, update the badge counter with the correct number.
However, a couple of devices do not seem to get the notification. One of the devices did get the notification after we rebooted the device, but after that it stopped.
Using the above mentioned GetAllRegistrationsAsync method, we have verified that the problem devices are correctly registered on Azure and have the correct tags and templates.
We were able to determine the device tokens of the problem devices from the Azure registrations. We used a PHP script which communicates directly with APNS to send a notification just to the problem devices using their device tokens. Every time, the device receives this direct-send notification. It's only the notifications from Azure which are unreliable.
When we examine the Azure Notification Hub Monitor page, we see these metrics for the past 24 hours:
967 APNS Successful Notifications
3 APNS Bad Channel Errors
2 APNS Expired Channel Errors
4 APNS Errors
... and no other errors reported for APNS or for Azure in general. The failure rate we're seeing should have produced an error count over 20.
We have not been able to determine which device tokens were responsible for the errors; is there a way to get this information from Azure?
We're at a loss to explain why we can send notifications directly to these devices over APNS itself, but not through Azure, and why it is that Azure doesn't report more errors than it does.
Any suggestions or insights?
It's quite possible that you have some sandbox device tokens in your database (I'm not sure if the device tokens are stored in your server or in Azure Notification Hub). When trying to send a notification with a sandbox device token to the production push environment, an InvalidToken error is returned by Apple, and the connection is closed.
Very often, by the time the server that sends push notifications to Apple's APN server gets the error response, it has already sent many more notifications (possibly with valid tokens), and all of which are discarded by Apple. At this point, new notifications are accepted by Apple only after a new connection with APNS is established, so messages that were sent after the invalid token to the old connection need to be resent. It is possible Azure don't handle this resending correctly.
As you said, the Azure Notification Hub Monitor page shows a few errors. I suspect that 3 APNS Bad Channel Errors means invalid device tokens. I don't know how many invalid device tokens you actually have in the DB, but even one can cause many notifications with valid tokens not to be accepted by Apple.
The best solution is to test all the device tokens in the DB and figure out the ones that are invalid and delete them.
We have 2 apps setup for Push Notifications. (A and B)
There are different profiles for each (of course) and we've generated separate certs for each.
App A receives Push notifications just fine, App B doesn't.
Both are talking to the same server - and it does figure out which app it's sending notifications to and uses the correct cert.
I've noticed that if you install both apps on one device, they both get the same Token (which our server tracks per app.). When the server sends a msg in this case, it sends it twice to the same Token - once with each cert. App A will receive the msg, App B won't.
When sending the msgs to both apps, the Apple server responds that all messages were sent correctly with no errors. But the msg never shows up for the one app.
Any suggestions on where to look?
After much searching and looking, I found this question: Iphone - Multiple Apps, Different App ID, Same Token
It points out that you must use a different .certSigningRequest for each app. I checked with our AppStore guy, and he had used the same one for both certs. He fixed that, and now it works!
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.