request: flutterfire configure with --ios-build-config should remove ios/Runner/GoogleService-Info.plist from list of Copied Bundle Resources

[stefan-wisemindlabs]

Is there an existing feature request for this?

• I have searched the existing issues.

Command

No response

Description

1. Start a new flutter default project
2. Run flutterfire configure --project=<some-firebase-project> --platforms=ios
3. Flutterfire creates a default set up - this includes placing a GoogleServices-Info.plist in ios/Runner and setting up for this file to be one of the resources to be copied in Xcode during the build phase:

4. Now imagine setting up two environments - dev and prod as described in the latest dev readme.

At this point Xcode has the new script to copy the correct service file during build:

But, it still has the service file in Copy Bundle Resources. This results in the original bundle file that was placed during step (2) above overwriting the bundle file copied during the flutterfire bundle-service-file script. This causes one of the environments to not work as the native initialization uses the file in Runner and creates a DEFAULT app that connects to that Firebase project, while the native Dart tries to connect to another firebase project. The result is an exception raised during Dart initializeApp() that there is already a DEFAULT app. This exception is just a symptom of the underlying presence of two different configs.

I'd like that when we set up multiple environments, the GoogleService-Info.plist in Runner is removed and Xcode updated to not copy it as part of the build phase. I am not sure if this is actually a bug or not, but decided to raise it as a feature request.

Reasoning

If this is not done and if you first set up a project without multiple environments, and then add multiple environments, your setup won't work. You need to manually go and remove the Runner version of the service file in Xcode from the build phase.

Additional context and comments

No response

[russellwheatley]

Thanks for raising the issue. I'm not sure if this is something that should be documented rather than silently removed when configuring multi-environment setup. I'll have a think and get back to you.

[stefan-wisemindlabs]

Thanks. Adding to the documentation will certainly be great. Especially since the official documentation for adding firebase support to a flutter app (here) ends up having people do steps (1) and (2) above. And then it just seems like a bug that can be quite nasty to track down.

Another option is to make sure, if possible, that the file from flutterfire bundle-service-file overwrites any other way that the service file may end up as part of the build. I am not very knowledgeable in Xcode build process, so can't really say if that's possible or not. This may be one solution that wouldn't require anything else to be done.

[github-actions]

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 attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.