We modularise our project into 20+ swift packages which split into many layers (Core -> Kits -> Features -> Integration)
We have to build a SDK out of it to deliver to our clients. Currently, we need to distribute 20+ xcframeworks which is quite scary for our clients to integrate our SDK.
What is the best strategy to reduce number of binaries we have to distribute to our clients?
I've also been dealing this problem. I wonder if there is a way to build the whole dependency graph into a single binary framework, i.e. would it be technically possible for somebody who understands the domain well. Maybe something like one framework with many modules, where each module represents a package product.
As far as I understand it currently, only a single module can be contained in a framework. Speculatively I don't see this as an inherent limitation, but maybe there are some major issues I don't know about. I think the only way to do what you want today is if you can use library evolution +
@_implementationOnly so you don't need to propagate the types from any of the transitive frameworks publicly, but that might be difficult depending on how your library is architected. This way the
swiftinterface that your consumers reference does not include any
imports for your transitive modules.
Thanks @Keith for the suggestion.
I was thinking about using
@_implementationOnly to hide transitive dependencies from my clients.
But I'm using some 3rd party libraries (specifically RxSwift) already in very low layers, Core. And my clients are also using RxSwift in their apps. And the idea is to not link RxSwift twice. As far as I can see from this report, there could be potentially an issue with duplicated symbols there
Yea I think in that case you'd either have to exclude that from your implementation only list, and require consumers to include it, matching your version. Or you could rename the RxSwift module you're including to avoid the name conflicts, at the cost of a (probably minor) binary size increase for consumers.