[🐛] Change error message for messaging().registerDeviceForRemoteMessages()

[ToyboxZach]

I have this code:

    await messaging().requestPermission(); // IMPORTANT!
    await messaging().registerDeviceForRemoteMessages();
    let token = await messaging().getToken();

If I run this I get an error logged:

Usage of "messaging().registerDeviceForRemoteMessages()" is not required. You only need to register if auto-registration is disabled in your 'firebase.json' configuration file via the 'messaging_ios_auto_register_for_remote_messages' property.

If I remove this line await messaging().registerDeviceForRemoteMessages();

getToken ends up throwing an error

[Error: [messaging/unregistered] You must be registered for remote messages before calling getToken, see messaging().registerDeviceForRemoteMessages().]

The right move seems to be to just register even though it logs that error, but the error messages are confusing.

[mikehardy]

This has been an area of confusion. It should just work - that is, if you have notification permission then the module auto registers for you, unless you have turned that auto-registration off in firebase.json and not re-installed Pods / rebuilt the app.

There is some scattered reporting that occasionally it fails to register automatically, and it's always true that registering manually can't hurt

So, the general recommendation is to go ahead and call it, even though it shouldn't be needed.

And that of course generates this warning message. I'll think about either re-wording it or just removing it, as it doesn't seem like it's actually helping anyone to have it in there.

[mikehardy]

If you wanted to post a PR that got rid of that error message, that would be fine by me - I may not have time to do so for a while

[mikehardy]

Note there is some extensive discussion about this whole area here:

https://github.com/invertase/react-native-firebase/pull/5597#pullrequestreview-730926468

[jacobwallstrom]

There seems to be a misunderstanding here. On IOS you can have a token and receive push notifications even when there's no permission (or the permission has been denied).

If the app has no permissions, silent push notifications can still be received in the background or normal push notifications received in the foreground. It's just that no notifications will be displayed. See e.g. this discussion https://stackoverflow.com/questions/30644343/is-silent-remote-notifications-possible-if-user-has-disabled-push-for-the-app

You also have the case of provisional push notifications: https://developer.apple.com/documentation/usernotifications/asking_permission_to_use_notifications

In my testing the app receives a token on the IOS native level directly after install if requested without asking for permissions.

[mikehardy]

tokens are driven by Installations package and used by other packages. It's generation doesn't require any permission but it's use in almost any way likely requires handling privacy concerns (GDPR etc) and it's use for notifications requires permissions. Since data-only messages are not guaranteed to be delivered reliably most people rely on FCM with notifications content, which requires the permission.

I understand all of that, I think.

I don't believe that has anything to do with removing a warning message for duplicate/extra calls to register when for notifications when you call it manually and the device is already registered

[jacobwallstrom]

There are at least two valid use cases on iOS of using registerDeviceForRemoteMessages without first doing requestPermission:

1. The app has not yet asked for permissions but is using the provisional notification opt out feature. 2nd link above.
2. The app has not yet asked for permissions. The app can still receive push messages in the foreground. 1st link above.

Both of the above applies also to notifications with user content, not only data messages.

So basically registering for push messages and getting a token is independent from getting permission for displaying notifications.

[mikehardy]

Ah, that is quite clear to me now, thanks. I must be honest and say that this does not appear to be blocking anyone, so it will probably not be a high priority to re-work this area, though pull requests are always welcome of course :-), and I'll leave it open for review when time is available

[stale[bot]]

Hello 👋, to help manage issues we automatically close stale issues. This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs. Thank you for your contributions.