Crashlytics, I'm also experiencing same problem. This is sending me the crash report in debug mode, but when I use signing the build and push to TestFlight it is not sending me the report.

Same here 👎

We also have the same problem

Also, seeing the same issue with an app not using CocoaPods installation. Using Firebase/Crashlytics (6.16.0).

I have tried with both pods and with static framework linking using 6.18.0

For others with the same issue, are you seeing the same log from Crashlytics and InstanceID? Eg:

[Firebase/Crashlytics][I-CLS000000] An application must have a valid bundle identifier in its Info.plist
...
[Firebase/InstanceID][I-IID003014] Error while reading embedded mobileprovision Error Domain=NSCocoaErrorDomain Code=260 "The file “embedded.mobileprovision” couldn’t be opened because there is no such file." UserInfo={NSFilePath=/private/var/containers/Bundle/Application/71738F66-30A3-4D4E-A60E-85F7FB3614AC/X.app/embedded.mobileprovision, NSUnderlyingError=0x282bc5b00 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

Crashlytics gets the app's bundle identifier using [[NSBundle mainBundle] bundleIdentifier] - this seems to be returning empty.

If this is happening with both Firebase 6.15.0 and 6.18.0, it seems unlikely a code change caused this to happen, since many apps have successfully released to the App Store in that timeframe with Crashlytics. I'm trying to figure out what could have changed with Apple's signing that would cause this. It seems like files in general can't be opened from Crashlytics and InstanceID.

• Are there other errors in the logs that indicate an issue with opening files?
• Does anyone's app successfully read from the bundle identifier, but see Crashlytics fail to?

@samedson we are using [[NSBundle mainBundle] bundleIdentifier] in our app, and the method seems like working fine. Only Crashlytics has difficulties with accessing this identifier.

@samedson

• Are there other errors in the logs that indicate an issue with opening files?

Haven't found any additional errors.

• Does anyone's app successfully read from the bundle identifier, but see Crashlytics fail to?

We are reading other files like translations of third party SDK's, so access is working fine. Also getting [[NSBundle mainBundle] bundleIdentifier] works as expected.

Want to ask a few more questions. I still haven't determined the root cause of the issue - wondering if maybe something changed with the timing of calling [NSBundle mainBundle] in iOS.

• How are you initializing Firebase? Is it with a call to [FIRApp configure] in the App Delegate?
• Was there some point where Crashlytics stopped working in new versions of your app, or is this the first time you've tried to ship with Crashlytics?
• What is your CocoaPods configuration?

@samedson

How are you initializing Firebase? Is it with a call to [FIRApp configure] in the App Delegate?

Yes

Was there some point where Crashlytics stopped working in new versions of your app, or is this the first time you've tried to ship with Crashlytics?

A new app under development but on TestFlight.

What is your CocoaPods configuration?

Not using CocoaPods.

@samedson

• How are you initializing Firebase? Is it with a call to [FIRApp configure] in the App Delegate?

FirebaseApp.configure() in App Delegate

• Was there some point where Crashlytics stopped working in new versions of your app, or is this the first time you've tried to ship with Crashlytics?

We've just tried to migrate from Fabric SDK to Firebase SDK. There were no issues with Fabric SDK, so we've migrated back. Today I've received an email from Google that Fabric services will be held up and running until early May.

• What is your CocoaPods configuration?

  pod 'Firebase/Core'
  pod 'Firebase/Messaging'
  pod 'Firebase/RemoteConfig'
  pod 'Firebase/Crashlytics'
  pod 'Firebase/Analytics'

Seems like that issue is connected to this one (also problems with bundle context):
#5092

Apologies, but I'm unable to reproduce the issue. Could you provide a project that reproduces the issue (if I build it for App Store distribution)?

From #5092, can you try setting FirebaseAppDelegateProxyEnabled to NO in your Info.plist and manually implement the delegate methods, to see if that resolves the issue?

I'm getting exactly the same error:

6.21.0 - [Firebase/Crashlytics][I-CLS000000] An application must have a valid bundle identifier in its Info.plist
6.21.0 - [Firebase/Crashlytics][I-CLS000000] Crash reporting could not be initialized
6.21.0 - [Firebase/InstanceID][I-IID003014] Error while reading embedded mobileprovision Error Domain=NSCocoaErrorDomain Code=260 "The file “embedded.mobileprovision” couldn’t be opened because there is no such file." UserInfo={NSFilePath=/private/var/containers/Bundle/Application/6AB4F02F-538A-4D3D-A29F-99FB98CE2532/XXX.app/embedded.mobileprovision, NSUnderlyingError=0x281964090 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

@Hans92 from #5092, have you tried setting FirebaseAppDelegateProxyEnabled to NO in your Info.plist and manually implement the delegate methods, to see if that resolves the issue?

FirebaseAppDelegateProxyEnabled is set to NO. I thought that it could be caused by different Info.plistfilename, but nope, it's not that.

How can I debug this and help you find the cause?

Seeing the same issue with Firebase/Crashlytics 6.22.0. In fact, we’re seeing this with enterprise builds too. This seems to happen with any build with a Release configuration.

Some ways folks can help cc @Hans92:

• Posting an Xcode project that reproduces the issue. You can also reach out to support and send via that channel.
• Before and after Firebase Initialization, printing the bundlepath in a project that reproduces the issue
• Trying out other configurations or code setups to see if the issue can be resolved

Questions still remaining:

• @pmfon (and others) when you build in Release, but don't ship to TestFlight / App Store / Enterprise, do you see the same logs, An application must have a valid bundle identifier in its Info.plist? You can do this by going to "Edit Scheme" and updating the Run "Build Configuration" to "Release" or "App Store"?
• Do folks here have an AppDelegate (or other shared app code) that gets pulled in via a framework by chance? This issue seemed to indicate there were problems with that: [FIRApp configure] changes context of AppDelegate bundle #5092

Notes thus far:

• I've tried reproducing this with an app using Cocoapods and Xcode 11.3.1, but did not reproduce the issue.
• Firebase versions affected: 6.15.0, 6.18.0, 6.22.0
• Seems that this is an issue regardless of whether Cocoapods or the manually-installed frameworks are used
• This code has been in Crashlytics for years (even the Fabric version pre 4.0.0-beta.1 release). At this time I don't believe a change in Crashlytics caused this issue, but it's possible there is code in FirebaseCore or another dependency that is causing this. I don't believe removing the check for bundle ID will resolve this as Crashlytics uses the bundle ID for many other things.

Digging into the code, here's where this check is:

• https://github.com/firebase/firebase-ios-sdk/blob/master/Crashlytics/Crashlytics/Controllers/FIRCLSReportManager.m#L526
• https://github.com/firebase/firebase-ios-sdk/blob/master/Crashlytics/Crashlytics/Settings/Models/FIRCLSApplicationIdentifierModel.m#L49
• https://github.com/firebase/firebase-ios-sdk/blob/master/Crashlytics/Crashlytics/Components/FIRCLSApplication.m#L28
• Which just boils down to a call to [[NSBundle mainBundle] bundleIdentifier].
• kondratk's comment AppStore Distribution / Release app does not send crashes due to Exported Symbols File missing __mh_execute_header #5020 (comment) indicates that calling [[NSBundle mainBundle] bundleIdentifier] in their app works, just not Crashlytics' call

One solution to "The file “embedded.mobileprovision” couldn’t be opened because there is no such file at https://stackoverflow.com/a/43473088/556617

@samedson
I think it fails at an earlier point. The FIRCLSApplicationIdentifierModel initialiser might return nil. That would cause the An application must have a valid bundle identifier in its Info.plist message.

We were able to reproduce this in the simulator with a release configuration.

A bit more detail, the dlsym call here is returning NULL

Great find @pmfon - now to figure out why this will fail in App Store signed apps. Going to do some research

Great find @pmfon - now to figure out why this will fail in App Store signed apps. Going to do some research

Here’s what we found so far

• the difference seems to be between debug and release versions (not necessarily signed, since it can be reproduced in the simulator)
• disabled striping in the release build and the symbol still can’t be found though it’s in the binary if you check with ‘nm’
• only changed the main project settings, the Pods configs were not touched
• calling dlsym from the AppDelegate has the same effect
• the legacy SDK (integrated with CocoaPods), with the same project configuration, works

Huh I still can't get it to happen on my end - I'm running in "Release" configuration in my Scheme, and have stripping on, but it doesn't reproduce the issue. Hoping to narrow it down to a few settings.

Would you be able to export the build settings that reproduce this (removing any PII - I see bundle IDs and paths in there)?

cd <your-project-directory>
xcodebuild -scheme "<your-app-scheme>" -showBuildSettings

What about the configuration name? I don't use default Debug and Release names but Debug, Release-AppStore and Release-AdHoc.

Right now the main thing that will help me debug this is an xcode project that reproduces the issue.

I don't feel confident in shipping a fix without being able to reproduce the issue because that dlsym call that's returning NULL is important for the Crashlytics SDK to function - skipping the call or some other workaround will cause other negative side effects.

I did try out duplicating the Release configuration with a new name, but did not reproduce the issue.

@samedson
Found it. The project sets Exported Symbols File in Release builds. This file is empty.

That seems to be the problem @pmfon. Reproduced it locally!

Can you try adding __mh_execute_header as a new line to your Exported Symbols File? That fixes the issue in the quickstart.

Going to work on logging help customers address this issue.

Gonna close this for now - but feel free to reopen if the following fix doesn't work for you. I've added logging in the SDK to give a clearer error message when this happens.

Fix

For those running into this issue, the fix is:

• Find the "Exported Symbols File" setting in your Xcode Build Settings
• Open the file that's set for that
• Add __mh_execute_header as a newline to that file

@samedson what if I don't have anything in Exported Symbols File and this field is blank?

@Hans92 from what I understand that means your build process is not exporting a symbols file. You should set a filepath in the field in Xcode, and Xcode will generate an exported symbols file there when you build your app.

A newly created project with Xcode 11.3.1 has nothing in Exported Symbols File. Should I create this file somewhere?

This doesn't make any sense.

I have several projects that uses Firebase. Only two are affected by this problem, but none of the projects use an Exported Symbols File.

I've created a new project that's effectively an empty app with Firebase SDK integrated, with no Exported Symbols File set and it's reporting crashes just fine.

Let me clarify:

• Crashlytics does not require the Exported Symbols File build setting. Your app will work without it. But if you do set that build setting (for some other reason), you must add __mh_execute_header to the file.
• The current understanding is this GitHub issue only impacts apps that have set Exported Symbols File, and do not add __mh_execute_header to it.
• If you're finding that your app is impacted by this issue, as indicated by the following log, we need to investigate further and see if there are other build settings that could be causing it.

[Firebase/Crashlytics][I-CLS000000] An application must have a valid bundle identifier in its Info.plist

The project related to this issue has nothing in the Exported Symbols File

Unfortunately, the issue still exists. The same as @Hans92 I don’t use exported symbols file.

@kondratk and @Hans92 are you seeing

[Firebase/Crashlytics][I-CLS000000] An application must have a valid bundle identifier in its Info.plist

in your app's logs? We're currently experiencing a delay in crash processing which may be causing crashes to not appear in console that's unrelated to this issue.

Googlers see outage number 19770

@kondratk @Hans92 the issue could be caused by another build setting or flag which strips that symbol from the binary, such as 'fvisibility' or 'Symbols hidden by default' (or even a run-script phase from another framework). Note that I've never found the 'embedded.mobileprovision' error in my logs.

Symbols hidden by default has a default value in my project.