`tuist xcodebuild` command

RFCs
1

Need/problem

We want to bring some Tuist features to vanilla Xcode projects minimising the amount of changes teams a developers need to make to their setup. One of those features is Tuist Analytics, where every interaction with the project, for example for building or testing through xcodebuild, is reported along with all the associated artifacts to provide useful analytics.

Motivation

We want to make some of Tuist’s value non-exclusive to Tuist Projects embracing Xcode projects and build systems as they are, and extending them where we can bring value.

Detailed design

Tuist will have a new command, tuist xcodebuild. At its core, it proxies to xcodebuild. Yet at the completion, it automatically collects and reports analytics according to the project’s Tuist configuration file.

The adoption for teams is straightforward because they only need to prefix xcodebuild with tuist and ensure Tuist is installed. For Fastlane users, we can explore making it customisable in gym and scan lanes in a generic way. For example by supporting overriding the command. Do you think this is feasible @mollyIV ?

The initial version of this command will collect and upload information about the environment, logs, and built artifacts that are previewable. On the server, we’ll refer to it as a “Tuist Run” or simply “Run”. And we’ll add more useful information over time (we have some ideas there)

On first run, the command should prompt the developer to sign and create a project on the server, since that’s mandatory for this new command to provide value. Otherwise it’s just a proxy to xcodebuild.

Drawbacks

  • We need to educate people on these new capabilities that can work with Xcode projects too. This will be challenging after so many years with a strong focus on Tuist projects, but I deem it feasible.

Alternatives

  • Piping xcodebuild instead of prefixing like xcbeautify does. However, the Tuist process wouldn’t know the flags xcodebuild has been invoked with, and this is necessary. We could try to extract that information from the logs, but they can change leading to breakages.

Adoption strategy

We’ll update the docs to include adoption journeys, one of which is designed for Xcode projects that want to bring analytics to their projects. We’ll optimise this funnel to be as short as possible. Ideally:

  1. Install Tuist
  2. Run your xcodebuild command with the “tuist” prefix

How we teach this

Besides the above, I propose settling on the following terminology, which we can start using consistently through the product and the docs:

  • Tuist Run: An interaction with a Tuist or Xcode project captured on the server
  • Tuist Analytics: The runs data analyses over time and made actionable for teams

I suggest that we adopt “Analytics” over “Insights” since it’s a more broadly used term.

Unresolved questions