Ask about bundle identifier for Firebase Crashlytics BigQuery Integration

[fumito-ito]

Hi team !

This is a question about Firebase Crashlytics BigQuery Integration. Currently, the Apple apps registered in my project share the same GoogleService-Info.plist across multiple binaries. For example, the situation is as follows:

• iOS App
  • bundle identifier: com.example.iphone.TheiPhoneApp
  • bundle id on GoogleService-Info.plist: com.example.iphone.TheiPhoneApp
• Apple Watch App for iOS App
  • bundle identifier: com.example.iphone.TheiPhoneApp.watchkitapp
  • bundle id on GoogleService-Info.plist: com.example.iphone.TheiPhoneApp

The following tables have been created in BigQuery:

• firebase_crashlytics.com_example_iphone_TheiPhoneApp_IOS_REALTIME
• crashlytics.com_example_iphone_TheiPhoneApp_IOS
• crashlytics.com_example_iphone_TheiPhoneApp_watchkitapp_IOS

According to firebase document, it states that in legacy behavior, batch tables are created based on the bundle id listed in GoogleService-Info.plist. However, in reality, it appears that tables are being created by referencing the binary’s bundle id rather than the GoogleService-Info.plist.

Could you please clarify which bundle identifier is used in the data that Firebase sends to the server side - the one from GoogleService-Info.plist or the one from the binary’s bundle identifier?

[themiswang]

Hey @fumito-ito ,
Thank you for reaching out and your observation is the correct behavior. For legacy behavior, we will read from the binary’s bundle id and process to the BQ table.

In Crashlytics there are 3 bundle id terminologies:

• The bundle id which directly associated with your app binary
• The bundle id which show up in the GoogleService-Info.plist
• The bundle id you give while trying to create the firebase project on console, refer to:

In legacy behavior, we read from the app binary for the bundle id, which for most of the simple use cases, it matches with the bundle ID in the GoogleService-Info.plist.

For the new export infrastructure, we will read from the bundle id which is registered Firebase App in your Firebase project (refer to the terminology 3).

Let us know if you have any question and we will update the documentation to make the explanation clearer.

[fumito-ito]

@themiswang Thank you for the detailed explanation. It was very clear and helpful.

I have one additional question. I understand that the new export infrastructure references the binary’s bundle identifier and routes data to batch tables for each Bundle ID registered in Firebase App. What would be the behavior if the binary’s bundle identifier is not registered in Firebase App?

[themiswang]

In that case the crash events with unregistered bundle id will still be routed to the registered batch table. Ideally your binary bundle id should be match with GoogleService-Info.plist and Firebase project bundle, but we don't drop/filter the event if it doesn't match. Just be aware then your batch table could contain events from different bundle id and you have to manually separate them.

[fumito-ito]

Thank you for the clarification! That’s very helpful to understand that events with unregistered bundle IDs will still be routed to the registered batch table rather than being dropped.

This gives me a clear picture of how the new export infrastructure works. Thanks again for your support!