If you’ve developed apps with Xcode for a while, you might have noticed how little to no observability teams have over their setup. This is fine when you’re just getting started, but when the project reaches a certain scale, the lack of data makes improving the setup difficult. In many situations I’ve encountered engineering teams that couldn’t fight back against leadership’s push for React Native as a solution to move faster. And they couldn’t fight back because they had no data to support their arguments. The result? They just leave the company. I’ve also seen engineers being dogmatic about things being just fine and fleeing when difficult times come to another Swift codebase that’s far from those moments.

If you ask me, this is problematic, but at the same time creates an opportunity for Tuist. I believe there are several reasons why we don’t see teams having more observability over their setups:

  • The data is often proprietary, like activity logs or result bundles, which requires additional community effort. For instance, Spotify built XCActivityLogParser & XCMetrics back when they were not using Bazel, but they no longer have incentives to maintain it.
  • The data is also not accessible. Everything is designed to be extremely coupled with Xcode, resulting in data that’s hard to find or parse because nothing is documented. Xcode is closed source, so a lot of that work involves reverse engineering, like we had to do with Xcode’s project format.
  • Even with access to the data, it’s not as valuable as when combined with other data or analyzed over time or across environments. This requires pushing the data to a database and making it accessible through visualization tools like a dashboard or Grafana. This was XCMetrics’ original motivation, but it faded. This likely means mobile teams have to investigate or collaborate with their backend teams to deploy, maintain, and keep a service up to date, which suddenly becomes a new responsibility for the company, distracting them from the business. We’ve also seen companies treating it as a hobby project (“let’s open source a backend in Vapor”), which is a fun exercise—I’ve done it myself too—but then the driver leaves the company, and the company finds itself with a business to run and open source to maintain.

This is the sad reality of Xcode development. Many developers find it acceptable. I don’t. And even sadder, Apple isn’t giving up on their proprietary and closed formats. Their new build system has no traces of making it extensible like Gradle is to provide access to data at build time. Or maybe some kind of telemetry built in with OpenTelemetry such that teams can plug their data pipelines into it. Strategically, nothing has changed at the tooling level, which again, is good for Tuist.

Teams should know where the build parallelization contention points are. They should also know which tests take the longest to execute or which ones are the most flaky. They should have a system to flag and disable flaky tests, or to debug their workflows on a website without requiring anyone to install Xcode in their environments. The web is the ultimate expression of accessibility, and they continue building against it.

So if this resonates with you and you’d like to bring that observability to your Xcode projects, let me know. You’d be surprised how much you’d suddenly know, and it’ll just make optimizing your setup easy and make conversations with leadership less uncomfortable. We take care of the annoying part of understanding proprietary formats, persisting them in a more standard and documented format, and making them available and actionable to you.