Apollo-ios: Survey: Carthage Support

[designatednerd]

In order to better facilitate the Swift Codegen project, I'd like to move a bunch of stuff to Swift Package Manager in a way that may make Carthage support a lot more annoying to maintain.

Honestly, our Carthage support isn't great as is. I've been tempted to remove official support for it for a while and recommend against using it, but it's taken a bit for people to get up to speed on SPM. But now, I think the only barrier to libs adopting SPM as a primary recommendation is dealing with resource dependencies, which we don't really have.

Before I spend a bunch of time trying to maintain Carthage support when I make this change, I'm curious to see how many people are a) Still using Carthage to integrate the apollo-ios AND b) Not willing to switch to integrating with SPM or CocoaPods. If you're both, please sound off in the comments about why so I can better understand the possible migration paths.

As a lower-friction headcount method, please respond to the post with the emoji corresponding with your opinion about this potential change:

👍 - You can stop supporting Carthage officially, it's cool.
👎 - Please don't stop, we're still using Carthage and don't want to/can't switch to SPM or CocoaPods (if you can, please explain in the comments)
👀- I don't care, I'm just here with popcorn for the fight in the comments

[designatednerd]

OK the simple measure is at a 5-5 tie about 12 hours after I posted this. People in the “please don’t rip it out” category, can someone elaborate on why they can’t/prefer not to make the switch so I can better understand the obstacles here?

[bwhiteley]

Until SE-0271 and SE-0272 are available in a shipping version of Xcode, we will be unable to move to SPM. Hopefully this Fall (and hopefully we don't discover other limitations at that time).

As for CocoaPods, we moved from CocoaPods to Carthage, and don't intend to move back particularly with SPM near-ish on the horizon.

[designatednerd]

So SE-271 is the one about package manager resources, and SE-272 is the one about binary dependencies. Neither of these proposals should affect Apollo directly.

Is the concern more that you would prefer to only have one dependency manager? I can totally grok that, I'm just trying to make sure I understand what the underlying problem is - that'll give me a better idea of when I should be able to revisit this question.

[bwhiteley]

Is the concern more that you would prefer to only have one dependency manager?

That is correct. For us Apollo is a transitive dependency, not a direct dependency of the app.
App -> Feature Framework -> Apollo.
The Feature Framework can't currently be pulled in via SPM, so that complicates trying to use two dependency managers.

[designatednerd]

Gooooot it, that's a very helpful example. Thank you.

[designatednerd]

OK, seems like there's enough folks who would prefer we not drop it yet that we'll hold off until there's a version of SPM with package manager resources and binary dependencies implemented.

Thank you for your feedback!