Is there any possibility to init Firebase in Flutter dynamically?

Question

I try to init Firebase depending on a user language preferences. For example:

User open an app. Select language A: Flutter should init project A (config, etc.). Similarly when the user selects a different language.

The problem is that iOS needs to have default GoogleService-Info.plist file. During the dynamic init of a Firebase there is created an app but the default one is from the default file and takes the priority over project A. Ultimately, two applications are created (DEFAULT and A). This causes that FirebaseMessaging is assigned to the default Firebase app instead of the second one based on a user preference.

According to the messaging.dart docs:

  /// If [app] is not provided, the default Firebase app will be used.
  // TODO: messaging does not yet support multiple Firebase Apps. Default app only.

In that case there is no possibility to support dynamic init of a Firebase config file due to the fact that there will be always a default app initiated from the default config file.

In native apps I can create many .plist files and invoke FirebaseApp.configure(options: options)

Do you have any idea how to solve this problem in Flutter?

Answer 1

The problem you are experiencing with FirebaseMessaging is a result of the firebase_messaging package not yet supporting .instanceFor(). The presence of the default app would not be an issue otherwise, but the default app is hard coded to be the only supported app in FirebaseMessaging.

Support for .instanceFor() has already been added to the FirebaseAuth, FirebaseFirestore and FirebaseStorage packages. If FirebaseMessaging supported instanceFor(), you could simply pass your secondary app name in and reference it using that method. Instead, the lack of support in that package adds needless complication. More info on instances here: https://firebase.flutter.dev/docs/core/usage/#secondary-firebase-apps.

Further information pertaining to the lack of multi-app support in fcm can be found here: https://github.com/FirebaseExtended/flutterfire/issues/5844. There is mention of a possible workaround (which I have not personally attempted) and also an open PR at https://github.com/FirebaseExtended/flutterfire/pull/6549 which is still in the draft stage.

You may be able to accomplish the desired functionality using flavors but I am not familiar enough with them to assist on that topic: https://flutter.dev/docs/deployment/flavors.

I was in the same situation and opted to subscribe all app users to the default app instance and in turn perform all fcm dispatching via firebase cloud function on behalf of my default project, until the firebase_messaging package team fixes this obvious hole in their implementation.

If you have the ability to contain all your data in a single project, organized by language collections and isolated by rules you may want to consider that an option as well.