Commit e496f20 ("make Package explicitly dynamic lib", 2026-07-06) changed:
-.library(name: "CoreStore", targets: ["CoreStore"])
+.library(name: "CoreStore", type: .dynamic, targets: ["CoreStore"])
This reverses #432, where the type was deliberately unset so Xcode could pick static or dynamic per consumer.
Impact: projects that have always linked CoreStore statically have no "Embed Frameworks" build phase. After this change the app links @rpath/CoreStore.framework/CoreStore but nothing embeds it, so the archive ships with undefined CoreStore symbols and no framework, and fails to load on device.
The failure is quiet. Xcode builds, archives, and uploads fine. App Store Connect only returns a warning that reads like an unrelated Mac issue:
ITMS-90863: Macs with Apple silicon support issue - The app links with
libraries that aren't present in macOS: @rpath/CoreStore.framework/CoreStore
Why this matters now: the change is on develop and in no tagged release, but consumers are currently pinning develop to get the Xcode 27 fix from #519, which is also untagged. That is how we hit it.
Request: could the explicit .dynamic be reverted to restore the #432 behaviour? If it is intentional, it would help to call it out in the release notes, since consumers need to add Embed & Sign to keep working.
Commit e496f20 ("make Package explicitly dynamic lib", 2026-07-06) changed:
This reverses #432, where the type was deliberately unset so Xcode could pick static or dynamic per consumer.
Impact: projects that have always linked CoreStore statically have no "Embed Frameworks" build phase. After this change the app links
@rpath/CoreStore.framework/CoreStorebut nothing embeds it, so the archive ships with undefined CoreStore symbols and no framework, and fails to load on device.The failure is quiet. Xcode builds, archives, and uploads fine. App Store Connect only returns a warning that reads like an unrelated Mac issue:
Why this matters now: the change is on
developand in no tagged release, but consumers are currently pinningdevelopto get the Xcode 27 fix from #519, which is also untagged. That is how we hit it.Request: could the explicit
.dynamicbe reverted to restore the #432 behaviour? If it is intentional, it would help to call it out in the release notes, since consumers need to add Embed & Sign to keep working.