firebase-ios-sdk: FirebaseApp.configure(options: options) not loads data when passing FirebaseOptions

Please correct me if I am wrong, but for a project with multiple build configs (dev VS prod) and targets (say Pokemon Black VS White), each config / target has its own bundle ID and Google app ID, and thus we have to have different plists for each target.

For a project with single target and multiple configs (dev VS prod), we cannot put the GoogleService-Info.plist files into different folders for each config, because if there are multiple files with the same name for the same target, Xcode randomly picks one into the bundle without keeping the folder structure. I figured it out by unzipping the .ipa file and check out the bundle, seeing all resources files from different source folders got put into just one bundle folder.

So, putting GoogleService-Info.plist files into different folders won’t solve the issue, and Firebase has to support loading config plist of different names.

I found a solution for myself.

1. I use only one target and a different .xcconfig files for each environment(dev/stage/prod). So, I store my GoogleService-Info.plist-s as below: Note: GoogleService-Info.plist-s shouldn’t be marked as a Target Membership in File Inspector.

2. Add to your .xcconfig files a path to GoogleService-Info.plist files: Dev.xcconfig: GOOGLESERVICE_INFO_PLIST = ${PROJECT_DIR}/TargetName/Resources/Firebase/dev/GoogleService-Info.plist Stage.xcconfig: GOOGLESERVICE_INFO_PLIST = ${PROJECT_DIR}/TargetName/Resources/Firebase/stage/GoogleService-Info.plist …

3. Modify your project Info.plist:

4. Open Target Build Phases, tap + icon, New Run Script Phase and add the following script:

# Get a reference to the destination location for the GoogleService-Info.plist
PLIST_DESTINATION=${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app

# Copy plist
echo "Using ${GOOGLESERVICE_INFO_PLIST}"
cp "${GOOGLESERVICE_INFO_PLIST}" "${PLIST_DESTINATION}"

1. Use FirebaseApp.configure() in application:didFinishLaunchingWithOptions:.

Done!

This is a baffling omission in my opinion. The workaround I’m currently using is having a new Build Phase in my project that copies the appropriate file:

cp "${SRCROOT}/ProjectName/GoogleService-Info${BUNDLE_ID_SUFFIX}.plist" "${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/GoogleService-Info.plist"

where BUNDLE_ID_SUFFIX is a user defined variable that differs between build configs. Hope this helps.

The plist file must be named GoogleService-Info.plist.

If you have multiple, an option is to put them in different folders.

please reopen this, its better to have different plist files than store same files in different folders

Is there any update on this subject? It’s open since 2017…

There is a warning underneath that section of the Getting Started guide mentioning:

Warning: This approach can impact Analytics collection in some circumstances, see the reliable analytics section.

That being said, I agree that we should be fixing Analytics to ensure it can handle runtime configuration changes. We’re going to work with the Analytics team to find an acceptable solution that hopefully won’t risk the integrity of data coming from Analytics.

BTW this is console output after FirebaseApp.configure(options: options) call.

<Error> [Firebase/Core][I-COR000012] Could not locate configuration file: 'GoogleService-Info.plist'.
<Error> [Firebase/Analytics][I-ACS020006] Google App ID from GoogleService-Info.plist is empty. Please, define GOOGLE_APP_ID in GoogleService-Info.plist for Analytics to work reliably.
<Error> [Firebase/Analytics][I-ACS025020] Analytics requires Google App ID from GoogleService-Info.plist. Your data may be lost. Google App ID has been changed. Original, new ID: (nil), 1:625184029135:ios:f8b3e130939c8434

Any updates on changing/setting configuration at runtime? In our product there is ability to switch modes within the same app, so we have to re-configure on a switch.

I’d just like to chime in that we are in the exact same position as others. I don’t think we will be able to migrate our other apps from Fabric to Firebase until there is a resolution here.

We have currently implemented a method that configures Firebase at runtime based on the bundle ID detected at runtime, with multiple config plist files.

For us, losing early analytics is by far preferable to changing our entire environment architecture.

I’d also like to point out the following changes (within the last week) to the documentation:

On iOS, do not add GoogleService-Info.plist to your project if you are supplying different configuration at run time, as this can result in an apparent change of GOOGLE_APP_ID and result in lost Analytics.

We were using the default name for production, which made us lose all reporting for other environments. @ryanwilson the following solution for configuration is working for crash-reporting:

private func dynamicallyLoadFirebaseConfiguration() {
    let bundleId = Bundle.main.bundleIdentifier
    var configFilepath: String?
    switch bundleId {
    case Global.devId:
        configFilepath = Bundle.main.path(forResource: "GoogleService-Info-Dev", ofType: "plist")
    case Global.stagingId:
        configFilepath = Bundle.main.path(forResource: "GoogleService-Info-Staging", ofType: "plist")
    default:
        configFilepath = Bundle.main.path(forResource: "GoogleService-Info-Prod", ofType: "plist")
    }
    guard let config = FirebaseOptions(contentsOfFile: configFilepath!) else {
        assert(false, "Unable to load Firebase config file")
        return
    }
    FirebaseApp.configure(options: config)
}

@ryanwilson, @paulb777 Is there any plan or timeline for fixing this issue? We are just couple of months away from google analytics service SDKs being sunset (https://support.google.com/firebase/answer/9167112?hl=en). Though as much as we would love to move to firebase, this issue at present is stopping us from completing the migration from google analytics to firebase. If this is not on a list of issues to be fixed, we will start looking for an alternative and migrating data to another service.

I have created following “workaround”. I have 2 plist files, both correctly named GoogleService-Info.plist, but in separated folders - Debug, Release (it has nothing to do with Debug/Release Xcode scheme). Those files are not even referenced in XCode project.

Then I have file GoogleService-Info.plist - which is empty and this file is referenced in XCode. We use fastlane to configure environment (setting API URL and some other properties), and we have added copying of correct file (from appropriate folder) in place of “placeholder” file.

Sure, this only helps when you want to switch file before build - not on runtime. But then you can use simply FirebaseApp.configure()

+1, seeing this issue for ages:

10.0.0 - [FirebaseAnalytics][I-ACS020006] Google App ID from GoogleService-Info.plist is empty. Please, define GOOGLE_APP_ID in GoogleService-Info.plist for Analytics to work reliably. See https://goo.gl/txkZbE
10.0.0 - [FirebaseAnalytics][I-ACS025020] Analytics requires Google App ID from GoogleService-Info.plist. Your data may be lost. Google App ID has been changed. Original, new ID: (nil), 1:767925875369:ios:62bc006ed59750a1

We use two different plist configurations within a single target just to toggle it in runtime between different stages – even in TestFlight where builds can be treated either as for a Sandbox project (for testers in TestFlight) or for a Production project (when the same build goes live to the App Store).

Pls give this a bit of prio to address it already. 🙏

Same issue here, but I can live with losing some analytics. But what I wonder about are the messages shown after that (Xcode, iOS app):

[403:42882] 5.12.0 - [Firebase/Core][I-COR000012] Could not locate configuration file: 'GoogleService-Info.plist'.
[403:42882] 5.12.0 - [Firebase/Core][I-COR000012] Could not locate configuration file: 'GoogleService-Info.plist'.

for completeness:

var options:FirebaseOptions!
...
options = FirebaseOptions.init(contentsOfFile: Bundle.main.path(forResource: "GoogleService-Info-staging", ofType: "plist")!)
FirebaseApp.configure(options: options)

When I step with my debugger over the last line, this gets printed in the console. options is not nil. According to my podfile.lock Firebase/Core is 5.12.0.

According to the “Getting Started” guide at home page. https://firebase.google.com/docs/configure/#use_multiple_projects_in_your_application

If the builds are part of a single target, the best option is to give both configuration files unique names (e.g. GoogleService-Info-Free.plist and GoogleService-Info-Paid.plist).

But according to reply above from @ryanwilson , there is no workaround at this moment.

Please fix Google Analytics for Firebase uses runtime configuration.

I want to bump this due to the performance aspect of this. Firebase initialization takes around 30 ms on iOS to initialize.

When passing options via constants this can be slashed almost to a half. Firebase is usually initialized in AppDelegate, which is critical for app start time. Reading and parsing XML plist files is very inefficient on the main thread.

I’m using the last version of Firebase and I’m initialising programmatically my configuration without the GoogleService-Info.plist. But now, I’m receiving an error in app initialising about this. Anybody knows how to fix that?

https://twitter.com/steipete/status/1249693487789944832 might help with workarounds.

Very similar issue here, where Analytics prevents us from switching configurations in runtime. Any progress on making Analytics accept dynamic configuration?

@lifely thanks for the update and the clear goal. It’s still an ongoing discussion and I’ll update with more as it progresses, thanks!

@forsen thanks for bringing that to our attention - looks like the line in question is https://github.com/firebase/firebase-ios-sdk/blob/c724f9d1e8c3d2f7a44b8959983e1ebaa3eaa5cb/Firebase/DynamicLinks/FDLURLComponents/FIRDynamicLinkComponentsKeyProvider.m#L29

This can and should be avoided, I’ll file an issue for it separately.

Seems like Analytics is not the only module that does not support multiple GoogleService-Info.plistfiles. We use multiple targets, and name the file like this: GoogleService-Info-<target>.plist. This has worked fine for some time, but when we now tried to add DynamicLinks to our project, it insists on loading the API KEY from GoogleService-Info.plist (which doesn’t exist), and completely ignore that we have initialised FIRApp with a custom name for the service file.

Does that mean we can not use multi config files in our projects (each file for an environment)?

Any update?

I’m using the last version of Firebase and I’m initialising programmatically my configuration without the GoogleService-Info.plist. But now, I’m receiving an error in app initialising about this. Anybody knows how to fix that?

@arthurgivigir I fixed this issue with following changes to run script in Build Phases: /path/to/pods/dir/FirebaseCrashlytics/upload-symbols -gsp /path/to/app/target/GoogleService-Info.plist -p ios /path/to/built_products_dir/target_name.dSYM/Contents/Resources/DWARF/target -val

If you are working on macOS app, then pass -p mac instead of -p ios. After this my dsym files uploading successfully.

@ryanwilson @paulb777 Should we assume that this is not going to be fixed?

@ryanwilson @paulb777 Is there any update that you guys can provide? Or should we consider that this issue is not going to get fixed in time for google analytics sdk being sunset?

Hey @ryanwilson Thanks a lot for providing the update.

Unfortunately, we do not have two different targets. We only have one target (IPA/APK) file which gets generated and has ability to connect to different servers (QA,STG,PROD) and hence we need an ability to switch the instance runtime. We decide where the user is logging in depending on the username and server specifier that they enter. It is strange since Firebase at core supports switching instance runtime. But just google analytics as a part of firebase does not support.

So we are not in a hurry since google analytics is not gonna be deprecated till next year. But do you think there would be a solution before that?

Once again, appreciate all the help.

Regards, Bhavik

I’d like to bump this, the issue seems to have been open a year ago.

We’re also struggling with this, we might implement the build-script solution but imho this isn’t a good solution at all.

Our goal is to be able to switch environment at runtime and even though the api looks like it’s build for it

FirebaseApp.configure with multiple FIRApp instances, Analytics use a static approach.

The best case scenario I would love to see:

let application = FirebaseApp.configure(options:) -> FirApp
application.analytics.logEvent()

were the static helper would simply call

Analytics {

  static func logEvent() {
   FirebaseApp.defaultApp.analytics.logEvent()
  } 

}

I understand their could be “lost” analytics, but that’s just our responsibility to call configuration as soon as possible.

• There could be an internal pool to store the events otherwise

And is there any reason why it should be named exactly like that? The init(contentsOfFile:) could parse any plist, if given in a right path.