Conversation
|
|
Replace the manual .o collection + libtool approach with programmatic Xcode project generation using tuist/xcodeproj. The generated project includes all source files as a framework target with MACH_O_TYPE=mh_dylib, producing proper dynamic .framework bundles in the archive — the same approach used by major frameworks like Lottie. Key changes: - Generate .xcodeproj with all LiveKit sources and SPM dependencies - Archive produces dynamic .framework (not static .a) - Use -archive/-framework syntax for xcodebuild -create-xcframework - Remove stageArtifacts, embedSwiftModules, libtool merging - Add _LiveKitStub target in output Package.swift (SPM workaround) - Gracefully handle per-platform failures instead of failing fast - Capture stderr in exec() for better error diagnostics Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Fix dylib install name to use @rpath (fixes runtime loading) - Add SwiftProtobuf as dependency in output Package.swift - Replace _LiveKitStub with LiveKitTargets wrapper target - Copy protobuf dependency line verbatim from Package.swift - Exclude x86_64 for tvOS/visionOS simulators (missing in WebRTC) - Always create zip (including --local mode) - Use .build/ as default output dir, revert .gitignore - Throw ValidationError instead of fatalError for missing deps Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Introduce PackageManifest struct to read Package.swift once - Merge duplicate switch cases for .swift/.m file extensions - Remove unused repoRoot parameter from addSources - Simplify archive failure counting Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use @_implementationOnly import under LK_XCFRAMEWORK flag so the ObjC helpers module is available at compile time but excluded from the public .swiftinterface, which consumers cannot resolve. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pblazej
force-pushed
the
blaze/xcframework
branch
from
d9b009a to
52d3f71
Compare
- Split generateFrameworkProject into smaller helpers - Extract archiveAllPlatforms from run() - Group generatePackageSwift params into OutputContext - Move extractVersion into PackageManifest - Suppress false-positive duplicate_imports in LKSampleHandler - Add targeted swiftlint:disable for file_length, function_body_length Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ency Replace @_implementationOnly with Swift 6 `internal import` for both SwiftProtobuf and LKObjCHelpers under LK_XCFRAMEWORK flag. This keeps both modules out of the .swiftinterface, removing the need for consumers to depend on SwiftProtobuf. - Update Makefile proto target to auto-apply internal import post-generation - Remove SwiftProtobuf from output Package.swift stencil - Remove protobufDependency from template context Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
internal import works in both SPM and xcframework builds, removing the need for the LK_XCFRAMEWORK conditional around this import. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pblazej
commented
Apr 22, 2026
| ], | ||
| targets: [ | ||
| .target( | ||
| name: "LiveKitTargets", |
Contributor
Author
There was a problem hiding this comment.
That's another variant of "stub" target - just to include some source files.
pblazej
commented
Apr 22, 2026
Contributor
Author
There was a problem hiding this comment.
Required of ObjC files are in the same target, should be ignored in plain SPM builds.
Add section covering COCOAPODS, LK_XCFRAMEWORK, and LK_BENCHMARK flags with their purpose and where they're set. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is quite tricky/manual process, as tools like https://github.com/segment-integrations/swift-create-xcframework won't work with newer SPM (that does not allow direct
xcodeprojgeneration, required for archiving) 💀Install https://github.com/mxcl/swift-sh to handle dependencies.
The ultimate test:
./scripts/xcframework.swift --localRepo
This will land in https://github.com/livekit/client-sdk-swift-xcframework (with LICENSE, maybe copied README).
Safety
This is mostly additive, except
LK_XCFRAMEWORKfor internal imports.