Carthage: Add support for "subspecs"

[justinmakaila]

Hey guys,
I think it would be super awesome if Carthage could add support for something similar to CocoaPods subspecs. This would encourage developers to build extensions and categories on to their frameworks which add support for some of the most popular frameworks today.

I think this is possible today by tagging a branch or commit which adds certain extensions to the framework, but I'm thinking that could add a lot of complexity to pushing a release, especially when new versions of Swift are released, or pull requests are filed.

Correct me if I'm wrong, but I think this would be a good thing to be handled by the infra.

Thoughts?

[justinmakaila]

This could potentially be implemented with target settings in the xcodeproj, or even binaries distributed through Carthage.

[jspahrsummers]

No, sorry. This encourages large frameworks, which are antithetical to modularity and composability.

I'd prefer for Carthage to encourage smaller frameworks that can be used independently of each other.

[aschuch]

I too think that this is something that should be considered for Carthage.

A lot of projects e.g. have ReactiveCocoa as a soft dependency to add ReactiveCocoa support.
At the moment, there are two options in this case:

• Add ReactiveCocoa support in a separate project
• Include ReactiveCocoa by default (forcing the dependency onto other developers)

I think @jspahrsummers prefers the former way of creating a small, optional framework that e.g. adds ReactiveCocoa support, which forces projects to become much more like µFrameworks (_yay_!).

---

Another approach would be to have a project expose multiple .frameworks that are dependent on each other.
E.g.

• X.framework (standalone)
• XReactiveCocoaExtensions.framework (linking against X.framework and ReactiveCocoa.framework)

I have only quickly tested this, but to me this approach looks very promising. This way, we can still have a single project that exposes multiple frameworks. Developers that do not want to use the ReactiveCocoaExtensions simply ignore the built XReactiveCocoaExtensions.framework and are good to go.

Any thoughts or caveats towards this method?

[justinmakaila]

@aschuch I agree with what you're saying. I ran into this issue with Moya. Currently, Moya's carthage build is dependent on ReactiveCocoa just for the ReactiveMoyaProvider, which may or may not be implemented by the end user.

I'm in the process of refactoring my own fork for it, where different dependencies are included and managed on separate branches (Moya, ReactiveMoya, and RxMoya). This has some pretty serious maintenance implications, and limitations for frameworks which may want to expose interfaces for certain development patterns.