Using the composable architecture in a closed source framework

[iteroji]

We're building an iOS framework - that by a business decision has to be closed source - and we'd like to use the composable architecture in it. At first it seemed like a viable option, however now we've ran into several issues.

• It seems like the host project doesn't apply the library evolution support to it's dependencies., so I get warnings in the compiler that it is not compiled with library evolution.
• When trying to integrate the framework into an app it tells me that cannot find modules like swift-composable-architecture and the others it depends on.
• If I build an XCFramework from the simulator and device frameworks I get an error when integrating into the project that the text interface is broken

Does anyone have experience with such setup? Is this even possible, or should I just go another way? I would not like to do it without TCA and would prefer not to do dirty hacks like copying all dependency sources into my target.

[eimantas]

Unless there is a business requirement not to expose dependencies (e.g. security) — what's wrong with defining TCA as a dependency? Given framework is going to be closed source I assume (!) it will be used by 3rd parties. What if 3rd party uses TCA in their project? The embedding of TCA into your framework would cause compilation errors about duplicate symbols. By having TCA defined as your framework's dependency you'd be able to leverage already present TCA framework in the 3rd party's project.

[iteroji]

your opinion may be biased by the fact that you're a user of TCA, most commercial projects aren't, and many of our clients are very opinionated about introducing new transitive dependencies to their projects. Nevertheless what you suggest could be a solution, however I found that importing TCA to my framework with @_implementationOnly import ComposableArchitecture solves this issue, the text interface doesn't list my dependencies publicly and it no longer leaks into the host app.