dSYM support for SE-0272 Package Manager Binary Dependencies

[steipete (Peter Steinberger)]

Hi folks,

We at PSPDFKit are more than excited to add support for our binary SDK with Swift 5.3. Our zip contains of two xcframeworks and two dSYM folders:

I read up on the proposal and discussions, but I cannot find any information how we can integrate the dSYM files for lldb to find. They should ideally be in the same folder as the xcframeworks for the resolution logic to work.

I did find a "FIXME: Add information on dSYMs (XCFrameworks support them out of the box right?)" note in [PITCH] Support for binary dependencies - however unfortunately xcframeworks do not support them out-of-the-box (unless we missed something, but while implementing we didn't see any kind of support for dSYM files).

Is this something that has been considered?

[matt (Matt Thomas)]

I would also support figuring out a way to better handle external dSYMs within SwiftPM. This would address some issues we currently have integrating 3rd party Libraries with our current codebase. When we have a 3rd party library, the dSYM is a separate entity we often have to figure out how to integrate into our continuous integration flow. Often it involves custom build phases to copy the external dSYM into the final archive that’s created and make sure it gets distributed correctly. This is particularly fragile and often leads to many unsymbolicated crash logs.

Also with our current setup, including these dSYMs only happens when we archive. As we’re in the development process, when a 3rd party library crashes, we’re often out-of-luck stuck in the console. Peter mentioned to me that this could be useful for those situations as well. Having dSYM information in development would be useful to contact the library author for crashes and other unexpected issues.

[NeoNacho (Boris Buegling)]

I would say this is essentially FB7166302 that you reported on XCFrameworks themselves.

Having a mechanism to deal with dSYMs in packages that is separate from XCFrameworks would go against one of the main goals of the binary dependencies proposal:

Support existing well-known occurrences of binary artifacts in the existing (often iOS focused) target developer market.

[steipete (Peter Steinberger)]

@NeoNacho

FB7166302

Thanks! I've commented on the radar with the increased importance.

[quentinfasquel (Quentin)]

Hey @steipete, there isn't much out there this subject so I got here. I thought you'd be interested in the results of my investigations.

My goal was different : using binary as a compile cache (pretty much in the idea of Rome for Carthage), but allowing breakpoint debugging through compiled frameworks. This is possible when Xcode knows the debugging symbols of a binary and you share breakpoints across Xcode projects using "Move breakpoint to > User" (from your framework xcproj in that case).

I figured that you can actually embed the PSPDFKit.framework.dSYM without renaming it into PSPDFKit.xcframework/_matching_architecture_/PSPDFKit.framework.dSYM. (In my case I zip the whole thing, upload it and reference it as a binaryTarget for SPM and Xcode 12 beta)

Since your framework is compiled for release (optimised), when you start debugging from your app, you'll get PSPDFKit was compiled with optimization - stepping may behave oddly; variables may not be available.

I don't think it is annoying to have the dSYM along with each architecture in an xcframework since there's not a raw copy of the xcframework in the app bundle. On top of that your embedded-script wouldn't have to be given references to the dSYM files, it could just find them relatively.

[steipete (Peter Steinberger)]

Looks like this is solved for good now With Xcode 12 b3! We're still working on testing everything and updating our scripts, but it looks like Xcode is now taking over everything and it seems to work great!