Swift Stories

Most solutions we build with software start with an idea: that solution you've always dreamed of having, that app with all the features you miss in other apps, some crazy new concept no one has thought about before, or simply an innovative solution to your employer's needs. These ideas emerge with energy that can fade if not paired with a building momentum that keeps you excited during development. Unfortunately, software has grown larger and more complex. Layers of abstraction emerge to hide this complexity, but complexity eventually leaks through these layers and steals your momentum, potentially putting the realization of your idea at risk. In the case of Apple's ecosystem, that momentum-spoiling culprit is Xcode's build system.

Xcode's build system, initially designed to support a single platform and product type, had to evolve quickly to support many platforms, programming languages, and product types. On it, many editor and compile-time features were built—from previews to Swift macros. It was asked to handle more than it could manage, and it's suffering. That idea you wanted to bring to life now faces slow compilation cycles, constant cleanups of derived data, and unreliable previews.

In a business context, this eventually leads leadership to push for radical shifts, from migrating everything to React Native to match the delivery speed on other platforms, to multi-year efforts to revamp a company's tech stack, including changing the build system. Reddit had to do exactly this to stay competitive in the mobile landscape.

Now you might wonder, is Apple doing anything about it? They are, but it will take many years until the ecosystem transitions to this new world. First, they introduced explicit modules, though adoption hasn't met expectations. These modules will play a crucial role in enabling a faster and more reliable future, and it would be beneficial if Apple emphasized them more. However, explicitness shifts build-graph complexity to Xcode projects, something teams generally avoid, and SwiftPM is already struggling to provide the developer experience that developers need. Will we see a new Xcode project format? Or perhaps an evolution of the current one? Time will tell.

The second piece in development is the unification of build systems, which will include a content-addressable store—the same mechanism Bazel uses internally to optimize compilations by pulling and storing binaries through the network. We might see elements of this announced at this year's WWDC. Still, explicitness and content-addressable storage are just foundational tools. If the layers above, including the language and project build settings, continue to allow side effects and implicitness, these foundational tools cannot perform optimally. Apple needs to rethink the high-level layers, perhaps introducing a language like Bazel did that's designed to prevent the issues that have brought Xcode's build system to its current state.

Staying close to the platform is always advisable, whether that platform is the Web, iOS, or watchOS. However, if doing so means constantly disrupting developers' momentum and flow, it's understandable that organizations and developers explore abstractions that restore that sense of momentum they lose when working directly with the platform. At Tuist, we built an abstraction — generated projects — to shield developers from Xcode's complexities and build slowness, ensuring they could stay productive. Ideally, we would love to peel back that layer in the future, should Apple address these challenges more effectively at a lower level. The ball is now in Apple's court to demonstrate that developers don't need additional abstractions to remain productive while building for their platforms, and that their tools can match others' productivity levels and reliability. Perhaps this WWDC?

Food for thought