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.
What did you do in this problem
I am thinking of an exact scenario as you
In the intervening years Apple introduced mergeable libraries, which offers another path forward here. If you create all your dependent frameworks are mergeable, you can then merge them into one final framework you distribute to your clients.
I have links to the WWDC talk and docs in An Apple Library Primer.
The one gotcha I see here relates to shared dependencies between your code and the app itself. If your code uses a popular framework and the app uses that same popular framework, the app might end up with two copies loaded into its process, and that often ends badly.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple