Firebase Crashlytics doesn't detect any bugs (NET 8)

[juniorsaraviao]

I'm currently using the Plugin.Firebase.Crashlytics package to run Crashltytics services on my app, but it doesn't detect any bugs on the dashboard (I'm pointing NET MAUI v8.0.100). According to this comment, it might be an issue in the native firebase crashlytics sdks.

when I use Plugin.Firebase.Crashlytics (v2.0.1) and NET Maui (v7), the dashboard detects the app even if there's no bug reported

Is there any workaround to solve this?

[ultimategrandson]

This is also happening to me, recently updated to .NET 8.0, prior to this it was working.

From what I could gather the "__mh_execute_header" needs to be in the Exported Symbols File (or not have the Exported Symbols File included at all in the build settings) in Xcode - I haven't worked out how to do this. Anyone have any ideas?

[rjhind]

I'm seeing this also. Have temporarily reverted to AppCenter for crashes as that is working with Net 8 (Maui app).

This is using Xamarin.Firebase.iOS.Crashlytics package.

[MarkMcCormackSF]

Same here, this was working when using Plugin.Firebase.Crashlytics v2.0.5 + .NET 6.0. Due to other constraints like Microsoft basically shooing everyone off .NET 6.0 for MAUI we had to upgrade (BTW .NET 7.0 was a complete utter mess, we had to skip that and go straight to .NET 8.0).

Thankfully, as poster above has mentioned, I've got AppCenter and Application Insights integrated that still work.

It is a shame, however, the dashboard UI for Firebase is probably the best of the 3.

However, by this point of using .NET/MAUI I am completely expecting anything to break at any minute when something is updated, so not really surprised when I tracked it down to an error in the iOS device logs saying Crashlytics wasn't working any more.

[Cheesebaron]

We made our own bindings for Crashlytics using .NET8 and it has the same issue. When the App starts and calling Configure() we get the same message:

FirebaseHelper started
2024-01-31 11:04:32.600632+0100 TrackMan.DrivingRangeApp.iOS[13088:173891] [Firebase/Crashlytics] Version 10.20.0
FirebaseHelper ended
2024-01-31 11:04:32.617119+0100 TrackMan.DrivingRangeApp.iOS[13088:173960] 10.20.0 - [FirebaseCrashlytics][I-CLS000000] Crashlytics could not find the symbol for the app's main function and cannot start up. This can be resolved 2 ways depending on your setup:
1. If you have Exported Symbols File set in your Build Settings, add "__mh_execute_header" as a newline in your Exported Symbols File.
2. If you have -exported_symbols_list in your linker flags, remove it.
2024-01-31 11:04:33.379659+0100 TrackMan.DrivingRangeApp.iOS[13088:173962] 10.20.0 - [FirebaseCrashlytics][I-CLS000000] Crash reporting could not be initialized

[cho-trackman]

Here is a workaround:

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

Note that it will increase the size of the build (see https://github.com/xamarin/xamarin-macios/commit/e3088879a619ba2af5d5d739d1d212243e810f24).

See @rolfbjarne 's explanation in this comment: https://github.com/xamarin/xamarin-macios/issues/19157#issuecomment-1798534439

[ultimategrandson]

Here is a workaround:

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

Note that it will increase the size of the build (see xamarin/xamarin-macios@e308887).

See @rolfbjarne 's explanation in this comment: xamarin/xamarin-macios#19157 (comment)

Brilliant!

I did a quick test, and this seems to work. In my case, the size increase was ~1mb.

[MarkMcCormackSF]

Here is a workaround:

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

Note that it will increase the size of the build (see xamarin/xamarin-macios@e308887).

See @rolfbjarne 's explanation in this comment: xamarin/xamarin-macios#19157 (comment)

Hey, thanks a lot for this. I can confirm that works for my iOS .NET 8 build too.

It's a shame there isn't any .NET stack trace for .NET errors/exceptions with Crashlytics (like there is with AppCenter and Application Insights) but it's worth it to have the Analytics working again.

[cho-trackman]

@MarkMcCormackSF The Kotlin devs are asking the same question: https://github.com/firebase/firebase-ios-sdk/issues/10030 🙃

[Lapinou42]

Here is a workaround:

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

Note that it will increase the size of the build (see xamarin/xamarin-macios@e308887).

See @rolfbjarne 's explanation in this comment: xamarin/xamarin-macios#19157 (comment)

Thank you ! I can confirmed it works for me too on iOS .Net 8.

[rjhind]

Here is a workaround:

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

Note that it will increase the size of the build (see xamarin/xamarin-macios@e308887).

See @rolfbjarne 's explanation in this comment: xamarin/xamarin-macios#19157 (comment)

Yep, worked for me too, thanks!

[vhugogarcia]

Hello friends, I'm facing the same issue, however, the workaround did not work for me. I'm using .NET MAUI 8.0.14 - iOS 16.4+

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

However, it worked on for MacCatalyst, which is strange, on iOS I still keep getting the error:

[FirebaseCrashlytics][I-CLS000000] Crashlytics could not find the symbol for the app's main function and cannot start up. This can be resolved 2 ways depending on your setup:
1. If you have Exported Symbols File set in your Build Settings, add "__mh_execute_header" as a newline in your Exported Symbols File.
2. If you have -exported_symbols_list in your linker flags, remove it.

Do you know of any other workaround or a potential change I need to apply? thanks in advance

Note: I also tried by adding <MtouchNoSymbolStrip Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">True</MtouchNoSymbolStrip> without luck.

[Cheesebaron]

@vhugogarcia even if you get these to work, it won't help much as the stack traces are pretty useless as it doesn't show any of the managed stack.

[MarkMcCormackSF]

@vhugogarcia even if you get these to work, it won't help much as the stack traces are pretty useless as it doesn't show any of the managed stack.

Yes, I still don't have stack traces for iOS, I do have for Android. Typically, the best thing that has managed stack traces for BOTH iOS & Android is being pulled by Microsoft within a year .. you can't make this stuff up, let's get rid of the thing that works really well.

"Visual Studio App Center is scheduled for retirement on March 31, 2025"

Yeah, thanks for that Microsoft.

[mahebisht]

I can not see the error on FirebaseCrashlytics dashboard in release mode for IOS. I am running app on release mode locally while device (IPhone) is connected. Only xamarin_find_protocol_wrapper_type error is visible on Crashlytics dashboard.

[Cheesebaron]

@vhugogarcia even if you get these to work, it won't help much as the stack traces are pretty useless as it doesn't show any of the managed stack.

Yes, I still don't have stack traces for iOS, I do have for Android. Typically, the best thing that has managed stack traces for BOTH iOS & Android is being pulled by Microsoft within a year .. you can't make this stuff up, let's get rid of the thing that works really well.

"Visual Studio App Center is scheduled for retirement on March 31, 2025"

Yeah, thanks for that Microsoft.

To be honest. This is something Google should be supporting and not Microsoft for this specific library. But they are also a bit tone deaf :) Other vendors like Sentry, Raygun etc. make their own binding libraries with support for net?-android and net?-ios, why shouldn't Firebase not do so and rely on MS to do it?

I get it Firebase is nice and has great tooling that spans widely, but this is not a Microsoft responsibility to support.