When packaging Swift runtime libraries, rules_apple uses swift-stdlib-tool to scan Mach-O binaries and determine which Swift runtime dylibs must be bundled. However, the scan currently only includes the main binary and any binaries propagated through _AppleSwiftDylibsInfo (code).
Prebuilt dynamic frameworks are instead represented via AppleFrameworkImportInfo, and their embedded Mach-O binaries are not included in the swift-stdlib-tool --scan-executable inputs.
As a result, Swift runtime dependencies introduced only by imported frameworks are missed. For example, an app may link against a prebuilt Swift framework whose binary contains a dependency such as:
@rpath/libswiftCompatibilitySpan.dylib
If the app binary itself does not reference this dylib, scanning only the app executable will not detect it, even though it is required at runtime. This will cause app crash on launch.
When packaging Swift runtime libraries,
rules_appleusesswift-stdlib-toolto scan Mach-O binaries and determine which Swift runtime dylibs must be bundled. However, the scan currently only includes the main binary and any binaries propagated through_AppleSwiftDylibsInfo(code).Prebuilt dynamic frameworks are instead represented via
AppleFrameworkImportInfo, and their embedded Mach-O binaries are not included in theswift-stdlib-tool --scan-executableinputs.As a result, Swift runtime dependencies introduced only by imported frameworks are missed. For example, an app may link against a prebuilt Swift framework whose binary contains a dependency such as:
If the app binary itself does not reference this dylib, scanning only the app executable will not detect it, even though it is required at runtime. This will cause app crash on launch.