Firebase Crashlytics not reporting crashes in .NET 10 MAUI application and startup crash with iOS linker settings

Question

Firebase Crashlytics not reporting crashes in .NET 10 MAUI application and startup crash with iOS linker settings

Vignesh Palthurai 50

I am facing an issue while integrating Firebase Crashlytics into a .NET 10 / .NET MAUI 10 application using Plugin.Firebase 4.0.0.

Background

I successfully configured Firebase Crashlytics in one .NET MAUI application using the same configuration, and crash reports are being received correctly in the Firebase Crashlytics dashboard.

However, when I apply the same configuration to another MAUI application that uses a different Firebase project, Crashlytics does not receive the crash reports.

Configuration verified

For the second application, I have verified the following:

The application has a unique ApplicationId / iOS Bundle ID.

The correct GoogleService-Info.plist from the second Firebase project is included.

GoogleService-Info.plist is configured as a BundleResource.

The plist contains the required <Link>GoogleService-Info.plist</Link> configuration.

CrossFirebase.Initialize(CreateCrossFirebaseSettings()) is called from WillFinishLaunching.

Crashlytics collection is enabled.

The application has been cleaned and rebuilt.

Firebase Crashlytics currently shows:

“App detected. Waiting for a crash to happen.”

Startup crash caused by recommended linker configuration

According to the recommended configuration, I added the following to the .csproj:

<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">
  <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">
  <_ReferencesLinkerFlags Include="-u __mh_execute_header" />
</ItemGroup>

There is an additional important observation regarding this issue:

When running the application in Debug mode, the application launches and runs successfully even with these linker settings.

However, when I create an IPA with the same linker configuration and install/run it through BrowserStack, the application crashes during startup.

The application crashes before I can reach the application UI, so I cannot reproduce the issue from within the application or capture the exception through normal application logging.

Because the crash occurs in the IPA/Release scenario, I currently do not have the actual exception or stack trace from the application.

When I remove the two linker configuration sections, the IPA launches successfully, but Firebase Crashlytics still remains in the state “App detected. Waiting for a crash to happen.”

This makes the issue particularly difficult to diagnose because Debug works, while the IPA/Release build crashes only when these linker settings are enabled.

Questions

Could you please help investigate the following?

Why do the _ExportSymbolsExplicitly and _ReferencesLinkerFlags settings cause a startup crash specifically in the IPA/Release build?
Why does the application run successfully in Debug mode with these settings but crash when the IPA is created and executed through BrowserStack?
Are these linker settings still required for .NET 10 / MAUI 10 with Plugin.Firebase 4.0.0?
Is there an alternative configuration for iOS that allows Firebase Crashlytics to work without adding these linker settings?
Could this be related to changes in the .NET 10 / MAUI 10 iOS linker/trimmer/AOT build process?
Since the IPA crashes during startup before I can capture an application-level exception, could you please advise how I can obtain the native iOS crash log or linker/AOT diagnostic information needed to identify the root cause?

The main issue is:

Without the linker settings: the application launches successfully, but Firebase Crashlytics does not receive crashes.

With the linker settings: Debug works, but the IPA/Release build crashes during startup when executed through BrowserStack, preventing me from obtaining the application exception.

Could you please advise on the correct configuration for .NET 10 / MAUI 10 + Plugin.Firebase 4.0.0 + Firebase Crashlytics on iOS?

Thank you.

0 comments

1 answer

Your answer

Answer 1

Nguyen Dam (WICLOUD CORPORATION) 595 Microsoft External Staff Moderator

Hello @Vignesh Palthurai , and thank you for reaching out. I was able to narrow this down to a known .NET 10 iOS Release-build issue involving Firebase Crashlytics.

For your questions, here are the answers:

Why do the _ExportSymbolsExplicitly and _ReferencesLinkerFlags settings cause a startup crash specifically in the IPA/Release build?

The startup crash is a known .NET 10 iOS issue with _ExportSymbolsExplicitly=false in Release builds. It's tracked in .NET for iOS issue #25427, and issue #25491 so please refer to them if you want the detailed technical investigation.
The underlying issue has since been fixed in PR #25494 but not available yet in .NET 10.

Why does the application run successfully in Debug mode with these settings but crash when the IPA is created and executed through BrowserStack?

The Debug/Release difference is expected for this issue.
The failure occurs in the Release/native iOS build path, while Debug does not reproduce the same startup failure. BrowserStack is running the generated IPA, so it surfaces the Release-only behavior.

Are these linker settings still required for .NET 10 / MAUI 10 with Plugin.Firebase 4.0.0?

No, these linker settings are not documented as required configuration for Plugin.Firebase 4.0.0 on .NET 10.
The _ExportSymbolsExplicitly=false setting was used as a workaround for the Crashlytics __mh_execute_header symbol issue, but it is affected by the .NET 10 Release-build issue described above. Plugin.Firebase 4.0.0's Crashlytics documentation does not list these linker settings as part of its standard iOS setup.

Is there an alternative configuration for iOS that allows Firebase Crashlytics to work without adding these linker settings?

There is now a confirmed fix for the Release startup crash, but it is not yet available in .NET 10. PR #25494 fixes the underlying strip issue.
Your reported iOS workload is 26.5.10315, while the latest .NET 10 iOS servicing release is 26.5.10318. PR #25494 is not listed in the .NET 10 iOS release notes, so the fix does not appear to be available in .NET 10 yet.

The available options you may want to try are:

Export __mh_execute_header directly through ReferenceNativeSymbol while leaving _ExportSymbolsExplicitly at its default value.

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">
  <ReferenceNativeSymbol Include="_mh_execute_header" SymbolType="Function" />
</ItemGroup>

Use the older toolchain combination documented in issue #25491: Xcode 26.3, workload set 10.0.300, and iOS workload 26.2.10233, with _ExportSymbolsExplicitly=false.
Move to the .NET 11 preview line, where the fix from PR #25494 is available.
~~Update the .NET 10 iOS workload to 26.5.10318 and retest.~~ (note: this approach is tried and didn't work)

Could this be related to changes in the .NET 10 / MAUI 10 iOS linker/trimmer/AOT build process?

Yes, the issue appears to be in the .NET 10 iOS linker/build pipeline.
In particular, issue #25491 reproduces the Release startup failure with a clean MAUI app and shows different results across .NET/iOS workload and Xcode combinations.

Since the IPA crashes during startup before I can capture an application-level exception, could you please advise how I can obtain the native iOS crash log or linker/AOT diagnostic information needed to identify the root cause?

Although there may be no need to collect the crash log now - if you still need to obtain the native iOS crash report from a BrowserStack App Live session, you can do as follows:

Open the BrowserStack App Live dashboard and upload or install the affected IPA.
Start a session using the affected IPA on a real iOS device.
Reproduce the startup crash during that session.
On the App Live vertical toolbar, select iOS Settings.
Under Crash Logs, select Fetch logs.
BrowserStack will download the crash logs as a ZIP file. The ZIP contains the native .ips crash report.

Please do note the logs checked under Console -> Logs are not the native crash report, but rather from iOS Settings -> Crash Logs -> Fetch logs instead. The .ips report contains the Exception Type, Termination Reason, and crashed thread.

In summary, this is a known .NET iOS issue that has already been fixed, but the fix is not yet confirmed to be available in .NET 10. On affected versions, the _ExportSymbolsExplicitly=false workaround can cause the Release build to crash at startup. Until the fix becomes available in .NET 10, you can use the older working configuration mentioned above or try the alternative workaround.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Vignesh Palthurai 50 Reputation points

2026-09-18T11:51:07.44+00:00
Hi @Nancy Vo (WICLOUD CORPORATION) ,

Thank you for the guidance.

I currently do not have access to a physical iOS device, so I am testing the IPA through BrowserStack. I checked the BrowserStack Console → Logs, but the downloaded logs mainly contain iOS system-service messages (SpringBoard, findmylocated, searchpartyd, etc.). I could not find the application crash information containing the Exception Type, Termination Reason, or crashed thread.

The reproducible behavior is:

Debug + linker settings enabled: Application launches and works.

UATMDU IPA + linker settings disabled: Application launches successfully.

UATMDU IPA + linker settings enabled: Application crashes during startup in BrowserStack.

The linker settings are:

<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'"> <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly> </PropertyGroup> <ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'"> <_ReferencesLinkerFlags Include="-u __mh_execute_header" /> </ItemGroup>

Build environment

IDE/Editor: Visual Studio Code Build method: .NET CLI Build configuration: UATMDU

The IPA is generated using:

dotnet clean dotnet build -c UATMDU -f:net10.0-ios dotnet publish -c UATMDU -f:net10.0-ios

.NET SDK: 10.0.103 MSBuild: 18.0.11+c2435c3e0f Workload version: 10.0.111.1

Installed workloads:

iOS: 26.5.10315/10.0.100

MAUI: 10.0.20/10.0.100

macOS: 26.5 macOS Build: 25F71 Architecture: arm64

Xcode: 26.6 Xcode Build: 17F113

There is no global.json in the project.

When the linker settings are removed, the application launches successfully, but Firebase Crashlytics remains at:

“App detected. Waiting for a crash to happen.”

Could you please let me know if there is an alternative way to obtain the native crash report from a BrowserStack iOS Simulator session, since I currently cannot use a physical iOS device?

Thank you.
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-21T02:16:09.55+00:00

Hello @Vignesh Palthurai , I have provided the full response in the original post, which also addresses your follow-up question if you still need assistance with it. Please take a look and let me know if it addresses your concerns. If you have any remaining questions or encounter any further issues, please feel free to ask.
Vignesh Palthurai 50 Reputation points

2026-09-21T14:13:55.2866667+00:00
Hi Nguyen Dam (WICLOUD CORPORATION),

Thank you for your detailed explanation. I have now completed the additional tests and also updated the .NET SDK and iOS workload as suggested.

My current environment is:

.NET SDK: 10.0.401

Workload set: 10.0.401

iOS workload: 26.5.10318

MAUI workload: 10.0.20

Xcode: 26.6

macOS: 26.5

Architecture: arm64

Build configuration: UATMDU

I tested the different configurations with the same Firebase project and Plugin.Firebase 4.0.0 setup.

Test results

1. _ExportSymbolsExplicitly=false

<_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>

The IPA crashes during startup in the Release/UATMDU build.

This behavior is still present even after updating to .NET SDK 10.0.401 and iOS workload 26.5.10318.

2. _ExportSymbolsExplicitly removed

When I remove this setting, the IPA launches successfully.

However, Firebase Crashlytics still does not receive the crash report and remains at:

“App detected. Waiting for a crash to happen.”

3. _ExportSymbolsExplicitly=true

I also tested:

<_ExportSymbolsExplicitly>true</_ExportSymbolsExplicitly>

The IPA launches successfully, but Crashlytics still does not update/report the crash.

I am currently keeping:

<_ReferencesLinkerFlags Include="-u __mh_execute_header" />

enabled.

Current situation

Therefore, the problem appears to be split into two parts:

Setting _ExportSymbolsExplicitly=false allows the Crashlytics symbol workaround but causes a Release startup crash.

Setting it to true or removing it allows the application to launch, but Crashlytics still does not report the crash.

Since I have already updated to the newer .NET 10 SDK and iOS workload and the Release crash still occurs with _ExportSymbolsExplicitly=false, could you please suggest a different supported configuration/workaround for Firebase Crashlytics on .NET 10 / MAUI 10?

In particular, is there another way to make __mh_execute_header available to Crashlytics without using:

<_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>

For example, should I use a different MtouchExtraArgs, exported-symbol configuration, or another Plugin.Firebase/Firebase Crashlytics configuration?

I would prefer not to downgrade Xcode/.NET unless that is the only supported solution, because the application is already using the current .NET 10/Xcode 26.6 toolchain.

Please let me know what configuration you recommend for this scenario.

Thank you for your support.
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-22T04:30:57.1633333+00:00
Hello @Vignesh Palthurai ,

There is another workaround suggested by the .NET for iOS maintainers in issue #25491 that exports the required symbol without setting _ExportSymbolsExplicitly to false:

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'"> <ReferenceNativeSymbol Include="_mh_execute_header" SymbolType="Function" /> </ItemGroup>

(also remove the following so only one mechanism is exporting the symbol)

<_ReferencesLinkerFlags Include="-u __mh_execute_header" />

No separate MtouchExtraArgs or exported-symbol configuration is needed for this, as ReferenceNativeSymbol is the supported way to export the symbol.

Please note that this addresses the Crashlytics startup/symbol problem specifically. There are reports where Crashlytics still does not receive events even after this symbol issue is resolved.

That said, since the application now launches successfully with _ExportSymbolsExplicitly removed or set to true, you may want to look into the Crashlytics side first. The missing crash reports may not be related to these linker settings, but rather to the Crashlytics setup or reporting path in your app. You may want to try forcing a test crash then launch the app again; or check the startup output under Console -> Logs in the BrowserStack session for the [FirebaseCrashlytics] [I-CLS000000] message about the app's main function.

Please give this a try and let me know how it goes. If you have any remaining questions or encounter any further issues, please feel free to ask.
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-24T02:50:32.8866667+00:00

Hi @Vignesh Palthurai , just checking in to see if this worked for you. If you’re still experiencing the issue, please let me know, and I’d be happy to assist further or clarify any points as needed.
Vignesh Palthurai 50 Reputation points

2026-09-24T08:43:33.6366667+00:00
Hi @Nguyen Dam (WICLOUD CORPORATION) ,

Thank you for your support so far.

I have now implemented the ReferenceNativeSymbol workaround:

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'"> <ReferenceNativeSymbol Include="_mh_execute_header" SymbolType="Function" /> </ItemGroup>

and removed:

<_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>

and:

<_ReferencesLinkerFlags Include="-u __mh_execute_header" />

With this configuration, the IPA launches successfully and Crashlytics is able to capture a crash.

I have two applications/build configurations using the same codebase, but with different build configurations:

UATMDU

UATDDU

Each build generates its own IPA and its own dSYM file. I uploaded the respective dSYM generated from each build to the corresponding Firebase Crashlytics application/project.

For the UATMDU build, the crash is being received and processed correctly.

However, for the UATDDU build, I am still facing an issue. I can see the crash as an unprocessed crash, and I have uploaded the dSYM generated specifically from the UATDDU build, but the crash is still not being processed/readable.

Also, the Crashlytics dashboard currently shows 100% no crashes for the relevant application, even though I can reproduce the crash and see the unprocessed crash entry.

Could you please advise what else I should verify for the second application?

Since both applications use the same code but different build configurations, could this be related to the Firebase application configuration, Bundle ID, GoogleService-Info.plist, or the dSYM/UUID matching for the second build?

Thank you.
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-24T10:38:38.4066667+00:00
Hello @Vignesh Palthurai ,

Please check whether Crashlytics reports a missing dSYM UUID. If it does, compare that UUID with the dSYM you uploaded:

dwarfdump --uuid /path/to/YourApp.app.dSYM

If the UUIDs do not match: Upload the dSYM whose UUID matches the one Crashlytics requests. To locate it, check the UATDDU build output under bin/UATDDU/net10.0-ios/ios-arm64/. If you created an .xcarchive, also check its dSYMs folder. Confirm that the dSYM belongs to the IPA tested in BrowserStack before uploading it.

If the UUIDs match: Confirm that

The CFBundleIdentifier inside the UATDDU IPA matches the Bundle ID registered for the UATDDU app in Firebase.

The GOOGLE_APP_ID in the packaged GoogleService-Info.plist matches the App ID shown for that same Firebase app under Project settings > Your apps.

The dSYM was uploaded to that same Firebase app.

If you have any further questions or encounter any remaining issues, please feel free to let me know.
Vignesh Palthurai 50 Reputation points

2026-09-25T08:58:42.56+00:00

Hi @Nguyen Dam (WICLOUD CORPORATION) ,

I built a fresh solution with version 14.4 and checked the UUID for both MDU and DDU.

First, I uploaded the MDU IPA to BrowserStack and triggered a crash, but I didn’t get any unprocessed crash in Firebase.

Then I uploaded the DDU IPA to BrowserStack and triggered a crash. This time I got an unprocessed crash in Firebase. I checked the missing dSYM UUID and compared it with the dSYM UUID from my DDU build, and they matched. I uploaded that dSYM file to the same Firebase app, and the dSYM status changed from Missing to Uploaded.

I also verified the other points you mentioned:

The CFBundleIdentifier inside the UATDDU IPA matches the Bundle ID registered for the UATDDU app in Firebase.

The GOOGLE_APP_ID in the packaged GoogleService-Info.plist matches the App ID shown under the same Firebase app.

The dSYM UUID matches the missing UUID and was uploaded to the correct Firebase app.

After the dSYM upload, the unprocessed crash disappeared, but Crashlytics is still showing 100% / No crashes, and I’m not seeing the crash report.

Could you please suggest what else we can check next?
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-25T10:54:27.9766667+00:00
Hi @Vignesh Palthurai ,

In case you haven’t already, please:

Relaunch the UATDDU app after triggering the crash, as Crashlytics sends pending reports on the next launch.

Clear the Event type and Version filters, expand the time range, and check whether the events appear under another event type or version.

Check the debug logs from the next app launch for a message indicating that report submission completed.

Based on the logs:

Submission message absent: Use the relevant debug logs to troubleshoot the Crashlytics reporting path or share them here if you need support.

Submission message present: Verify the selected Firebase app, app version, dashboard time range, and filters.

A confirmed submission with no available report would indicate that the remaining issue concerns Crashlytics processing or the Firebase dashboard rather than the .NET MAUI build. In that case, please contact Firebase Support with the logs, dSYM UUID, app version, approximate crash time, and screenshots so they can investigate the report’s processing status.

If Firebase identifies a .NET MAUI build or runtime issue, please share its findings here, and I’ll be happy to help if you still need support.
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-29T02:00:12.1+00:00

Hi @Vignesh Palthurai

Just following up as I haven't seen an update recently. If you're still working on this issue or need any further assistance, please feel free to reach out.
Vignesh Palthurai 50 Reputation points

2026-09-29T07:39:08.13+00:00
Hi @Nguyen Dam (WICLOUD CORPORATION) ,

I’m still working on this issue and I also followed the steps you suggested.

I tested the UATDDU app using two different ways to trigger a fatal crash:

Using a command-bound button:

private void TestFirebaseCrash() { throw new Exception("Fatal Firebase Crash Test"); }

Using CrossFirebaseCrashlytics.Current and abort() on iOS:

CrossFirebaseCrashlytics.Current.Log("About to trigger fatal test crash via abort()"); abort();

I also relaunched the UATDDU app after triggering the crash, but I still don’t see any new crash report in Firebase Crashlytics.

I cleared the Event Type and Version filters and checked the available time range as well, but there is still no crash report.

For the new build/version, I’m not even getting an Unprocessed crash or a Missing dSYM notification. Firebase is not showing the new crash at all, so it is not reaching the stage where it asks me to upload the dSYM.

I also verified the CFBundleIdentifier, GOOGLE_APP_ID, and dSYM UUID for the UATDDU Firebase app, and they are matching correctly.

Additionally, I tested by debugging the exception and confirmed that the exception reaches the Crashlytics call:

CrossFirebaseCrashlytics.Current.RecordException(ex);

So the exception is reaching RecordException(ex), but I’m still not seeing the crash/report in the Firebase Crashlytics dashboard.

Could you please advise what else we can check to determine why the report is not appearing in Firebase?

Thank you for your support.
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-29T09:01:52.45+00:00

Hello @Vignesh Palthurai ,

Thank you for the detailed update and for completing the additional troubleshooting steps.

The original .NET iOS linker issue has been resolved with ReferenceNativeSymbol; the remaining issue concerns UATDDU reports not appearing in Firebase Crashlytics.

Because the remaining investigation concerns Crashlytics report submission, processing, or dashboard visibility, it falls outside the scope of .NET MAUI support. I recommend contacting Firebase Support and providing the troubleshooting results, debug logs, dSYM UUID, app version, approximate crash time, and relevant screenshots so that the Firebase team can investigate the report status from their side:

https://firebase.google.com/support/troubleshooter/crashlytics

This is a non-Microsoft website. The page appears to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classified as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

If their investigation identifies a .NET MAUI, .NET for iOS, linker, AOT, or runtime issue, please feel free to share their findings in a new Microsoft Q&A thread, and we will be glad to assist further.

For the original .NET iOS issue, you may also follow this guide to provide your confirmation if the solution addressed it.

Thank you for your understanding.
Vignesh Palthurai 50 Reputation points

2026-09-29T11:23:35.2433333+00:00

Hi @Nguyen Dam (WICLOUD CORPORATION) ,

Thank you for your support and for helping me troubleshoot this issue.

The ReferenceNativeSymbol solution resolved the original .NET iOS linker issue, and I appreciate your guidance throughout the investigation.

I’ll proceed with Firebase Support for the remaining Crashlytics reporting issue and will share their findings if they identify anything related to .NET MAUI or .NET for iOS.

Thank you again for your help.
Nguyen Dam (WICLOUD CORPORATION) 595 Reputation points Microsoft External Staff Moderator

2026-09-30T02:37:29.53+00:00

Hi @Vignesh Palthurai

I’m glad to hear that the original issue has been resolved. Thank you for your patience and cooperation throughout the investigation.

If you encounter any other Microsoft-related issues in the future, please feel free to reach out on Microsoft Q&A. We’ll be glad to assist.

I also hope the additional information I provided was helpful. If it does, kindly follow this guide, as it can help indicate to other users that the answer may be useful to them as well. Thank you.

Firebase Crashlytics not reporting crashes in .NET 10 MAUI application and startup crash with iOS linker settings

Background

Configuration verified

Startup crash caused by recommended linker configuration

Questions

1 answer

Build environment

Test results

Current situation

Your answer