Discontinuing Carthage Support

[scannillo]

👋 Welcome

We're using GitHub Discussions as a place to engage with the members of our community, to share ideas, and to support one another.

📱 Discussion Topic: Discontinuing Carthage Support

The Braintree iOS SDK team is considering dropping support for Carthage in our next major version release (v6). Here are a few reasons:

• Rapidly increasing adoption of Swift Package Manager.
• Carthage lagging behind other package managers in adding support for Apple's new (and sometimes required) features.
  • Example: Delayed support for xcframeworks. Though Carthage's May 0.38.0 release supports xcframework dependencies, this time frame greatly lagged behind the other package managers (~ 1 year), making it an unusable option for M1 Macs for awhile.
• Allocating more Braintree dev resources toward SPM and CocoaPods support.

🗣 Let Us Know

Please use this thread to voice your opinions, concerns, or thoughts!

[gyulavoros]

Hi @scannillo, thank you for providing this opportunity and making any decisions publicly!

I'm in favor of keeping the Carthage support with the following remarks:

• we use Braintree in a fairly large project with a very specific setup (lots of modules, relatively many dependencies, usage of Xcodegen)
• although we consider migrating from Carthage (mostly because of the reasons that you mentioned above - slow maintenance), we still have concerns regarding the build times and the efficiency of SPM in a large scale project (we can keep even clean build times around ~60 seconds with Carthage for now)
• we have both statically and dynamically linked dependencies, and the last time I've checked it's not trivial to have a multi-module project with mixed dependencies
• unless we can migrate to SPM module by module, it will be a huge effort to make the transition
• I understand that it varies from library to library, but providing Carthage support should be relatively easy - as long as the project can be built with standard xcodebuild, you should be good to go

[Blackjacx]

Yeah thanks for giving us the opportunity to discuss this topic freely. We also prefer(ed) the drop-in SDK for the following reasons:

• We prefer Carthage in general over SPM since working with SPM slows us, our local builds and especially our CI builds down significantly. We discovered that Carthage has the best mix to efficiently work with many dependencies and especially dependency caching on CI systems.
• For the resons described above we aim for creating a local Swift package for our dependencies where we link so-called binaryTargets, i.e. xcframeworks which are built using Carthage. The advantage of this is that we can leverage all the power of the Carthage caching mechanism - the Carthage folder is cached (SPM does not have such a folder in the project root and implementing Bitrise Caching with an ever changing DerivedData folder is not possible). This means we let Carthage build all the XCFrameworks and reference it in the packages Package.swift file as binaryTarget. Then we link our single dependency package to all of our app targets (we build a WL product with countless of app targets).

[gyulavoros]

Hi @scannillo, may we get an update on the current status quo? Has any decision been made?

[scannillo]

Hi @gyulavoros - the decision won't need to be "made" until our next major version release (v6). Though, with the increase stability of Carthage on xcframeworks after their v0.38.0 release, and merchant interest in still wanting to use Carthage - I think our case for removing it is much lower now.

Please do add your feedback / thoughts as well!

[gyulavoros]

Thank you for the update @scannillo! I'm happy to hear that continued Carthage support is likely. I can confirm that using the latest Carthage version and migrating to XCFrameworks are stable from a tooling/environment perspective. We had to apply a couple of workarounds for some of our dependencies, where official XCFramework support was not available, but open-source libraries and vendors are catching up, and now the developer experience of integrating these libraries are getting nice and simple.