Update...before I ever posted
I actually discovered the solution before I posted this but thought I'd post it anyway in hopes of saving someone else's time.
As a last resort I tried deleting the APNs Authentication Key and reverting back to the certificate for the application in Firebase Cloud Messaging project settings. That fixed it. Below is the message I'd intended to post.
I'm attempting to push notifications to subscribers of a specific topic using Firebase FCM. According to the Cloud Messaging console the notifications are being sent but they're never received by a device subscribed to the topic. I'm also not receiving test messages sent via the console.
I've confirmed the following:
APNS is properly configured for my project. I was able to receive a
notification on a device using a testing site
(https://www.apnstester.com/apns/)
The topic is being subscribed to or at least subscribeToTopic doesn't
return an error.
I'm receiving a remote instance ID token.
I'm receiving an APNS device token
I've also tried:
Enabling and disabling swizzling (and yes, when it's disabled I'm
setting the APNS token)
Deleting and reloading my APNs Authentication Key
Updating the Firebase framework
Removing and re-adding the GoogleService-Info.plist
I should point out this is old app (hence the Objective-C swizzling) and notifications worked fine in the past. Any suggestions or advice?
Related
I'm using "twilio_voice" for a flutter application for generating and receiving call from app to real number and vice versa.
When I'm trying to call to a real number from app it's working fine. But when i'm trying to receive call within the app, it's not working.
When I checked at Twilio console I found "Error 52134 Invalid APNs device token".
I have already created the VOIP certificate in Appstore console and also generated a Push Credential in Twilio console. The SID also used in the backend.
In my applog I also found "Successfully registered for VoIP push notifications." as a confirmation.
But still not working.
After your app has register for the push notification, you will need to create a binding with the Push Token to the Twilio server. For that you will need an intermediate server of your own(Can be a Node js/PHP/Python server application). First you will make a rest api request to your own server from the app. The server application will send a binding request to Twilio server. Once that is done, you will receive push notification every time there is an incoming call via didReceiveRemoteNotification() delegate in AppDelegate.
For the server application sample and Rest api sample for iOS app, follow this documentation from Twilio:
https://www.twilio.com/docs/notify/register-for-notifications-ios
Got the solution.
The issue was in the registering device. I was sending fcm token to the server for registering device. But after changing it device UUID, it worked.
Also point to be noted that, you will need a different SID from Twilio for development and Testflight. SID from Sandbox credentials won't work if you running app from TestFlight.
I've added Push Notification to my IONIC App using this tutorial: Using Push Notifications with Firebase in an Ionic + Angular App.
For Android all works fine, but on IOS notifications are not delivered. In my Firebase console there is an information that notification was sent, but nothing appeared on my IPhone. The app is installed by TestFlight (Internal Tests).
Questions would be:
How can debug or somehow detect where might be the problem?
If there is no way to check it, maybe there is a list of common problems with that?
Check if iOS push notifications permissions are enabled
Check to see if you receive a push notifications token when you run your app (it doesn't work on simulator, must be real device)
Register push notifications key on your apple developer account and add the key to your firebase app.
Push notifications on iOS is a bit tricky. This tutorial helped me: https://devdactic.com/push-notifications-ionic-capacitor/
Check on the client that it sends a push token to the server.
Check on the server if any errors are reported when pushes are sent to apple.
Check in the console logs whether and pushes appear on your client device.
Check in the app if any push notifications are received.
In addition to following the advice already listed and assuming that you have followed the linked tutorial in detail, what helped me to understand the problems related to my experience with push notifications is to check the validity of the token received from the
// On success, we should be able to receive notifications
PushNotifications.addListener('registration',
(token: PushNotificationToken) => {
alert('Push registration success, token: ' + token.value);
}
);
is to contact this link https://iid.googleapis.com/iid/info/{{Token}}?details=true by entering your received token. If the response contains an error your configuration is incorrect and the error should be found in the changes applied to AppDelegate.swift. Furthermore, I noticed that not always the listener to capture the token does not always activate after a registration and I had to insert in my app also the #capacitor-community/fcmplugin that offers the method
FCM.getToken ()
.then ((r) => alert (`Token $ {r.token}`))
.catch ((err) => console.log (err));
which always returns the token according to my tests, this solution has been applied only for iOS, moreover this plugin also allows you to manage topics efficiently. It's definitely not a clean solution but for me it solved a problem I've been struggling with for days. The last advice I can give you is to pay attention to the activation and deactivation of the listners and to try to use setTimeout () to understand if your failure to work derives from an incorrect initialization of the resources and if these must be moved to the app states where the resources required by the various methods are available.
I have two questions about APNs push notification using gcm library.
Does gcm or fcm have a public api for uploading APNs certificates? I need to do this automatically instead of manually.
It seems that sending upstream using gcm library in an iOS app, only works when app is in foreground. Is it correct? Is there any workaround to send upstream even when app is not open or is in background? I want to send notification click event using gcm upstream to my server and it is highly preferable to do it instantly.
I am aware that I can save this click event and send it when app become active, but it is possible that user does not open the app for a long time.
1. Does gcm or fcm have a public api for uploading APNs certificates?
There is currently no public API for uploading APNs Certificates. For FCM (and any new projects), it's only done via the Firebase Console. Also, it seems that making use of the APNs Authentication Keys over certificates seem more convenient now (APNs Overview).
2. It seems that sending upstream using gcm library in an iOS app, only works when app is in foreground. Is it correct?
Yes. There has to be a connection for upstream messaging to work.
Is there any workaround to send upstream even when app is not open or is in background?
AFAIK, no. As mentioned in the FCM doc (emphasis mine):
To send messages upstream to the server, an iOS client app composes a message, connects to FCM, and calls sendMessage.
To connect, set the shouldEstablishDirectChannel flag to YES in the AppDelegate. FCM manages the connection, closing it when your app goes into the background and reopening it whenever the app is foregrounded.
...
The FCM client library caches the message on the client app and sends it when the client has an active server connection. On receiving the message, the FCM connection server sends it to the app server.
It mentions that FCM manages the connection, however AFAICT, there is this limitation for iOS devices that limits apps to maintain running services if the app is in background/closed (see this answer). And if a connection can't be established, upstream messaging won't work.
As general practice, data passed through FCM should as much as possible improve the user experience and that no app critical data is passed.
I am aware that I can save this click event and send it when app become active, but it is possible that user does not open the app for a long time.
It's possible. But it's also highly unlikely for a user to not click on a push notification immediately after it displays. In that scenario, the usual action would be for the user to immediately click on the notification while there is still an open connection.
I was trying out new GCM feature to send notifications to iOS devices. Everything worked very smooth except the feedback message. I assume after GCM sends message through APNS, GCM also calls feedback service of APNS to get the invalid tokens. Next time when we use the same device token to GCM, it should respond with error message. I tried several times after uninstalling the app, but never received an error message from GCM. Each time it shows success message. What went wrong here?
Note: If you are not familiar with new GCM features, please do not blindly answer to this.
I think the problem here is with the environment. I am using developer certificate to test the notification. APNS may not be giving any details for developer environment. Hope it will work in production.
Updates
Support from Google gave following details.
We did some digging, it seems that is how things are being handled by APNS:
When last sandbox app is removed from the device, device disconnects from APNS sandbox and not able to receive pushes/provide feedback anymore. Thus, APNS feedback doesn't register that the device has been uninstalled.
If you install another push-enabled sandbox app on the device, which would force device connection to APNS again. And we checked that under this circumstance, we get notified that the device has been uninstalled and return NotRegistered to our client.
APNS feedback service is not instantaneous. GCM does poll APNS feedback service but in my experience it was a bit delayed (not sure if it was APNS's delay or GCM's delay).
You should wait for some time and then try to use an old registration token and you should see a "Invalid Registration Token" error.
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.