feat: dynamic xcframeworks shipped in package#416
feat: dynamic xcframeworks shipped in package#416mario-launchdarkly wants to merge 6 commits intomainfrom
Conversation
sdk/@launchdarkly/react-native-ld-session-replay/scripts/build-xcframeworks.sh
Show resolved
Hide resolved
- Bump @launchdarkly/observability-android to 0.29.0, adding MAUI hook proxy and fixing fullsnapshot nodeId reset. - Bump @launchdarkly/observability-react-native to 0.7.1, addressing ldclient dependency issues. - Bump @launchdarkly/session-replay-react-native to 0.2.2, fixing ldclient dependencies and updating workspace dependency on observability-react-native.
sdk/@launchdarkly/react-native-ld-session-replay/scripts/build-xcframeworks.sh
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
| KSCrashFilters \ | ||
| KSCrashInstallations \ | ||
| KSCrashRecording \ | ||
| URLSessionInstrumentation |
There was a problem hiding this comment.
Incomplete strip list may leave unresolvable imports in swiftinterface
Medium Severity
The comment at line 225 says "fold in all internal / ObjC-only deps whose imports we will strip," and line 257 says "strip KSCrash*" (wildcard). However, strip_imports for LaunchDarklyObservability only strips 4 of the 8 merged KSCrash modules — KSCrashCore, KSCrashRecordingCore, KSCrashReportingCore, and KSCrashSinks are missing. Similarly, NetworkStatus and ObjCBridge are merged but not stripped. If any of these modules appear in the generated .swiftinterface, consumers would get "missing module" compile errors since these aren't shipped as separate xcframeworks. Adding them to the strip list is harmless (a no-op if absent) and more robust.
Additional Locations (1)
| build_xcframework "LaunchDarklyObservability" \ | ||
| Common \ | ||
| NetworkStatus \ | ||
| ObjCBridge \ |
There was a problem hiding this comment.
I don't see SessionReplayC here.
Do we need such fragile way of handling in itemized way in .sh. script. Can we consume as the whole delegating decision what should be included to XCode tools.
Vadman97
left a comment
There was a problem hiding this comment.
Shipping prebuilt dynamic XCFrameworks eliminates flaky SPM resolution at build time and gives consumers a deterministic, version-locked binary that just works.


Summary
Build
LaunchDarklyObservability.xcframeworkandLaunchDarklySessionReplay.xcframeworkasdynamic frameworks from
swift-launchdarkly-observabilityat release time and ship them inios/Frameworks/inside the packageNote
Medium Risk
Changes iOS packaging/linking by moving from SPM to shipped binary XCFrameworks and adding an Xcode project patch, which can impact app build/link behavior across Xcode/iOS environments.
Overview
Switches the iOS integration from
spm_dependency(SPM atpod installtime) to vendored prebuilt XCFrameworks shipped insideios/Frameworks/, and updates the podspec to reference those frameworks (and enableBUILD_LIBRARY_FOR_DISTRIBUTION).Adds a release-time build pipeline (
scripts/build-xcframeworks.sh,build:xcframeworks, updatedprepack/files) to generate and publish the requiredLaunchDarkly*,OpenTelemetry*, andSwiftProtobufxcframeworks, and introduces an optional Expo config plugin (plugin/,app.plugin.js) to setALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES=YESin Xcode projects. Also updates ignores/clean scripts and refreshes the examplePodfile.lock/yarn deps accordingly.Written by Cursor Bugbot for commit cd7815d. This will update automatically on new commits. Configure here.