Xcode 16 generates DWARF/dSYM warnings during packaging for App Store

[freakboy3742]

Describe the bug

As of Xcode 16, archiving an iOS app for submission to the App Store leads to a large number of warnings during the validation process.

Steps to reproduce

1. Generate a HelloWorld iOS app with Briefcase
2. Add a developer identity to the project
3. Select Archive from the Product menu
4. Select the recently generated archive from the list in the archive window
5. Click "Validate App", then Validate
6. Wait for the validation report

Expected behavior

No validation issues should be found.

Screenshots

No response

Environment

• Operating System: macOS 15.3.2, Xcode 16.3
• Python version: 3.13
• Software versions:
  • Briefcase: 0.3.23

Logs

The validation log will list a single issue with Python.framework, and with each of the binary modules included in the app:

Upload Symbols Failed
The archive did not include a dSYM for the Python.framework with the UUIDs [87F39C90-34C0-3669-89EA-B18F5F01DBCC]. Ensure that the archive's dSYM folder includes a DWARF file for Python.framework with the expected UUIDs.

Upload Symbols Failed
The archive did not include a dSYM for the _asyncio.framework with the UUIDs [89363EE2-D685-3DF8-A31B-99A9E597B564]. Ensure that the archive's dSYM folder includes a DWARF file for _asyncio.framework with the expected UUIDs.

Upload Symbols Failed
The archive did not include a dSYM for the _blake2.framework with the UUIDs [9509B0A6-CB26-3D32-AAAB-E6A781581B15]. Ensure that the archive's dSYM folder includes a DWARF file for _blake2.framework with the expected UUIDs.

...

Additional context

These are warnings - they do not prevent submission of the app to the App Store. However, it would be desirable to have no warnings during the build process.

A dSYM folder can be generated after compilation using dsymutil <binary> -o <binary>.dSYM; however, it needs to be generated at the same time as compilation to ensure that source file references can be generated.

[johnzhou721]

I'm too busy to work on this, can someone else take a look? -g seems to do this if put in CFLAGS, but that's the only insight I have right now.

[freakboy3742]

Firstly - I've got a fix for this problem almost ready to land.

Secondly - there's no expectation that you work on everything, everywhere. Pick one project at a time, and contribute where you can. If you can't contribute... don't. There's no need to call out a bug asking for someone else to help unless it's something that you're (a) actively working on, or (b) it's actually impacting you personally.

[johnzhou721]

Secondly - there's no expectation that you work on everything, everywhere. Pick one project at a time, and contribute where you can. If you can't contribute... don't. There's no need to call out a bug asking for someone else to help unless it's something that you're (a) actively working on, or (b) it's actually impacting you personally.

Sorry, I was trying to work too hard, apparently.

Firstly - I've got a fix for this problem almost ready to land.

Oh no, more git rebases...

[freakboy3742]

It turns out this is a little more complex to roll out than first thought. If the project using the framework isn't ready to handle dSYM files, this mode of distribution causes segfaults at runtime. I've temporarily disabled dSYM generation in the support package in the short term.