firebase / firebase-ios-sdk

Firebase SDK for Apple App Development
https://firebase.google.com
Apache License 2.0
5.55k stars 1.45k forks source link

FirebaseApp.configure(options: options) not loads data when passing FirebaseOptions #230

Open ashhanai opened 7 years ago

ashhanai commented 7 years ago

Describe your environment

Describe the problem

In my app, I have more targets and configurations which require more GoogleServices-Info.plists. I have them all downloaded from firebase console after registering new apps.

On app launch, I am trying to load FirebaseOptions from plist at file path via FirebaseOptions(contentsOfFile: plistPath). Finding plistPath via Bundle.main.path(forResource: plistName, ofType: "plist") (every plist have different name). Although path to plist is found and init is returning FirebaseOptions instance, returned instance is empty.

FirebaseApp.configure(options: options) is then complaining about not finding plist named GoogleService-Info.plist.

Steps to reproduce:

PlistName is different than GoogleService-Info.

guard let plistPath = Bundle.main.path(forResource: plistName, ofType: "plist") else {
    fatalError()
}

guard let options = FirebaseOptions(contentsOfFile: plistPath) else {
    fatalError()
}

FirebaseApp.configure(options: options)
paulb777 commented 7 years ago

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

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

ashhanai commented 7 years ago

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.

baolocdo commented 7 years ago

I don't think it must be named "GoogleService-Info.plist". Can you check whether the plist file is in the correct bundle or linked properly? Can you double check with the code below? [[NSDictionary dictionaryWithContentsOfFile:plistPath]

ashhanai commented 7 years ago

[[NSDictionary dictionaryWithContentsOfFile:plistPath] works properly. Now I noticed, that FirebaseOptions init works just fine, but FirebaseApp.configure(options: options) cannot handle the passing options and is trying to find "GoogleService-Info.plist" anyway.

So it is a different issue after all.

ashhanai commented 7 years ago

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
ryanwilson commented 7 years ago

Currently, Firebase Analytics depends on the GoogleService-Info.plist file internally, so that's the issue you're seeing. It's something we're working on, I don't believe there's a workaround for you unfortunately.

paulb777 commented 7 years ago

FirebaseCore is checking for GoogleService-Info.plist by name at https://github.com/firebase/firebase-ios-sdk/blob/master/Firebase/Core/FIROptions.m#L103

ashhanai commented 7 years ago

@paulb777 I believe that this check is executed only when you are loading default plist, than it should be named "GoogleService-Info.plist"

@ryanwilson Ok, thank you for this insight :)

baolocdo commented 7 years ago

If it doesn't pass the Options from the plist, then the options is probably wrong. Did you rename the GoogleService-Info.plist that you downloaded from the Firebase dashboard? Did you see any logs in this init: https://github.com/firebase/firebase-ios-sdk/blob/master/Firebase/Core/FIROptions.m#L206

baolocdo commented 7 years ago

Sorry, I have just noticed the log @ashhanai gave us:

[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

So it looks like the GoogleService-Info.plist was parsed just fine. There is no problem with Firebase Core. Now, Analytics has such error message because it requires a static plist file instead of run-time options. We deliberately output the message to let you know that there could be some events very early in the app life cycle that requires the Google App ID, so you potentially miss some data. In conclusion, we recommend to have a static GoogleService-Info.plist file (https://firebase.google.com/docs/ios/setup)

tuantmdev commented 6 years ago

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

morganchen12 commented 6 years ago

You can, you just may miss out on very early analytics info.

morganchen12 commented 6 years ago

Closing due to inactivity.

tedgonzalez commented 6 years ago

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

morganchen12 commented 6 years ago

@useeless37 you can create FIRApp instances from different plist files. Analytics in particular uses one of a specific name to capture events very early on in the app lifecycle.

54lihaoxin commented 6 years ago

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.

sinofool commented 6 years ago

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.

ryanwilson commented 6 years ago

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.

matelo commented 6 years ago

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()

mmynarski commented 5 years ago

Little bit more insight on that one. I have project with Firebase and switching names in runtime using FirebaseOptions(contentsOfFile: filePath)

It was working well on Xcode 9.4.1, but after update to Xcode 10 I have an output FirebaseOptions([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:: filePath)

And debugview at firebase panel doesn't even see the device (simulator ¯_(ツ)_/¯)

lifely commented 5 years ago

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.

forsen commented 5 years ago

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.

ryanwilson commented 5 years ago

@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.

bbhagat commented 5 years ago

Hello everyone,

We have had the same problem of Analytics not working when initializing FIR instances runtime. Is there any time frame that can be provided for the fix? We have also seen this problem on Android and will it be fixed for both platforms or just iOS?

Background: We are moving from google analytics to firebase and we need support for ability to switch firebase app runtime. More information:

https://stackoverflow.com/questions/53878190/configure-multiple-firebase-projects-runtime-in-ios-application-and-firebase-goo/53887107#53887107

Regards, Bhavik

ryanwilson commented 5 years ago

@bbhagat sorry for the delay, we're working on the docs to make it more clear.

As Paul mentioned in the stackoverflow question there's a workaround where you can have two files named GoogleService-Info.plist in different folders and include them in different targets for your application.

While this isn't exactly the ability to switch at runtime, it's the current supported setup. Unfortunately I don't have a timeline to share with you about any further resolution.

bbhagat commented 5 years ago

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

rcresnik-zz commented 5 years ago

Any options of NOT using plist files? They're not the most secure way of storing keys in an app and would prefer to not use em.

oflannabhra commented 5 years ago

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)
}
damianun commented 5 years ago

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

ir-fuel commented 5 years ago

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.

vg-identance commented 5 years ago

In our case we need to use more than one analytics instances at same time. So waiting for customizing Analytics by different App instance too.

bbhagat commented 5 years ago

@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.

bbhagat commented 4 years ago

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

bbhagat commented 4 years ago

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

andreamazz commented 4 years ago

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.

cornr commented 4 years ago

This is also an issue for us as we are having multiple stages (debug/beta/release). A naming scheme GoogleService-Info.${STAGE}.plist would be a lot easier to handle.

@andreamazz thanks for the workaround.

paulb777 commented 4 years ago

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

arthurgivigir commented 4 years ago

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?

Screen Shot 2020-07-15 at 13 57 11
itsdamslife commented 4 years ago

Even I am getting this issue. But my context is I am building a macOS standalone process, a command line tool. I am trying to integrate crashlytics into it. I manage to fix all other issues with bundle identifier etc. But not able to run the script in build phases as per the documentation.

error: Could not get GOOGLE_APP_ID in Google Services file from build environment FirebaseCrashlytics/upload-symbols: FirebaseCrashlytics/upload-symbols: cannot execute binary file

itsdamslife commented 4 years ago

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?

Screen Shot 2020-07-15 at 13 57 11

@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.

madhuch073 commented 3 years ago

@arthurgivigir I am also having same issue. Did u find any solution ?

david-var commented 2 years ago

Any updates on runtime configuration? We are configuring our app on run time, after login, depending on the user type and prod/development env. And facing the same problem as others, so we cant do that at build time.

schornon commented 2 years ago

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: Снимок экрана 2022-05-04 в 09 56 20 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: Снимок экрана 2022-05-04 в 10 15 29

  4. Open Target Build Phases, tap + icon, New Run Script Phase and add the following script: Снимок экрана 2022-05-04 в 10 19 36

# 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!

david-var commented 2 years ago

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.

sbhmajd commented 2 years ago

I just did log event successfully in Debug View at firebase console as following:

let options = FirebaseOptions(googleAppID: googleId, gcmSenderID: gcmId) options.apiKey = apiKey options.projectID = projectId options.bundleID = bundleId FirebaseApp.configure(options: options)

Then used Analytics.logEvent to send event with -FIRDebugEnabled and -FIRAnalyticsDebugEnabled in scheme args.

Every thing seems initialized and correctly configured even in Xcode logs, but FirebaseAnalytics logs tell something else 🙃 ?

[FirebaseAnalytics][I-ACS024000] Debug mode is on [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 [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) [FirebaseAnalytics][I-ACS023007] Analytics v.9.4.0 started [FirebaseAnalytics][I-ACS029014] Successfully parsed a configuration. [FirebaseAnalytics][I-ACS023016] Analytics is ready to receive events

I don't event have GoogleService-Info.plist in the project.

username0x0a commented 1 year ago

+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. 🙏

ghost commented 1 year ago

Is there any update on this subject? It's open since 2017..

jozefvodicka commented 9 months ago

Any update?

mkj-is commented 9 months ago

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.

paulb777 commented 9 months ago

Thanks @mkj-is Can you show the Instruments logs where you measured the slow plist reading and parsing?