2024 Wrapped

When you decide to introduce Tuist into your toolchain, you are trusting us with your project, your team, and your time. Therefore, it's important for us to be transparent about what we do to earn that trust and what's in our plans to continue supporting you in the future. This blog post reflects what we did in 2024 and what's in our roadmap for 2025.

Tuist started in 2017 as a project to conceptually compress the complexities and eliminate the annoyances of Xcode projects, and a lot has changed since then. Some long-standing issues like frequent merge conflicts have been somewhat alleviated by Apple in Xcode 16, albeit still not completely resolved. They are also nudging projects away from bad practices like implicit module dependencies toward explicit ones, and the community is pushing the Swift Package Manager and packages to be the building blocks to describe projects and avoid the Xcode project format altogether. As of today, we know it might not be a good idea from a DX perspective, but with so much push from the community and resources from Apple, who knows what the future holds for the platform.

With that context, we started to think about the role that Tuist should have in the ecosystem and how we could best support teams and developers in their journey of scaling development. What we concluded is that Tuist should embrace the existing toolchain, with its strengths and weaknesses, and connect to it as an extension instead of trying to abstract it away. We are not fans of abstractions, but in the case of Xcode project complexities, it was unavoidable. However, as Apple addresses the issues at more foundational layers, we can gear our efforts toward leveraging existing APIs to fill the gaps to work at scale. In that effort, we'd dog-food and push the boundaries of what's possible with the existing APIs, and as more pieces become open-source by Apple, we'd contribute back to the community.

With the above context, let's dive right into our investments in 2024 and our roadmap for 2025.

Community - More vibrant than ever

When I think of Tuist's uniqueness, I think of its community. They are the ones that make Tuist what it is today. In 2024, we merged 723 pull requests in our repositories from over 321 contributors.

In 2024, contributors also helped us translate 100% of our documentation to Korean, and work to translate it into Japanese, Portuguese, and Russian is ongoing. Meeting developers where they are also means meeting them in their language, and for that reason we invested and we'll continue to invest in making Tuist speak other languages.

Having a healthy and vibrant community is a precious asset that we were struggling to nurture and support due to our limited resources, so earlier in the year we started to wonder whether Slack was the right platform for communication to happen. Similar questions repeated, the synchronous nature of the platform made it difficult to keep up with the conversation, and the closed nature of the platform made it difficult for us to put some tools in place to make the community more self-sufficient. For that reason, we decided to deploy our own community forum using Discourse, the same solution that the Swift community forum uses. The forum encouraged deeper, longer, and more asynchronous conversations that are more peaceful to navigate. Moreover, search engines can index the content, so it's easier for developers to find answers to their questions. And Discourse has a rich set of plugins that we can use to make the community more self-sufficient. Why not GitHub Discussions, you might wonder... the reason is simple: for a reason we don't understand, GitHub Discussions is not well indexed by search engines, and there's no extensibility available, which is crucial for us to mold the forum to our needs.

2025

In 2025, we'll roll out the Tuist Ambassadors program to recognize contributors who have gone above and beyond and support them in representing Tuist in the community. We'll also invest in improving the contribution experience by removing any friction in the process, and explore how to bring the community component to the features we are planning for the product. In the same vein as Dagger has built a Daggerverse for their ecosystem of pipelines.

In January, we'll start publishing issues in a new newsletter, "Swift Stories", which aims to create a cozy space for new voices to share their ideas. As part of our work at Tuist, we get to interact with many people who have great ideas and reflections that remain siloed because they don't feel they are worth sharing. We'll empower them through our newsletter and other initiatives to share their ideas with the community.

Product - From project generator to an integrated extension of Apple's toolchain

2024 was a year of transition for Tuist. We entered the year shifting from the idea that we are a project generator toward the idea that we are an integrated extension of Apple's toolchain. This is a shift that takes time because once people have formed an idea of what you are, it's difficult to change that perception. Still, we deem it necessary. Otherwise, new unrelated features start gravitating around a legacy solution, and people get even more confused. So you are a project generator, but you also do this and that.

How to make that shift? Besides communicating it actively in every interaction with the community, we revamped our brand, which materialized in a new logo, marketing site, and documentation site. We consider the website a living organism, so we continue to iterate on it as we learn from our developer community. The amazing Guinda studio took on the task of designing our new website, and as a result of that work, we also opened our marketing design system under the CC BY-SA 4.0 license. Did you notice our new title? "Scale your Swift App development". It beautifully encapsulates our mission.

We started the year officially introducing Tuist Cloud, which we later consolidated into just Tuist (so no more cloud). We also invested in supporting Xcode 16 features from Tuist Projects and developed new features like Tuist Previews (along with a macOS app). Developers complained about compile-time of Swift Macros, so we extended Tuist Cache to support caching them too.

2025

The first problem we'll solve in 2025 is slow Swift Package resolution that's inherent to SwiftPM's decentralized approach to package resolution using Git. We'll roll out a Swift Package Registry that mirrors the packages from the Swift Package Index and distributes them from a global storage network.

Then our efforts will gravitate to two things:

1. Bringing our insights and optimizations to vanilla Xcode projects (i.e. standard Xcode projects that are not defined with Tuist Projects' DSL).
2. Expanding metrics to projects, builds, and built products, and making them actionable

At Tuist, we first focused on understanding Xcode projects and the build system, and optimizing them. We now think it's time to bring these optimizations to vanilla Xcode projects and Swift Packages, ensuring the adoption is as frictionless as possible. And with that foundation in place, we deem it crucial that teams have a deeper understanding of their development to make informed decisions. Our metrics will focus on projects, builds, tests, and built products, and we'll go the extra mile to make them actionable. Think of Tuist as the platform teams' copilot or a virtual platform team. Not only will it tell you how things are going, but also the things that you might consider doing to improve your development environment and the apps that you build.

In parallel, we'll start doing some explorations around CI. It's a space where innovation has stagnated. Many Tuist users are vendor-locked into platforms through proprietary YAML schemas and ecosystem of steps and are asked to pay abusive prices by some vendors. We want to help our developers move away from that, and we are going to take the opportunity to rethink the space. Our investment will gravitate around three needs that remain unaddressed today:

1. Debugging a pipeline locally is not possible
2. There's too much indirection (CI > Proprietary YAML > Scripts (e.g. Fastlane) > Apple toolchain > Xcode Project)
3. Developers love using Swift for everything

So expect some new open-source projects in this space in 2025. More on our open-source strategy further down.

Engineering - Embracing simplicity

We are a small team with limited resources, and this is something that we've embraced as positive. Since we can't afford throwing money at problems, early in 2024 we wondered what technology strikes the best balance between powerfulness and costs (i.e., development and scaling). It was then when we crossed paths with Elixir, which builds on a very matured and battle-tested runtime, Erlang, to build fault-tolerant and scalable systems. We didn't think twice. We rewrote the Tuist server from Ruby into Elixir, and we never looked back. Unlike many other solutions, which present themselves as simple while abstracting a world of complexity that sooner or later becomes costly, Elixir and Erlang are simple by principles and concepts.

The functional nature of the language and the actor model makes it possible to parallelize test runs without introducing flakiness. We can scale servers vertically by adding more CPU and memory, and all we really need is a powerful server instance. Its hot-reloading capabilities in development have been crucial for speed of iteration, and the same goes for its REPL when it comes to debugging issues. We are also embracing web standards as much as possible to minimize dependency on layers of proprietary abstractions that can disrupt and distract us from our mission. The interaction between the CLI and the server is through a well-documented REST API (we plan to open it to third-party developers down the road). Our UIs are Phoenix LiveView, and our upcoming design system will make use of Web Components. One of the beauties of the web platform is that it's always backward compatible, so if we embrace it, the Tuist that we build on the server will work today, next week, and in years to come, and the team will pour its limited resources into bringing more value and not keeping up with trends.

In 2024, we also commoditized some Tuist components, like XcodeGraph, and thanks to Andy's amazing work, the investment is already paying off since you'll soon be able to use some Tuist features like selective testing with vanilla Xcode projects. Isn't it amazing? We also created Path, forking some utilities from swift-tools-support-core, standardized file-system operations across Tuist packages with another open source project, FileSystem. We also open-sourced Command to run system processes in Linux and macOS environments.

One common denominator across all the technical efforts in the CLI is that we are trying to make the foundational pieces work with macOS, Linux, and soon Windows, in case we need Tuist to support other ecosystems in the future where developers might need to run the CLI from Linux or Windows environments.

Thanks to Swift Macros and Kolos Foltányi's amazing work with Mockable, which we started adopting in our codebase, we are now saving a lot of time not writing the mocks that we used to write. We also started adopting Swift Testing, and we are quite pleased with the experience so far.

In 2024, we also made a fair investment in bringing performance improvements to the project generation by parallelizing operations that previously ran sequentially.

2025

In 2025, we'll iterate on our architecture to dependency-inject core utilities to be able to isolate each test case and run them in parallel without the risk of introducing flakiness. As part of the development of some features, we'll open-source and maintain some commodities for the community to build upon.

Design - Laying a missing foundation

Since the first line of code, the focus of Tuist has always been on code craft. For the surface where design was needed, like the CLI output and input (e.g., names, flags), and the website, we always tried to keep it simple and functional. It served us well for a long time, but as Tuist takes shape in new platforms, like our macOS app and the dashboard, it's time to stop treating design as an afterthought and start investing in it.

When it comes to code, sooner or later in the lifecycle of a project, you start extracting the common elements into reusable code utilities and frameworks for consistency and reusability. The same notion applies to design, and the extraction of common patterns for reusability and consistency usually manifests as a design system. Guess what, that's what we started doing in 2024.

Asmit took on the task of coming up with a design system for Tuist. He shared the progress with the community and is almost done with the first iteration. And as huge fans of open source as we are, the design system will be open too for anyone to use. We'll soon start converting it to web components that are easily reusable across websites. At first, we'll use them in the Tuist dashboard, and then in some CLI features like interactive graphs, which are CLI features that don't need a server.

Inspired by Ruby and Ruby on Rails, we've always optimized for joy. At the end of the day, who doesn't like enjoyable experiences when using technology? That's one of the reasons why Apple is so successful when building products. They put meticulous attention to detail in the design of their products. When we look at the developer space, we see quite the opposite: data and randomly designed components stitched together and information competing for attention. Or even worse, sales or marketing leaking into the product anywhere you go. We have an excellent opportunity in front of us to do things differently, and let me tell you something: we won't miss it.

Design systems are not just about consistency; they're about agility. Since we'll have a common language between developers and designers, and a set of reusable components ready to use, a lot of the work will revolve around assembling them and presenting content in them. I still remember my time at Shopify when we used Polaris to build some internal services, and the speed of delivery was just unbeatable.

2025

The first feature that makes use of the design system will be our dashboard. We'll redesign it from the ground up, bringing feature parity with the CLI, and bringing workflows that have traditionally been CLI-first, like adding Tuist to a project, which you'll soon be able to do right from the web. Remember the mobile-first trend? We've been CLI-first too, like Fly is, and we'll continue to be so, but we'll make sure operations are also achievable through a beautifully designed dashboard.

We'll also pour resources into improving the design of the CLI output. With no control, it's easy to end up with outputs that are hard to parse and understand. So like we are doing for the web, we are open-sourcing a design system for Swift CLIs, Noora, which we'll adopt throughout the CLI. We'll separate and differentiate between logging, which we are turning into a debugging tool, and treat user output more like UI in a standard AppleOS application. Terminals are limiting environments, but they spark a lot of creativity.

Business - Building a different business

When you enter a business relationship with another company through a service they provide, you are introducing some risk to your development or operations. The company you transitively depend on through a service might go bankrupt, take a direction that doesn't align with your needs or values, or leverage their competitive advantage in a market to roll out abusive prices that you can do little about. We are seeing a lot of this last one in the CI space. Deciding on a service is a decision that can't be taken lightly, despite many companies doing so.

As surprising as it sounds, when the dependency is on one or two developers who are building open source software that you depend on, the risks are more often ignored. When you all decided to introduce such a foundational tool as Tuist into your workflows, you all trusted us to minimize that risk for you. And minimizing that risk is in fact what motivated us to build Tuist as a company, a different type of company.

The support and requests work demanded people to be full-time on Tuist, and that required us to bring some business structure to the project. We drew a line between the CLI and the server. CLI-only features would be free, and those that required a server would be paid. We'd keep the server closed-source until we could financially secure the resources needed to support Tuist. Since we knew a closed-source server could be concerning for some of you, we did something unique that not many companies provide: a longevity plan. What does that mean for you? Simply put, if we screw things up, the code of the server will be open-sourced and given to the community. We believe that's the right thing to do.

But just that is not enough. What if for any reason, you disagree with us and want to take your project elsewhere? In a traditional model, it would be so painful that you'd rather stick with the service and hope for the best. Just not so long ago, I was told that some CI providers are offering to "migrate your CI pipelines for free." How bizarre is that? If that's a business practice that companies are adopting, we are doing something wrong as an industry. We need to do better. For that reason, we bet on standards and open source as much as we can because we respect people's freedom to choose, and Tuist is no one to get in their way.

So our model is simple. We monetize the server features to develop more open source software. Server features are usually features that large enterprises need and are willing to pay for, so we funnel capital to support not only open source but also indie developers and small startups that are getting started. I think it's a beautiful model.

We also embraced a different pricing model compared to the norm in the industry. Since these tools are geared towards large enterprises, they place a "contact sales" option on their website and put you in the position to have great negotiation skills to get the best price out of it. Additionally, they give you a very limited demo so that you get a taste of it, and the demo is slapped with "contact sales" buttons everywhere. Once again, we think we are doing something wrong as an industry. So we decided to take a different approach based on three principles:

1. We charge per usage
2. You don't pay if you don't use it enough
3. We aim to be the cheapest at every scale

The model is working exceptionally well. Companies already using Tuist are now becoming customers of our paid features, helping us continue to build even more open-source software. Some, like Trendyol, have even gone so far as to provide us with a case study unsolicited, which is truly humbling. We've seen steady conversion, and we're already collaborating with several other companies to bring them on board as customers.

Beyond that, we’ve learned a great deal about German bureaucracy and the nuances of running a business—things like taxes, accounting, contracts, and most recently, hiring. Christoph and Asmit are officially joining us full-time in January 2025, and I can't wait for them to get started. We’re a small team, but one that is poised to make a significant impact in the industry.

2025

In 2025, we’ll continue to work with organizations adopting our paid features, helping them integrate these solutions into their workflows. Alongside this, we’ll invest in enhancing the Tuist CLI and developing other essential tools for the ecosystem. We’ll also be releasing new features tailored to small startups and indie developers, offering them self-upgrade options with minimal costs based on their usage.

In Q1 2025, we expect to obtain the SOC 2 certification, which should accelerate our ability to become a vendor for companies requiring this certification.

Marketing - Our community is our best marketing

As you may have noticed, we’ve spent very little on marketing. When you spend money on marketing, it becomes forced. You can get people to talk about you, write about you, or put you in front of people—but that only works as long as you continue to spend.

Instead, we focus on being human with our community. What does that mean? We nurture our community and empower its members. They connect with the project in such a unique way that they become our most powerful marketing tool. That’s how we’ve gained such popularity in countries like South Korea, without spending a dime on marketing there. It’s truly mind-blowing.

This might go against conventional marketing advice, but believe me, the best marketing comes from the people you support and empower. For this reason, much of what we do focuses on the people rather than ourselves. When we decided to launch a newsletter, it was clear from the start that the focus would be the community, not us. That’s why it’s called "Swift Stories" and not "The Tuist Newsletter."

We’ve also sponsored conferences to support community-driven initiatives, but we’ve never seen that as a marketing tactic. We draw inspiration from what others are doing and help them along their journey. We don’t believe in paying people to talk about us. If you like Tuist and want to write about it, that’s amazing! We’re forever grateful, and we’ll send you tokens of appreciation, but we won’t pay you for it.

2025

In 2025, our marketing efforts will continue to center around the same philosophy—investing in our community and community-driven projects, like our newsletter. We’ve also considered launching a podcast, but due to time constraints, we’ll have to delay it for now. It’s something we’ve always dreamed of doing, so we’ll make it happen eventually.

Closing words

It’s incredible to look back and see how much we’ve accomplished in 2024 with just two people working full-time, alongside our open-source community. The Tuist project is more vibrant than ever, and we’re excited for what 2025 holds.

Contributors

Whether you’re using Tuist, contributing to it, or helping maintain it, I’d like to personally thank you for being part of this journey. We’re building something special here, and we’re doing it together.

And huge thanks to all those who contributed to Tuist in 2024:

danieleformichelli, ollieatkinson, kwridan, waltflanagan, adellibovi, laxmorek, olejnjak, actions-user, lakpa, andreacipriani, mollyIV, RomainBoulay, natanrolnik, ezraberch, vytis, alexanderwe, luispadron, adamkhazi, hisaac, facumenzella, marciniwanicki, regularberry, danyf90, hebertialmeida, rowwingman, mikchmie, thedavidharris, LorDisturbia, iteracticman, leszko11, frijole, danibachar, dangthaison91, maciejpiotrowski89, rofle100lvl, yurapriv, ferologics, freak4pc, woin2ee, anlaital-oura, cpisciotta, dcvz, kapitoshka438, KaiOelfke, jsorge, serejahh, Lilfaen, TheInkedEngineer, apps4everyone, fila95, hiltonc, TamarMilchtaich, wattson12, mstfy, rgnns, ffittschen, erkekin, DimaMishchenko, paulsamuels, devyhan, foyoodo, svenmuennich, pewegela, raven, MontakOleg, Rag0n, ladislas, jeroenleenarts, zhuhaow, jakeatoms, baekteun, minhaaan, jrescabias, chojnac, shahzadmajeed, pavel-trafimuk, PaulTaykalo, AlbGarciam, xoxo-anastasi-xoxo, davebcn87, morozkin, dxmvsh, esttorhe, moritzsternemann, nandodelauni, miscampbell, bolismauro, Jake-Prickett, FranzBusch, DevVenusK, santos88, spqw, vijaytholpadi, ahmdyasser, costapombo, dankinsoid, kyungpyoda, mustiikhalil, oozoofrog, dp221125, thelvis4, tovkal, zdnk, darrarski, softmaxsg, woohyunjin06, setoelkahfi, rsarv3006, fuzza, orbitekk, lo1tuma, michaelmcguire, Binlogo, dcordero, cristi-lupu, DavidBrunow, david-all-win-software, ajkolean, Arideno, dogo, roanutil, DevilDimon, Andrea-Scuderi, Ernest0-Production, mfcollins3, havebeenfitz, mihaicris-adoreme, L-j-h-c, myihsan, InderKumarRathore, iainsmith, nicholaskim94, gustn3965, GermanVelibekovHouzz, PierreCapo, codeOfRobin, griches, sphanley, sampettersson, saim80, SergeyPetrachkov, fdzsergio, schinj, MagnificentMiles, tdkn, simpers, JCSooHwanCho, st-small, steprescott, rist, stefanomondino, kalkwarf, stevelandeyasana, stephanecopin, sujata23, doulos76, devMinseok, mohitsaxenaknoldus, tosbaha, NataliaKurek, NickZemlin, nivanchikov, oronbz, Austinate, wogus3602, BalestraPatrick, pavm035, petrukha-ivan, platonsi, PushedCrayon, Arafo, OhKanghoon, enlivn, rhysm94, rmnblm, RomanPodymov, aniltaskiran, brianvar, cheskapac, dcramps, honghoker, euriasb, ibrahimoktay, jimmy-li-houzz, kimxwan0319, kyounh12, MariusDeReus, pierrerodgers, ronanociosoig-200, sabade-omkar, sh-a-n, sonuvryahoo, vendulasvastal, tatagrigory, tzxdtc, jihoonahn, c0diq, TahaTesser, ActuallyTaylor, tejassharma96, ThiemeFM, takinwande, hoangatuan, tiarnann, vkrol, victor-sarda, VilleWitt, vcoutasso, in4lio, vldalx, khramtsoff, SpectralDragon, wangjiejacques, wojciech-kulik, Buju77, neakor, yungu0010, zzzkk, aegzorz, acosmicflamingo, cruisediary, Killectro, danrevah, dansinclair25, dbarden, danielmoro, DarkoDamjanovic, buresdv, Primecutz, cieslakdawid, decanus, denil-ct, francuim-d, dever25, navartis, Dmitry-Pliushchai, DmitrySerovWise, eddieh, ElonPark, bogren, eito, Juanpe, abbasmousavi, alpanyukov, alexfilimon, Smponias, alvar-bolt, alvarhansen, andruvs, rock88, aim2120, Garfeild, a-sarris, Gladkov-Art, astromonkee, ajevans99, barakwei, BarredEwe, batuhansk, BenjaminPrieur, bhuemer, brunoorocha, csjones, chris-livefront, cconstable, JulianAlonso, kabirkhaan, nagra, avbangar, kevin58332, kevinrandrup, kientux, UniekLee, lucabartoletti, lucasmpaim, luciav-github, lm2s, mpodeszwa, MartinStrambach, MarvinNazari, Mstrodl, MatyasKriz, Speakus, michalsrutek, mikeger, mgray88, akaDuality, Ethan-IS, Lommelun, filipracki, MrCloud, gcacoutinho, gaetanomatonti, Arclite, mangofever, grdsdev, Tulleb, haeseoklee, haifengkao, swiftty, HossamYoussof, isavynskyi, eltociear, ilia3546, TheImShrey, unxavi, jesus-mg-ios, mo5tone, jinuman, johnyorke

And the following people have contributed translations to Tuist in 2024:

Shun Tedokon, eunpyo hong, sunghun, Boram Jeong, Trickart, Takashi, Sean Hong, 김효성 (devvenusk), leesam, Roy