Since the April 1st 2021, my Apple push notifications with java-apns stopped working, i.e my devices wouldn't receive push notification anymore, while my backend server using the java-apns library wouldn't throw any exceptions... I've checked my .p12 certificates and they have not expired, so I am quite unsure as to what's happening?
Has anyone run into this issue?
As the java-apns github page says:
Warning
Apple will no longer support the legacy binary protocol after March 31, 2021. Java-Apns will stop working. See details in their announcement.
It is recommended to use Pushy instead, which supports Apple's HTTP/2-based APNs protocol.
So basically the library stop working, as it uses a protocol that us no longer supported and you can try migrate to Pushy or any other libraries.
Related
I have come to know that Apple has mandated to use HTTP/2 based Push Notifications for APNS from 31 March, 2021. HTTP/2 protocol for APNS has been added in IBM Mobile First version 8 and not supported in MFP7.1.
https://developer.apple.com/news/?id=uzyxiriy
My question is, as my already live application is present in Apple Store created using MFP7.1, will the push notifications generated from that application will not been delivered to the iOS devices from 31 March, 2021?
If yes, will there be any very quick solution except upgrading to MFP8 and which we can implement in 1-2 days in our MFP7.1 app?
Thanks in advance.
we are using Amazon Simple Push Notifications to push the notifications to APNS. We had our app certificate changed around December 2015 and missed out to update in AWS. Thus, the notifications is failed to deliver to user.
We update the certificate in AWS in June 2016 and we had user complaints that he received a lot of notifications. After we troubleshoot, we found that the notifications that user received is the notifications we sent between December 2015 to May 2016 but this should not happening as the notifications should be failed to deliver to user.
We had check with AWS and they mentioned that their services is to deliver the message to APNS and nothing much can do from their end.
Thus, we would like to request for help to troubleshoot for this issue.
There are few questions we would like to ask:
1. How long is the notifications will be cache if it do not able to deliver to user?
2. Is the notifications services have any retry mechanism?
3. Anyway we can reset/kill all notifications that we have sent to APNS?
4. Any possible scenario that the notifications will be keep for half year long?
STEPS TO REPRODUCE
We tried to use the following steps to reproduce the issue but we not able to reproduce the issue.
Revoke the push notifications certificate in app configuration.
Send few notifications.
Update the new push notifications certificate.
Test if the notifications sent after push notification is revoked will be received by user.
Recently, I want to change my codes of pushing notifications to apple from basing on old binary API to new http2 API. The question is that should I use a different certificate for this http2 API when I connect to apple ? Because when I send a notification to apple with a valid token(the token is valid when I send notifications with old API) using http2 API, it returns "BadDeviceToken". So I'm wondering whether the token is really bad or the certificate that I use is not qualified .
We were also trying to break our heads with such an issue where we were trying to send push to production device tokens using the HTTP/2 API but were getting {"reason":"BadDeviceToken"} as the response and it was a clear mistake from our side, we were using the same code that we were using for test push notifications on dev environment to send push notifications on production, which was sending push to
https://api.development.push.apple.com/3/device/
rather for production it should be
https://api.push.apple.com/3/device
Hope it helps somebody but one issue with the new API is the distribution SSL certificate works for both the sandbox and production, not the other way round so be careful.
You can still use your old certificate with the new HTTP/2 API.
The BadDeviceToken is most commonly because you are trying to push through their production gateway wth a development token or vice versa.
Tokens are only valid for either development or production, and this is determined by the provisioning profile of your app.
I developed a PHP backend for a mobile app that runs as an Bluemix CF app. I use custom PHP code to send push notifications via APNS. Everything works but the connection to APNS is extremly slow. The same app uses GCM for push Android devices and this works great. Any advice?
It is not uncommon to see a delay in APNs Push Notifications as seen in some of the other posts:
Apple's APNS Delivery is Sometimes Slow
How much delay of ios push notification?
In regards to PHP specifically I also found a post about delay in connection:
Pushing notifications using ApnsPHP is slow
Finally I will share with you a document from Apple showing the architecture of APNs in order to get a better idea of how and where the delay may occur:
Apple Push Service
We're getting an error in WebSphere's SystemOut log approximately every hour on our Worklight Server.
It seems to be trying to validate push notification configuration. We currently have working notifications, using Apple push notifications only. Errors are:
com.notnoop.apns.internal.ApnsFeedbackConnection getInactiveDevices
Failed to retreive invalid devices ava.lang.RuntimeException:
javax.net.ssl.SSLHandshakeException
Our notifications are working, but, what is this hourly process? I don't see anything in the docs regarding a batch process that's run by Worklight Server.
Our setup: Worklight Server 6.0.0.20130909-1459, WAS 8.0.0.6, JDK 1.6.
Worklight uses notnoop open source library to push notification to APNS. This is a known harmless bug in notnoop.
https://github.com/notnoop/java-apns/issues/29
I believe this check is part of the way APNS's feedback service works.
From: Provider Communication with Apple Push Notification Service
Section: General Provider Requirements
Connect regularly with the feedback service and fetch the current list
of those devices that have repeatedly reported failed-delivery
attempts. Then stop sending notifications to the devices associated
with those applications. See “The Feedback Service” for more
information.
As for what it means, it looks to me like your exception quote is cut. Is that all of it?