2025 is almost over, and what a perfect time to reflect on what the year has meant for Tuist. We thought for a while about what the best format would be for this, and the one thing we were sure about is that we didn't want it to be the classic wrapped kind of structure that has spread across all platforms. Even LinkedIn has it these days. Who would have thought? We thought we'd give it a personal touch.
A different model
We've been thinking a lot about what makes software companies sustainable. Closed-source software has a straightforward playbook: create artificial scarcity and churn. Place features behind paywalls, require sales calls, deprecate things that work fine to push upgrades. It's not pretty, but it works.
Open source breaks that playbook. When anyone can run your code, you can't manufacture scarcity. You need a different model. For Tuist, that meant the product had to take a different shape, solving problems where the server and infrastructure play a more important role. The value we charge for isn't the software itself, but running it fast, reliably, and securely. Think of how Supabase contributes to PostgreSQL and hosts it as a service. Or how Grafana built an empire around open-source observability tools. GitLab proved this at scale: they built an $11B business while keeping developers' trust by making community engagement a company-wide priority. The software is free. The operational excellence is the product.
We began transforming Tuist from a tool where most value lived in a client CLI, to one where more value lives in the server and eventually infrastructure. Organizations can pay us to run and scale their productivity infrastructure fast, safely, and reliably. We want most if not all of it to be open source and available for anyone to run locally. This year we made the server source available, and that felt like coming home. Openness eliminates barriers and makes you more accountable, leading to a much better product. When you work in the open, the community keeps you honest.
Growing the team
We knew we couldn't do this alone, so we welcomed Chris and Asmit to the team. Chris brought tons of expertise working with web services powered by Elixir. Asmit's design skills would elevate Tuist's visual identity to a new level. We firmly believed that with our taste and ability to build great developer experiences, multiplied by how they'd be presented to users thanks to gorgeous design, and spiced with open source, we'd end up with a recipe that's unique in its space. We still believe that.
Design is often undervalued in developer tools. There's this implicit assumption that developers don't care about aesthetics, that function trumps form. We think this is wrong. Good design is about clarity, and clarity is about respect for the user's time and attention.
We designed and implemented a design system called Noora for both Elixir with Phoenix LiveView and Swift for the terminal. It got highlighted on Apple's new Swift website, which was a proud moment. We overhauled our dashboard, redesigned our marketing site, and open sourced Noora for the web including all the Figma design files. We believe design systems should be a commodity, not a competitive advantage to be hoarded. This is how we contribute to the commons.
What we shipped
With that foundation in place, we shipped a lot with a team of 3.5 (the 0.5 was me, juggling business and housekeeping duties like getting SOC 2 certified). We built a Swift package registry and made it publicly available without requiring an account. We brought build insights and test insights. We added support for Xcode cache that works with any Xcode project. Our previews got better with tracks and a native iOS app. We built Tuist QA, which uses AI agents to test your previews. We shipped bundle analysis with a gorgeous dependency graph. If you look at Tuist at the end of 2025, it has nothing to do with the one we had at the beginning of the year.
But here's what matters more than the list: most of these solutions work with your existing Xcode projects. You don't need to use generated projects. You don't need to adopt a new project format. Most features can be adopted with a single line of code or command. This is intentional. We believe the best tools are the ones that meet you where you are. That said, generated projects remain the best option for scaling modular codebases—module caching alone can transform build times in large projects. Many still think of Tuist as a project generator, or as a Swift version of other project generation tools. It's fine! We're here to remind you. If you need a definition, we are a productivity platform for your app development. A virtual platform team.
What we learned
Something we learned this year is that developer needs fall into two buckets: problems teams actively seek solutions for, and problems they've learned to live with. The first category is straightforward—teams know what they need and can evaluate solutions easily. CI fits here. The second category is more interesting. Take build and test performance: teams often work without visibility into what's slowing them down. Many accept poor productivity as normal until it becomes unbearable. When we built insights, we weren't just offering a feature—we were helping teams see problems they didn't know they could solve. That's where we believe we can deliver the most value: illuminating the invisible friction that teams have normalized.
When it comes to growth, our strategy continues to be the same: publish great content that goes deep into areas that interest our community, and share the vision we have for the space we build for. This doesn't bring customers directly, but creates the brand awareness that brings us closer to companies. We tried cold outreaches, but they're not effective. Developers don't like to be contacted through random channels. Developers don't like going through lengthy procurement, security, or legal processes. You can't sell to developers the way you'd sell enterprise software. You have to earn their trust through substance, not spectacle.
What works is engaging in conversations as early as people show up in our community. We try to understand what brought them there, and then we keep those conversations warm. We hold the hands of our prospects, and they appreciate having an engineering team sitting virtually next to them. GitLab calls this the "open core flywheel": community contributions fuel product innovation, which attracts more users, which generates more revenue, which enables more investment in the product. We're building our own version of this flywheel.
Gaining traction
We closed the year with good sales momentum, and we believe we'll reach profitability in Q1 or Q2 next year. We can't emphasize enough how important this is. It signals there's a solid foundation here and a validation that Tuist is addressing the right needs.
We've closed deals that we wouldn't have imagined years ago. Hopefully we'll share more about those next year in the form of case studies, because the impact that Tuist has had in their ability to ship apps fast is astounding. Did we mention we are having first conversations with Korean companies where Tuist has traditionally had a huge presence through its communities? Localization and supporting the communities that form around open source is something we actively work on. It involves understanding the culture you're building for and adapting your solution to fit their expectations and needs.
Where we go from here
We want to reach teams that are burning engineering resources on tooling problems. Teams where productivity has gotten so bad that leadership is considering abstracting the platform away entirely. We want to bring them joy again, the feeling of building apps without fighting an unreliable toolchain.
We also noticed that Android teams essentially have one option when it comes to build optimization and insights. There's an opportunity there to simplify contracts and bring something fresh and better. In 2026, we're expanding to Android by integrating our features with Android build systems. All our solutions are valued in Android too, and we could simplify the vendor landscape for our customers by being their single productivity platform across ecosystems.
This reminds us of the problem that had to be solved in global shipping. Before the 1950s, moving cargo between ships, trucks, and trains was a nightmare of incompatible systems and manual labor. Then standardized shipping containers came along, creating a universal interface regardless of what was being transported or who was transporting it. The result transformed global logistics. We see a similar opportunity in build infrastructure. Many build systems and test runners with similar capabilities but inconsistent contracts. We want to build the bridge that solves this fragmentation, the shipping container for developer toolchains.
This doesn't mean we're building another build system. We're not interested in replacing Gradle or Xcode's build system. We're interested in the layer above them: the insights, the caching, the optimization. And we want to build that layer in the open. When you open-source the technology and offer to run it as a service, you become the natural choice. Would you pay Grafana for hosting a Grafana instance, or someone else? Likely Grafana, right? By contributing the technology back to the ecosystem, you earn the trust to run it. We see Tuist's role becoming two-fold: making ecosystems evolve through open source, and bridging the gap between build systems and infrastructure as a service. For example, while building our registry we found and fixed several bugs in SwiftPM's registry implementation (#8166, #8188, #8194) and contributed performance improvements that parallelize package resolution. The ecosystem gets better, and so do we.
Another thing that became obvious throughout the year is that to enable new developer experiences, we need more control over where things run. Latency matters. If your cache is far from where you're developing, the experience suffers. Most solutions are optimized for CI, where you can co-locate cache servers and CI environments on the same network. But what about developers working remotely? What about agentic coding environments that also need fast builds, caching, and insights? These environments don't run in the same network where CI is hosted, resulting in higher latency and degraded experience.
This CI-centric mindset has created solutions that disregard the diversity of environments we have today: local development, CI, and now agentic coding environments like Claude Code and Codex. We want to build infrastructure that treats all these environments as first-class citizens. This is going to be our first step into deeper infrastructure, and we couldn't be more excited. We don't yet know the full shape it will take, but we're confident in the direction.
Looking ahead
Our focus today remains strong on mobile. But next year's expansion to Android, hopefully with a good level of agnosticism, will give us a foundation to understand the content, not just the containers. For years, many have focused on the containers: where things run, whether that's local development, CI, or agentic environments. But the content, what actually runs inside them, has been largely ignored. With the right observability, that content can be optimized quite significantly.
We're ready to jump into this space with a fresh take. One that is more open. One that places community first. One that values innovation over imposing restrictions to stay afloat. The best tools get out of your way and make you more productive. The best companies build trust through transparency and earn your business by genuinely solving your problems. That's what we're building.
Thank you
None of this would be possible without the people who contribute to Tuist. Whether it's code, documentation, translations, bug reports, or community discussions, every contribution matters.
First, the team. Chris joined and immediately made an impact, scaling our infrastructure, evolving our caching system to improve its latency and reliability, and implementing our design system for Phoenix LiveView. Asmit brought design excellence to everything we do, from Noora to the marketing site to the countless details that make Tuist feel polished. Marek has been the engine behind most of what we shipped this year, from the registry to test insights to countless improvements in the CLI.
From the community, Hilton Campbell stood out with over 15 merged PRs, including cache profiles, Config manifest caching, tag-based generation, and a stream of bug fixes that made Tuist more reliable for everyone. Daniele Formichelli continued his long-standing contributions with 10 commits this year. Simon Cook, Mikhail, and Francisco Diaz each contributed multiple improvements. Gorbenko Roman, Paul Taykalo, Natan Rolnik, Mike Simons, and Md. Mahmudul Hasan Shohag all made their mark with multiple contributions.
We also received valuable contributions from Yusuf Özgül, YoHan Cho, Hiroshi Kimura, Luke Van In, Liam Nichols, Kolos Foltányi, Denys Telezhkin, Connor Ricks, Antoine Marcadet, Felix Lisczyk, Stefano Mondino, Ethan Wong, and many others who submitted fixes, improvements, and new features throughout the year.
Ryu0118 brought Sendable conformance to Noora, helping us keep up with Swift's concurrency evolution. Noora also got sharper thanks to feedback from Joannis Orlandos, Finn Voorhees, Raul Menezes, and Ernest0N.
Our Korean community continued to grow, with 2sem writing blog posts and reporting issues that helped us improve localization. jihoonahn added TuistUI Plugin, ZhgChgLi contributed XCFolder, and shahzadmajeed shared a code signing plugin. Leo Dion kept the EmpowerApps resources fresh, and iosdevzone caught broken links before our users did.
And then there are the translators. Sofia Kalinina, Boram Jeong, Randy Lu, Emirhan Karahan, and many others through translate.tuist.dev made Tuist accessible to developers around the world. Thank you.
We're bound to have missed some names, and we apologize for that. If you contributed in any way, know that we see you and appreciate you. Building something like Tuist is a team sport, and you're all part of the team.
