Sharing a Swift Package Across App and SDKs Leads to Runtime Crash

Hi all,

I’m encountering a runtime crash related to Swift package linking when integrating SDKs into our app, and I’m hoping someone can shed some light on this.

Here’s the setup:

  • We have a Swift package A that defines common protocols and integration logic.
  • Multiple SDKs (e.g., SDK B, SDK C, etc.) depend on package A and are distributed as xcframeworks.
  • Our main app also directly depends on package A and on all SDKs.

To compile the xcframeworks, we set BUILD_LIBRARY_FOR_DISTRIBUTION = YES to ensure module stability.

Now the issue:

When we integrate one of the SDKs (e.g., SDK B) into the app, the app crashes at runtime with an
EXC_BAD_ACCESS when we use one of theSDKs.

From what I can tell, this may be due to package A being statically linked into both:

  • The SDK’s xcframework (e.g., B), and
  • The main app itself.

This likely causes multiple copies of the same types/protocols to exist in memory, leading to undefined behavior and crashes when bridging between them.

I tried setting type: .dynamic for package A in its Package.swift to avoid static linking. However, when I do this, the app fails to launch due to a linker error at runtime.

dyld[39600]: Symbol not found: _$s1A9AProtocolP8listenerAA9AListener_pSgvsTj
  Referenced from: <3975CEFA-8ED3-3B27-AFAB-49AE6F9476A6> DerivedData/App-dpyzeizkwvcryzcaffrmmdrximmk/Build/Products/Debug-iphonesimulator/B.framework/B
  Expected in:     <90C1E2B4-E443-3C4C-B3A2-4CDA746497C4> DerivedData/App-dpyzeizkwvcryzcaffrmmdrximmk/Build/Products/Debug-iphonesimulator/PackageFrameworks/A.framework/A
  1. Is it supported (or recommended) to share a Swift package like A as a dynamic library across multiple SDKs and the main app?
  2. Are there best practices for structuring Swift packages and SDKs to avoid these kinds of symbol duplication/runtime crashes?

I’ve attached a minimal test project that demonstrates the issue with both dynamic and static linking scenarios.

Any insight would be very helpful—thank you!

— Stefan