[Crashlytics] Xcode16 missing dSYM in Firebase in Debug Builds

[dustin2023]

Description

Issue Description

This is related to issues #13543 and #13764.

The problem is that when building the application with Debug mode on Xcode 16.1, the dSYM files fail to upload to Crashlytics. It worked in latest Xcode 15 version.

The workaround is to disable Debug Dylib Support in the target's Build Settings. However, this causes SwiftUI previews to stop working.

Reproducing the issue

1. Set ENABLE_DEBUG_DYLIB=YES for build options
2. Build the application in Xcode 16.1

Firebase SDK Version

11.4.0

Xcode Version

16.1

Installation Method

Swift Package Manager

Firebase Product(s)

Crashlytics

Targeted Platforms

iOS

Relevant Log Output

11.4.0 - [FirebaseCrashlytics][I-CLS000000] [Firebase/Crashlytics] Packaged report with id '67cba1a19d7b4800a514f208856ed765' for submission
11.4.0 - [FirebaseCrashlytics][I-CLS000000] Submitting report async
11.4.0 - [FirebaseCrashlytics][I-CLS000000] [Crashlytics:Crash:Reports:Event] Sending app_exception event to Firebase Analytics for crash-free statistics
11.4.0 - [FirebaseCrashlytics][I-CLS000000] Completed report submission with id: 67cba1a19d7b4800a514f208856ed765

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[jclardy]

I'm also experiencing this issue on the same setup, Xcode 16.1, Firebase 11.4.0. For now I have a separate previews target for development.

[MichaelVerdon]

Does this issue come up when using the latest version 11.5.0?

[dustin2023]

Does this issue come up when using the latest version 11.5.0?

Sadly, yes. I get the some error and also I figured out that I also get this Warning: warning: (arm64) /Users/dustin/Library/Developer/Xcode/DerivedData/MyAppName-cicejndcecececfe/Build/Products/Debug-iphonesimulator/MyAppName.app/ MyAppName empty dSYM file detected, dSYM was created with an executable with no debug info.

[rizafran]

Thanks for reporting. I tried setting the ENABLE_DEBUG_DYLIB to YES, but I was able to upload the dSYMs in the Crashlytics dashboard, and I'm using Xcode 16.1 to reproduce the issue. May I know if you're encountering any error when uploading the dSYMs?

[MichaelVerdon]

I have reliably been able to reproduce this error achieving the same warning and have been investigating it. Using XCode 16.1 and the current version. No errors come up but the exact same warning comes up after running a test app.

[themiswang]

The warning seems like is from XCode/lldb compiler rather than Crashlytics (https://lldb.llvm.org/cpp_reference/SymbolFileDWARF_8cpp_source.html line655). This is probably something on Apple side, Crashlytics only consumes dSYM which is generated from Xcode. Related conversation on Apple side: https://developer.apple.com/forums/thread/761589?answerId=806733022#806733022

[dustin2023]

The warning seems like is from XCode/lldb compiler rather than Crashlytics (https://lldb.llvm.org/cpp_reference/SymbolFileDWARF_8cpp_source.html line655). This is probably something on Apple side, Crashlytics only consumes dSYM which is generated from Xcode. Related conversation on Apple side: https://developer.apple.com/forums/thread/761589?answerId=806733022#806733022

I opened a new post for this: https://developer.apple.com/forums/thread/768802 Maybe they have a solution. I will share it here as well.

[Harikarthyk]

+1

[CtrlJone]

+1

[grantespo]

+1

[danielshaffer]

+1

[alexanderkhitev]

Hello! Any news/updates?

[girishw]

+1 Maybe related to this ? https://developer.apple.com/forums/thread/761589?answerId=806733022#806733022

[BartoszCichecki]

+1

I literally just started working on a new app. Xcode 16.1 followed configuration, builds correctly. After test crash, there is "Missing dSYM" warning in Firebase console.

Don't know what more info is needed, but script says:

Running upload-symbols in Build Phase mode
Validating build environment for Crashlytics...
Validation succeeded. Symbol uploading will proceed in the background.

so it looks like run thinks everything is ok.

[themiswang]

One thing I realized after update to xcode 16.1 my test app build setting for Debug information format debug mode is changed to DWARF instead of DWARF with dSYM file. Can you double check the build setting and try it again? So far I cannot reproduce the issue using latest version of Firebase SDK. I also gonna send an issue to Feedback Assistance this week regarding with the warning.

[BartoszCichecki]

For me, it's a brand new project created with Xcode 16.1. I checked project file in text editor to make sure DWARF with dSYM file is selected. All other settings in Firebase guide here are correct. Yet, I get both the warning about empty dSYM is there, AND most importantly, dsyms are not uplaoded - console warns about missing dSYM.

Here is a redacted pbxproj with app name/teams removed (extension changed to txt so that github accepts the file): project.txt

[BartoszCichecki]

I tried setting "Enable Debug Dylib Support" to "No", and I confirm - upload start working, but it breaks SwiftUI previews. What is more dSYMs that where uploaded to Firebase are missing version number.

I dont know what is happening here, but it's time to take this more seriously and start being more active here guys.

PS: behaviour is the same with Xcode 16.2 beta 3.

[BartoszCichecki]

@themiswang since you added "needs-info" last, can you share what more info do you need?

[theoks]

We encounter the same issue with version 11.5.0. Any indication when this will be fixed?

[gokhanBozkrt]

+1

[kadirfayzi]

Same issue with version 11.6.0

[morozbogdn]

11.6.0 - same issue

[BartoszCichecki]

Don't worry guys, it's only a "minor" issue stretching several versions of Firebase with over 20 comments confirming it and no response from the team in over a week. We'll get there...

[theoks]

@themiswang this issue is retagged with the needs-info tag. Is there something in particular that any of the users that have commented in this thread can provide, eg like project configuration or logs?

As more and more projects transition to Xcode 16 this is becoming a real issue. Furthermore, manually uploading the dSYMs from the archives, doesn't change anything in the console.

Can someone in the team provide some guidance, workaround or estimate for a fix please?

[BartoszCichecki]

I did some investigations and while I don't hope for the Firebase team to take this seriously anymore here are the findings which are the likely cause of the issue.

When you build the app with Enable Debug dylib support, the structure of the dSYM is different compared to having this setting off or build on Xcode 15 and lower.

First of all, the message we see in logs:

empty dSYM file detected, dSYM was created with an executable with no debug info.

while confusing is NOT a bug. Let me explain.

When you build with Enable Debug dylib support enabled this is the contents of the dSYM for your app:

Notice that DWARF folder now has two files. The first one with no extension is only 8KB and, yes, it IS empty. It does not have any code, because what this option does is it effectively puts all of your code into a dynamic lib - this is the second file that in the picture above is 15,9MB.

Now the fun part: both files should be used for symbolication. When we try to look at UUIDs they have:

UUID: F6E59681-35B6-3E7B-AF46-2CFBD9557194 (arm64) /Users/bartosz/Library/Developer/Xcode/DerivedData/SampleApp-aoqqqukvbpngbebzelwfyxfsiekw/Build/Products/Debug-iphoneos/SampleApp.app.dSYM/Contents/Resources/DWARF/SampleApp
UUID: BF97E804-5141-3AD4-BA65-F7BB3B13A503 (arm64) /Users/bartosz/Library/Developer/Xcode/DerivedData/SampleApp-aoqqqukvbpngbebzelwfyxfsiekw/Build/Products/Debug-iphoneos/SampleApp.app.dSYM/Contents/Resources/DWARF/SampleApp.debug.dylib

obviously they are different. The problem is that most likely Firebase ignores completely the SampleApp.debug.dylib file - which it isn't surprising because AFAIK this has not been a case before in earlier Xcode versions. If it is really the case, that is a mistake on Firebase side.

So why when using the script from the documentation the dSYMs are not uploaded to Firebase?

My guess is that there are some checks ran on the dSYM before upload, to avoid sending garbage. The script looks at the main file, sees that it's empty and skips upload.

This behavior most likely needs to be updated. Just like, most likely whatever does symbolication on Firebase backend also will need an update, to correctly use both files from the dSYM.

My humble opinion is that, this is not "an Apple bug". It's simply a change in how dSYMs are formatted/structured and Firebase needs to adjust to it.

The above investigation/conclusions were confirmed and acknowledged by another vendor providing crash reporting and they started working on a solution.

It just baffles me, how is it possible that absolutely no-one at Google verified if Crashlytics will work with new Xcode. Especially, that it is not like Xcode 16 came out a week ago. It's been TWO MONTHS since Xcode 16 release. And first beta that had this option was release like what? 6 months ago?

This comment marks end of my input into trying to help troubleshoot this issue. I will not waste my time on this, when the Firebase team doesn't give a flying *. I am moving crashlytics to a vendor that takes these things seriously.

[themiswang]

Hey @theoks,

First on our side as me and @rizafran have tried we cannot reproduce the issue, we really appreciate if someone could give us a test app example or steps can actually reproduce the issue as so far on our side we cannot reproduce the issue. Even with the build setting described in the issue I am still see my test app dSYM is getting generated and uploaded as expected.

And @BartoszCichecki, we really appreciate some patient as we are also trying to get solution out. The issue you mentioned is exactly the issue which resolved in https://github.com/firebase/firebase-ios-sdk/issues/13543, so I am surprising it is still not work for some other folks. If it's possible could you send your dSYM or project information from Firebase Support so we can get a further look? +1 and speaking with anger really does not help either you or the community as eventually we all trying to solve the problem.

[google-oss-bot]

Hey @dustin2023. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[theoks]

His @themiswang,

This issue apparently affects a lot of different people. I counted 14 different people in this thread confirming this is indeed an issue that impacts them. 11.6.0 did not fix the issue either.

In our case this is how the console looks like:

This is an issue that has rendered a very crucial submodule of the SDK completely unusable. We are littered with unsymbolicated crashes, that we cannot debug, hurting our users' experience and our bottom line as well.

I understand the difficulty to resolve it when you cannot reproduce it yourselves, but on the other hand you need to understand that it's difficult for us to provide you with more info than "we followed your setup instructions and it doesn't work"—or in some cases it only works intermittently. The ones that know the intricacies of the SDK is the iOS Firebase team. We cannot possibly know what's causing it, and we have no tools to debug it properly, given that this feature requires an orchestration between the client and your backend to work correctly. It's also difficult to hand you over the code we are working on, due to contractual obligations. However it is evident that something changed with the latest Xcode release that affected how dSYMs are exported (as @BartoszCichecki described as well).

I'd request again that someone from your team looks into it again, on a more complex project maybe, and try to find out what's the issue here.

[peterfriese]

Thanks, @theoks - can you share some details about the structure of your app? For example, do you use any app extensions, do you use local packages, etc.?

Does it also occur with a plain new project?