Xcode 16 warning about missing symbols of static framework

Pretty much the same issue here

. Ensure that the archive's dSYM folder includes a DWARF file for EzCCS.app with the expected UUIDs

Hello same issue here, do we have a solution for this?

This is a new warning in Xcode 16 where if you're missing a dSYM, Xcode lets you know in case you aren't expecting that — this is to reduce scenarios where you won't are able to fully symbolicating frames coming from your app's code in crash reports. In some cases, you may not have a dSYM, such as a closed source library from a vendor, and in those cases, the warning is safe to discard.

For those developing or using libraries that are statically linked, I was not able to reproduce this warning using either the example XCFramework attached in the bug reports noted in this thread, or by doing some simple testing with libraries that I know are popular in the iOS developer community and also statically linked. For the purposes of these tests, I'm creating a brand new Xcode project, adding the library through a Swift package, and making at least function call into the library so that it doesn't appear as dead code that can be eliminated as a release optimization. For these tests, the Xcode archive contains only the dSYM for the app, as the library code coming in from the XCFramework is merged into the main app's binary at link time, rather than it remaining as a separate dynamic library in the app, which would have a separate dSYM file. If you have a scenario with a straight forward test project set up using a statically linked library in an XCFramework that still unexpectedly gives you this warning about a missing dSYM file when uploaded, I'd like to see that project — please feel free to share a link to it so I can look at it further.

I also did some tests with some libraries popular among the iOS community that are dynamically linked and closed source (with no dSYM provided), and in those circumstances, I did receive the warning, but that warning is expected in that situation.

—Ed Ford,  DTS Engineer

I do not get this error when i am exporting the ipa generated from Xcode and uploading through transporter.

@DTS Engineer Any ETA on fixing this ? Thanks!

I'm seeing this as well on a project using multiple home-built dynamically linked xcframeworks, but they are packaged as a zip file in a single cocoapod. I think cocoapod is the culprit here.

Linking Firebase static frameworks via Swift Package Manager reliably reproduces the issue. See https://github.com/firebase/firebase-ios-sdk/issues/13551 and https://github.com/firebase/firebase-ios-sdk/issues/13764

@paulb777, it's likely that the frameworks are not static, but dynamic. Here's a test I just ran that produced dynamic libraries. Firebase is a third-party library with its own support from its vendor and not Apple, so I'm configuring it in an Xcode project here for testing in the simplest way possible for vetting what's happening with Xcode, rather than what's happening with Firebase:

1. File > New Project > iOS app.
2. Add a package dependency to https://github.com/firebase/firebase-ios-sdk
3. Select FirebaseAnalytics and add it to the test app target
4. Build > Archive

Here's the file layout of the archive, edited down for clarity:

TestApp 10-9-24, 6.32 PM.xcarchive
├── Info.plist
├── Products
│   └── Applications
│       └── TestApp.app
│           ├── Frameworks
│           │   ├── FirebaseAnalytics.framework
│           │   │   └── FirebaseAnalytics
│           │   ├── GoogleAppMeasurement.framework
│           │   │   └── GoogleAppMeasurement
│           │   └── GoogleAppMeasurementIdentitySupport.framework
│           │       └── GoogleAppMeasurementIdentitySupport
│           ├── Info.plist
│           ├── TestApp
│           └── embedded.mobileprovision
└── dSYMs
    └── TestApp.app.dSYM

In this structure, you can see the app's Frameworks folder contains the frameworks you name, and those are dynamic libraries, because they report this:

 % file TestApp.app/Frameworks/FirebaseAnalytics.framework/FirebaseAnalytics: Mach-O universal binary with 1 architecture: [arm64:Mach-O 64-bit dynamically linked shared library arm64]

Since these framework binaries don't have a corresponding dSYM in the dSYMs folder, the warning from Xcode is expected, as I said in a previous response above:

This is a new warning in Xcode 16 where if you're missing a dSYM, Xcode lets you know in case you aren't expecting that — this is to reduce scenarios where you won't are able to fully symbolicating frames coming from your app's code in crash reports. In some cases, you may not have a dSYM, such as a closed source library from a vendor, and in those cases, the warning is safe to discard.

Your library vendor may have intentionally made that choice to not include a dSYM for proprietary SDK reasons, and that's a choice that's up to them.

For others reading this thread regarding other libraries you're using, you can use the same process to inspect the structure and type of the framework library in the built app to understand why you're getting the warning.

— Ed Ford,  DTS Engineer

I want to summarize my findings: Firebase libraries, such as Firebase, usually provide dSYM files correctly.

Maybe this helps to evaluate possible solutions

Xcode 16:

• There is a warning: “empty dSYM file detected, dSYM was created with an executable with no debug info” when archiving in Xcode 16. This leads to dSYM files not being properly generated for certain frameworks.

Xcode 15:

• This issue did not occur in Xcode 15. The dSYM files were generated correctly, and there were no related warnings

TransponderApp:

• When using the TransponderApp, the dSYM files are generated correctly, and there are no warnings or errors regarding missing dSYM files

I assume Firebase libraries generally support dSYM files for debugging, but issues with dSYM generation might occur, especially in Xcode 16. Xcode may fail to generate them correctly.

@ThomasATL

Xcode 16: There is a warning: “empty dSYM file detected, dSYM was created with an executable with no debug info”

That's a different message than the ones provided in multiple screenshots throughout this thread, "The archive did not include a dSYM for SomeKit.framework with the UUIDS [...]"

If you have actionable steps to reproduce using only Xcode and Swift package manager in a test project, I can take a look, but it'd be better to fork that off to a new thread because this one is focused on a different error message, though they may seem similar on the surface.

— Ed Ford,  DTS Engineer

@DTS Engineer Sorry for the misunderstanding. I’m focusing the problem description on “Xcode 16 warning about missing symbols.”

Goal: To submit my build with Xcode 16 to App Store Connect with dSYM included without getting warnings (see image ).

Xcode 16: When I create an archive in Xcode 16 and submit it to App Store Connect, I receive the following warnings: “Upload Symbols Failed…”

Xcode 15: When I create an archive in Xcode 15 and submit it to App Store Connect, I receive no warnings and the dSYM files are included.

Xcode 16 (Using Custom Distribution & Transponder App): When I use Xcode 16 and select the distribution method as “Custom” -> “App Store Connect” > “Export”, and then upload the “app-name.ipa” via the Transponder app to App Store Connect, I receive no warnings and the dSYM files are included.

I hope this clarification helps you better understand the issue.​ – Thomas

@DTS Engineer, Ed, there is already a thread for "warning: (arm64) /Users/user/Library/Developer/Xcode/DerivedData/SomeApp-dih...wzn/Build/Products/Debug-iphonesimulator/SomeApp.app/SomeApp empty dSYM file detected, dSYM was created with an executable with no debug info."

https://developer.apple.com/forums/thread/764301

In that thread you point to this thread :)

@DTS Engineer Thanks for investigating. If I download the FirebaseAnalytics from the link in the Package.swift https://github.com/firebase/firebase-ios-sdk/blob/main/Package.swift#L306C13-L306C84 and run the file command it shows up as a static archive:

$ file /Users/paul/Downloads/FirebaseAnalytics.xcframework/ios-arm64/FirebaseAnalytics.framework/FirebaseAnalytics /Users/paulbeusterien/Downloads/FirebaseAnalytics.xcframework/ios-arm64/FirebaseAnalytics.framework/FirebaseAnalytics: current ar archive

My understanding is the Swift Package Manager or Xcode is wrapping the static framework with a dynamic wrapper when embed and sign is chosen.

Since the Package.swift is pointing at a static framework, the resulting issue looks like a coordination issue between Apple tooling.

same warning

I'm having this same issue. I want to upload my app to the app store, but the functionality relies on Firebase (as I access a Firebase/Firestore function I've created). Should I downgrade Xcode to version 15 and validate the app there?

Upload Symbols Failed The archive did not include a dSYM for the openssl_grpc.framework with the UUIDs [C10C567E-5647-3F05-87BE-20E45D5E2EFE]. Ensure that the archive's dSYM folder includes a DWARF file for openssl_grpc.framework with the expected UUIDs.

I am getting 5 of these, but they are just warnings, so I will try uploading still. Wish me luck!