Skip to content

Add support for the new FCM registration ID.#16133

Draft
leojaygoogle wants to merge 24 commits into
mainfrom
fid
Draft

Add support for the new FCM registration ID.#16133
leojaygoogle wants to merge 24 commits into
mainfrom
fid

Conversation

@leojaygoogle
Copy link
Copy Markdown
Contributor

No description provided.

It defaults to NO. When enabled, FCM will not generate an FCM registration token, but an FID instead.
…anagement system.

Currently, the FCM SDK calls the `https://fcmtoken.googleapis.com/register` backend to register an FCM V4 registration token. Going forward, we'd like to deprecate this token and use FID instead.
Once `unregister()` is called successfully and auto-init is disabled, Sending a push notification to the FID will result in an `UNREGISTERED` error.
This method is similar to `messaging(_:didReceiveRegistrationToken:)`, but will be called instead when `isInstallationIdEnabled` is `YES`.
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Comment thread FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessaging.h Outdated
Copy link
Copy Markdown

@Doris-Ge Doris-Ge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does our existing implementation listen for a FID change via a listener and re-register on a change? If not, we may want to add that.

I'm still reviewing the PR, but I'd like to give some early feedback in case you want to address or discuss it. Since I'm not familiar with Swift, I need more time for a full review. Sorry about that!

Comment thread FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessaging.h Outdated
Comment thread FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessaging.h Outdated
Comment thread FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessaging.h Outdated
- (void)updateDefaultFCMToken:(NSString *)defaultFCMToken {
NSString *oldToken = self.tokenManager.defaultFCMToken;
NSString *newToken = defaultFCMToken;
if ([self.tokenManager hasTokenChangedFromOldToken:oldToken toNewToken:newToken]) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we always invoke the callback even if the FID is not changed after a backend sync (we don't need to invoke the callback on every app start if the cached FID is not expired and it's still the same), considering that unlike a token, the FID is not going to be changed after a subsequent register() call following an unregister() call?

This change would enable developers to regularly sync the FID with their app servers, allowing for easier self-recovery during incidents. For instance, if a 404 error is mistakenly returned for a send request, leading an app server to delete a FID, invoking the callback regardless of a change would allow the server to re-acquire the FID automatically.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do that. Do you want to limit this behavior to FID only or do you want the callback to be called no matter what value isInstallationIdEnabled is?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FID only. Thanks!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline and we have decided to not change the existing behavior.

Comment thread FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessaging.h
Comment thread FirebaseMessaging/Sources/Public/FirebaseMessaging/FIRMessaging.h
Comment thread FirebaseMessaging/Sources/FIRMessaging.m Outdated
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we update FIRMessagingTest.m to test changes in this file? Some test cases to consider:

  • When isInstallationIdEnabled is true

    1. A call to register() can successfully invoke didReceiveRegistration() regardless whether the same FID has been registered or not and regardless whether isAutoInit is enabled or not.
    2. A call to unregister() should invoke didUnregister() and leave the app as unregistered.
    3. When isAutoInit=true, didReceiveRegistration() is invoked on app start when a new FID is registered or the registered FID has expired or the FID is changed.
    4. token/deleteToken should throw an error
    5. retrieveFCMTokenForSenderID/deleteFCMTokenForSenderID should throw an error
  • When isInstallationIdEnabled is false

    1. register()/unregister() should throw an error.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add tests for the first 3 items. Regarding throwing exceptions, our style guide suggests avoiding them. go/objc-style#avoid-throwing-exceptions.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good! Good to know that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@"apns_token" : apnsTokenString,
@"app_version" : appVersion,
@"apns_environment" : apnsEnvironment
},
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've proposed adding the bundle_id field to the backend API in cl/913512427. Can we start passing it here?It should be fine, even in the worst-case scenario where the API Council disapproves the CL.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline. we will add that later.

@"No Sender ID is available to register");
return;
}
[self setupInstallationIDObserver];
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we clear the observer during unregister()? If an app disables the auto init and calls unregister() after calling register(), not clearing the observer may automatically register the app with backend on FID changes, which may be unexpected for developers.

Copy link
Copy Markdown

@Doris-Ge Doris-Ge May 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, it seems the observer is only set up in the register() method. Calling register() is optional for apps that enable auto-init. We should make sure that those apps can also re-register on FID changes.

Consider setting up this observer regardlessly but only re-register when the app is registered as Eldhose did for Android: https://screenshot.googleplex.com/xmAGrSTKbyRMpSm.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

It tests that when `FirebaseMessaging.isInstallationIdEnabled` is `YES`, calling `register()` triggers a V1 registration API HTTP request. After receiving the registered FID, the message delegate's `didReceiveRegistration` should be called.
…register`.

So that it doesn't depend on the `register` being called.
@wiz-9635d3485b
Copy link
Copy Markdown

wiz-9635d3485b Bot commented May 13, 2026

Wiz Scan Summary

Scanner Findings
Vulnerability Finding Vulnerabilities -
Data Finding Sensitive Data -
Secret Finding Secrets -
IaC Misconfiguration IaC Misconfigurations -
SAST Finding SAST Findings 3 Low
Software Management Finding Software Management Findings -
Total 3 Low

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants