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
- Is it supported (or recommended) to share a Swift package like A as a dynamic library across multiple SDKs and the main app?
- 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