today I’m having a doubt about apnsToken function from Firebase's Messaging object… I’m reading that apnsToken should be unique until the app has been reinstalled, but I want to know if it’s possible to change this value per launch, I mean, we’re having troubles in a solution because the apns is the same in a certain device, we are changing accounts but it’s possible to have THE SAME APNs token in multiple accounts and the problem is that notifications are getting received in the same device using different accounts and that’s not good because we are mixing push notifications in accounts, so we need to have a unique apnsToken per launch but I’m not sure if it’s possible or not… Hope you can help me to understand about it. Thank you so much.
Here’s a little documentation I have read
https://firebase.google.com/docs/cloud-messaging/ios/client
Related
This bounty has ended. Answers to this question are eligible for a +500 reputation bounty. Bounty grace period ends in 5 hours.
Scorb wants to draw more attention to this question.
I have a cross platform flutter app. I am using FCM to send notifications and they are not arriving on the iOS app in any state (foreground, background, terminated). I am testing on a physical device.
The notifications work on Android, so I know the topic subscription and send code is correct.
I have followed these steps for configuration defined here...
https://firebase.flutter.dev/docs/messaging/apple-integration/
To verify I have:
added and initialized firebase using google-services-info.plist.
created and added my APNS key
created the app identifier in the Apple Developer center and confirmed it matches my apps bundle id (and added push notification
capability for the identifier.
added push notification capability to the app in xcode
added background fetch and background remote notification capabilities to the app in xcode.
It seems like I have addressed every step to configure FCM on iOS. But none of my notifications arrive.
When the app is minimized, no system tray notification is triggered, and when in the foreground the FirebaseMessaging.onMessage is never triggered, like is is when on Android.
An important note is that this is the second iOS app added to this project, and the first iOS app works correctly. Though there is no indication that there are any special steps for a second app.
We saw a similar problem (for a native iOS app) where FCM would deliver to one app in the project but not the other. The mistake we made was not repeating the configuration in Firebase for the other apple bundle id since each app in our project has a different bundle id. Given it works for one of your iOS apps but not the other on the same project, it sounds like you've got the same issue.
Also, a good diagnostic step is to use the Firebase Console to manually send off a Push Notification to a particular app. It means you can then discount errors further upstream in your backend that may not have caused FCM to be invoked.
Have you tried to send testing notifications via firebase console?
You can log your device token in your app.
Background notification must work if you have done correct with firebase and APN settings despite without implementing some methods of AppDelegate file for remote notification on the next step.
Your question is very blur to have a specific answer but you can separate your concerns to find the issue and then try to resolve that:
1. Make sure about the APNs configuration
First, try to send a notification to your iOS app, directly using the APNS key. If you get the notification, it means you have configured the APNS correctly
2. Make sure about the firebase setup
Check with both the Android and iOS app and see if there are connected to the firebase console. You can use the real-time event to confirm that.
3. Make sure you have implemented the correct methods.
Firebase and apple have different methods for push notifications. Make sure you are implementing the correct one. Also, it may vary based on the configuration file of firebase. search for iOS firebase swizzling for more information
4. Make sure you got the right permissions from the user
You should get the notification permission from the user before trying to show any notification. Make sure you've done that
Note that you may have already tried some of these but I've mentioned them for the sake of completeness. Hope it helps you and others.
I have push notifications setup for my app and it’s corresponding App Clip. Let’s say that the App has an AppID, com.X and the App Clip has the ID com.X.Clip.
I set the topic of the aps to com.X.Clip to send push notifications to my App Clip and it works properly. However, when I try to send push notifications to my App, I get the error DeviceTokenNotForTopic because the device token is for the AppClip and not for the app. Fixing the topic to com.X, solves the problem.
My question is, is there a way to set the topic to something common that can be shared by my App and the AppClip so that I don’t receive these errors? Otherwise I would have to also store which device tokens are for the app and which are for the clip which will increase storage costs.
Or perhaps there is another way?
Not sure if you figured it out, but I just asked a similar question here: How do I detect whether an iOS App Clip or Universal Link is running?
You can't combine them, but you can tell your server where to register the device token.
Our app uses Firebase phone auth. The App Store review has rejected the app due to pushes being required:
Guideline 4.5.4 - Design - Apple Sites and Services
We noticed that your app requires push notifications in order to function.
Specifically, we noticed if the Push Notifications setting was not enabled on our device, we encountered an error message after entering our phone number within the app.
Next Steps
Push notifications must be optional and must obtain the user's consent to be used within the app.
And they've also attached the screenshot that depicts Firebase error "Remote notifications and background fetching need to be set up for the app [...]"
Firebase documentation states that APNs notifications are absolutely required for phone auth to function:
https://firebase.google.com/docs/auth/ios/phone-auth
To use phone number authentication, your app must be able to receive APNs notifications from Firebase. When you sign in a user with their phone number for the first time on a device, Firebase Authentication sends a silent push notification to the device to verify that the phone number sign-in request comes from your app. (For this reason, phone number sign-in cannot be used on a simulator.)
However App Store review guidelines state that Push Notifications must not be required in order for the app to function: https://developer.apple.com/app-store/review/guidelines/
4.5.4 Push Notifications must not be required for the app to function, and should not be used for advertising, promotions, or direct marketing purposes or to send sensitive personal or confidential information.
Users need to sign in before they can use the app (the app is about sending digital GIF invitations to your guests and sharing photos), which is why Push Notifications are basically required for the app to function, if the sign in method is Firebase phone auth.
We have tested the app a lot, and the authentication works without a problem when push notifications are enabled (on real devices, both in distribution Ad Hoc builds with production environment and development builds with sandbox environment).
Come to think of it, how did App Review team even disable Push Notifications? The notification center setting does not stop actual pushes, it just doesn't display them.
We have tested with this setting off, and firebase phone auth works fine, pushes are still coming through as expected.
I am very surprised with this issue, as Firebase is a huge service provider. Did anyone else encounter this issue?
Are there plans to remove APNs requirement for phone auth? Is there maybe some other way to use Firebase phone auth without pushes?
Firebaser here. We have released an updated Firebase Auth SDK, 4.2.0, as Leetmory mentioned, which should hopefully resolve these issues going forward.
The issue was caused by the fact that the Firebase Auth SDK using APNs to validate the request - this is to minimize the risk of SMS spam abuse or similar. The validation uses a silent APNs notification, so doesn't require explicit user consent for iOS 8 and above. However, this still failed if APNs was completely disabled, as in this review case.
The 4.2.0 release introduced the facility to use a reCAPTCHA prompt inside an SFSafariViewController (or webview for older iOS) to prevent abuse if APNs isn't available. We don't expect this to happen very much, but it accounts for the unusual state encountered here. It also enables support for testing Firebase Phone Auth on the simulator!
You'll notice there is a new uiDelegate parameter on the verifyPhoneNumber method. In most cases you wont need to use this, but it is part of the fallback verification.
What you will need to do, if you haven't already, is add the REVERSED_CLIENT_ID (from the GoogleService-Info.plist) as a custom URL scheme. This will allow the reCAPTCHA view to return validation to your app.
There is a gotchas to be aware of in the current version though:
In the callback from verifyPhoneNumber you'll need to redispatch to the main thread, using DispatchQueue.main.async {} - this will be fixed in the next version of Firebase Auth!
Other than that, things should work as normal! We definitely recommend supporting silent push where ever possible to ensure the best user experience.
For a full walk through, see the full Phone Auth developer guide.
UPD: Firebase 4.2.0 has rolled out, which fixes the issue. You will need to add your reverse-client-id which looks something like this: com.googleusercontent.apps.123456-abcdefg99 to URL schemes in your Info.plist, and you are set.
To find this
value, open the GoogleService-Info.plist configuration file, and look for the
REVERSED_CLIENT_ID key.
Firebase support has confirmed this bug and has given the response to this issue:
to me
Thank you for the detailed information Leet. This is indeed an odd situation, and our Phone Auth engineers are taking a look. I'll get back to you as soon as I have an answer.
Best,
Jeff
to me
Hi Leet,
Our engineers are working internally on a long-term fix for this, but in the meantime, would like to meet with you to see if we can figure out a workaround.
It appears that there is indeed a bug in Firebase phone auth / Firebase UI.
I contacted Firebase support and here's an excerpt:
In terms of the concern around users disabling push notifications - Disabling push notification for the app by the user does not normally prevent users from signing in using their phone number with Firebase Auth. Our requirement is that the app must set up and enable push notification, not the user. Regardless of if the user accepts or declines your app's push notification prompt phone auth will continue to work since we use silent pushes that don't require any action from the user.
I researched further and found that silent push notifications do indeed arrive to the device even when the user explicitly disables push notifications. To disable silent push notifications you would need to go to Settings -> Your App -> Background Refresh to disable it. See Is Silent Remote Notifications possible if user has disabled push for the app?
So you can tell the App Store Review team that your login will only work when Background Refresh is enabled. I don't believe this violates their terms.
EDIT
After some testing, it appears that phone auth can work when Background Refresh is disabled. However, it works for me because Firebase already has access to my APNS device token. I have found no way to disassociate my device token from Firebase - they provide no API for it. This unfortunately makes it impossible to test the scenario where a new user disables Background Refresh and Remote Notifications before doing the phone auth which I believe may be the cause of the error.
EDIT 2
I can confirm that on a fresh device with a fresh install of our app, if you disable Background Refresh then Firebase Phone Auth will not work. Once you enable it, it will work again.
The reason is that the SDK likely calls [[UIApplication sharedApplication] registerForRemoteNotifications] which is ignored by the system if a user manually disables the Background Refresh and Notifications settings.
Unfortunately there is no workaround until Firebase releases a new SDK which does not require APNs.
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'm currently struggle with annoying store-and-forward function limitation of APNS. Here is a quote from the Apple docs:
If APNs attempts to deliver a notification but the device is offline,
the notification is stored for a limited period of time,
and delivered to the device when it becomes available. Only ONE recent
notification for a particular application is stored. If multiple notifications
are sent while the device is offline, each new notification causes the prior
notification to be DISCARDED.
I specifically make ALL CAPS for the keywords of my problem. In Google Cloud Messaging notifications service their store and forward function have much more capabilities:There is a limit on how many messages can be stored without collapsing. That limit is currently 100. If the limit is reached, all stored messages are discarded. - so Google service can store up to 100 push messages for a max time of 28 days. And in addition to this they have also coalescing (collapsible) notifications but for 4 different collapsible messages. And in APNS all we have is - one recent
notification for a particular application is stored - it is quite a limited behaviour for my app (I need to store at least four different push notifications while the device is offline at one given moment of time).
So I'm interested are there some ways I can improve store and forward capability of APNS?? Can I in some way make APNS to store more push notifications for a specific device?Or at least store several coalescing notifications as in Google collapsible messages? Some third party solutions or whatever? May be I missed something in APNS docs? I know we can orchestrate apple push notification on google platform - but I think it is not a solution because of its unjustified complexity.
As you found yourself in Apple's APNS docs, there is no way to store more than one notification per application for a single device. If you want to compare it to GCM, APNS server acts as if all notifications have the same collapse key.
No third party solutions can work around that, since Apple doesn't return an acknowledgment of delivery to the sender of the notification, so the server (whether it's implemented by you or by some third party provider) has no way of knowing which messages to store and resend (assuming that all the messages are valid and were not rejected by APNS server).
Apple Push Notifications are not intended to deliver important data. Their purpose is to notify the user of the app that new data is available at the server, which allows the app to load that data if the user chooses to open the app. That's the reason why they don't store more than one message per app for the same device.