# Tuist is coming to Android šŸ¤– **URL:** \ **Category:** General\ **Tags:** android\ **Created:** [December 13, 2025, 8:26am UTC](https://community.tuist.dev/t/tuist-is-coming-to-android/838 "2025-12-13T08:26:50Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![pepicrft](https://community.tuist.dev/user_avatar/community.tuist.dev/pepicrft/32/5_2.png) [@pepicrft](https://community.tuist.dev/u/pepicrft)\ **Post date:** [December 13, 2025, 8:26am UTC](https://community.tuist.dev/t/tuist-is-coming-to-android/838/1 "2025-12-13T08:26:51Z")
**Hola** šŸ‘‹ 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. šŸ˜© The go-to solution in the Android world is [Develocity](https://gradle.com/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. šŸ¤– ## Why Gradle is exciting for us āœØ 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](https://github.com/craigatk/opentelemetry-gradle-plugin)). 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 šŸ§ (and eventually Windows), which means breaking some assumptions weā€™ve made about running on macOS. ## How weā€™re approaching this šŸ›  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** šŸš€ 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** šŸ“Š 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 šŸ’¬ 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. šŸŒ ---
**Author:** ![pepicrft](https://community.tuist.dev/user_avatar/community.tuist.dev/pepicrft/32/5_2.png) [@pepicrft](https://community.tuist.dev/u/pepicrft)\ **Post date:** [December 13, 2025, 10:36am UTC](https://community.tuist.dev/t/tuist-is-coming-to-android/838/2 "2025-12-13T10:36:36Z")
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? ---
**Author:** ![marekfort](https://community.tuist.dev/user_avatar/community.tuist.dev/marekfort/32/8_2.png) [@marekfort](https://community.tuist.dev/u/marekfort)\ **Post date:** [December 13, 2025, 10:44am UTC](https://community.tuist.dev/t/tuist-is-coming-to-android/838/3 "2025-12-13T10:44:42Z")
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. ---
**Author:** ![pepicrft](https://community.tuist.dev/user_avatar/community.tuist.dev/pepicrft/32/5_2.png) [@pepicrft](https://community.tuist.dev/u/pepicrft)\ **Post date:** [December 13, 2025, 11:26am UTC](https://community.tuist.dev/t/tuist-is-coming-to-android/838/4 "2025-12-13T11:26:31Z")
Thatā€™s fair. Letā€™s see what the prototype reveals. ---
**Author:** ![jamesolrog](https://community.tuist.dev/user_avatar/community.tuist.dev/jamesolrog/32/813_2.png) [@jamesolrog](https://community.tuist.dev/u/jamesolrog)\ **Post date:** [February 7, 2026, 8:33pm UTC](https://community.tuist.dev/t/tuist-is-coming-to-android/838/5 "2026-02-07T20:33:25Z")
Is there a way we can register interest to be involved in any early testing of Tuist for gradle/Android? ---
**Author:** ![marekfort](https://community.tuist.dev/user_avatar/community.tuist.dev/marekfort/32/8_2.png) [@marekfort](https://community.tuist.dev/u/marekfort)\ **Post date:** [February 9, 2026, 8:20am UTC](https://community.tuist.dev/t/tuist-is-coming-to-android/838/6 "2026-02-09T08:20:56Z")
Weā€™ll be announcing early support for Gradle very soon, follow our social channels or this forum to stay up-to-date šŸ˜Œ Additionally, would you be up to sending us an email to contact@tuist.dev about your teamā€™s needs and what you would like to initially see from the Gradle implementation? So we know what to prioritize šŸ™‚