"method is deprecated and will be removed" Solution: migrate to modular style APIs. There is a guide

[Maintainer edit 👋 - We are resolving comments as people note things and we implement changes - but we really appreciate any feedback. If you convert to modular namespace and still see deprecation messages, or have other feedback, please leave a comment. Thanks]

Got Warning
This v8 method is deprecated and will be removed in the next major release as part of move to match Firebase Web modular v9 SDK API. Please use getApp() instead.

on both Android and IOS

Maintainer here 👋

This message will trigger for every API you use that is deprecated, so basically every single time you use any of the non-modular / chained APIs directly off one of the firebase modules - they are easy enough to search for in each file.

You will need to move to the new non-modular APIs.

I will really underline to everyone: This sounds painful. When I first looked into it in my projects I thought "oh no..."

The API move is purely mechanical though. It is really just changing syntax. It is not difficult, it just changes a lot of files.

The migration is not to be feared.

We just posted up a migration document but this isn't a bug or an issue or anything.
Google has deprecated the non-modular APIs in firebase-js-sdk and they are removing them.
We are obligated to conform to the firebase-js-sdk API set, so we must follow them.

The migration is straightforward thankfully - see here for how you migrate, or - once you accept that you know react-native-firebase v22 will drop all the APIs that are warning you - you can defer your maintenance as long as you like and disable the messages

https://rnfirebase.io/migrating-to-v22

(note, the feature of disabling the messages is present in react-native-firebase 21.7.3+)
(also note, the feature of enabling "strict mode" is present in react-native-firebase 21.10.1+)

Frequent Questions

Things I'm noting as I read comments here, we will add to the migration guide as we see people's concerns:

-" is it that critical?"

the APIs will be removed in react-native-firebase v22 so you will not be able to upgrade until you complete the migration. How critical is it for you to maintain a path to upgrade such that you maintain the ability to receive bugfixes, new ios/android system support, etc? Every project has a different timeline and answer for that

"I've seen some issues related to the migration":

Indeed there are still some typing issues at the moment, for typescript users. We are treating those as high priority bugs and fixing them as quickly as possible

Your thought here. I/we are listening. If you post a comment noting something specific you see about the migration, and have some constructive suggestion that would be great. We'll try to smooth the process out in response to any specific notes or constructive suggestions

Cheers

@andrastoth-ws

Hey @andrastoth-ws thanks for the details on this, it makes sense. I'm still a bit confused about this warning though:

WARN  This method is deprecated (as well as all React Native Firebase namespaced API) and will be removed in the next major release as part of move to match Firebase Web modular SDK API. 
Please see migration guide for more details: https://rnfirebase.io/migrating-to-v22 Please use `getApp()` instead.

I've tried setting strict mode via globalThis.RNFB_MODULAR_DEPRECATION_STRICT_MODE = true but I don't see any errors being thrown (still just see the warnings in CLI).

If I try and purposely consume a deprecated method like await analytics().setUserProperty('hash_uid', uid) then I just get an error being thrown with no details:

ERROR  Error: Deprecated API usage detected while in strict mode., js engine: hermes

Hello,

Apologies, it's unclear to me around the deprecation of logScreenView from analytics. I'm being told to use logEvent instead.

I tried:

logEvent(analytics, 'screen_view', {
    screen_class: currentScreenClass,
    screen_name: currentScreenName,
});

But I'm getting type errors saying that Argument of type "screen_view" is not assignable to parameter of type 'add_to_cart' | 'add_to_wishlist' | 'remove_from_cart'.

I don't get how I'm supposed to replace logScreenView as the guides are all outdated.

This blog post suggests that what I have is correct but the types say otherwise: https://firebase.blog/posts/2020/08/google-analytics-manual-screen-view

If anyone can help I'd appreciate it :)

Hello,

Apologies, it's unclear to me around the deprecation of logScreenView from analytics. I'm being told to use logEvent instead.

I tried:
logEvent(analytics, 'screen_view', {
    screen_class: currentScreenClass,
    screen_name: currentScreenName,
});
But I'm getting type errors saying that Argument of type "screen_view" is not assignable to parameter of type 'add_to_cart' | 'add_to_wishlist' | 'remove_from_cart'.

I don't get how I'm supposed to replace logScreenView as the guides are all outdated.

This blog post suggests that what I have is correct but the types say otherwise: https://firebase.blog/posts/2020/08/google-analytics-manual-screen-view

If anyone can help I'd appreciate it :)

I found this in node_modules/@react-native-firebase/analytics/lib/modular/index.d.ts:

export declare function logEvent(
  analytics: Analytics,
  name: 'screen_view',
  params?: {
    firebase_screen: EventParams['firebase_screen'];
    firebase_screen_class: EventParams['firebase_screen_class'];
    [key: string]: any;
  },
  options?: AnalyticsCallOptions,
): Promise<void>;

I tried this BUT DebugView throws a "14" error "Event parameter name is reserved".

I'm starting to think this is a bug. Perhaps I should be creating a new issue?

Ok, I'm pretty certain that the requirement to add firebase_screen and firebase_screen_class is incorrect. I've run a test to compare logEvent vs logScreenView and both show the same params in the DebugView.

logScreenView/logEvent(analytics, 'screen_view' as string, {
    // firebase_screen: currentScreenName,
    // firebase_screen_class: currentScreenClass,
    screen_class: currentScreenClass,
    screen_name: currentScreenName,
});

@7ammer

@7ammer I also think those are incorrect. When using them, this appears in the native logs:
Parameter name uses reserved prefix. Ignoring parameter: firebase_screen. (because firebase_* is reserved iirc).

@mikehardy is this something that is easy to fix?

The Web API documentation states the following:

logEvent(analytics, 'screen_view', {
  firebase_screen: screenName, 
  firebase_screen_class: screenClass
});

I am guessing the intention is to use those 2 params in react-native too

That could be yeah, though it’s weird because it prevents sending those because they are reserved (see my previous comment).

As I understand the specific issue about logScreenView is tracked here

I'm getting a method is deprecated even after migrating all the calls in my app to the modular style API in strict mode

@KrisLau

I also faced this @KrisLau, for me it was logging the warnings but not throwing with strict mode because it was being used outside of react lifecycle.

Basically I was importing crashlytics in a util function and it gets loaded on module resolution rather than runtime when my entry file sets the globalThis strict setting so the stack trace isn't set.

You can also try removing the conditional around the throw (sorry I'm on my phone and no access to computer to tell you where exactly to patch with patch-package) and that will throw always and it helped me find the last ones.

I also faced this @KrisLau, for me it was logging the warnings but not throwing with strict mode because it was being used outside of react lifecycle.

Basically I was importing crashlytics in a util function and it gets loaded on module resolution rather than runtime when my entry file sets the globalThis strict setting so the stack trace isn't set.

You can also try removing the conditional around the throw (sorry I'm on my phone and no access to computer to tell you where exactly to patch with patch-package) and that will throw always and it helped me find the last ones.

mine is the opposite. Not sure if it's the same cause it's throwing in strict but no warnings w/o strict mode :/

@react-native-firebase+app+23.3.1.patch

This patch should always throw and ignore the setting of the env var (as I said, I was setting it too late in my App.tsx entry file).
Maybe it will help if you add it to patch-package
I also noticed that file splitting is a potential problem, so if the bundle is split and doesn't get loaded on first screen then you need to visit every page in your app to get fresh warnings, I thought I was done until I went into all my settings screens

@ChromeQ

EDIT: Fixed messaging issues. Had to run npx react-native clean-project-auto & re update the packages

@ChromeQ Ok not sure if was cache reasons but I cleaned project and now I see the errors with strict turned off. They all seemed to be being triggered by the messaging methods. My current code:

import { getAPNSToken, getMessaging, setAPNSToken } from '@react-native-firebase/messaging';
const messaging = getMessaging();
const apnsToken = await getAPNSToken(messaging);

error:

Method called was `getAPNSToken`. Please use `getAPNSToken()` instead.

I'm getting the same error on all messaging methods. What am I doing wrong or is this still related to the patch you mentioned?

@7ammer

@7ammer @dgreasi @JustJoostNL hey you three - the discussion around analytics screen views (and perhaps 3 other events which are apparently not in the enum?) is very interesting to me.

I'm not 100% clear on what the current state of it is - that is, are there still gaps and some related testing results that show the gaps when trying to use the event API (or trying to replace the screen view API with the event API) ?

If so could you please 🙏 open a new issue with the details as you understand them? That will help track that as a real issue vs buried in here which was the generic "we're migrating..." issue

Many thanks

@mikehardy

@mikehardy Thanks for your reply. I currently only have the issue where the screen_view doesn't work as expected. That issue is tracked here already: #8609. If you could review #8687 that would be great.

Navigation Menu

Repository navigation

"method is deprecated and will be removed" Solution: migrate to modular style APIs. There is a guide #8282

You will need to move to the new non-modular APIs.

The migration is not to be feared.

Frequent Questions

65 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"method is deprecated and will be removed" Solution: migrate to modular style APIs. There is a guide #8282

Description

Activity

umakantv commented on Feb 8, 2025

furkananter commented on Feb 8, 2025

sanjaykdotworld commented on Feb 8, 2025

SamJbori commented on Feb 8, 2025

retyui commented on Feb 8, 2025

mikehardy commented on Feb 8, 2025

You will need to move to the new non-modular APIs.

The migration is not to be feared.

Frequent Questions

furkananter commented on Feb 8, 2025

mikehardy commented on Feb 8, 2025

65 remaining items

steinalex commented on Aug 13, 2025

7ammer commented on Aug 14, 2025

7ammer commented on Aug 14, 2025

7ammer commented on Aug 14, 2025

JustJoostNL commented on Aug 14, 2025

dgreasi commented on Aug 26, 2025

JustJoostNL commented on Aug 26, 2025

dgreasi commented on Aug 26, 2025

KrisLau commented on Sep 24, 2025

ChromeQ commented on Sep 24, 2025

KrisLau commented on Sep 24, 2025

ChromeQ commented on Sep 24, 2025

KrisLau commented on Sep 24, 2025

mikehardy commented on Sep 25, 2025

JustJoostNL commented on Sep 26, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions