Tuist is coming to Android 🤖

General
1

Hola :waving_hand:

Something has been brewing in our heads for a while, and I’m excited to finally share it with you.

If you’ve been following Tuist’s evolution, you know we started as a project generation tool for Xcode and grew into something bigger: a platform that helps teams ship faster through caching, insights, and build optimization. Along the way, we realized that the challenges we’re solving aren’t unique to Apple developers. Android teams face the same pain. Slow builds. Limited visibility. Wasted CI minutes. :weary_face:

The go-to solution in the Android world is Develocity, built by the same folks behind Gradle. It’s a great product and we’ve actually used it as inspiration for parts of our dashboard. But we think there’s room to bring the Tuist philosophy to this space: tools that are a joy to use, data that’s actually actionable, and a focus on the 20% of information that matters 80% of the time.

So here’s the plan. We’re going to bring Tuist to Android. :robot:

Why Gradle is exciting for us :sparkles:

Unlike Xcode’s proprietary world of .xcactivitylog and .xcresult files, Gradle is open and extensible. This is a breath of fresh air. The build system already has caching capabilities, and the community has built amazing plugins (like one that exports OpenTelemetry data). Our job becomes figuring out how to plug Gradle into our infrastructure in the most seamless way possible.

One interesting question: what’s the role of the CLI? For Apple developers, the CLI is central because of project generation. For Android, most of the logic can live in a Gradle plugin. The CLI becomes primarily about authentication and providing an interface for agents to interact with. We’ll also need to support Linux :penguin: (and eventually Windows), which means breaking some assumptions we’ve made about running on macOS.

How we’re approaching this :hammer_and_wrench:

We want to start focused and expand from there.

Phase 0: The foundation

First, we need a platform-agnostic configuration format. Our current Swift-based manifest assumes a Swift developer, which won’t be true anymore. I’m leaning toward .toml with a public schema that editors can use for autocompletion. We’ll start simple: just the project handle and server URL.

Then we’ll get authentication working on Linux. Users should be able to install the CLI, authenticate, and get going.

Phase 1: Cache :rocket:

This is where we believe we can bring the most value right away. We’ve been investing heavily in componentizing our caching infrastructure to minimize latency, and we want to bring that to Gradle. This means building the API endpoints, creating a Gradle plugin, and extending the dashboard to support Gradle projects.

On the dashboard side, we’ll introduce a “build system” attribute to projects (Xcode or Gradle) and show the relevant features for each. Same layout, adapted terminology, no duplicated views where we can avoid them.

Phase 2: Insights :bar_chart:

Once caching is solid and we’ve tested it with Android teams at companies already using Tuist, we’ll tackle insights. This is where Develocity really shines with granular data. Our approach will be to focus on presentation and making sure the most valuable information is front and center.

I’d love to hear your thoughts :speech_balloon: Are you an Android developer dealing with these challenges? Have you used Develocity and have opinions on what works and what doesn’t? We’re building this with you, so your input genuinely shapes where this goes.

Let’s make build systems less painful, one platform at a time. :globe_showing_europe_africa:

2

A random thought…

Gradle plugins, which we can write in Kotlin, can link binaries with C bindings, so I was thinking the functionality from the Tuist CLI that we want to have access to from the plugin could just be a binary with C headers, for example the logic to refresh the token. That way we don’t have to duplicate functionality. Thoughts?

3

We first need to do a prototype of what we actually need before we can have a discussion about this. In the initial implementation, we can just call out to the Tuist CLI, I don’t see a need for the complexity of C bindings for the initial version.

4

That’s fair. Let’s see what the prototype reveals.

5

Is there a way we can register interest to be involved in any early testing of Tuist for gradle/Android?

6

We’ll be announcing early support for Gradle very soon, follow our social channels or this forum to stay up-to-date :relieved_face:

Additionally, would you be up to sending us an email to [email protected] about your team’s needs and what you would like to initially see from the Gradle implementation? So we know what to prioritize :slightly_smiling_face: