Hey all! I was reading https://blog.pusher.com/what-i-learned-building-the-pusherswift-framework/, and one of the first things the author goes into is how the framework they built uses only one target for all platforms.
Currently Moya has 4 targets for each 3 of our frameworks (12 total), and then 3 for tests.

I'm not sure how the author was able to make a universal target, but maybe we could do something similar?
I know how. I've done it for other projects. It's fairly simple. There are couple things not really mentioned but this article covers mostly how to do this http://promisekit.org/news/2016/08/Multiplatform-Single-Scheme-Xcode-Projects/.
@petester42 that looks really cool, it would be awesome to have Moya vend through one target as well.
I could take a shot in a PR, but since you've done this before it may be easier for you to do it? Let me know what you think.
Ya sure I could do it. I was creating a script that would automatically do this but I haven't finished it. I could do it manually, it wouldn't take too long.
馃挴
A script that would do this automatically for any project?
That... that'd be awesome 馃槺
How would this work with bundleID collisions with say a watchOS extension.
This more for frameworks than actual applications. It's not really useful for application targets
frameworks still have bundleID's though.
Reason I am asking is because I do this already for other frameworks and had issues when we wanted to use the framework compiled in this way in an Application as well as a Watch extension bundled with that Application.
@aaroncrespo can you give a concrete example?
I think the issue with bundle ID collisions disappears when you have one universal target, since there is only one target - it can't collide with something that no longer exist.
sorry if I misunderstood your comment 馃槄
It's more a question maybe we weren't loading/linking the framework correctly across watch/extension/app.
I have no idea about watchOS stuff.
@petester42 I think we should go ahead with this, and we can fix watchOS issues if/when they come up. When you create a PR, can you close this issue?
Thanks 馃槃
@scottrhoyt @BasThomas @pedrovereza: Along the lines of simplifying the project structure in #885, I think it would be really awesome to have this implemented too.
Especially if we can have it in before the 8.0.0 release.
Hmm, would this be a breaking change? I agree this would definitely be nice, but I am not so sure if we need it before releasing 8.0.0.
I don't think it would be a breaking change.
Oh, you guys are right. It would have 0 effect on the API, it was just related to the new project structure we had
Implemented in #967 馃槅