Michael McGuire

Organizations have long yearned for more from Xcode's build system. They needed solutions for dependency management and build-time optimizations, but Apple remained unresponsive. As a result, tools like @cocoapods, @tuistio , and @bazelbuild had to rely on the foundation of #Xcode projects. Unfortunately, with the Swift Package Manager (SPM), these problems not only persist but worsen: 1️⃣ Developers lack control over dependency resolution at launch time, leaving them helpless if things go wrong or slow down. Most dependencies no longer support CocoaPods, forcing reliance on pre-compiled binaries. 2️⃣ New build-time features are tied to SPM, neglecting their integration into Xcode projects. This seems like an attempt to push developers towards SPM adoption. 3️⃣ Xcode's launch experience starts to resemble Android Studio, dynamically resolving elements such as dependencies. However, unlike Android Studio's flexibility and optimization potential, Xcode remains hermetic with limited room for improvement. 4️⃣The ecosystems built around tools like @reactnative heavily rely on CocoaPods and, by extension, Xcode projects. Discouraging project usage directly impacts these ecosystems. We'd love to see Apple reconsider its approach and allow extensibility and replacement options within its build system. #Swift #Xcode

Xcode projects are our public APIs to optimize projects and build times. Swift Packages are the new internal API that doesn’t leave room for optimisation.

Thanks to the generous sponsorship of @AmericanExpress, who are now our gold sponsors 🙇‍♂️, we are able to double the issue bounty amount. Are you interested in earning some money while helping our non-profit open source project? Check out the list here: github.com/tuist/tuist/discu…