Consider shipping libVLC as a dynamic xcframework for LGPL 2.1 compliance

[loopion]

Summary

libvlc.xcframework ships libVLC as a static archive (libvlc.a). Because libVLC is LGPL 2.1, static linking puts App Store consumers of SwiftVLC in an awkward position, and the README's own warning ("Static linking may have licensing implications") is the only signal that this is a decision the consumer has to reason about.

Would you consider shipping a dynamic libvlc.xcframework or offering a dynamic SPM library product alongside the current one?

What I observed

From the resolved artifact at v1.0.0:

libvlc.xcframework/Info.plist  →  LibraryPath = "libvlc.a"   (every slice)
ios-arm64/libvlc.a             →  73 MB static archive
find libvlc.xcframework \( -name "*.dylib" -o -name "*.framework" \)  →  no matches

Why it matters

LGPL 2.1 §6 requires that a user be able to modify the library and relink the application against their modified version.

• Dynamic linking satisfies this inherently the user can swap the framework. This is why VideoLAN's own MobileVLCKit ships as a dynamic .framework.
• Static linking falls under §6(a), which instead requires distributing the application's object files so the user can relink. That is not something an App Store app can do.

So for App Store distribution specifically, the current packaging leaves consumers without a practical compliance route. I don't think that's intentional the README already flags the concern, which suggests it's known.

Why I'd rather not just switch away

SwiftVLC is a materially nicer integration than MobileVLCKit for a modern codebase Swift 6, @Observable, typed throws(VLCError), AsyncStream events, and VideoView(player) doing the rendering lifecycle. I'd prefer to keep using it. Licensing is the only thing pushing the other way.

It's also worth noting the size tradeoff runs the other way: static linking lets the linker dead-strip unused symbols, so a dynamic framework would likely ship larger. That's a real cost of what I'm asking for, and it may be exactly why it's packaged this way.

Possible shapes this could take

1. A dynamic libvlc.xcframework (either replacing the static one or as a second binary target).
2. Both, with the SPM product letting the consumer choose static for those who don't distribute publicly, dynamic for those who do.
3. Failing either, a short section in the README stating the linkage explicitly and what it implies for LGPL, so the decision is visible before adoption rather than after.

Even (3) alone would help the current warning is a single sentence and easy to read past.

Happy to test a dynamic build against a real app if that's useful.

[omaralbeik]

Thanks for raising this and explaining the tradeoffs so clearly. I agree that the current static artifact puts App Store developers in an uncomfortable position.

Here is the direction I am leaning toward:

• Ship libVLC as a single dynamic framework and keep the static archive as an internal build step.
• Keep SwiftVLC's existing API and package product unchanged.
• Avoid offering both variants initially. SwiftPM does not model this choice cleanly, and developers could select static linking without realizing the implications.
• Include the LGPL license, third-party notices, exact source, and framework replacement instructions with every release.
• Test signing, App Store archives, playback, size, and launch performance across all supported platforms.

I tried a small prototype and the results look promising. SwiftPM embedded and loaded the framework correctly, the integration tests passed, and the size increase was modest.

Would a dynamic-only default cover your use case, or do you still need a supported static option?

I would also appreciate feedback from anyone already shipping SwiftVLC or libVLC in an App Store app. Are there packaging, signing, performance, or licensing concerns we should consider?

[loopion]

Dynamic-only default covers our use case. We only needed this for LGPL compliance, not for anything static linking specifically bought us. Happy with that direction.

Two things worth checking before it ships, from an App Store playback-app angle:

1. Cold-launch cost of the dylib load. We use libVLC on the player screen, not at app launch, so this shouldn't hit our launch-time budget but if anyone links it in earlier in their app lifecycle, first-frame dylib load + relocation could show up in launch metrics Apple now surfaces in App Store Connect. Worth a before/after launch-time number in your prototype numbers if you have them.
2. Codesigning on embed. With static linking, signing was a non-issue. It's inside our binary. With a dynamic xcframework pulled in via SwiftPM, does it get re-signed automatically as part of our app's embed/sign step (Xcode's "Embed & Sign" phase), or is there a scenario where the framework's original signature has to be stripped/re-applied? Also curious whether App Thinning / on-demand resources interact with it at all, or whether it's just a flat embedded framework in every install.

Nothing blocking on our end so dynamic-only sounds right. Happy to pull the prototype into a TestFlight build and report back on size, signing, and launch numbers from an actual submitted app if that's useful data.