As part of building Tuist, we experience firsthand the sheer volume of proprietary decisions and formats that Xcode and its surrounding toolchain have baked in. From build systems that output their own data formats to test runners that insist on their own proprietary outputs. It's not that standards don't exist, it's that Apple consistently leans toward the proprietary side.

Ultimately, choosing proprietary formats is a way of increasing vendor lock-in between consumers and the product, and by extension, the company behind it. The European Union has implemented measures against this, requiring that users can export their data and take it elsewhere. But if the data format itself is proprietary, why would I export it in the first place?

When you decide against a standard, you're also deciding against interoperability. You make integration so painful for your users that they'll eventually accept the extra pain and seek more interoperable alternatives. Sometimes standards don't exist, and that's completely normal. But when they do exist, neglecting them is a complete mistake.

Take Notion, for instance. I'd never use it, no matter how many features they offer. Any rich experience layered on top of text feels unnecessary to me, and the marginal value compared to the cost of using some proprietary format (god knows which one) simply isn't worth it. I'd rather keep my content in plain text files using standard Markdown. It turns out LLMs love Markdown too. What a coincidence, right? You don't have to wait for Notion to open an MCP API that converts their proprietary format into Markdown for LLMs to understand. You see? The cost is high.

Or consider Tailwind. Everyone loves it. They've managed to get LLMs to generate Tailwind classes everywhere. But it's not a standard. It's a proprietary language with developer experience add-ons, when you could just write plain CSS, use CSS variables for configurable designs, and leverage modern CSS nesting if specificity is an issue. No need to rely on proprietary formats.

In the context of Tuist, we're thinking deeply about leveraging standards that backend teams have traditionally used to help teams understand their projects, builds, and perhaps eventually their apps. Take OpenTelemetry (OTel), a standard people use to add telemetry to backend services. What if Apple's new unified swift-build exported telemetry data using the OTel standard? Wouldn't that be cool? You could use any of the many available collectors and visualize your data in Grafana, which has built-in support for OTel. Instead? This isn't even on their roadmap.

Swift SDKs for OTel exist, so imagine if we leveraged our infrastructure and API to store apps' OTel data, allowing users to observe their apps using the tools they already know and love, like Grafana. They wouldn't have to rely on any proprietary tool. And if they don't like Tuist? They can switch.

I don't believe people should stay with a product because you've vendor-locked them into a system filled with proprietary decisions. They should stay because you've built the best and most fairly priced solution. This is why I'm excited about the concept of runners as a service plugged into CI systems (e.g. Namespace). Whether we like it or not, we're trending toward Git forges' CI solutions becoming the standard, with a standard contract for plugging in runners. This way, you don't have to migrate away from CI providers whose businesses are sinking and who resort to proprietary gimmicks to stay afloat. Like, "Hey! Design your pipeline in our proprietary visual editor, choosing steps from our proprietary marketplace." Fuck that. Give me a standard YAML that's well-documented, that I can ask LLMs to write, and reusable steps in open-source Git repositories that are easily pluggable. This is the way. I'd never go back to any CI provider, and you probably shouldn't either if you want better and cheaper CI.

We're now building Tuist QA, and we're adding an option to export QA session results as JUnit format. It's the closest standard to what we need, and if you want to use that JUnit output with your test analysis tools, go for it.

Recently, I've been exploring Grafana for observability of our production services and the product itself. It blew my mind when I realized that panels and dashboards follow a standard, serializable schema that's well-documented and that LLMs understand. I can provide our ClickHouse and Postgres database schemas to an LLM and ask it to generate entire dashboards or panels. Within seconds, I have everything we need. We'll get there too. Our API has a publicly available OpenAPI spec, and we want to expose more read endpoints and simplify authentication so LLMs can access it and provide useful responses to users. Some of our data is proprietary to Tuist's domain because no standards exist for it, but wherever possible, we'll adopt standards. For example, by exposing data that overlaps with Prometheus or OTel specs in those formats.

The best products embrace standards and put users first. Those that don't feel more like Berlin before the wall fell. They'll throw money at luring users into closed ecosystems. We've seen CI providers do this for years, claiming to be "platforms" (like "Mobile DevOps") that are just vaporware. But sooner or later, the wall will fall, and when it does, it'll hurt hard.