Having a binary package depend on another binary package causes duplicate symbols when distributing app

Hello,

We are working on an SDK that has both open-source packages and closed-source binary frameworks as dependencies. We work on our SDK using SPM to get all dependencies, generate an XCFramework (enabling bitcode and setting BITCODE_GENERATION_MODE=bitcode), and distribute it as a binary framework as well.

When someone integrates our SDK into an app, as soon as they run it, they get a bunch of errors saying Class X is implemented in both [framework name] and [app name]. One of the two will be used. Which one is undefined. The app works normally.

If we archive the app, and then try to distribute it by turning on Rebuild from Bitcode, the ipatool fails with a duplicate symbols error. This is the showstopper, as our clients cannot distribute their apps with bitcode enabled.

I have generated an Example app that is using an example binary framework as a dependency. This framework has Alamofire and TwilioVoice as dependencies, to illustrate the issue that we have. This example binary framework is generated from an example closed source framework. This follows the same setup we have: private repository from which XCFramework is generated > published into vendored repository which is open > integrated into apps from clients. The Example app displays all the issues that I am experiencing.

I believe this happens only when using binary frameworks because on a previous iteration of my example framework, I just added Alamofire as a dependency, and not TwilioVoice (binary framework) and I wasn't able to reproduce the issue.

I am at a loss of what is the issue, and I don't want to file any bugs because this is probably an issue with our setup rather than with SPM.

Thanks for your help.

1 Like

@gersonnoboa have you been able to find a workaround for your issue? I'm getting a similar error Assertion failed: Duplicate symbols for {UUID} when exporting the archive.

@ferologics Hello, not really. We have decided to halt support for bitcode in the meantime, which is really unfortunate. We have found this document which might indicate that what we are trying to do is not possible at the moment.