Back

Sparking joy working with Xcode

I learned by working with Ruby and Ruby on Rails during my time at Shopify that using tools and programming languages that spark joy is crucial for developers’ motivation. Even though we developers love to understand complexities, we enjoy working with simplicities and conveniences day-to-day.

In the Swift community, we’ve seen a proliferation of tools to help developers with different needs (e.g. generation of Swift interfaces from resources, code linting, dependency management) that inevitably led to a non-cohesive and complex developer experience where Fastlane acted as the glue. On top of that, the authority bias is nudging teams to have more than one dependency manager in their projects to stick to Apple’s recommendations.

Below there’s a common Xcode project setup with all the elements that are part of it and how they depend on each other. Note the estensive list of elements that you need to work on the project. There are a lot of caveats in such setup:

The diagram shows an example of a complex Xcode project setup

That’s a setup prone to errors and stress for developers with which I’d never want to work. We’ve spent most of our time building great tools but not that much thinking about providing a cohesive experience when bringing them together.

For this reason, we continue investing in Tuist. We believe there’s an opportunity for providing a Rails-like experience for developers building apps with Xcode. An experience that combines primitives from Apple like xcodebuild and tools from the community.

Anyone can and should be a project architect. To make this possible, developers need simple setups and APIs to describe their projects. Having an infrastructure team is useful to steward the project’s growth, but there shouldn’t be any strong dependency between feature teams and them. The trap many companies fall into is building this strong dependency where every time you need to do something that touches the architecture, you have to do it through the infra team. The setup must be simple. Embracing complexity is the formula for creating an environment in which developers don’t want to work. Tuist owns complexity and the optimization of workflows to provide a simple and efficient workflows through the CLI. A more straightforward setup will make the environments more reproducible, and thus developers will have to spend less time debugging issues when they arise. To work with Tuist, teams only need to install Tuist, and that’s it. No dependency on Ruby, Homebrew, nor Fastlane. It’s you, Xcode, your project, and Tuist.

Developers might see this setup as rigid like many companies saw and continue to see Rails. But look at companies like GitHub and Shopify that were able to build excellent products in part thanks to the fact that developers could focus on building the product and not fighting the underlying tooling and frameworks. As apps become larger, the need for a Rails-like foundation becomes more important, and that’s the place I think Tuist can take in the community.