Avoid exposing LDSwiftEventSource as dependency, when building xcframework

[dingtianran]

Requirements

• [/] I have added test coverage for new or changed functionality
• [/] I have followed the repository's pull request submission guidelines
• [/] I have validated my changes against all supported platform versions

Related issues

Due to some users can't using public SPM on GitHub, using pre-build binary xcframework is a good option. But at the source code, using import LDSwiftEventSource will expose it as another dependency(both LaunchDarkly.xcframework and LDSwiftEventSource.xcframework) which isn't necessary.

Potential related issue: https://github.com/launchdarkly/ios-client-sdk/issues/257

Describe the solution you've provided

Solution👉 Mark LDSwiftEventSource as @ _implementationOnly will prevent it from expose as dependency: it'll remove LDSwiftEventSource from the final .swiftinterface file

[keelerm84]

Thank you for your contribution, and my apologies for the delay in responding.

According to the Swift docs, @_implementationOnly isn't a stable language feature and it's use is highly discouraged.

I would like to gain more insight into your setup though as this background helps inform our future changes.

Can you explain the nature of your setup a bit more? What type of application are you building, what does your build process look like, which platforms are you targeting?

My hope is to replicate your setup locally so that if this feature becomes stable, I can add regression testing for it.

[dingtianran]

Hi @keelerm84 thank you for your reply, here is my use case(a bit odd I have to admit). Due to security requirements, I can't use public github/swift package link in my Xcode project. The way I managed to do is manually have a bunch of xcframeworks referred in project, instead of SPM denpendencies. If the library I need can provide pre-built xcframeworks(like Firebase), that's sweet for me. If not, then I compile them from source code to binary xcframeworks then chuck into Xcode project(like LaunchDarkly).

During the compilation, I found that I have to build both LaunchDarkly.xcframework and LDSwiftEventSource.xcframework, and put both of them into project, because LaunchDarkly depend on LDSwiftEventSource. But in my opinion this is unnecessary, as a consumer of LaunchDarkly, I want LaunchDarkly.xcframework to be the single source of truth, I don't want have another sidekick library. This is why I did some research and found @_implementationOnly could help.

What you concerned of is legit, this @_implementationOnly is not recommended yet by swift community to be using publicly. Maybe there is another way to produce an independent LaunchDarkly.xcframework?

[dlewandaDK]

Bumping the conversation on this, as I think something like this will help my team as well. We are trying to use Xcode Cloud, but because LDSwiftEventSource is a dynamic library, Xcode Cloud runs into this issue. If there's a way to hide LDSwiftEventSource such that it doesn't run into this issue, it will help at least until Apple can rectify this problem with their CI solution.

[rayalarajee]

Hi , Facing same issue while creating the xcframework, any solution will help . Thanks in advance.

[dingtianran]

@rayalarajee the solution is add @_implementationOnly before all "import LDSwiftEventSource" and build xcframework. This will make a standalone xcframework, no other dependency needed. It's a hack but works well for me

[rayalarajee]

Thank you. @dingtianran