I joined one of those teams at Shopify. It was called Mobile Tooling, part of a broader group called Dev Acceleration. The premise was simple: if you have hundreds of engineers using build systems, test runners, and deployment pipelines every day, you need a team that ensures those tools are used in the most optimal way possible. Human capital is expensive. You do not want engineers sitting idle waiting for a build to finish. You do not want them rerunning a test suite because they cannot trust the results. You want every resource, human and machine, working at its best.

The reason these teams exist comes down to two things.

First, understanding developer tooling at a deep level is rare. You need years of experience with build systems, test runners, and the kinds of failures that only emerge at scale. Knowing how a compilation graph distributes work across cores, understanding why a particular dependency ordering creates bottlenecks, recognizing when a configuration choice made two years ago is now costing you minutes on every build. This is not knowledge you pick up in a weekend. And asking a product engineer to context-switch into this work is a big stretch. It is like asking a chef to also be the plumber. They could probably figure it out, but you are wasting their best skills.

Second, by the time you form a platform team, the codebase is already large and there is a lot of activity happening. Making meaningful improvements requires changes in configuration, changes in tool versions, reorganizing code. Doing all of that while business demands keep rolling in is incredibly difficult. It is surgery on a patient who refuses to stop running.

The reactive trap

What happens in most organizations is that the platform team, if it exists at all, works reactively. Something breaks, someone complains, the team investigates. The tools themselves are not designed for observability. The interaction model is you and a terminal. You configure a build system once, you grow the codebase for months or years, and you rarely revisit that initial configuration. Performance degrades slowly, invisibly, like a frog in warming water.

Think about it like a factory floor. Imagine a manufacturing plant where nobody monitors the machines. They were set up correctly on day one, and for a while everything runs smoothly. But over time, bearings wear down, belts loosen, calibrations drift. Because nobody is watching the telemetry, because there is no telemetry, the degradation accumulates silently. By the time someone notices that production has slowed by 30%, there is no single cause. It is a hundred small regressions stacked on top of each other, and untangling them is a nightmare.

This is exactly what happens with developer tooling. And with coding agents entering the picture, the problem has accelerated. Agents produce code at a velocity that human developers never reached. If any step in the process of turning that code into a compiled artifact or running tests to validate it is slow or unreliable, you diminish the returns of the entire agentic workflow. Flaky tests that an agent cannot trust. Builds that take twenty minutes when they should take three. These are not minor annoyances anymore. They are bottlenecks that make expensive infrastructure less valuable.

Three layers

This is something we have been thinking about a lot at Tuist. Not just how to fix individual problems, but how to frame the entire space of developer productivity in a way that gives us and our users a shared mental model. Without a clear framework, it is easy to end up with a product that is a Frankenstein of features. A cache here, an analytics dashboard there, some CI integration over there. Everything loosely connected but lacking a coherent story. We needed a structure that would hold everything together and guide us as we expand into new ecosystems.

What we arrived at is that developer productivity operates in three layers, stacked vertically. Each layer has its own characteristics, its own economics, and its own relationship to the others.

Think of it like the human body. The toolchain is your form and technique: how efficiently you convert effort into movement. Compute is your muscles: raw strength and power. And cache is muscle memory: movements you have already learned that you do not need to think about again. A strong athlete with bad form wastes energy and gets injured. Perfect form still has a physical ceiling if the muscles are not there. And muscle memory is what lets you perform beyond what conscious effort alone allows, because you are not repeating work your body already knows how to do.

The toolchain layer

This is the layer closest to your project. It is the interaction between your code and the build systems, test runners, linters, and all the tools that turn source files into something that runs. It is the least glamorous layer and the one that gets the least investment. Not because it is the least important, but because it is the hardest.

Going deep into the toolchain requires understanding every ecosystem individually. How Swift compilation graphs work is different from how Gradle resolves dependencies, which is different from how Vite bundles JavaScript. In networking, there is a concept called the narrow waist: the thin layer that sits between everything above and everything below, translating between the two. TCP/IP is the narrow waist of the internet. The toolchain layer is the narrow waist of developer productivity. It sits between your project and the infrastructure that builds it. But unlike TCP/IP, there is no universal protocol here. Every ecosystem has its own narrow waist, with its own data structures, its own performance characteristics, its own failure modes. You have to learn each one individually. There is no shortcut. This makes the toolchain layer unattractive for companies that need quick returns to meet investor expectations. You cannot raise a round, hire a team, and have ecosystem depth in six months. It does not work that way. We believe there is real value in making this investment, but it is value that compounds over years, not quarters. The trust you earn by going deep into an ecosystem, by contributing to the tools developers already use, by understanding problems at a level that most companies will not bother with, that trust is what turns into adoption and retention over time.

The tools themselves are typically not designed for observability. Your build system speaks to you through standard output. You see a wall of text, maybe some timing information if you are lucky, and that is it. All the rich internal data, the compilation graph, the dependency ordering, the parallelization profile, is flattened into a log stream. You miss most of what is actually happening.

And even when you can extract useful data, you need to understand it over time. Is a particular module a parallelization bottleneck? Maybe. But it depends on how often that module changes. If it changes on every commit, optimizing it is critical. If it changes once a quarter, it probably does not matter. Frequency is something you only know if you persist the data and analyze trends. A single snapshot tells you almost nothing.

This is the layer where we started at Tuist, and it is where we believe the most impactful work happens. We have gone deep into Xcode. We are going deep into Gradle. And as we expand into more ecosystems, we will do the same thing every time: understand the data structures the tools work with, observe them properly, and get to a point where we can proactively surface insights instead of waiting for someone to complain.

Most companies avoid this layer because each ecosystem requires dedicated investment. They prefer solutions that look the same everywhere. That preference is understandable. It is also why the toolchain layer remains the most neglected.

The compute layer

If the toolchain layer is your form, compute is your muscles. This is the raw power where the action happens. Your developer laptop. Your CI runner. And increasingly, the sandboxed environments where coding agents execute their work.

Compute is where most of the money flows in our industry, because it is the easiest layer to invest in. It is tangible. You can measure it. You can compare specs. You can say "my machine has 32 cores and 64 GB of RAM" and feel like you have solved something. Companies compete on milliseconds of startup time, on core counts, on I/O throughput.

And it matters. Of course it matters. A faster machine compiles code faster, runs tests faster, everything faster. But compute alone has a ceiling, and that ceiling is determined by physics. You can buy the most powerful machine available, and your build still takes however long it takes to process everything from scratch.

Here is the part that I find genuinely fascinating: organizations pour money into faster compute while completely ignoring how their projects use that compute. If your compilation graph has one massive module that everything depends on, you will have one core working at full capacity while fifteen others sit idle waiting for it to finish. That is an expensive machine doing very little work. It is like a weightlifter with massive arms but terrible form. The strength is there, but most of it is wasted.

The compute market is getting crowded. CI companies that have invested in their infrastructure for years are now offering those environments for agent workflows. Sandbox companies like Daytona, E2B, and others are providing boxes for agents. Product companies like Linear, Codex, and others are spinning up their own environments. Everyone is offering compute because compute is a relatively straightforward product to build and sell.

But when everyone is selling the same thing, differentiation becomes razor thin. Someone will always match your specs at a lower price. This is where companies that only do compute start to struggle. Their improvements become incremental: 200 milliseconds faster startup, 100 milliseconds less latency. Important, but diminishing.

The cache layer

At some point, no matter how fast your machine is, you hit the physical ceiling. Your cores are saturated. Your I/O is maxed. And yet you are compiling or testing something that someone else, maybe even you ten minutes ago, has already done. From the perspective of using resources optimally, repeating that work is waste.

This is where caching enters. Build systems like Bazel pioneered remote caching years ago. Gradle has it. Xcode introduced compilation caching recently. The trend is clear: caching is becoming a standard capability across ecosystems.

The interesting tension with caching is that it introduces the network. You break through the physical ceiling of a single machine by distributing pre-computed results across a network. But in doing so, you make latency the new bottleneck. If you can pull a cached artifact in 5 milliseconds, caching is transformative. If it takes 500 milliseconds, you might be better off just rebuilding locally. The gains from caching are directly proportional to how close the cache is to the compute.

Going back to the body analogy: muscle memory only works if the recall is instant. If there is a delay between your brain sending the signal and your muscles executing the movement, you lose the advantage entirely. You might as well be learning the movement from scratch. Proximity between the memory and the muscles is everything.

This is why compute and cache must be colocated. They are not independent layers you can optimize separately. They have to work together, physically close, with minimal latency between them. A fast machine with a distant cache is not much better than a fast machine with no cache at all.

But low latency is only half the problem. The other half is access. A cache is only as useful as the number of contexts that can reach it. Today, your code builds in many places: your laptop, your CI runner, an agent sandbox, a colleague's machine. If the cache is only accessible from one of those contexts, you are still repeating work everywhere else.

This is where many existing solutions fall short. GitHub Actions cache, for example, is tightly coupled to CI pipelines. It lives inside the CI compute and can only be accessed from within a workflow run. Your developers cannot pull from it locally. An agent running outside of GitHub Actions cannot benefit from it. The cache exists, but it is locked inside a single context. That is not a cache infrastructure. That is a feature of a CI product.

A cache worth building needs to be accessible from anywhere the action happens. Multiple interfaces, multiple protocols, multiple entry points. Your build system should be able to reach it. Your IDE should be able to reach it. An agent running in a container somewhere should be able to reach it. The cache should be a piece of infrastructure that serves all compute, not a feature that serves one product.

Why the framework matters

The reason we wanted to capture these three layers as a mental model is that without it, we risk building a product that lacks coherence. When you expand into new build systems, when you ship new features, when you make architectural decisions, you need something to anchor those choices. Which layer does this feature serve? How does it interact with the other layers? Are we neglecting one in favor of another?

Without this framework, you end up with a product that is a collection of loosely related tools. A cache that does not understand the toolchain. A compute layer that does not know about the cache. Analytics that show you numbers without telling you what to do about them. Each piece works in isolation but the whole is less than the sum of its parts.

With the framework, every decision has a place. When we jump into a new ecosystem like Gradle, we know exactly what we need to build: deep toolchain understanding, cache integration, and compute awareness. The same structure applies regardless of the technology. The specifics change, but the architecture does not.

What we are building

At Tuist, we are designing the product so that you can choose the layer you need. You do not have to buy the whole stack. If you only want caching, you can deploy it close to your own compute and get the latency benefits without changing anything else. If you want compute and caching together, we will provide environments where they are colocated, so you do not have to think about proximity. It will just be fast.

And then we layer the toolchain understanding on top. This is the part that ties everything together. We do not just give you a fast machine with a cache. We make sure you are using those things in the most optimal way possible. We look at your build graphs, your test runs, your compilation patterns, and we surface the things that are wasting your resources. Not as a dashboard you have to check. As proactive insights that tell you what to fix and why.

This is the vision: we want to be the platform team that most organizations cannot afford to build themselves. Not a team of people you hire and retain and hope they stay long enough to accumulate the knowledge. A product that carries that knowledge, that watches your workflows, that understands your tools deeply enough to optimize them for you.

We are making this accessible to everyone. Not just the companies with hundreds of engineers and the budget for a dedicated platform team. Everyone. The team of five that just started a project and wants to build good habits from the beginning. The solo developer who does not want to spend a weekend figuring out why their builds got slow.

The three layers are simple enough to explain in a conversation. But they represent years of accumulated understanding of what actually matters for developer productivity. And they are the framework that will guide everything we build from here.

Along the way, we noticed something. Many of the problems we were solving weren't unique to Xcode. Slow builds? Gradle has them too. Flaky tests blocking PRs? That's universal. Build cache infrastructure that's expensive and painful to maintain? Teams working with Gradle deal with this every day. The underlying challenges are remarkably similar across ecosystems.

That's why we're excited to announce that Tuist now supports Gradle.

What's included

Build insights

Build time directly affects your feedback loop. As projects grow, build performance degrades. But most teams have no visibility into how or why. They track CI pipeline duration but can't answer basic questions: Which tasks take the longest? How does build time change across Gradle versions? Did that dependency upgrade actually make things worse? You can't improve what you can't measure. And with coding agents generating more changes than ever, slow builds don't just slow down one developer, they become a multiplier on wasted CI time across the whole team.

The plugin automatically sends build analytics to Tuist, giving you visibility into task execution and cache behavior in the dashboard. You can track which tasks take the longest or how build performance evolves over time. No additional configuration is needed, build insights are collected automatically once the plugin is installed.

Remote Gradle cache

Once you understand where build time goes, caching is the most effective lever to reduce it. Tuist provides a remote cache that integrates directly with Gradle's built-in build cache to share build artifacts remotely. When a task's outputs are already cached, Gradle skips execution and pulls the result from Tuist's remote cache. Your team stops rebuilding the same things over and over, and CI times drop.

But a remote cache is only as fast as the network between your builds and the storage. That's why Tuist hosts cache infrastructure with global coverage, giving you low latency no matter where your CI runners or developers are located. You get the speed of a local cache with the reach of a shared one, without provisioning or maintaining anything yourself.

On top of that, you get full visibility into how the cache is performing, such as hit rate over time or individual cache keys for each Gradle task, so you can understand exactly what's being cached and why something missed.

Test insights

A healthy test suite is a fast and reliable one. But as test suites grow, that's hard to maintain without data. Which tests are the slowest? Are they getting slower over time? Where should you focus your effort to get the biggest improvement? Without answers to these questions, test suite health degrades gradually until everyone just accepts that "tests are slow."

Tuist gives you the answers you need as the plugin automatically tracks every test run, individual test durations, failure patterns, and reliability trends. You can spot the slowest tests, catch regressions early, and focus your effort where it matters most.

Flaky test detection and quarantine

You change one line of code, push, wait for CI, and it fails on a completely unrelated test. You retry. Someone else merges in the meantime, so now you have conflicts. By the time you're green and merged, an hour and a half has passed — for a one-line change. Every retry is a context switch, every false failure is a distraction from real work, and most teams have no idea how much time they're losing. Worse, developers stop trusting the test suite. "It's probably just that flaky test" becomes the default assumption, and real bugs slip through.

With coding agents producing more PRs than ever, this problem scales with your team. If your test suite is flaky, your PR throughput doesn't scale and it ends being the bottleneck.

Tuist detects flaky tests in two ways:

• Test retries: When you use the Test Retry plugin, Tuist analyzes each attempt. If a test fails on some attempts but passes on others, it's automatically marked as flaky.
• Cross-run detection: Even without retries, Tuist compares results across different CI runs on the same commit. If a test passes in one run but fails in another, both runs are flagged.

Once detected, flaky tests appear in your project's dashboard where you can track their flakiness rate and drill into individual failures. Tests are automatically cleared after 14 days of stability.

And you don't have to stop at detection. With automatic quarantining, newly detected flaky tests are immediately isolated from your CI pipeline. The Gradle plugin fetches the quarantined test list before each test task and excludes them using Gradle's excludeTestsMatching filter. Your PRs stop getting blocked by tests that have nothing to do with your changes while you investigate the root cause.

Built for automation and agentic workflows

All the data Tuist collects — build insights, test results, flaky test history — is accessible through the CLI and the API. This matters because it makes Tuist a natural fit for the growing world of AI-assisted development.

For example, our fix-flaky-tests skill gives coding agents like Claude Code the context they need to actually fix flaky tests. The agent queries Tuist for flaky test data, analyzes failure patterns, identifies root causes, and applies targeted corrections. Coding agents are only as effective as the context you provide them with and Tuist provides the missing link for tackling these kinds of challenges.

Getting started

First, install the Tuist CLI. Then run tuist init in your Gradle project root and follow the interactive setup. The command handles authentication, project creation, and generates the configuration for you. Then apply the plugin in your settings.gradle.kts:

That's it. Build insights and test insights start flowing automatically, and enabling the remote cache is a one-liner in gradle.properties:

For the full details, see the Gradle plugin documentation.

Android-specific features

Beyond the Gradle plugin, Tuist also supports features that are particularly useful for Android teams.

Bundle insights

As your app grows, so does your bundle size. Tuist supports analyzing both .aab (recommended) and .apk files:

You get a detailed breakdown of your bundle and the bundle size tracked over time. When integrated with GitHub, Tuist posts bundle size analysis directly in your pull requests. You can also get notified directly in Slack with our Slack integration, so your team gets notified about size regressions as soon as they happen, ensuring they get caught before they ship.

You don't need to host anything

One thing we hear from teams evaluating build infrastructure tools: "We don't want to run more servers." We get it.

With Tuist, you don't need to host anything. We host the infrastructure for you, regardless of team size. There's no Gradle remote cache server to maintain, no analytics database to provision, no artifact storage to manage. You install the plugin, authenticate, and everything works.

For teams that do want more control, there are two self-hosting options:

• Self-host everything: Deploy the full Tuist server on your infrastructure. The whole server is source available, so you can inspect exactly what's running. See the self-hosting guide.
• Self-host just the cache nodes: This is especially interesting for teams working from the office or using self-hosted CI runners. You can deploy lightweight cache nodes close to where builds happen while letting Tuist handle the server itself, which is more involved to self-host. See the cache self-hosting guide.

Source available and open

The entire Tuist codebase is source available, and a large part of it is MIT licensed. You can read the source, understand how your data is handled, and contribute if you want. Transparency is a core part of how we build.

And since we dogfood everything we do, we're also using Tuist for our own Gradle-based projects and you can check out the public dashboards of these:

• Tuist Android app
• Tuist Gradle plugin

What's next

All of the Gradle features are currently free as our thank you to early supporters. Pricing for the remote cache will come later this year, but for now you can use everything mentioned here at no cost.

We'll continue going deeper into build and test insights. We want to track more data to pinpoint build bottlenecks, monitor CPU usage, and bring native support for test sharding. We're also building a native Tuist Android app (releasing later this month) that will make accessing and running Tuist Previews on Android devices seamless, just like the existing macOS and iOS apps do for Apple platforms. If there's anything your team is missing from the dashboard, let us know and we can prioritize it.

We're excited to bring everything we've learned from scaling Apple platform builds to the Android ecosystem, and to keep growing both sides together.

Reach out to us in our community forum or send us an email at contact@tuist.dev. We'd love to hear how you're using Tuist with Gradle.

That's why we're very excited to announce that the Tuist CLI runs on Linux.

Why Linux matters

There are three main reasons we invested in Linux support:

• Gradle on Android: We're bringing Gradle project integration to Tuist. Android builds commonly run on Linux CI machines, and requiring macOS for a tool that manages Gradle projects would be a dealbreaker. Linux support makes Tuist viable for Android workflows out of the box.

• Analytical workflows on CI: Commands like tuist test case list don't need Xcode or macOS. They talk to the Tuist server, process data, and return results. Linux machines are typically much cheaper than macOS ones, so running analytical and data-ingestion workflows there is a straightforward cost saving.

• Agentic environments: AI coding agents are increasingly running in cloud environments that default to Linux. Whether it's an agent that checks build analytics, manages project settings, or automates test quarantining, it needs a CLI that runs where it lives. Linux support makes Tuist accessible in these agentic workflows without requiring a macOS VM.

Supported commands

Not every command makes sense on Linux — commands like tuist generate or tuist xcodebuild inherently depend on Xcode and remain macOS-only. What does work on Linux are the commands that don't need Xcode: authentication, account and project management, analytical commands for browsing builds and test cases, cache configuration, and tuist init for scaffolding new projects. In short, anything that talks to the Tuist server or sets up your project works on Linux today.

How we got here

Getting a Swift CLI to compile and run on Linux is not trivial. Here's how we approached it.

Modularization and incremental migration

Before touching the Tuist CLI itself, we had already invested in Linux support across our open-source libraries, such as Noora, our terminal UI framework, or FileSystem, our file system abstraction. This meant the foundational layers were ready.

When we started to add Linux support, we knew we wanted to do so gradually by cross-compiling individual modules instead of doing everything in a single PR. And while Tuist was already heavily modularized, we still had a couple of monolith modules that mixed platform-specific and platform-independent code. TuistSupport, our shared utility layer, was broken into focused modules like TuistConstants, TuistEnvironment, and TuistLogging. TuistKit, which contained all the command logic, was split into per-command modules: TuistAuthCommand, TuistCacheCommand, TuistBuildCommand, and so on. Once separated, each module could independently target Linux compilation without pulling in macOS-only dependencies. That not only allowed for a gradual migration, but it allowed us to use compiler directives like #if os(macOS) and #if canImport(...) sparingly, keeping the code easier to read and maintain.

Fully static binaries with musl

Our first Linux builds linked the Swift standard library and system libraries like libcurl dynamically, meaning the binary required the Swift runtime and matching system libraries on the target machine. Instead, we switched to Swift's Static Linux SDK which cross-compiles against musl libc to produce fully static binaries with zero shared library dependencies:

The resulting binary runs identically on Ubuntu, Fedora, Alpine, or any other Linux distribution. No dynamic linker, no shared libraries, no Swift installation required. The trade-off is a larger binary since everything is bundled in, but for a CLI tool that's distributed once and run many times, portability is worth it.

The switch to musl did require some code changes. The C library module is named Musl rather than Glibc, so platform imports became three-way:

Distribution

We wanted the installation experience on Linux to be identical to macOS. Tuist is installed via mise, so we updated the aqua-registry and mise itself to recognize Tuist's Linux binaries. The result is that installing Tuist on Linux is the same single command you're already used to from macOS:

What's next

The Linux support is our first step outside of macOS and Apple platforms, but not the last one. We already have plans for support of:

• Gradle: We'll be officially releasing Gradle project integration soon, enabling Tuist to optimize and track Android builds.
• Windows: We'd like to bring Tuist to Windows as well. However, some of our transitive dependencies, like swift-nio (used via our FileSystem library), don't yet support Windows. We're keeping an eye on upstream progress and will revisit this as the Swift-on-Windows ecosystem matures.

If you're running CI on Linux or exploring cross-platform workflows, give the Linux CLI a try and let us know how it goes. Reach out to us in our community forum or send us an email at contact@tuist.dev for sharing your feedback

We've been thinking about this differently since coding agents became capable enough to hold context across long feedback loops. What if the agent could do the mechanical work of migration while we focus on defining the constraints and validating the output? If that works, Tuist handles the complexity of Xcode projects, agents handle the tool adoption, and developers get faster workflows without the friction of a manual migration.

We decided to test this on the Mastodon iOS client. A real app with multiple frameworks, extensions, third-party dependencies, and all the quirks that come with a production codebase. The goal was a generated workspace that builds, runs, and benefits from caching. You can find the resulting project on GitHub. We also wanted captured the process in a reusable skill that makes it easier for other teams to migrate without having to instruct the agent themselves on how to close the feedback loop.

What we asked Codex to do

We didn't hand Codex a step-by-step checklist. We gave it a set of outcomes: produce a Tuist-generated project that stays as close as possible to the original, integrate dependencies through Xcode project primitives so they can be cached as binaries, validate that the app actually launches on a simulator, and write a skill.md that captures the migration knowledge for future use.

A migration like this isn't just about compiling. It requires understanding feedback loops, holding state across errors, and making judgment calls when things break. We used Codex 5.2 with GPT-5 as the underlying model because we wanted to test whether the model could handle that without constant human supervision.

How it actually went

The first step was establishing a baseline. The original Xcode project compiled and the app launched on the simulator. Having that baseline gave us a reference point for the benchmark and confirmed we were starting from something healthy.

From there, the agent extracted build settings into .xcconfig files and wired them back into the target definitions in Project.swift. This follows our migration guidance, which recommends xcconfig extraction because it preserves the settings hierarchy and keeps the manifest readable. Then it created the initial Tuist.swift, Project.swift, and Tuist/Package.swift, mapping each target into the Tuist graph.

The first tuist generate was successful, but then things started breaking, which is exactly what happens in real migrations.

The missing class that wasn't missing

The first failure was a missing TimelineListViewController referenced by DiscoveryViewModel. The agent had excluded a directory called "In Progress New Layout and Datamodel" because it looked like unfinished work. Reasonable assumption, wrong conclusion. The class lived in that directory, and the original Xcode project included it while excluding only one specific file from the folder.

The agent went back to the pbx structure, inspected the exception set, and adjusted the source glob to mirror exactly what the original project did. After the fix, those errors were gone.

Resources, sources, and boundary confusion

The second round of errors was subtler. .intentdefinition files were being treated as resources when they needed to be sources. .xcstrings files were getting shadowed by .strings globs under a broader resource directory. Settings bundles were being treated as individual files rather than folder references.

Each of these was straightforward to fix once identified, but they are a good illustration of why migrations are tricky. The mistakes aren't about code logic. They are about boundaries: where sources end and resources begin, what counts as a file versus a folder reference, which build phase something belongs to.

Making it launch

After the workspace built successfully, the agent installed the app on the simulator and launched it. It crashed immediately with an unrecognized selector, processCompletedCount, coming off NSUserDefaults. Since Tuist integrates dependencies as Xcode-native targets and defaults to static linking, the linker was stripping object files that contained only Objective-C categories without class definitions. The category methods simply disappeared from the binary. As Apple Technical Q&A QA1490 explains, this is expected behavior. Our dependency documentation covers this in more detail.

The fix was adding -ObjC to OTHER_LDFLAGS in the shared project xcconfig, which forces the linker to load all object files from static libraries. After that, the app launched and stayed up. This is why it's important to instruct the agent to actually run the app on a simulator and tell it how to do so. That way it can detect runtime failures on its own and close the feedback loop without human intervention.

Unlocking cache

The whole point of migrating was to unlock caching. A modular generated project is nice, but what we really wanted was fast clean builds by default.

Once everything compiled and ran, tuist cache warmed the binaries and tuist setup cache enabled the Xcode compilation cache.

The benchmark

We used hyperfine for repeatability. Both scenarios ran three times as clean builds with xcodebuild clean build and a dedicated -derivedDataPath per scenario.

No-cache baseline: the Tuist-generated workspace with the cache profile set to none, derived data wiped between runs, and Xcode compilation cache disabled.

Cached build: the all-possible cache profile so only the app and its extensions built from source, with Xcode compilation cache enabled. Before each run, local binaries and the compilation cache directory were removed so artifacts were pulled from the remote cache.

The commands looked like this:

Results:

That is a 4.98x speedup and a 79.9% reduction in clean build time.

It's worth mentioning that cache effectiveness depends on how modularized the project already is. If most of your code lives in a single app target, there is less to cache. Mastodon has several internal frameworks, but the app target itself is still large. Teams that invest in smaller targets and clearer module boundaries should see even larger gains.

The skill

The most valuable output of this migration isn't the Mastodon workspace itself. It is the skill file that captures how to do this again.

The agent wrote skill.md as a migration guide that starts where a real engineer would start: with a baseline build, a target inventory, and a realistic set of constraints. It focuses on what tends to go wrong, how to detect it, and how to keep the generated project aligned with the original. It intentionally avoids caching instructions so it stays focused on migration mechanics. The published version of that skill lives at tuist.dev/skills/migrate/SKILL.md, and the installation steps are documented in our Skills guide.

What we took away from this

A coding agent took a production iOS app, migrated it to generated projects, fixed a few issues along the way, confirmed the app runs, and got clean builds down by 80%.

Manual migrations can take days or even weeks, which is why many teams never got around to it. This one took a few hours of agent time. With agents doing the heavy lifting, the cost of adopting generated projects drops significantly. Your developers wait less on builds, and your CI stops redoing work that hasn't changed.

We're going to keep using this skill on more projects and refining it as we go.

Try it on your project

If you want to migrate your project, you can get started with the migration skill today. Point your coding agent at it and let it work through the feedback loop. If you run into issues or have feedback on the skill, we'd love to hear about it at contact@tuist.dev or in our community forum.

This scenario plays out thousands of times a day across engineering teams everywhere. And the worst part? Most organizations have no idea how much time they're losing. Flaky tests are a silent productivity killer that compounds over time, eroding trust in your test suite and frustrating developers who just want to ship their work.

The hidden cost of flaky tests

The direct cost is easy to see: wasted CI minutes, wasted developer time, delayed merges. But the indirect cost is far more damaging.

When flaky tests become common, developers stop trusting the test suite. "It's probably just that flaky test" becomes the default assumption when CI fails. Real bugs slip through because the signal has been drowned out by noise. The test suite that was supposed to catch regressions before they reach production now gets ignored because it fails too often due to tests being unreliable.

And unlike a slow test suite or a missing feature, flaky tests are invisible in aggregate. No dashboard shows you "your team lost 47 hours this month to spurious failures." No alert fires when trust in your CI erodes past the point of usefulness. The cost accumulates silently until someone finally asks why PRs take so long to land.

Why this matters more than ever

With the rise of AI coding agents like Claude Code and Codex, teams are producing more PRs than ever before. Agents can write code faster than humans, but they still have to wait for CI like everyone else. If your test suite is flaky, you've just created a bottleneck that scales with your agent usage. The more PRs you open, the more time gets wasted on spurious failures.

If your test suite is flaky, your PR throughput doesn't scale with your team. It becomes the bottleneck.

Detecting flaky tests automatically

No developer should have to manually track which tests are unreliable. Flaky test detection builds on top of Test Insights, so if you're already using it, you get flaky detection automatically. Tuist detects flaky tests in two ways:

Retry-based detection

When you run tests with Xcode's retry functionality using -retry-tests-on-failure or -test-iterations, Tuist analyzes the results of each attempt. If a test fails on the first attempt but passes on the retry, Tuist automatically marks it as flaky.

This catches flakiness within a single CI run rather than needing multiple runs to detect it. We recommend enabling test retries if you haven't already.

Cross-run detection

Even without retries, Tuist can detect flaky tests by comparing results across different CI runs on the same commit. If a test passes in one CI run but fails in another for the same commit SHA, both runs are marked as flaky.

This catches the particularly elusive flaky tests that don't fail consistently enough to be caught by retries but still cause intermittent CI failures that waste your team's time.

Once detected, flaky tests appear in your project's Flaky Tests page, where you can see the flakiness rate, track flaky runs over time, and drill into individual test cases.

Stop flaky tests from blocking your PRs

Knowing which tests are flaky doesn't help if they're still failing your CI. How do you keep shipping while you investigate and fix them?

This is where quarantining comes in. When you quarantine a test, you're marking it as "known flaky" and excluding it from your CI runs entirely. This prevents flaky failures from blocking your PRs while you work on a fix. You can enable automatic quarantine in your project's Automations settings so newly detected flaky tests are isolated immediately, or manually quarantine tests from the test case detail page when you want more control.

Skipping quarantined tests

To actually skip quarantined tests in your CI, use the tuist test case list command with the --skip-testing flag:

This fetches all quarantined test identifiers and formats them as xcodebuild arguments. Your CI becomes reliable again, PRs stop getting blocked by unrelated failures, and your team stays productive while you fix the underlying issues.

Once you've shipped a fix, unmark the test as flaky from the test case detail page. If it becomes flaky again, Tuist will detect it and notify you.

Stay informed with Slack notifications

You don't want to find out about flaky tests by having them block a critical PR. With the Slack integration, you get notified the moment a test becomes flaky.

The notification includes direct links to investigate the flaky test case, so you can start debugging immediately rather than waiting until it blocks someone.

Additionally, when a PR has a flaky test run, it gets surfaced directly in the Tuist PR comment. The "Flaky Tests" section shows a summary of flaky tests per scheme with links to view all flaky runs without leaving your pull request.

Getting started

To start detecting flaky tests, you need Test Insights configured for your project.

Once Test Insights is running:

1. Enable test retries in your CI with -retry-tests-on-failure
2. Update your CI to skip quarantined tests using tuist test case list --skip-testing
3. Set up Slack alerts to get notified when new flaky tests are detected

For detailed configuration options, see the Flaky Tests documentation.

What's next

We're continuing to build on flaky test detection with features that further streamline your workflow:

• Issue tracker integration: When a new flaky test is detected, Tuist will be able to automatically create an issue in your tracker. When the issue is resolved, the test case gets unmarked as flaky, keeping everything in sync.
• Sharding: To further increase CI throughput, sharding lets you run your test suite across multiple machines in parallel. Since Tuist already knows the average duration of each test case, we can create balanced shards that all finish around the same time.

What would you like to see next? Reach out to us in our community forum or send us an email at contact@tuist.dev. Your feedback shapes what we build.

Stop the cycle

Flaky tests don't just waste time. They erode trust in your test suite, slow down your release cycle, and compound developer frustration. Every retry is a context switch. Every false failure is a distraction from real work.

With automatic detection, quarantining, and notifications, Tuist turns flaky tests from an invisible drain on productivity into a visible, manageable problem. You can see exactly which tests are unreliable, stop them from blocking your PRs, and fix them on your own schedule rather than in the heat of a blocked deployment.

Your test suite should give you confidence, not anxiety. Get on top of your flaky tests and stop wasting time on retries.

This reactive approach to project health is the default across our industry. Even if you collect data, such as by using Tuist Insights, unless someone actively checks dashboards, regressions slip through unnoticed and impact your team for way longer than they should.

We think there's a better way. Instead of waiting for problems to become obvious, what if your tools could surface issues the moment they happen?

Bringing insights to where your team already works

This is why we're introducing two new complementary features that integrate with Slack: daily reports and alert rules.

With these, Tuist becomes proactive. Rather than requiring you to remember to check dashboards, it delivers the insights that matter directly to your Slack channels where your team already communicates.

Daily reports

Daily reports give your team a pulse check on your project's health. Each morning (or whenever you configure), Tuist sends a summary to your chosen Slack channel with key metrics:

• Build duration trends
• Test duration trends
• Cache hit rate
• Selective test effectiveness
• Bundle size

Each metric includes a trend indicator showing how it compares to the previous period. Is your p90 build time creeping up? Or your cache hit rate dropping? Tuist reports keep you up-to-date.

Alert rules

While reports are great for staying informed, some regressions need immediate attention. Alert rules let you define trigger notifications when something significant changes.

For example, you might configure an alert that fires when the p90 build duration increases by more than 20% compared to the previous 100 builds or when the cache hit rate drops by 30%.

When an alert triggers, you get a Slack notification with the specific metric that regressed, the magnitude of the change, and links to investigate further. No more sifting through a week's worth of PRs to find the culprit, you'll know something went wrong within hours of the change landing. And a 24-hour cooldown prevents notification fatigue when a metric stays elevated, so you won't get spammed while investigating an issue.

Why this matters

The cost of a build time regression isn't just the extra seconds or minutes each build takes. It's the compounding effect across your entire team, multiplied by every build they run, every day the regression goes undetected. A 20% build time increase that goes unnoticed for a week can translate to hours or days of lost productivity. Not even mentioning the frustration and context-switching that slow builds cause.

Proactive monitoring turns unknown unknowns into known issues. You can't fix problems you don't know about, and the longer they persist, the harder they become to diagnose.

Getting started

To connect Slack to your Tuist project:

1. Connect your Slack workspace in the Integrations tab
2. Configure reports and alert rules in your project's notification settings

For detailed setup instructions, including configuration options and on-premise installation, see the Slack integration documentation.

What's next

This is just the beginning of making Tuist more proactive. We're working on:

• Email notifications: not everyone lives in Slack, so we're adding the option to receive reports and alerts via email
• Flaky test alerts: as we build out flaky test detection, you'll be able to get notified when a flaky test is introduced, so you can address it before it starts causing spurious CI failures

We're also eager to hear from you. What other events would you want to be notified about? What metrics matter most to your team? Let us know in our community forum as your feedback shapes what we build next.

Initially, we focused on minimizing friction for developers, introducing features like posting comments directly in your pull requests, allowing anyone to click a link and start testing without checking out a branch or waiting for a local build.

But as teams adopted previews, it became clear we needed to expand our primary audience beyond engineers. Product managers wanted to see features before they shipped. QA teams needed consistent access to the latest builds. Leadership wanted to stay informed about what's coming.

Today, we're taking the first steps in that direction with the new Tuist SDK and tracks.

The Tuist SDK: In-app update notifications

Here's a common problem: you share a preview with a tester, they find an issue, you fix it and share a new preview. But the tester is still using the old build. They don't know a new version is available.

The Tuist SDK solves this by enabling your app to detect when a newer preview is available and notify users. Add the SDK to your project:

Then start monitoring for updates:

When a newer preview is available, the SDK will present an alert prompting the user to update:

Update checking is automatically disabled on simulators and App Store builds, so you don't need to worry about conditional compilation.

For more control, you can perform a single update check instead of continuous monitoring:

Tracks: Control which updates to notify about

By default, the SDK checks for updates within the same git branch. A preview built from main will only notify about newer previews also built from main. This works well for PR-based workflows, but what about nightly builds, beta releases, or internal testing that aren't tied to a specific branch?

Tracks let you organize previews into named groups and control which updates the SDK notifies about:

Tracks are lazily created – specify a track name and it will be created automatically if it doesn't exist. When you share a preview with --track beta, the SDK will only notify users about newer previews on the beta track.

This is useful for several scenarios:

• Beta testing: Share stable builds with external testers on a beta track, keeping them on vetted releases rather than every commit
• Nightly builds: Automate nightly builds to a nightly track for internal QA
• Feature demos: Create a demo track for product reviews and stakeholder presentations

What's next

We're excited to take previews even further. We will soon start working on distribution groups – the ability to define groups of users who should receive specific previews. You will be able to add your QA team to a qa group and having them automatically notified whenever a new preview is shared to the nightly track.

We're also exploring Android support. As previews expand beyond engineering, teams expect a single way to share their apps – regardless of platform. A product manager shouldn't need different tools to test iOS and Android builds. QA teams shouldn't have to learn separate workflows. With Android support, you'd share previews the same way across both platforms, and testers would receive updates through the same SDK. If your team builds for both platforms and you're interested in bringing previews to Android, reach out to us – we'd love to hear about your use case.

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.

At monday.com, we work with a large, mixed iOS codebase that has been evolving for nearly a decade. Dozens of engineers contribute hundreds of commits every month across multiple product areas. What began as a small team eventually grew to almost 20 iOS engineers, and with that growth came real architectural and workflow challenges.

Building the project was slow and messy. We wanted a highly modular setup that allowed developers to build only what they needed, as quickly as possible. But creating modules inside Xcode was painful and error-prone, and the project naturally drifted toward a big monolithic structure. Code became tightly coupled, merge conflicts were common, and restructuring the project often felt like fighting the tool instead of building with it.

"Restructuring the project often felt like fighting the tool instead of building with it."

The underlying Xcode project format also caused hidden configuration issues. Because everything lived in pseudo-XML, it was easy to end up with unexpected behaviors, inconsistent settings, or modules that behaved differently for reasons no one could easily trace. Understanding why something was configured in a certain way was becoming harder over time. We needed a cleaner, more reliable, and more scalable way to define the project.

Choosing Tuist

Both Natan and Shai had followed Tuist for years and were already fans of the team and their open source work. Each of us had contributed to Tuist in the past, and Natan had even served on the core team, so we knew the project well enough to trust its design, direction, and philosophy. On top of that, Natan and our colleague JD had used Tuist successfully at their previous company, which gave us additional confidence.

We also had the chance to meet Pedro and Marek at a few conferences and left those conversations with a strong sense of trust in both the people and the product. Seeing other large companies use Tuist to solve similar challenges reinforced that we were on the right path. For a rapidly growing project with a massive line count, Tuist felt like the right tool to help us transition from a large monolith to a more modular, scalable, and maintainable architecture.

The approach

In mid-2022, Natan and JD kicked off a full migration of our Xcode project to Tuist generated projects. They began with the leaf nodes, the ones with the fewest dependencies, and gradually worked their way up the dependency hierarchy. The initial pull request was massive, with more than 60,000 changes. Tools like xcdiff helped us validate that everything remained consistent throughout the process.

That first migration got the entire team working with Tuist. Over time, we built many of our own abstractions on top of it, including unified Framework and Project Description Helpers that allow anyone on the team to create new modules quickly and safely, as well as custom Resource Synthesizers for Lottie animations and other specialized resources. Every module also includes its own Preview App, Tests, etc, which lets developers work in complete isolation instead of building the entire application. This was a significant improvement in quality of life and developer experience.

A bit later, we adopted Tuist’s module cache. This made a noticeable difference in build times, especially in CI. Today, tuist generate has become a familiar command across the team and a natural part of our daily workflow.

The results

• All modules, app targets, and configurations are now defined in Tuist’s Swift-based manifests. It provides a real source of truth, far more transparent and reliable than managing settings inside a pbxproj file.
• We now maintain around 200 modules, and creating new ones is simple enough that anyone on the team feels comfortable doing it. The cost of modularizing has gone way down.
• Our CI merge workflow dropped from more than 20 minutes in 2022 to about 9 minutes today. This came from many improvements across the board, but Tuist's module cache played a significant role. The result is a faster iteration cycle and a meaningful reduction in developer hours lost to waiting on builds.
• It's also much easier to make large-scale changes or experiment with a new build configuration. Because everything is defined in code, large refactors and optimizations feel safer, more predictable, and far more approachable.

"We now maintain around 200 modules, and creating new ones is simple enough that anyone on the team feels comfortable doing it."

What’s next

Tuist gives us confidence that we can continue scaling the team and the codebase. Spinning up a new app is basically as simple as creating a new target and reusing the modules we already have, which opens the door for faster experimentation across the engineering team.

We're excited to keep improving the developer experience for our iOS engineers, and we're equally excited to see what the Tuist team builds next. Their work has already had a significant impact on how we ship software, and we expect that impact to continue as we grow.

"Tuist gives us confidence that we can continue scaling the team and the codebase."

As your test suite grows, you will inevitably face pains like slow test suites or flaky tests. Additionally, debugging issues on the CI has always been a challenge – can't I get a link that tells me exactly what went wrong, instead of trying to understand the logs, running the tests locally, or downloading the .xcresult?

Test Insights gives you a comprehensive overview of your overall test suite over time along with a detailed report of every test run to ensure your test suite is healthy and is not slowing down your development. No one wants to be waiting an eternity for a CI pipeline to finish only for it to fail with a cryptic error message.

👉 If you'd like to see it in action, check out the video below:

Getting started

To get started with test insights, you will need a Tuist account and a project. The best way to get started is to use our CLI and run the tuist init command.

Once you authenticate, you will need to add a tuist inspect test command in your Xcode scheme test post-action – unless you use generated projects, in which case we generate the post-action for you. Note that the exact script depends on your installation. If you use mise, the full script should be:

For more details how to set up test insights, head over to our docs.

Test detail

Once you start tracking tests both on the CI and in your local environments, things start to get interesting. Let's imagine the following scenario:

• your test fails
• you look into your CI logs, but the xcodebuild log doesn't include the exact test failure, only which test failed
• you try to reproduce locally, but the test passes
• you need to update your CI pipeline to upload the .xcresult and re-run the test
• the test may (or may not) fail again – in case, it does, you can finally download the .xcresult and investigate the failure in Xcode

So. Much. Friction. Wouldn't it be awesome if you would get a link to your failed test directly in the PR or in your CI logs? That's exactly what you'll get with test insights:

Let's imagine another scenario: your run on the CI was taking longer than expected. But you have no idea why. With test insights, you can now get a breakdown of how long individual test cases, suites, and modules took to run. And you can compare them with the average.

Tests over time

Things start to get really interesting when you start tracking tests over time. Is your test suite slow? We can tell you which of your test cases are the slowest, so you know what to focus on:

Is your test suite getting faster or slower? Has there been a recent regression in the test execution time? The Tuist dashboard provides you with answers to these questions as well:

And it bears repeating – the test insights are environment-agnostic, so you can get a holistic view of your test suite's performance across different environments, not just your CI. Additionally, the test insights are CI-agnostic, it doesn't matter which CI provider you're using, you will get the same insights wherever you run your tests.

Do you want to explore the feature on your own? Our Tuist dashboard is open for anyone, including the new test insights.

How test insights work

You might be wondering what happens under the hood when you run tuist inspect test. Here's a quick overview:

1. The post-action finds the latest .xcresult from your derived data. The derived data location is determined based on the $SRCROOT environment variable that Xcode provides.
2. We use Apple's xcresulttool to get the JSON representation of the .xcresult. This gives us access to the structured test data that Xcode collects.
3. We extract the most important pieces – duration, test status, failure messages, and more – and send the data to the Tuist server.
4. All of this happens in the background, so Xcode can finish the test action without waiting for the upload to complete.
5. The server stores the data in ClickHouse, an analytics database optimized for fast queries over large datasets. This allows us to efficiently analyze your test history and surface insights in the dashboard.

Since the full implementation is open-source, you can check it out here.

What's next

Test Insights takes Xcode's test data, makes it readily available in your browser, and analyzes it over time – whether you need to debug a failing test on CI or understand how your test suite's performance is trending.

But this is just the beginning. The test insights will provide us with a great foundation to provide more capable features in the future. We want to be more proactive and leverage the data we track to either optimize your projects or tell you what's wrong – without you having to do the digging. Here are some of the things we will be working on:

• Test flakiness: which of my tests are flaky? Can you skip running them until the flakiness is resolved?
• Sharding: For optimal sharding, it's important for each shard to run for a similar amount of time. We already know how long your tests take on average, so we can use that information to optimize your sharding strategy.
• Slow test alerts: have you added a test that is abnormally slow? Let us tell you!
• Snapshot attachments: if you're using snapshot testing, we'll show you the image differences directly in the test detail

Are there any day-to-day pains related to your test suite? Let us know and we'd love to prioritize solving your needs.

To learn more about test insights, head over to our documentation. If you have any feedback or suggestions, please don't hesitate to reach out to us at contact@tuist.dev.

What if we could change that? What if AI agents could actually understand builds, not just parse their text output?

This is an exploration of what could be possible. Some of the concepts discussed are aspirational and would require Apple's support to fully realize.

The Problem: Build Logs Are Not Built for Understanding

Picture this: you're building a large iOS app and hit a linker error. The output looks something like this:

What do you do next? You scroll up through hundreds of lines of compilation output, grep for "error", check if your Swift Package dependencies resolved correctly, maybe clean the build folder, and try again. If that doesn't work, you might delete the DerivedData folder entirely and rebuild from scratch. Sometimes that fixes things. Sometimes it doesn't, and you're left wondering what actually went wrong.

The frustrating part is that the build system knows exactly what happened. It knows which target failed, which dependency was missing, what the entire dependency graph looks like, and how long each step took. But instead of exposing this rich structured data, it communicates through a stream of text that looks like it was designed for a terminal from the 1980s.

We've all been there. We've all lost hours to build failures that should have taken minutes to diagnose.

What xcodebuild actually gives you

When you run xcodebuild from the command line, you get output that mixes progress indicators, compiler invocations, warnings, and errors into a single undifferentiated stream:

This output wasn't designed for debugging. It was designed for logging. There's no structure, no hierarchy, no way to programmatically distinguish between a compilation step and a linker invocation without parsing the text itself.

For humans, tools like xcbeautify help by colorizing the output and filtering out noise. They make the wall of text easier to scan. But these tools are designed for human eyes scanning a terminal. They take unstructured text and make it prettier unstructured text.

Why this matters for AI agents

Now consider what happens when an AI agent tries to help you debug a build failure. The agent faces a fundamental challenge: the output it receives is unstructured text. It has to parse free-form strings, try to guess at relationships between different lines, and hope that the error message contains enough context to be useful.

Even with perfect parsing (which is hard, because the output format isn't formally specified and can change between Xcode versions), there's critical information that simply isn't present in the logs. None of this information appears in xcodebuild output. It exists inside the build system, but it doesn't make it to the terminal.

A step in the right direction: xcsift

There's an interesting project called xcsift that takes a different approach to this problem. Instead of formatting build output for humans to read, it transforms xcodebuild output into structured JSON that's optimized for AI consumption:

This produces machine-readable output with extracted errors, warnings, and test failures organized into a proper data structure. The tool even offers a custom format called "TOON" that reduces token usage by 30-60% compared to JSON, which matters when you're paying per token for AI API calls.

This is a genuinely clever solution. It works within the constraints of what xcodebuild exposes and makes the best of a difficult situation.

But there's a fundamental limitation: xcodebuild output is a flattened representation of what's actually happening. The build system internally maintains a rich graph of dependencies (target A depends on target B, file X imports module Y, this compilation must wait for that linking step). When it writes to stdout, all of that structure gets serialized into a linear stream of text. The graph becomes a list. The relationships disappear.

xcsift can parse that list beautifully, but it can't reconstruct the graph. It can tell you that target A failed, but not that targets B, C, and D were waiting on A and never got a chance to run. It can tell you that a file was compiled, but not why it needed recompilation or what downstream tasks were triggered as a result.

The build system has this information. It just doesn't share it.

The gap between parsing logs and observing builds

There's a meaningful difference between parsing build logs and actually observing what the build system is doing. It's a bit like the difference between reading a transcript of a meeting and actually being in the room. The transcript captures the words that were spoken, but it loses the timing, the context, the reactions, the side conversations.

When you parse xcodebuild output, you're working with what the build system chose to print. When you observe the build system's internal messages, you see everything: every task that started and ended, every dependency that was resolved, every timing measurement, every decision the scheduler made.

That's what we wanted to explore. What if instead of parsing the output of xcodebuild, we could tap into the structured messages that the build system uses internally to coordinate its work? What would that unlock for AI agents trying to understand and debug builds?

Discovering What Builds Actually Know

A few months ago, we got curious. We built a small tool called XCBLoggingBuildService to intercept the communication between Xcode and its build service. We wanted to see what was actually happening under the hood.

What we found changed how we think about build observability.

When you hit "Build" in Xcode or run xcodebuild, you're not directly invoking compilers and linkers. Your request goes to a separate process called SWBBuildService. This is the actual build engine. Xcode is just a frontend that sends requests, receives responses, and translates them into the UI you see. The same goes for xcodebuild, which translates them into text.

The communication between these processes isn't text. It's not JSON either. It's MessagePack, a binary serialization format, flowing over stdin/stdout pipes. And here's the thing: every build event is a discrete, typed message with structured data.

Apple recently open-sourced this build system as swift-build. So now we can actually read the message definitions. We can see exactly what data flows between components. What was once a black box is now source code anyone can study.

The difference is striking

Let's look at a concrete example. When you compile a Swift file, xcodebuild prints this:

One line. That's it.

But internally, the build service sends a BuildOperationTaskStarted message that looks like this:

And when that compilation finishes, there's a BuildOperationTaskEnded message:

See the difference? The protocol knows how long the compilation took, how much memory it used, which target it belonged to, and whether it was part of a larger task. It has a unique identifier that lets you correlate this task with any errors it produced, any output it generated, and its position in the dependency graph.

None of that makes it to the terminal.

What gets lost in translation

When we started looking at the SWBProtocol module, we kept finding data that never reaches xcodebuild output:

Timing, for one. Not just "the build took 45 seconds," but exactly how long each individual task took. You can see that a compilation ate 8 seconds of wall time but only 2 seconds of CPU time, which tells you it was probably blocked waiting for something else.

Memory usage per task. If your CI builds are getting killed by the OOM killer, you could pinpoint exactly which compilation is the culprit.

Task relationships. Every task knows which target it belongs to, and optionally which parent task spawned it. You can reconstruct the full tree of what happened, not just a flat list.

Cache information. There's a message called BuildOperationTaskUpToDate that fires when a task was skipped because nothing changed. You could calculate your actual cache hit rate instead of guessing.

And diagnostics. Errors don't come as text strings. They come as BuildOperationDiagnosticEmitted messages with the file path, line and column, source ranges, fix-it suggestions, and which component emitted them.

The build system knows all of this. It's just not telling us.

What Structured Build Data Unlocks

So we have this rich stream of structured messages flowing through the build system. What could we actually do with it if we captured and exposed it properly?

Intelligent failure diagnosis

When a build fails today, an AI agent sees an error message and tries to help based on pattern matching against its training data. Sometimes that works. Often it doesn't, because the agent lacks context about your specific project.

With structured build data, the agent could answer questions like:

• "This linker error happened because target NetworkKit failed to build. NetworkKit depends on CoreUtilities, which succeeded, so the problem is isolated to NetworkKit itself."
• "You've seen this exact error three times in the last week. The first two times, cleaning the build folder fixed it. The third time, you had to delete DerivedData."
• "This compilation failed at 2:34 PM. The last successful build was at 2:12 PM. Between those builds, you modified APIClient.swift and Models/User.swift."

The agent isn't guessing anymore. It's working with actual build history and dependency information.

Performance analysis that goes beyond timing

Build performance is usually measured in one number: how long did it take? But that number hides a lot of complexity. A 60-second build might be 60 seconds because you have one massive target that can't parallelize, or because you have 30 small targets with a long critical path, or because your incremental build isn't actually incremental.

With task-level timing and dependency data, you can answer the questions that actually matter:

• "Your build took 47 seconds, but only 12 seconds of that was actual compilation. The rest was waiting for code signing and asset catalog processing, which ran sequentially after everything else."
• "The critical path runs through FeatureA → SharedUI → MainApp. If you could shave 5 seconds off SharedUI, your entire build would be 5 seconds faster."
• "You have 8 CPU cores, but your build only achieved 3.2x parallelization. Here are the targets that are blocking better parallelization."
• "This 'incremental' build recompiled 847 files. Based on the task signatures, the trigger was a change to Constants.swift, which is imported by everything."

The data includes start and end times for every task, plus which target each task belongs to. From this, you can compute concurrency over time, identify sequential chains (likely dependencies), find the critical path, and spot contention points where one target blocks many others.

For example, if tasks from target A consistently end right before tasks from targets B, C, and D begin, target A is probably a dependency of all three. If A takes 20 seconds and blocks everything else, that's your bottleneck. The protocol also includes a DependencyGraphResponse message with an explicit adjacency list of target dependencies, so you can get the actual dependency graph, not just inferred relationships from timing.

This is the kind of analysis that build engineers at large companies do manually, staring at build traces and dependency graphs. There's no reason an AI agent couldn't do it automatically if it had access to the same data.

Proactive suggestions

Once you have historical build data, patterns start to emerge. An agent with access to weeks or months of build history could notice things like:

• "Your clean build times have increased by 40% over the last month. The growth correlates with the addition of 12 new Swift files in the Analytics module."
• "Builds on Monday mornings are consistently 2x slower than other times. This might be related to cache invalidation over the weekend."
• "Developer A's builds fail 3x more often than Developer B's, and the failures are almost always linker errors. This might indicate an environment configuration issue."
• "This target has been rebuilt from scratch in 80% of incremental builds. The problem appears to be a bridging header that changes frequently."

None of this is possible with a single build's text output. It requires structured data that can be stored, queried, and compared over time.

Natural language queries about builds

Perhaps the most immediately useful application is simply being able to ask questions about your builds in plain English:

• "What was the slowest target in my last build?"
• "How many warnings did we have last week compared to this week?"
• "Which files take the longest to compile?"
• "Has this test target always been this slow, or did something change recently?"
• "What percentage of my builds are clean builds versus incremental?"

These questions have answers. The build system knows the answers. We just don't have a good way to ask.

Why this matters now

AI agents are becoming legitimate development tools. People use them to write code, debug issues, refactor systems, and automate workflows. But when it comes to builds, agents are working blind. They can see the code, but they can't see how the code gets built.

As projects get larger and build systems get more complex, this gap becomes more painful. A developer might spend hours debugging a build issue that an agent could diagnose in seconds, if only the agent had access to the right data.

The structured messages are already there. The build system already generates them. The question is whether we can capture them in a way that makes them accessible to the tools developers are increasingly relying on.

Inside the Build Protocol

So where does this build service actually live? If you dig into your Xcode installation, you'll find it here:

That's the binary that does all the work. When you build something, Xcode spawns this as a separate process and talks to it over stdin/stdout pipes. Looking at BuildServiceEntryPoint.swift in swift-build, you can see it also supports running in-process, which is probably how Xcode uses it for tighter integration.

How Xcode understands your project

Before a build can start, the build service needs to understand your project structure. This happens through something called PIF: the Project Interchange Format.

If you've ever tried to parse an .xcodeproj file programmatically, you know it's a nightmare. The .pbxproj format is byzantine, poorly documented, and full of UUIDs that reference each other in ways that are hard to follow. PIF is what the build system actually uses internally, and it's much cleaner.

Looking at the ProjectModel directory in swift-build, you can see the hierarchy: workspaces contain projects, projects contain targets, targets contain build phases, and build phases contain files. It's all defined in straightforward Swift structs like Workspace.swift, Project.swift, and Target.swift.

What's clever is that PIF supports incremental updates. The build service caches your project structure, and on subsequent builds, only the parts that changed get re-transferred. That's part of why incremental builds in Xcode feel faster than running xcodebuild from scratch each time.

What happens during a build

When you actually kick off a build, there's a conversation that happens between Xcode and the build service. First, Xcode establishes a session. Then it transfers the project structure (or updates to it). Then it sends a build request with the configuration, scheme, and targets.

During execution, the messages we talked about earlier start flowing: targets starting and ending, tasks starting and ending, progress updates, diagnostics. When everything's done, there's a final message with the overall status and aggregate metrics.

The interesting thing is that sessions can be reused. Xcode doesn't tear down the connection after each build. It keeps the session alive so that subsequent builds can skip the setup phase and benefit from cached state.

You can swap out the build service

Here's what makes this really interesting for observability: Xcode explicitly supports using a custom build service.

There's an environment variable called XCBBUILDSERVICE_PATH. If you set it, Xcode will use whatever binary you point to instead of the bundled one. The swift-build repository even includes a launch-xcode plugin that builds swift-build from source and launches Xcode with the custom service:

This means you could modify the build service, add logging for the messages you care about, rebuild it, and have Xcode use your version. Or you could build a proxy that sits between Xcode and the real build service, capturing messages as they flow through.

That's exactly what XCBLoggingBuildService does. It's a pass-through proxy that logs messages without modifying them:

The protocol isn't hidden. It's open source, documented in code, and Xcode explicitly supports swapping out the implementation. The pieces are all there for anyone who wants to build better observability into their build process.

Making Builds Agent-Friendly

Capturing build messages is only half the problem. The other half is making that data useful for AI agents.

If you just dump raw protocol messages into an agent's context, you'll quickly run into limits. A single build can generate thousands of messages. That's way too much for any reasonable context window, and most of it isn't relevant to whatever question you're trying to answer.

We need to think about this differently. Instead of giving agents raw data, we need to give them the right data at the right level of detail.

The correlation problem

There's a practical challenge we hit immediately: how do you connect a build invocation to its data?

When an agent runs xcodebuild, it needs some way to later ask "what happened in that build?" The build service doesn't automatically tag its output with any kind of identifier. If you're running multiple builds, or if you want to query historical data, you need a way to correlate them.

One approach is to pass a build ID through an environment variable. The agent generates a unique ID before invoking the build:

The logging service reads BUILD_TRACE_ID from the environment and tags all captured messages with it. Later, the agent can query using that same ID.

This sounds simple, but it's the kind of glue that makes the difference between a demo and something actually usable. Without correlation, you're stuck with "show me the last build" and hoping there wasn't a concurrent build that interleaved with it.

Storing build data

Where would you put all these messages? SQLite seems like a natural fit.

It might seem like overkill, but SQLite has some nice properties for this use case. It's a single file, so there's nothing to set up. It's queryable, so agents can ask specific questions without loading everything into memory. And it's portable, so you can copy build history between machines or share it with teammates.

The key insight is that you wouldn't want to store raw messages and query them directly. You'd want to pre-compute the things agents are likely to ask about. Think of it as layers:

Summary layer. One row per build with pre-computed metrics: total duration, number of targets, number of tasks, error count, warning count, cache hit rate, whether it succeeded or failed. This is maybe 50 tokens. An agent can get a high-level view of any build almost for free.

Top-N layer. The slowest targets, the slowest tasks, the most recent errors. Pre-sorted and limited. If an agent asks "why was this build slow?", you can answer with a couple hundred tokens instead of dumping the entire task list.

Details layer. Individual diagnostics, task timing breakdowns, the full error messages with file locations. You only fetch this when drilling down into something specific.

Raw layer. The original messages, stored as JSON. Almost never accessed, but there if you need to debug something weird or answer a question the other layers don't cover.

The schema might look something like this:

Nothing fancy. The point is to make common queries fast and cheap.

Exposing data to agents

Once you have the data stored, how do agents access it?

The simplest approach is a CLI. Agents can already execute shell commands, so there's no need for a separate server or protocol. A CLI built into the same executable that captures the data could expose commands like:

The agent just calls the command and gets back structured output. No server to run, no protocol to implement. The CLI handles the database queries and returns JSON or human-readable output depending on what's needed.

You could support convenient aliases too. Instead of requiring exact build IDs, let agents say latest for the most recent build, latest:MyScheme for the most recent build of a specific scheme, or failed for the most recent failure.

Real Build Analysis: Wikipedia iOS

To validate this approach, we instrumented a real build of the Wikipedia iOS app, a large open-source project with 19 targets and thousands of tasks. Here's what the build service captured:

Build Summary

A clean build completed in 457 seconds, spanning 19 targets and 3,303 individual tasks. Zero cache hits because we started fresh. The build succeeded with 86 warnings that would be worth investigating.

Identifying Bottlenecks

This is where the dependency graph becomes invaluable. By analyzing which targets block other targets and how long they take, we can compute a "bottleneck score" (duration x dependent count).

The WMF framework is the critical bottleneck. It takes 246 seconds and blocks 4 other targets from starting: ContinueReadingWidget, Wikipedia, WidgetsExtension, and NotificationServiceExtension. The app extensions all depend on it. If you wanted to improve build times, this is where to focus: either splitting WMF into smaller, more independent modules, or finding ways to parallelize work within it.

Other notable bottlenecks include CocoaLumberjack (34s, blocking 3 targets) and the individual app extensions (each around 252s, blocking the main Wikipedia target).

The Critical Path

Using the dependency graph, we can compute the longest chain of dependencies that determines the minimum possible build time: WMF (246s) -> ContinueReadingWidget (253s) -> Wikipedia (456s), totaling 955 seconds of serial work.

This tells us something important: if these targets ran sequentially, the build would take 955 seconds. The actual build took 457 seconds, meaning we achieved roughly 2.1x speedup through parallelization. But we can also see the limit: no amount of parallelization can make this build faster than whatever is on the critical path.

Slowest Targets

The five slowest targets tell an interesting story: Wikipedia (456s, 926 tasks), ContinueReadingWidget (253s, 61 tasks), WidgetsExtension (252s, 95 tasks), NotificationServiceExtension (252s, 60 tasks), and WMF (246s, 902 tasks).

Notice that ContinueReadingWidget takes 253 seconds but only has 61 tasks, while WMF has 902 tasks but takes slightly less time. This suggests the widget's compilation is CPU-bound on a few expensive files, while WMF has better internal parallelization.

Slowest Tasks

Drilling into individual tasks reveals optimization opportunities. Asset catalog compilation was the slowest single task at 131 seconds, using 3.1 MB of memory. This is nearly a third of the critical path target's time, and it runs as a single task that can't be parallelized.

The next slowest was a batch Swift compilation (83 seconds, 373.7 MB) covering 25 files including ArticleURLListViewController.swift and DonateFunnel.swift. Individual Swift file compilations showed similar times around 81 seconds because they're compiled together in the batch.

What an Agent Could Do With This

Armed with this data, an AI agent could provide actionable recommendations:

"Your Wikipedia iOS build took 457 seconds. The main bottleneck is the WMF framework (246s), which blocks 4 other targets. Consider:

1. Split WMF: The framework has 902 build tasks. Breaking it into 2-3 smaller frameworks could allow better parallelization.

2. Asset catalog optimization: Asset catalog compilation takes 131 seconds and runs serially. Consider breaking the catalog into smaller, per-feature catalogs that can compile in parallel.

3. Build order insight: Your critical path is WMF -> ContinueReadingWidget -> Wikipedia. The theoretical minimum build time with infinite parallelization is 955 seconds serial time, you're achieving 2.1x parallelization.

4. 86 warnings to fix: These don't affect build time, but fixing them will reduce noise and potential future issues."

This isn't guessing based on log output. It's analysis based on actual dependency relationships, task timing, and resource metrics that the build system tracks internally.

What This Requires

This exploration demonstrates what's possible, but turning it into a robust tool requires acknowledging some challenges.

Protocol Stability

The swift-build protocol is now open source, which is a significant step forward. What would make this truly useful is Apple officializing it: giving xcodebuild a flag to specify where to store build trace data (a SQLite database path), and providing a CLI interface to query that data. We've built exactly this in our exploration, and Apple could do the same with proper support. They'd need to standardize the data schema and handle migrations when the schema evolves across Xcode versions.

What's already possible with post-build artifacts

Before diving into what protocol-level access would unlock, it's worth recognizing what's already achievable today. Xcode generates .xcactivitylog files (gzip-compressed build logs with structured data) and .xcresultbundle directories (containing test results, code coverage, and build metadata). These artifacts contain a wealth of information that tools can parse after builds complete.

Tools like xclogparser have been parsing these files for years, extracting timing data, warnings, and errors into queryable formats. This post-hoc approach works well for many use cases: you can analyze build performance, track warning trends over time, and identify slow compilation units.

At Tuist, we've built exactly this. Our Build Insights feature parses .xcactivitylog and .xcresultbundle files to provide teams with dashboards showing build times, cache effectiveness, and historical trends. The data spans across developers, CI pipelines, and time, giving teams visibility into patterns they'd never notice from individual builds. And we're extending this to tests too: Test Insights (already available in our public dashboard) will bring the same cross-time, cross-space analysis to your test suite. Adopting it is as simple as adding a post-action to your Xcode schemes.

This matters because much of what we've described in the "Vision" section, like team-wide build intelligence and build archaeology, is achievable with post-build artifacts. You don't need Apple to bless a new extension point to start getting value from structured build data.

Why protocol-level access would still matter

So if we can already parse .xcactivitylog files, why bother with the build protocol at all?

The key differences come down to timing and data availability.

Real-time intervention. When you parse post-build artifacts, the build is already done. An AI agent watching the protocol stream could notice a problem mid-build and take action: pause the build, alert the developer, or even suggest a fix while there's still time to act on it. With post-hoc parsing, you're always reacting to something that already happened.

Rebuild causality. The protocol includes BuildOperationBacktraceFrameEmitted messages that explain why each task was rebuilt: was it because the rule never ran before? Because the signature changed? Because an input was rebuilt? This causal chain is invaluable for debugging incremental build issues, but it's ephemeral. It flows through the protocol during planning and execution, then disappears. Result bundles record that a task ran, but not the decision tree that led to it running.

Live dependency graph computation. The protocol exposes ComputeDependencyGraphRequest and ComputeDependencyGraphResponse messages showing how dependencies are resolved during planning. You can see the actual adjacency lists of target-to-target dependencies as the build system computes them. This information exists in the protocol as it happens, but the result bundle only contains the final build output, not the planning decisions.

Real-time progress. BuildOperationProgressUpdated messages stream live status with target names, status messages, and completion percentages. You could build a web dashboard showing your build's progress in real-time, with tasks appearing and completing as they happen. This enables experiences like watching your CI build live from anywhere, something that's not possible with post-hoc parsing.

Per-task resource attribution. While result bundles contain aggregate timing data, the protocol streams per-task metrics as each task completes: user-mode CPU time, system CPU time, peak memory usage, and wall-clock duration. This granularity makes it possible to identify not just which targets are slow, but which specific compilation units within those targets are consuming resources.

What would make this better

If Apple designed an extensible architecture where anyone can hook into the build event stream, the community could build powerful tooling on top of it. A stable contract for build events would enable real-time build monitoring in CI dashboards, AI agents that can intervene during builds, and custom workflows we haven't imagined yet.

The pieces are already there in swift-build. What's missing is Apple blessing this as an official extension point rather than an implementation detail that might change without notice.

The Vision: Where This Could Go

The Wikipedia iOS analysis shows what's possible with a single build. But the real potential emerges when you think about builds over time.

Much of what follows is achievable today by parsing .xcactivitylog and .xcresultbundle files after builds complete. That's exactly what we're building at Tuist with Build Insights. Protocol-level access would add real-time capabilities and richer causality data, but you don't need to wait for Apple to start getting value from structured build observability.

Team-Wide Build Intelligence

Imagine a CI system that captures structured build data from every pull request. Over weeks and months, patterns emerge:

• Which targets get slower as the codebase grows
• Which developers' changes tend to invalidate more cache entries
• What times of day have the slowest builds (and why)
• How merge queue builds differ from individual PR builds

This isn't theoretical, it's the kind of analysis that large companies do manually with custom tooling. Structured build data makes it accessible to everyone. And it's achievable today: post-build artifacts contain all the timing data, target information, and warning counts you need to build these dashboards.

Proactive Developer Assistance

With historical data and dependency information, agents could provide guidance before you even start a build:

"You're about to modify Constants.swift. Based on build history, this file is imported by 847 other files and will trigger a near-clean rebuild. Would you like me to suggest a more targeted approach?"

Or during code review:

"This PR adds a new import to SharedFramework.h. Our build data shows this header is included by 12 targets. This change will add approximately 45 seconds to incremental builds for those targets."

These insights come from correlating build data over time with code changes. The build artifacts contain timing data; the git history contains what changed. An AI agent with access to both can make these connections.

Real-Time Build Monitoring

This is where protocol-level access becomes essential. The build service generates events in real time, and an agent could watch these events as they happen:

"Build in progress... The Analytics target is taking longer than usual (45s vs. typical 30s). This started after yesterday's PR that added 3 new tracking events. The additional compile time is coming from type inference in EventBuilder.swift."

Post-hoc parsing can tell you that Analytics was slow after the fact. Protocol-level access could tell you while it's happening, giving you the option to stop the build, investigate, or take corrective action before wasting more CI minutes.

Build Archaeology

When something goes wrong weeks later, structured data lets you investigate:

"This linker error started appearing 3 days ago. Looking at build history, the last successful build was commit abc123. Between then and the first failure, there were 7 commits. The failure correlates with the addition of NewFeature.framework without updating the library search paths."

This kind of analysis is entirely achievable with post-build artifacts. You need a database of historical builds with their errors, timing, and associated commits. Then it's a matter of querying and correlation, exactly what AI agents excel at.

The build system already knows everything it needs to answer these questions. The data is available in post-build artifacts. We just need to capture and expose it in a way that's useful.

Key Learnings

Building this exploration taught us several things:

The build system is far more sophisticated than it appears. What looks like "compile a bunch of files" is actually a complex graph scheduler with caching, parallelization, and detailed instrumentation. The data is there, it's just not exposed.

Structured data fundamentally changes what AI can do. An agent parsing "CompileSwift normal arm64..." has almost nothing to work with. The same agent given structured events with timing, dependencies, and metrics can provide genuinely useful analysis.

Context window efficiency matters. You can't dump 3000 build tasks into a prompt. The tiered approach (summary -> top-N -> details -> raw) makes the difference between "unusable" and "practical."

Dependency graphs are the key to build optimization. Knowing that WMF blocks 4 targets is far more actionable than knowing WMF takes 246 seconds. The graph tells you what to fix; timing alone just tells you something is slow.

Build observability is underinvested. Developers lose hours to build issues that could be diagnosed in minutes with better tooling. The gap between "what the build system knows" and "what developers can see" is enormous.

What's Next

There are two parallel paths forward, and we're actively working on both.

What you can use today

At Tuist, we're building Build Insights and Test Insights using post-build artifacts. This works today, requires no experimental tooling, and gives teams visibility into build performance across developers, CI pipelines, and time. Adopting it is as simple as adding a post-action to your Xcode schemes that uploads your .xcactivitylog and .xcresultbundle files.

This is the pragmatic path: you don't need Apple to bless anything, you don't need to swap out your build service, and you can start getting value immediately. Team-wide build intelligence, historical trends, warning tracking, and build archaeology are all achievable with post-build parsing.

Exploring real-time protocol access

For real-time features and richer causality data, we've open-sourced Argus, a fork of swift-build that provides an agentic interface for AI agents. This is very much an experiment. It demonstrates what's possible when you tap into the build event stream directly, including features that post-hoc parsing cannot provide:

• Real-time monitoring: Watch your build progress live in a dashboard
• Mid-build intervention: An agent could pause a build when it detects a problem
• Rebuild causality: Understand why tasks were rebuilt, not just that they were
• Live dependency resolution: See how the build system computes dependencies during planning

Install Argus globally using mise:

Then add the following to your agent's memory or system prompt to enable build observability:

If you have ideas for how to improve things, open PRs or issues on the Argus repository. We'd love to see what you build with it, so share your learnings on Mastodon, Bluesky, or LinkedIn and tag us.

Check out the swift-build repository to see the protocol definitions, join the Tuist community to discuss build optimization, or book a call if you need help scaling your development workflows.

Since launch, the registry has grown to serve almost 10,000 packages and more than 160,000 releases. Teams using the registry have seen disk space savings of up to 91% – from 6.6 GB down to 600 MB – and CI cache restore times dropping from 2 minutes to less than 20 seconds.

As teams started to integrate the registry, one point of friction has become clear: the registry required a Tuist account and authentication. Something developers are not used to when downloading open source packages from other registries in ecosystems like npm or CocoaPods. Having now understood better how teams use the registry, we have decided to remove the need for authentication and account creation. Now, anyone can use the registry without any additional steps. The same security measures remain in place – packages are sourced directly from their original repositories and the Swift CLI or Xcode verifies checksums on every download.

Setting up the Tuist registry

Thanks to the registry being open now, the only thing you need to do is to run the following command in your project (install the CLI first by following these instructions):

This command will configure the Tuist Registry for your project – regardless of your setup. This command works with standard Xcode projects, generated Xcode projects, and Swift packages. For Swift packages, you can even use directly the swift CLI:

Either of these commands will create a configuration file, with its location depending on your setup. For Swift packages, this would be in .swiftpm/configuration/registries.json, for Xcode projects, it would be in YourProject.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/configuration/registries.json. Make sure to commit this configuration file, so all your colleagues and your CI have access to the registry.

When unauthenticated, you will be rate-limited to 10,000 requests per minute – more than enough for resolving hundreds of packages in a typical clean build. If you are running into limits, you can still authenticate with your Tuist account to increase your rate limit to 100,000 requests per minute:

But for typical workflows, the current limits should be more than enough. If not, please reach out to us, we'd love to know, so we can adjust the rate limits to accommodate typical workflows.

If you're already using the registry, we recommend re-running tuist registry setup to update your configuration file with the new endpoint that allows unauthenticated access.

What's next?

We believe that to provide the best experience, we need to use our own tools daily. Opening the registry has allowed us to integrate the registry in our monorepository where all of our Swift packages are installed via the Tuist Registry, which we've done as part of this PR.

Now that the registry is open, our next step will be to allow authenticated organizations to publish their own packages to a private registry, so they can move all of their packages away from the source control resolution and improve the resolution of both open source and internal packages.

And as always, we're keen to hear your feedback – do you have any suggestions or ideas for how we can improve the registry? We'd love to hear from you!

In systems thinking, there's a pattern called "Shifting the Burden", identified by Peter Senge in "The Fifth Discipline", where organizations repeatedly apply symptomatic solutions that provide quick relief while the fundamental problem grows worse. When build times slow down, companies buy faster hardware. When throughput drops, they hire more developers. When coordination fails, they rewrite everything in a different technology. These solutions feel productive because they're tangible and immediate. But they're treating symptoms, not the disease. And with each symptomatic fix, the organization becomes more dependent on them, while losing the capability to solve the underlying problem.

This is that story. And it costs companies millions before they realize what's happening.

The Metric That Rules Everything

There's a number that strongly signals whether your engineering organization is thriving or drowning. It's not lines of code. It's not story points. It's not even bugs per release. It's merge throughput: how many code changes successfully make it into your main branch each day. This metric tells you how fast features reach your customers, how quickly bugs get fixed, how rapidly you can respond to market demands. It's the heartbeat of your engineering organization.

And here's what most engineering leaders don't realize until it's too late: as your team grows, this number can actually go down. Sometimes dramatically. Let me show you what's coming.

Phase 1: The Lone Wolf

You launch your startup on a Tuesday. You're a solo founder who codes, armed with Claude and GitHub Copilot as your pair programmers. No team. No process. No friction. You push straight to main. Multiple times a day, every day. There are no code reviews because there's nobody to review with. There are no merge conflicts because you're the only one committing. There's no CI pipeline slowing you down because every bug that slips through goes straight into the weekly release to your five beta users who are just happy the app exists.

With your AI coding assistants writing boilerplate and suggesting implementations, you're moving at a pace that would have seemed impossible five years ago. The merge throughput is pure: one developer, zero overhead. This is the golden age. This is what velocity feels like.

But your app is growing. Users are signing up. And one bad commit ships a critical bug in your weekly release because there was no safety net. That's when you realize: pure velocity without quality control is just recklessness in disguise.

Phase 2: Adding Safety Nets

You set up GitHub Actions. You create a branch called "develop" and promise yourself you'll only merge to main after tests pass. You hire your first engineer, Marcus, who's also using AI coding tools to write code faster. Now when you want to ship a feature, you open a pull request. The CI kicks off, running tests and linting. Marcus reviews your code. Then it merges. When Marcus ships code, you review. The cycle repeats.

You're still moving fast, though not quite as fast as before. Once or twice a week you run into a merge conflict because you both touched the same file, but it's quick to resolve. Occasionally a test fails randomly, and you just rerun the CI. Your team of two has added some overhead per commit. But you've also stopped shipping bugs in your weekly releases. It's a worthy trade-off.

The app is growing. Revenue is growing. You raise a seed round and decide it's time to build a real team.

Phase 3: The Team Multiplier

Six months later, you have five engineers. Everyone has AI assistants helping them write code. The roadmap is ambitious. The team is talented. The codebase has tripled in size. You'd expect throughput to multiply with the team. But that's not what happens.

Li opens a PR in the morning. It sits waiting for review because you're in meetings and Marcus is deep in his own feature. Hours later, you finally review it. You request changes. Li makes the updates, but the CI takes longer now because the test suite has grown. And when it finishes, there's a merge conflict because Marcus merged something that touched the same service. Li resolves it, reruns CI. By afternoon, one commit finally lands.

This happens to everyone, all day long. PRs sit in review queues. Merge conflicts happen frequently now that five people are touching overlapping code. The CI occasionally has a flaky test, and nobody's quite sure which test it is, so they just click "retry." Many PRs come back with requested changes, adding another round trip. The throughput has grown, but nowhere near what you'd expect from adding three more engineers.

And then there's the CI bottleneck. Your provider asked you to estimate how many runners you'd need. That works when your workload is predictable, but it's not. Nobody's is. During peak hours, PRs pile up waiting for available runners. Your team sits idle, watching the queue grow. The provider is just leaking the pain of hosting Mac minis to you. They can't absorb your elastic demand because they don't operate at the scale you need. You're not blocked by budget. You're blocked by infrastructure that can't keep up.

You hired three more people and throughput improved, but not nearly as much as you expected. This isn't what growth is supposed to look like.

Phase 4: The Complexity Wall

Two years in, your mobile team has grown to 30 engineers. Everyone is shipping code, everyone has AI tools making them more productive than ever, and the feature velocity should be incredible. But something's wrong.

The CI now takes 15 to 25 minutes. Nobody remembers who wrote half the tests in the suite. Flaky tests fail frequently, and debugging which test is flaky wastes hours. PRs sit for hours waiting for review because everyone is context-switching between their own features, meetings, and multiple PRs in their queue. When reviews finally happen, many come back with requested changes. More waiting. More CI runs. Merge conflicts happen constantly. When someone finally resolves a conflict and merges, they hold their breath hoping nobody else merged while the CI was running. If they did, back to square one.

You're paying millions in engineering salaries and getting a fraction of the output you should. Leadership asks why feature delivery has slowed down. You don't have a good answer.

Phase 5: The Brute Force Trap

Your team comes up with a plan. Three plans, actually. Each one sounds reasonable in isolation, but none of them address the root problem:

Option 1: Faster Machines "We'll upgrade to the beefiest CI runners GitHub offers," he says. Sixteen cores instead of four. It'll cost hundreds of thousands per year, but it'll cut the CI time in half. Your team calculates the improvement: modest at best.

Option 2: More People Someone suggests hiring more developers to "parallelize the work." Another million-plus in salary. But you've learned the math by now. More people means more conflicts, longer review queues, even slower CI. Throughput might not move at all. It might even go down.

Option 3: Technology Rewrite A CTO from your previous company suggests you rewrite everything in React Native. "No compilation step," he says. "Way faster iteration." The rewrite would take months, cost your entire team's focus, and millions in opportunity cost. And at the end, you'd inherit a new set of problems:

• A brittle foundation built on constantly-evolving packages. The ecosystem moves fast, breaking changes are common, and keeping dependencies up to date becomes a perpetual maintenance burden. What works today might require rewrites tomorrow.

• A massively expanded security surface. Instead of relying on platform APIs maintained by Apple and Google, you now depend on hundreds of npm packages, each with their own maintainers, each a potential entry point for supply chain attacks.

• Platform features become harder to access. Every time iOS or Android releases a new API, you wait for someone in the community to write a bridge. Native features that should take hours now take days or weeks, assuming someone builds the bridge at all.

• Performance optimization becomes the default state. Instead of focusing on building features, your team spends cycles debugging why lists scroll slowly, why animations drop frames, why the app uses too much memory. The abstraction layer adds overhead that you constantly fight against.

But you'd still have the same coordination problems.

You pick the faster machines because it's the cheapest mistake. Throughput improves slightly. You're paying hundreds of thousands a year to make a small dent in the problem. You know you're treating symptoms, not the disease. The disease is that you're building and testing everything, every time, for every change, no matter how small. But you don't know what else to do.

Phase 6: Smart Optimization

But there's an elephant in the room. Something that would be cheaper than all three options, and would have a dramatically better impact.

What if you didn't compile and test everything every time? What if you could diff the changes to be selective about what to compile and what to test? When Li changes the authentication module, why are you rebuilding dozens of other modules that didn't change? When someone touches a networking utility, why are you running the entire test suite instead of just the tests that actually depend on that code?

Then you talk to an engineering leader at another company who faced the same wall. "We integrated Tuist," he says. "Binary caching and selective testing. Changed everything." The idea is simple: only rebuild what changed, only test what's affected, and share the cached results across your entire team and CI.

Your team spends one week integrating Tuist. You set up binary caching so when Li changes the authentication module, the other modules use cached builds from the last time they were compiled. You implement selective testing so the CI only runs the tests affected by the change, not the entire suite. The first PR after the optimization merges in minutes instead of an hour.

Your CI time drops dramatically. The queue disappears because jobs finish faster. Review time drops because fast feedback means reviewers can stay in context. Merge conflicts drop because the faster cycle time means less overlapping work. The merge throughput more than doubles.

You're still paying the same in engineering salaries. But now you're getting dramatically more output. The efficiency more than doubles. You've unlocked millions in value. The investment was a fraction of one engineer's salary per year for Tuist and one month of implementation time. The payback period was measured in days, not years.

What Just Happened

Let's trace your journey. At one developer, you had pure efficiency. Zero overhead. At two developers, you maintained most of that efficiency. At five developers, efficiency dropped noticeably. At thirty developers, efficiency crashed. You were getting a fraction of the output you should from your team size.

After optimization, with the same thirty developers, efficiency more than doubled. Not perfect, but dramatically better than where you were. And here's the key insight: you optimized workflows first, not hardware. Instead of spending hundreds of thousands per year to make your waste happen slightly faster, you spent a fraction of that to eliminate the waste itself. The hardware approach provided marginal gains. The workflow approach transformed the organization.

Why Most Companies Get This Wrong

Here's the pattern we see repeatedly: companies optimize in the wrong order and waste millions before discovering the right solution.

Let's take a typical scenario: a 30-person mobile team with 20-minute CI times. Each developer waits for CI roughly three times a day. That's 60 minutes per developer per day spent waiting. Across the whole team, you're wasting the equivalent of 5 full-time engineers just waiting for builds. At an average salary of €140K, that's €700K per year in wasted time.

"But they can just work on something else while waiting," you might think. This misses the real cost. Research shows it takes an average of 23 minutes to regain focus after an interruption. When CI breaks your flow three times a day, you're not losing 20 minutes per build. You're losing 20 minutes of waiting plus 23 minutes getting back into flow state. Task switching reduces productivity by up to 40%. The actual cost isn't the wait time. It's the shattered attention, the broken flow states, the mental fatigue from constant context switching. That 60 minutes of visible waiting becomes 2+ hours of lost productivity.

The typical sequence looks like this:

Year 1: Faster Hardware. Team hits slow CI times. Leadership approves €300K annually for the fastest runners available. CI time drops from 20 minutes to 12 minutes. Modest improvement. Everyone celebrates. But wait times per developer only drop from 60 to 36 minutes per day. The team is still building and testing everything, just slightly faster. Value unlocked: roughly 2 FTE worth of time (€280K). But it costs €300K per year. You're barely breaking even.

Year 2: Hire More People. Throughput is still terrible. Leadership hires 10 more developers at €1.4M annual cost. But more developers means more CI contention, longer queues, more conflicts. Wait times actually increase to 75 minutes per day. Instead of gaining capacity, you've made the problem worse. The coordination overhead grows faster than the output.

Year 3: Technology Rewrite. Someone suggests rewriting everything in React Native. "No compile times!" The rewrite takes six months, costs the entire team's focus, and millions in opportunity cost. At the end, you've traded one set of problems for another. The coordination problems are identical. They just happen in a different language.

Total spend over three years: €3M+ in direct costs (hardware, new hires, rewrite), plus countless hours of engineering time. Throughput improved marginally.

The alternative sequence that actually works:

Month 1: Implement binary caching and selective testing. When a developer changes one module, the others use cached builds. When someone touches code, only the affected tests run, not the entire suite.

The result: CI time drops from 20 minutes to 4 minutes. Wait times drop from 60 to 12 minutes per developer per day. That's 48 minutes saved per developer per day. Across 30 developers, you've saved 4 FTE worth of time annually. At €140K average salary, that's €560K in recovered value. The cost? Roughly €20K per year. Not by building faster, but by building less. Only what changed. Only what matters.

The Choice

This story is every company's story. The only question is which chapter you're in, and whether you'll choose to optimize the right thing.

The difference isn't just the value, though that's dramatic. The difference is that one approach treats symptoms while the other fixes the disease. Faster hardware makes waste happen faster. More people amplify coordination overhead. Better workflows eliminate the waste entirely.

Optimize workflows before hardware. A faster machine makes your waste happen faster. A better workflow eliminates the waste. One costs significantly more and provides modest improvements. The other costs a fraction and transforms the organization.

Ready to see what this looks like for your team? Talk to us about how Tuist can help you scale, or get started and see the difference in days, not months.

As Tuist evolved, the old website no longer represented what we’re building and shipping today. After redesigning our developer dashboard, we wanted our landing page to match its new look and feel. We began by reviewing what worked well on the previous site and what could be improved, drawing inspiration from other developer tools. We also realized some important information was missing, and with new features launching every cycle, it felt like the perfect time for a redesign.

The process

Before redesigning the website, we spent time researching what could be improved and what was missing. We reviewed over 25 developer tool websites, studying their strengths and weaknesses. The website plays a big role in shaping our brand identity, and with the dashboard redesign, we wanted to bring the same look and feel to our site.

The main issues we identified were:

• The old website didn’t clearly communicate that Tuist had grown beyond the CLI.
• The previous site layout made it hard to find information or understand Tuist’s features.
• It was difficult to showcase new features and updates effectively.
• We weren’t clearly demonstrating how Tuist supports real teams or inspire new contributors to get involved.
• The website visuals didn’t align with the newly redesigned dashboard.

Stage 1: Clarifying the Message

The first thing we noticed was that our story wasn’t being told the way we wanted. Tuist had grown far beyond being just a CLI tool, yet our website still gave that impression. We wanted to communicate what Tuist truly is today, a platform that helps teams build, collaborate, and ship mobile apps.

To do this, we reworked the content and page flow to focus on the bigger picture of Tuist’s ecosystem. We looked at developer tools like Vercel, Supabase, and Linear, understanding how they convey complex ideas in a clear, simple way. More on this topic below.

Stage 2: Improving the Structure and Navigation

Another issue we saw was how difficult it was to understand what Tuist offered at a glance. The navigation felt fragmented and didn’t guide new visitors through the story. We decided to rebuild the site structure with clarity in mind, making it easy for developers to discover what Tuist does, explore its features, and understand how it can help their teams. Now the navigation is divided into three main parts: Features, Developers, and Resources, each designed to provide clarity on a specific aspect of Tuist.

• Features highlights what Tuist offers, showcasing key capabilities and how they help teams build and scale Xcode projects efficiently.
• Developers puts the focus on the community, open-source contributions, documentation, and ways to get involved.
• Resources brings together learning materials, blog posts, and guides to help both new and experienced users make the most out of Tuist.

Stage 3: Enhancing Visual Storytelling

Our previous design made it hard to showcase Tuist’s features, especially as we kept releasing new ones. Updating the website each time felt limited due to the old design system. To make this process smoother and more engaging, we introduced bento card designs, modular sections paired with custom illustrations that explain each feature visually. This made it much easier to highlight what’s new, while also giving the page a more dynamic and consistent feel. This is my favorite part of the entire website!

Stage 4: Showcasing Customer Stories and Community Impact

Being an open-source first company, we’ve always valued transparency and community involvement. But the old site didn’t really show how Tuist was helping teams or how contributors were shaping the project.

We added customer case studies with custom illustrations to tell real stories, how teams reduced build times, improved collaboration, and scaled their development workflows using Tuist.

We also introduced community metrics to highlight our open-source growth and inspire more developers to contribute.

Stage 5: Unifying the Brand and Visual Language

Finally, we wanted to make sure our website felt like a natural extension of our newly redesigned dashboard. The previous site had a different tone and visual style, which made the overall experience feel disconnected. We brought everything together under a unified brand identity and built the website using the Noora Design System. All core elements, buttons, input fields, shadows, colors, and variables, are based on Noora for consistency and scalability.

While the foundation remains the same, we introduced and customized several components specifically for the website, such as blog post cards, header background visuals, and the overall gradient-driven style. You can think of it as a more stylized, marketing-focused version of Noora. Even the custom illustrations were designed using Noora’s color variables to keep everything visually cohesive.

This consistency not only strengthened how Tuist looked but also how it felt to use and explore.

Iterating on the Perfect First Impression

One of the biggest hurdles in the redesign was getting the header illustration just right. It plays a huge role in shaping the first impression, but representing the tool’s value in one illustration is quite challenging.

At first, we tried using a simple dashboard screenshot, but that approach quickly proved impractical. We release new features frequently, and updating the image every time would be too time-consuming. On top of that, a static dashboard screenshot doesn’t communicate much value to new users who are unfamiliar with the product.

Next, we experimented with a CLI animation, but it didn’t quite fit. Tuist has grown far beyond the CLI, and focusing on it wouldn’t convey the story we wanted to tell about how fast the product is evolving.

We then explored a concept featuring interactive charts and graphs, complete with animated team cursors to visualize collaboration. Although this version looked interesting in tests, we realized that random charts and metrics wouldn’t mean much to someone visiting the site for the first time.

Finally, we landed on the current version, one that centers around the mobile development experience, highlighting key features we’re proud of, such as reducing build times, skipping repetitive tests, and automated QA testing. This version feels true to what Tuist is today and communicates our message clearly.

As Tuist continues to grow, we expect the header to evolve as well, after all, it’s the first impression any developer gets when they land on our page.

What’s next

Design is never truly done. It’s a constant process of refinement and exploration. While dark mode is definitely something we’ve been thinking about (and it’s on the list), our minds are already moving toward what’s next, experimenting with new visual patterns, micro-interactions, and immersive storytelling elements that make the experience feel more alive.

We see Tuist’s design language as something that will evolve with the product, adapting to how developers use it, and reflecting the balance between engineering precision and creative expression.

If we had to describe it in one line: we’re building something functional, but with soul. Redesigning and redefining Tuist’s message was and will continue being a fun and rewarding process.

Traditionally, teams have used Xcode's building blocks like projects, targets, and schemes to model these organizational patterns. A project might contain all networking-related modules, another might house the UI layer, and so on. This approach works, but it has a fundamental limitation: it forces you to choose a single organizational dimension. If you organize by layer, you lose visibility into features. If you organize by feature, you obscure the architectural structure.

The reality is that organizational needs are often orthogonal to each other. The networking layer crosses multiple features. A single feature might span multiple architectural layers. A team might own modules across different parts of the system. Xcode's project-based organization cannot easily represent these intersecting concerns.

Enter metadata tags

This is precisely the problem that metadata tags solve, and it is one of Tuist's most powerful yet underutilized features. Metadata tags are simple string labels that you attach to targets in your project manifests. They allow you to organize modules across multiple dimensions simultaneously without restructuring your codebase or creating complex Xcode project hierarchies.

Here is a practical example:

Notice how each target can have multiple tags representing different organizational dimensions. NetworkKit is simultaneously part of the networking layer, owned by the platform team, and considered core functionality. This multi-dimensional organization is impossible to represent with traditional Xcode project structures.

Tag naming conventions

While you can use any string as a tag, following a consistent naming convention makes your tags more maintainable and discoverable. We recommend using prefixes to namespace your tags by dimension:

You can combine multiple dimensions on a single target, creating a rich metadata system that reflects the true complexity of your codebase without adding structural overhead.

Focusing your development

Once you have tagged your targets, you can use these tags to focus your development workflow. Here's a quick walkthrough showing how this works in practice:

Want to work exclusively on the networking layer? Simply generate a focused workspace:

Tuist will generate a workspace that includes all targets tagged with layer:networking, plus their dependencies. This gives you a smaller, more manageable workspace that contains only what you need for your current work.

You can also combine tags with target names:

When you focus on targets, Tuist automatically includes:

• All targets matching your query
• All dependencies of those targets
• Test targets for the focused targets

Everything else is excluded, giving you faster project loading, quicker indexing, and more focused development.

The real power: combining tags with module caching

This is where metadata tags truly shine. Tuist's module caching can replace targets with their precompiled .xcframework binaries, dramatically speeding up build times. When you combine this with metadata tags, you get fine-grained control over which parts of your codebase remain as editable source and which are replaced with binaries.

Here is a concrete example. Imagine you are working on the networking layer of your app. You want to iterate quickly on networking code, but you do not need to touch any UI or business logic. With metadata tags and module caching, you can do this:

Tuist will generate a workspace where:

• All targets tagged with layer:networking remain as editable source code
• All dependencies of those targets that are not tagged with layer:networking are replaced with cached binaries
• You get full compile-time feedback on your networking changes
• But you avoid recompiling unrelated parts of the codebase

This workflow is transformative for large codebases. A one-line change in a low-level module traditionally forces a full rebuild. With focused caching through metadata tags, you recompile only what matters for your current work.

Let's look at a more complex scenario. Suppose you are on the commerce team working on payment features. Your workspace might look like this:

Now only your team's modules compile from source. All platform infrastructure, other features, and shared utilities? Cached binaries. You get instant feedback on your team's code without waiting for the entire codebase to compile.

Or perhaps you want to work across features but only at the UI layer:

Now you can freely modify UI components across different features, while the business logic and data layers are served from cache.

Practical examples

Let's walk through some real-world scenarios to illustrate how teams can leverage metadata tags.

Scenario 1: Feature team development

Your app has multiple features: authentication, payments, settings, and analytics. Each is owned by a different team. You tag your modules accordingly:

A developer on the commerce team runs:

They get a workspace with PaymentKit and PaymentUI as sources, everything else cached. The workspace loads faster, Xcode indexes less code, and clean builds are dramatically faster because most of the app is precompiled.

Scenario 2: Architectural layer refactoring

Your team is refactoring the data layer to use a new database framework. You want to work on data layer modules without touching business logic or UI:

All data layer modules remain as sources. Business logic and UI layers are cached binaries. You can iterate rapidly on your database code, running tests frequently without waiting for unrelated code to compile.

Scenario 3: Platform infrastructure work

You are working on core infrastructure that many features depend on: networking, logging, analytics. These modules are tagged as platform team ownership:

You get all platform infrastructure as sources, allowing you to make changes across multiple infrastructure modules simultaneously, while feature code remains cached.

Scenario 4: Multi-platform development

Your codebase supports iOS, macOS, and watchOS. You are working exclusively on the watchOS app:

Only watchOS-specific code and its direct dependencies remain as sources. iOS and macOS modules? Cached. You avoid the cognitive load and compile time of irrelevant platforms.

Standardizing tags with helpers

As your tagging strategy matures, you will want consistency across your project manifests. Project description helpers provide a perfect way to standardize tag application:

Now in your manifests, you can use this helper to ensure consistent tagging:

This approach ensures every module gets tagged consistently, making your organization system reliable and maintainable as your team grows.

Organizing tags with enums

For even better maintainability and compile-time safety, you can define your tags as constants organized in enum namespaces. This prevents typos and makes it easy to discover available tags:

Note that these are enums used as namespaces containing static string properties, not enum cases. When you access Tags.Domain.authentication, you get the string "domain:authentication" directly.

Then use these constants in your target definitions:

And in your manifests:

This approach provides:

• Autocomplete - Your IDE suggests available tags as you type
• Refactoring safety - Renaming a tag updates all usages
• No typos - The compiler catches invalid tag references
• Discoverability - New team members can explore available tags through IDE completion

You can extend this pattern further with methods that return computed tags:

This gives you the flexibility to generate tags dynamically while still maintaining organization and type safety.

Best practices

Based on our experience helping teams adopt metadata tags, here are some recommendations:

Start simple. Begin with a single tagging dimension that solves your most pressing organizational problem. If your biggest pain point is architectural clarity, start with layer tags. If it is team boundaries, start with team tags. You can always add more dimensions later.

Be consistent. Use the same naming conventions across all manifests. Document your tagging strategy in your project's README so everyone understands the system.

Use helpers. Leverage project description helpers to enforce consistency. This prevents typos and ensures new modules get tagged correctly from the start.

Iterate based on workflow. Pay attention to which tags you actually use for focusing. If you rarely use certain tags, consider whether they are adding value or just noise.

Review periodically. As your project evolves, review your tagging strategy. Teams reorganize, features mature, and architectural patterns change. Keep your tags current.

Why this matters

Metadata tags might seem like a simple feature, but they unlock a fundamentally different way of working with large codebases. Instead of fighting against monolithic builds or creating complex Xcode workspace hierarchies, you can organize your code conceptually and generate focused workspaces on demand.

When combined with module caching, this becomes even more powerful. You get the benefits of modularization, fast compilation times, and the flexibility to work on any part of your codebase without waiting for irrelevant modules to compile.

If you have been using Tuist but have not yet explored metadata tags, we strongly encourage you to try them. They represent a different paradigm for organizing and working with Xcode projects, one that scales naturally as your project grows.

To learn more about metadata tags, check out our documentation. You can also explore how tags integrate with module caching to supercharge your development workflow.

We would love to hear how you are using metadata tags. Share your experiences in our community forum, Slack, or on Mastodon.

This sometimes leads to drastic choices being made by iOS engineering teams, such as moving to other build systems like Bazel that has a great support for caching or completely abstracting away the platform with technologies like React Native. We've developed our own solution to help teams with their build times by leveraging generation to cache modules as .xcframeworks. And we believe that, at the time of writing, the Tuist module cache is still the best solution for iOS teams looking to speed up their builds.

However, now you can improve your incremental and clean build times in just a couple of minutes, regardless of your Xcode setup, with the new Xcode compilation cache introduced in Xcode 26.

How is this different than derived data

You might be wondering how the new Xcode compilation cache is different than derived data.

Build artifacts in the derived data directory are stored in a location-based structure. When Xcode builds your project, it places compiled objects, indexes, and intermediate build products in paths tied to your project's location and configuration. On the surface, this seems reasonable-put the outputs next to the inputs. But this seemingly simple design decision has created a cascade of problems as our development workflows have evolved.

Consider a typical scenario: you're working on a feature branch, building and testing locally. Your colleague in another time zone is working on a different feature. Your CI system is running builds for every pull request. All of you are compiling the same dependencies-maybe a large framework like Alamofire or a set of internal modules that rarely change. Yet each of you is doing this work independently, from scratch, because derived data can't safely share these artifacts.

Why not? The problems run deep:

Non-deterministic builds: The same source code compiled on different machines or in different locations can produce different artifacts. This isn't just theoretical-debug symbols contain absolute paths, frameworks reference their build location, and various metadata gets embedded during compilation. If you build on your MacBook Pro and I build on my Mac Studio, we get different bytes, even though the source code is identical. This makes caching across environments fragile at best and incorrect at worst.

Path dependencies: Artifacts often contain hardcoded absolute paths. Your framework compiled at /Users/you/Projects/App doesn't work when I try to use it at /Users/me/Code/App. These path references break when moved between machines or when the project is located in different directories. It's not just about where the framework is-it's about where it was built, where its dependencies were, where the SDK is installed. It's turtles all the way down.

Coarse invalidation: When something goes wrong-and something always eventually goes wrong-developers resort to deleting the entire derived data directory. Hours of compilation work, discarded in seconds, because there's no reliable way to determine which artifacts are still valid and which are corrupted or stale. We throw away the good with the bad because we can't tell them apart.

Limited sharing: These characteristics combine to make it nearly impossible to reliably share build artifacts across team members or between local development and CI environments. Some teams have tried-setting up shared network drives, syncing derived data directories, elaborate rsync scripts. These approaches are fragile and often cause more problems than they solve. The fundamental architecture just wasn't designed for this use case.

Moving beyond derived data: Xcode compilation cache

All of these problems are solved by the new Xcode compilation cache which, in many ways, is similar to other performant build systems like the already-mentioned Bazel or Gradle. These build systems and now the Xcode compilation cache use a combination of a key value store (also known as action cache) and a content-addressable storage (commonly referred to as CAS).

When the build system compiles your app, instead of storing artifacts based on file paths, it computes a hermetic fingerprint for each build action and stores the compilation artifacts in the content-addressable storage where each artifact is identified by a unique digest of the contents. This makes builds deterministic, portable, and more efficient.

This shift has taken Apple multiple years to execute – the first RFC to add support for caching using the content-addressable storage in the LLVM project (which the Swift build system builds upon) was proposed in 2022. But since Xcode 26, you can enable the Xcode compilation cache by setting the COMPILATION_CACHE_ENABLE_CACHING to YES in your build settings or in the xcodebuild invocation and reap the benefits – at least locally.

Sharing cache across environments

Improving local incremental builds is already a huge improvement to our daily Swift development. But since the new compilation cache is portable, shouldn't we be able to reuse build artifacts from the CI on our local machines? Or between individual CI runs? Can we finally stop rebuilding the same code over and over again?

You might wonder if you can cache the whole compilation cache across CI runs and then download the whole directory to your local machines – and while you can, this directory will be continuously growing and there's no direct way to tell which artifacts are still actively being used and which not.

Instead, the build system uses a gRPC contract to communicate with external services. Whenever the build system needs to look up a value in the key-value store or the content-addressable storage, if it's not found in the local compilation cache, it will connect to the remote service, if available, and attempt to retrieve the missing data from there. Similarly, when storing new artifacts, the build system will store them both in locally and remotely.

So, how do you get started with remote caching using Tuist?

1. Install the Tuist CLI if you haven't already.
2. Integrate your project with Tuist by running tuist init.
3. Run tuist setup cache.

The tuist setup cache then lists out the build settings that you need to configure in your project:

• COMPILATION_CACHE_ENABLE_CACHING=YES to enable local or remote caching -COMPILATION_CACHE_ENABLE_PLUGIN=YES to enable a plugin that communicates with the remote cache
• COMPILATION_CACHE_REMOTE_SERVICE_PATH=$HOME/.local/state/tuist/your-organization-handle_your-project-handle.sock to instruct plugin where it can find the gRPC socket proxy

The gRPC socket proxy acts as a bridge between the build system and needs to be running as a daemon in your system. Note that tuist setup cache will automatically start the gRPC socket proxy for you.

The Xcode compilation cache in the real world

Let's take a look at how the Xcode compilation cache helps to reduce build times in real world projects. We've benchmarked the performance of the Xcode compilation cache in the following projects:

• Pocket Casts
• Wikipedia
• Tuist CLI

Note: The following benchmarks were conducted on Namespace M4 Pro runners on 20th and 21st October 2025 using Xcode 26.0.1. All benchmark results are available in our cache-benchmark repository.

Here's what we've found:

For Wikipedia, the build time was reduced by 24% when using the local cache (simulating clean builds with local compilation cache already populated) and by 18% when using the remote cache (simulating clean builds with remote, not local, compilation cache already populated). For Pocket Casts, the build times were reduced by 36% for the local cache and by 20% for the remote cache.

We've observed the biggest improvement in build times for Tuist CLI, where the build time was reduced by 77% when using the local cache and by 53% when using the remote cache. Why is the cache so much faster against the Tuist CLI project? We'll need to talk about the current state of the cache.

Not everything is cacheable (yet)

The compilation cache is still an early, opt-in feature. In the latest Xcode release (26.0.1), there are still a lot of tasks that are not cacheable, like computing the build graph or compiling parts of Swift packages. This is why the Tuist CLI performs better than other projects because we integrate our packages as Xcode projects. In fact, we've also measured the performance of the cache against Mastodon – in one case using the default SwiftPM integration, in the other generating those dependencies as Xcode projects. The difference was significant:

Whereas building Mastodon with the local cache and the remote cache with the default SwiftPM integration improved the build by 19% and 30%, respectively, the improvements were 55% and 69% for the Mastodon project generated with Tuist.

We certainly expect the types of tasks that Xcode can cache to expand, including a better support for Swift packages, but it's important to highlight the current limitations of the cache.

Latency is key

Apart from a difference between generated and non-generated projects, you might have also noticed that the remote cache is typically slower than the local cache – and that will always be the case as file operations are faster than going over the network–because physics. The build system is making thousands or tens of thousands of requests per build and each request has a cost associated with it.

This is why we're investing heavily in our edge infrastructure to minimize that cost and serve the cache requests at the minimum latency. We're also exploring the possibility of pushing the edge concept into our customers' offices-deploying cache nodes on local networks to improve the latency even further. And we expect that Apple will invest more into optimizing the distributed cache, such as by computing which artifacts will be needed during the build earlier and prefetching them.

The power of module-based caching

While Apple continues to invest into the build caching, we've already iterated on module-based binary caching over the years and based on our benchmarks, our approach currently outperforms the remote cache – achieving better or similar build times (including generation and fetching of binaries) as the local compilation cache. Instead of caching individual compilation units, we cache entire frameworks and libraries, pre-fetch them before generating the project and then letting the build system compile only what has changed. This also has the side effect that Xcode projects are leaner and Xcode is faster.

And the combination of both approaches can achieve even greater improvements. Xcode compilation cache provides a more granular level caching that works seamlessly with Xcode, while module-based caching delivers the coarse-grained reuse that dramatically cuts build times in modular architectures.

Looking ahead

If you've been intrigued, head over to our documentation to get started with the Tuist cache. We're currently offering the remote Xcode cache for free while we iterate on the integration of this feature with pricing being announced later in the year. In the meantime, we will continue to improve the latency and introduce detailed analytics to help you understand the impact of the cache on your build times. You can already leverage our build insights to track the build performance in both local and CI environments.

And if you have any questions or feedback, reach out to us in our community forum, Slack or send me a mail directly at marek@tuist.dev.

We see many large organizations showing up seeking support, and many developers who, having experienced the support that Tuist gives them, don't think twice when they start new projects and bet on Tuist from the get-go.

In this post, I'd like to discuss the common challenges that we continue to see and how Tuist helps you overcome them. I'll also acknowledge some of the work that Apple has done and is doing to improve the state of things, and hopefully leave you informed about the many things you likely suffer from but can't pinpoint to the root cause. But before we dive into the details, let's first talk about what I like to call the wake-up leadership crisis.

Wake-Up Leadership Crisis

Apps usually are just another interface for the users or customers of a business to interact with the business domain, and a business's ultimate goal is to increase revenue and profit. If they move in competitive markets, this requires them to move at a faster pace, and this often leads to tension in iOS development teams where, regardless of how many human resources you throw at the problem, the bottleneck is the toolchain and everything that surrounds it. Your build times of 2 minutes or CI time of 5 years ago have become 30, and there's no Apple Silicon that can take those 30 back down to 2 minutes. And it doesn't matter how much blame you place on Apple—business doesn't care about that or about how much you've normalized those times. They deem it unacceptable, especially when they have other platforms like the web with much faster and more advanced tooling that gives them not only the speed they need but also visibility into what's happening to optimize the setup.

Having reached that point, we often see companies taking a few paths. One of the most common is adopting React Native. They throw a JS runtime into the mix, which allows them to hot-reload changes in development and even distribute updates and fixes over the air. Shopify migrated all their mobile apps to React Native for this exact reason. They had invested in React prior to this decision, and it made sense for them because it would also align mobile with the mental model they were already familiar with on the web. But you need to be mindful of the trade-off you are making here. By choosing React Native, you are abstracting away the native platform, and this comes at a cost that you can absorb yourself, as was the case with Shopify by assembling a team to develop and maintain foundational pieces, or rely on companies like Expo that package an ecosystem of libraries and services under an umbrella.

The second path that we see some companies taking is Bazel. Bazel is a very advanced and powerful build system. But replacing an entire build system is often even costlier than introducing React Native. Most programming languages and ecosystems come with some build system built-in: Elixir, Swift, Xcode, Gradle, Cargo... So when you replace it with something else, reconciling the build system piece with everything that builds upon it is a huge investment that not many companies are willing to make. At Tuist, we often see companies whose story goes like this: One or a few engineers get excited about Bazel, they convince leadership to spend a few months of work introducing Bazel, they manage to get it working although no one knows how it works except them, those engineers leave the company, and the company decides to drop Bazel because it's too costly. We've seen countless companies going through this path, and I completely get it. As much as you can, you should stay close to your build system because that also means staying close to the ecosystem that surrounds it.

For those who prefer to stay closer to the native toolchain and therefore have a lower cost to scale up their development, they see Tuist as the best option. This is by design. We abstracted just where we had to, such that we helped teams overcome the challenges while keeping an eye on and peeling abstractions when the issues were addressed at the right layer, like we saw with Xcode 16 and the introduction of buildable folders.

At this point, you might wonder: what are those challenges that large companies are facing, and that I might face too, if not today, maybe tomorrow? Let's explore some of them.

1. Modularization

Modularization is not just a tool for defining boundaries between components. It's also a tool to access reusable pieces of code across repositories and to share code between an app and the extensions contained in it. It's something that we'll do sooner or later. Modularization sadly comes at a cost, also related to an Xcode design decision.

As you might know, binaries can be linked statically or dynamically. Static linking happens at build time, while dynamic linking happens at runtime. The decision of one or the other for each module in the graph has implications that expand beyond just setting the linking type. For example, dynamic modules need to be explicitly copied into the right product so the linker can find them. Or static libraries will have to be linked from certain products that can link static libraries, ensuring we don't end up with duplicated symbols. Doing these things right is easy if there are a few modules in the graph, but as it grows in complexity, no human brain can hold a graph in memory to set things up and fix issues when they arise.

As with derived data, people feel this pain. And the pain was so strong that they decided SwiftPM would be the best solution to alleviate the pain. "These people have solved defining modules, so they must have figured out how to reconcile a SwiftPM's graph into an Xcode project's," the community must have thought. So without planning it, Apple found itself reconciling a SwiftPM graph with an Xcode project's graph, which might also contain dependencies that are implicitly defined. What a fun challenge that must have been for Apple. And if that wasn't challenging enough, they added an extra variable to make it even more challenging: mergeable libraries.

Over the past years, we've seen more and more companies outsourcing graph complexity to SwiftPM, just to realize soon after that they had to trade developer ergonomics to reduce the complexity of maintaining a graph. Now projects are resolved asynchronously, at times that you can't control, and a project that used to be ready to compile at launch no longer is because now it's invoking a SwiftPM process in the background whose process needs to be reconciled with Xcode's legacy business logic and UI. Fun, fun.

We've seen more and more companies outsourcing graph complexity to SwiftPM, just to realize soon after that they had to trade developer ergonomics to reduce the complexity of maintaining a graph

This is a complicated topic to bring into a discussion because one of the reasons why this happens is Swift itself and Package.swift manifests, which have to be compiled. Some of which can contain implicit side effects that they can't know but assume exist, as the pulling of sub-modules automatically shows. It's amazing writing manifests in Swift—Tuist does that, too—but when it comes at the cost of degrading the developer experience at a certain scale, I wonder if that's a good idea. For comparison, Cargo, Rust's build system, uses serializable .toml files. The JavaScript ecosystem uses .json, and Bazel uses the Starlark language, which is domain-specific and optimized for build systems.

For Tuist, making modularization extremely simple was our main goal, along with avoiding frequent git conflicts, from the get-go. It was the thing that set us apart from other generation tools and also the foundation that we needed to optimize teams' projects. I might be biased here, but Tuist is the best modularization tool out there. SwiftPM was designed for resolving dependencies, does a decent job at that, and should remain as a tool for that. Xcode projects should evolve to ease modularization such that SwiftPM is not used as a project manager. This is a symptom that Xcode and Xcode projects require a design iteration. Until then, I think generating projects like Tuist does is the best path forward. Anything required to get the linking right, from build phases to build settings, is all taken care of for you, such that you can focus on the graph structure and not on the implementation details that make it possible within an Xcode project.

2. Build Times

Every new year, new Apple Silicon comes out, and your managers rush to put a case to leadership to buy them because they might help make a cut in the build times of your projects. But the cuts got smaller and smaller over time. Justifying the investment got harder and harder over time, and you need an alternative. Unfortunately, React Native and Bazel are not an option, and sadly, Xcode doesn't help you with that.

This is the main driver of organizations adopting Tuist. They want their build times to be faster. Depending on whom you ask what "slow" is, you get different answers, but we've seen them ranging from "I'm tired of my 5-minute builds" to "I'm tired of my 2-hour builds on CI." Those times have been terribly normalized in the ecosystem. And they get worse when people clean derived data to mitigate an Xcode issue that they don't understand. "Can't they multi-task?" you might wonder. As if multi-tasking is the answer to everything. Multi-tasking means context-switching, and context-switching is terribly expensive too.

Soon after having made modularization easier with generated projects, we noticed we had the right foundation to optimize build times, learning from projects like Carthage or Bazel, and mutating the graph to incorporate binaries in it and ensuring our generation logic would reconcile all the changes. The result? A caching system that helps teams achieve up to 80% improvements (e.g. Trendyol achieved 65%) in their build times. The effectiveness depends strongly on the modularization and how the contributions distribute across all the modules. At the very least, you'll get all your third-party dependencies cached. Because who wants to be compiling code that you barely change on clean builds?

You can check out Tuist's public dashboard to see how our current cache effectiveness moves around 84%. Or take, for example, this test run where 122 modules were replaced with binaries. We hope that caching will eventually come natively to the native build system, and CAS is the right step in that direction. At Tuist, we are preparing for that by building the fastest and lowest-latency solution so that people can plug their Xcode projects in the near future without any hassle.

3. Test Times

Building is just part of what teams do after changes are implemented. They also need to run tests. Locally, developers usually run the tests that have changed or those that are connected with the file changes. However, on CI, teams commonly run all the tests of the test suite. And this means that the more tests they add, the slower they'll take to run on CI, and at some point, you'll have to do something about it.

We touched on some strategies here, but the general idea is that you should first consider parallelizing within the environment, since CI environments give you access to all the Apple Silicon cores. This comes with the challenge of ensuring your code is designed for parallelization, which is often not the case, manifesting as race conditions that appear as flakiness or, even worse, data races. If that's not enough, you can then parallelize across environments, but this requires doing some sort of sharding of tests across environments and playing with the -build-for-testing and -test-without-building flags. Sharding is something we plan to solve at Tuist such that developers can automatically do it by using flags with the CLI instead of having to write their own script. If this is not enough, the last thing that you can do is test selection, which consists of selecting the tests that should run based on the file changes.

At Tuist, we provide selective testing, which works both with generated projects and vanilla Xcode projects and makes use of our fingerprinting logic that's Git-agnostic and has been battle-tested by many large organizations with complex Xcode projects. The adoption is quite straightforward:

4. Insights

You build or run tests in your Xcode project, Xcode's UI presents you with the result, and that data remains there, in your environment, as if nothing happened, until you accidentally clean it with your deletion of derived data. Things look no different on CI. Your builds run, and the output from your builds is two things: whether it passed or not and xcodebuild's logs, often formatted using formatting tools like xcbeautify. The isolation and ephemeral character of that information prevent the big picture that teams need to answer these questions: Are my builds getting faster or slower? And what about my tests? Is my app growing in size? Are there any new flaky tests? In other ecosystems like the web, collecting, processing, storing, and analyzing data is a common practice. In Apple's, it's not, despite its importance in making informed decisions to improve the development setup.

As for the reasons for this not being that common, I have a few guesses. The first one is that the data exported by Apple's toolchain is very proprietary, which adds an extra level of indirection requiring some processing pipeline before the data can be exported to systems to analyze it. The .xcresult and .xcactivitylog are good examples of that. That was never data designed to be consumed outside of Xcode and therefore lacks documentation and the tools to process it. The second reason I believe is that storing the data requires a database, which in some cases might need to be more than just a standard SQL database—for example, ClickHouse—and a server that can authenticate and authorize access to the database. These are systems that, first, iOS teams don't usually have the familiarity with and the eagerness to build and maintain, and second, struggle to get leadership's support to do. Therefore, they end up with this being a hobby project within the company that often takes the shape of tinkering with Swift in the server environment. It's impressive what teams out there have been able to build, but it's not enough.

For data to be useful, you also need to present it in a way that's useful. You also need to correlate data to derive new useful information. And also build a system such that you can define tripwires and help teams monitor if things don't go as planned. It's a lot. And this is what we are building with Tuist such that the leadership of those companies can outsource that to Tuist and let their engineering resources be focused on building the apps. You can check out our read-only public Tuist dashboard to get a sense of the data that you'd be able to get for your teams. For example, with one scheme post action, you can get build insights in the dashboard, and soon you'll be able to do the same with your test results.

You can continue working blindly, and you might go a long way with it, but without data, you'll have a hard time having conversations with your leadership, especially when times like "I've heard of React Native; what do you think?" come.

5. Derived Data

Who doesn't know derived data? That folder that everyone deletes when compilation fails. The same folder whose deletion leads to a clean build, which can be quite slow in some cases. Derived data proved to be a bad decision whose effects are felt in the long run. A decision that has made many projects in the wild compile not because they are explicitly importing dependencies, but because they can accidentally find them in derived data. Implicit imports can lead to editor features such as macro expansions or Swift previews working unreliably because the editor resolves an invalid graph, causing missing binaries to be absent in derived data for those editor features to work. As crazy as it sounds, it's all rooted in derived data, but we don't talk much about it—not enough, in my opinion. We joke about previews not working or cleaning derived data here and there, but the problem is indeed serious.

The good news is that Apple is aware of it and is working on it through a different approach called content-addressable store (CAS) and explicit modules, which they are gently pushing people toward. So instead of having one shared directory, the build system uses hashes to look up compilation artifacts from previous compilations and uses them instead of invoking the compiler. This works in cases where your project has no implicit dependencies. And here's the thing: rolling out such a system requires Apple not only to introduce explicit modules but also to nudge the ecosystem to adopt them. In my opinion, the push has been too gentle and lacked a bit of the "why it's needed." Perhaps because doing so requires acknowledging a past design decision that led to derived data becoming a problem. I think it's fine. I'd rather see Apple being open and transparent about it and how they are approaching it than discussing it internally and leaving us making the connections between some Xcode features and the reasons why they might be introducing them.

Tuist-generated projects can't prevent implicit dependencies, but the explicitness of declaring dependencies makes them a bit less likely. Because of that, we introduced a command that developers can run against their generated projects to check for implicit imports using static code analysis, and this is something I strongly recommend to everyone.

As I mentioned earlier, my bet is that the reliability of many Xcode features is strongly correlated with the explicitness of the project's graph, so the less implicitness you have, the better. Sadly, this is not evangelized enough, neither by Apple nor by the community, so it often feels like sending messages into the void.

Closing Thoughts

At Tuist, we are building the native platform for scaling Swift app development so that you don't have to. There are problems that are on Apple to solve, and we are excited to see them implicitly acknowledging some of them and throwing some resources at them. And there are other problems that require some awareness first from your side, and this is what we aim to create with these posts, and solutions like Tuist that take some of the burden off your plate such that adopting them is just one line of code in your project, instead of having to maintain a complex system.

These solutions happen to make any agentic coding experience even better, because at the end of the day, any pain experienced by humans will be more annoying through agents. From slow feedback loops in compilations to lack of information to inform the coding sessions. That's why we deem crucial in the platform that we are building explicitness and openness of the data that we are working with such that agents have access to it at any time.

Scaling Swift app development happened to be the challenge we got obsessed with and that we continue to be excited about. If any of the challenges resonated with you and you'd like to share them with us, send us an email at contact@tuist.dev and let's chat. We are here to help any organization out there because we want organizations to be more effective at their missions.

At Tuist, we've been deeply immersed in exploring how AI can transform the Apple development experience. Through continuous experimentation and community collaboration, we're building bridges between cutting-edge AI capabilities and the realities of Swift and Xcode development.

Inspired by Penpot's thoughtful AI whitepaper, this document shares our vision for AI's role in Apple development. We're taking a pragmatic, incremental approach that enhances rather than replaces existing workflows, working with Apple's tools to unlock new possibilities while respecting the platform's unique constraints and opportunities.

Building the foundation for agentic coding

Since Tuist's inception, we've tackled the most frustrating aspects of Apple development—from decoding Xcode's proprietary project formats to revolutionizing build times through intelligent binary caching. These improvements aren't just quality-of-life enhancements; they're essential infrastructure for the AI-powered future of development.

Here's the critical insight: the same pain points that frustrate human developers completely break agentic coding experiences. When an AI agent modifies your SwiftUI view, it needs immediate feedback—not a 5-minute incremental build that might fail mysteriously. When it refactors your networking layer, it needs to verify the changes instantly, not wait for a full app rebuild and simulator launch.

Agents need fast feedback from multiple sources: the build system, running applications, live previews, and more. Some information can be collected because it exists in the system and either the model has learned about it or accesses it through Model Context Protocols (MCPs). However, agents often lack access to crucial information, such as SwiftUI preview trees resolved at runtime or how the build system processes graphs to generate artifacts.

Some improvements remain outside our direct control, such as enhancing framework documentation, minimizing major Swift changes, or Apple decoupling Xcode's layers and providing programmatic APIs for extension. Whether these changes occur likely depends on Apple's willingness to trust their developer community beyond just app creation to include tool enhancement.

The community is actively bridging the gap between agents and official tools. This includes MCPs that expose CRUD APIs for Xcode projects and solutions that approximate hot-reloading workflows by managing xcodebuild and simulator tools. Until underlying tools provide better APIs and documentation, these translations remain essential.

This brings us to our role. As mentioned earlier, shortening feedback loops is crucial, and we believe this should be our primary contribution. Today, this means binary caching based on project generation, but in the future, when caching is built into the build system, we're working toward creating the fastest, lowest-latency cache solution that agents can access regardless of their location.

Imagine an edge-accelerated Xcode build cache that makes compilation virtually instantaneous, regardless of project size or location. We're building the infrastructure that enables both agents and developers to iterate at the speed of thought. Every build generates rich diagnostic data streamed to ClickHouse, providing immediate insights when things go wrong—because agents need to understand failures just as much as successes.

Autonomous QA: Testing at the speed of development

The traditional testing pyramid is being turned upside down. While unit tests remain valuable, the real game-changer is automated acceptance testing—the kind that actually validates user experiences but has historically been too expensive to maintain.

Consider the current reality: a developer submits a PR, waits for CI, gets feedback hours later, context switches are everywhere. Now imagine this: an AI agent reviews your code, spins up a preview, tests it like a real user would, and provides comprehensive feedback—all within minutes of pushing your changes.

Acceptance tests are expensive to develop because they require learning imperative interfaces for UI interaction through accessibility APIs. Moreover, the contract and use case being tested often remain implicit, making tests fragile and difficult to fix when they break. While Xcode 26 reduces the cost of writing these tests, it addresses only part of the challenge.

An alternative is QA testing, but this approach is equally or more expensive. Human testers are costly, and the process doesn't scale effectively. As variability increases, scenarios multiply, and QA teams often end up testing less critical scenarios because they lack business context to prioritize effectively. When issues arise, the diagnostic information they provide is limited—typically written reports and screenshots without logs, network requests, or database and keychain state information. This leads to significant developer time spent on QA interactions.

Consequently, many companies rely solely on unit tests and solid architecture to prevent certain issues, but this approach cannot catch all scenarios. While no solution is perfect, we believe you can approximate comprehensive testing with minimal cost.

We're making this a reality with Tuist QA. Our AI agents don't just run test scripts—they interact with your app like actual users. They understand context from your PR description, explore edge cases based on code changes, and provide detailed reports with screenshots, logs, and actionable insights.

Here's how it works: mention @tuist-qa in your PR, and within minutes, an agent spins up a macOS environment, installs your app, and methodically tests the changes. It reads your QA.md for context, understands your app's architecture, and focuses testing on what matters most.

All the necessary components for agentic QA are already in place: Tuist supports previews for app bundle uploads with commit and branch tracking, and it integrates with GitHub for event-driven actions. Additionally, integration with Namespace is being built for spinning up macOS environments where agents can operate. Early results are promising.

You mention us in a PR, and we respond shortly after with a summary and link to a detailed testing report that includes logs, screenshots, and all necessary diagnostic information. We gather context from PRs and other sources, such as QA.md files.

Instead of developing and maintaining expensive acceptance test suites, you can simply tag us to test work, and we handle the rest.

Instant previews: Share work in seconds, not hours

In an AI-accelerated development cycle, the ability to instantly share and test changes becomes critical. Traditional preview distribution is broken—it takes hours to get a testable build to stakeholders, and by then, the context is lost.

The fundamental problem? Apple's code signing. Current solutions force you to pre-sign apps for specific devices, meaning every new tester requires a pipeline re-run. Enterprise certificates help but come with their own limitations and costs.

We're solving this with on-demand signing. Instead of signing at build time, we sign at install time—specifically for each device. This means:

• Push code, get a preview link immediately
• Anyone in your organization can install with one tap
• Automatic certificate management
• Feedback flows directly back to your PR or Slack

The future we're building: An agent completes a feature, generates a preview, and your entire team is testing it within seconds. Product managers provide feedback that agents immediately incorporate. The development cycle compresses from days to hours.

We'll also build an SDK that collects feedback and forwards it to places where agents can access context, whether Slack channels or GitHub PRs. If we develop an alternative experience for idea ignition, you'll have a "share" button that completes with "here's your link, share it with the world"—because that's how we believe developer experience should work.

Unlocking Apple's black box: Data accessibility for AI

Apple's development ecosystem is notoriously opaque. Build logs are binary, project formats are undocumented, and runtime behavior is largely invisible. This opacity becomes a critical bottleneck when AI agents need to understand what's happening in your codebase.

We're systematically breaking down these barriers:

• Build insights: We parse .xcactivitylog files to extract compilation times, bottlenecks, and failure patterns
• Bundle analysis: Rosalind transforms binary artifacts into queryable schemas
• Test intelligence: Real-time analysis of test execution, flakiness patterns, and coverage gaps
• Runtime telemetry: Capturing and structuring app behavior data for agent consumption

If you've used tools like Claude Code, you've likely noticed it knows how to interface with GitHub CLI to view PR comments and address them. GitHub provides data and makes it accessible through CLI for agent consumption. We're adopting a similar approach, where agents can plan work by examining flaky tests in test suites or optimize project build parallelization by analyzing project graphs and build result data.

As mentioned earlier, since these formats and internal layers are designed to feed upper internal layers rather than external tools that could enhance development experience, Apple may be hesitant to expose them. Opening these systems might enable ecosystem development around alternative coding experiences, as we're seeing with increased Cursor adoption for iOS development. While we believe such openness would be hugely beneficial, Apple's approach continues to evolve in interesting ways that suggest growing openness to developer tool innovation.

From idea to app: Exploring rapid materialization

Every great app starts as a spark of inspiration—a "what if" moment that demands exploration. But the path from idea to working prototype is often where that spark dies, buried under setup complexity, build configurations, and distribution friction.

The industry is attacking this problem from multiple angles. VibeTunnel validated that developers want to continue development remotely or on the go. Meanwhile, tools like Lovable and V0 are presenting hosted, conversational no-code-like solutions that enable rapid prototyping through natural language. But Apple development presents unique challenges: native capabilities are essential, but the platform's controlled distribution creates inherent friction.

We're exploring this frontier with Ignite, our experiment in zero-friction prototyping:

• Instant setup: No Xcode projects, no configurations—just start coding
• Live preview: Changes reflect immediately in your browser
• Develop anywhere: Continue building from any device, anytime, without local setup
• Native bridge: Access platform capabilities without leaving the rapid iteration loop

This isn't about replacing native development—it's about creating the fastest possible path from idea to validation. Once you know something works, our infrastructure helps you graduate to a full native implementation with proper testing, distribution, and all the platform capabilities you need.

Importantly, we're holding to see how this space evolves. The rapid pace of change means what seems promising today might be obsolete tomorrow. We recognize that full agentic coding solutions are massive undertakings better suited to generic players in the space. Our approach is more measured—we're interested in how our specific strengths in caching, build optimization, and the Apple ecosystem can contribute to lowering the barriers to idea exploration.

Some of this work is already happening through our existing infrastructure. Our binary caching reduces build times, our preview system enables rapid sharing, and our data accessibility efforts provide the context agents need. Each improvement reduces the incremental cost of exploration, which increases our appetite to continue investing in this direction—but always with a focus on what uniquely benefits Apple developers.

The journey ahead

What dominates discussions today may be obsolete tomorrow. The pace of change in this space is extraordinary, which is why we approach these ideas with an exploratory mindset, discussing and refining them weekly as a team. We remain open-minded in some areas while focusing our energy where we see solid opportunities, like Tuist QA.

Moreover, some problems like coding can be well-addressed by generic solutions like Claude Code that have learned Swift and can interface with external systems through MCPs. However, other challenges benefit from vertical solutions built upon existing platforms, specifically designed for app development and requiring ecosystem knowledge and expertise—which we've developed over years of building tools for Xcode and Swift.

We'll focus on areas where we can bring exceptional value within our vertical—value that organizations can perceive instantly and that wouldn't make economic sense for generic solutions to pursue. Our strong understanding of Apple's ecosystem, combined with years of solving developer pain points, positions us to deliver specialized solutions that generic tools simply can't justify building.

We built Tuist to help teams and developers address existing challenges, but also to explore ideas that make development more enjoyable and accessible to everyone. We want more people building more apps for the Apple ecosystem.

Get involved: If you're intrigued by any of these ideas or would like to try the experiences we're building, we'd love to hear from you. Reach out to us at contact@tuist.dev or join the conversation in our community. The future of Apple development is being written now, and we believe it's better when we write it together.

But while the majority of teams using Tuist are building an iOS app, we haven't had an opportunity to build and integrate with this platform, until now.

We're really excited to announce that Tuist is now available on the App Store. We're starting with streamlining accessing and running Tuist Previews, but we have more in store for the future.

Delivering a high-quality iOS app is not easy. To ensure the best experience for your users, you need to test apps often, otherwise, bugs will inevitably creep in. And the best time to test a new feature is still in the PR stage. Instead of checking out a branch and compiling the changes, a time-consuming process, teams often fully re-test the new changes from a nightly build. But at that point, it's really difficult to pinpoint when a regression was introduced.

Tuist Previews aim to solve this problem by providing an extremely easy way to test your app. What started as a CLI command to share apps via links has evolved into a comprehensive ecosystem of tools that bring testing closer to where development and QA teams actually work. We've already made installing previews on macOS as easy as clicking a button with our menu bar app. Now, we're taking the same step on iOS with our Tuist app, creating a unified experience across Apple's platforms.

Tuist app features

In the Tuist app, you can see the latest previews for your projects – and you can tap on any preview to see it in detail, such as to see who created the preview or which commit it's related to. In both the list of previews and the detail view, there's a "Run" button that allows you to run the preview directly on your device.

Additionally, clicking on any preview link – or scanning a QR code – will open the preview in the Tuist app:

To see the app in action, you can also watch the following video:

Native developer experiences for native engineers

While the app is currently laser-focused on previews, the app is also a foundation block for us to build more native features for Tuist. Imagine triggering a release build or running a QA agent directly from your phone – and having a live activity that tracks the progress. These kinds of native developer experiences have been missing from the iOS ecosystem and we hope to fill in the gap.

Let us know your feedback over at our community forum or Slack. And since the app is fully open-source and written in SwiftUI, this might be the perfect opportunity for you to get involved with open source if you'd like to improve the app yourself.

Steve Jobs said that computers are bicycles for the mind. I think programming languages are too. They are tools for expression, to be creative.

At Tuist, we've been huge fans of Swift, the most common programming language of the ecosystem we build for. Yet, we always remained open to finding the right programming language or technology that would allow us to express what we wanted to express.

Through Swift, we could express ourselves in terminals. We built Tuist's main CLI and filled some gaps with other open source tools like Noora. Through VitePress, a JavaScript-based solution, we could build a documentation website for our community with built-in search, llm.txt generation, in multiple languages. And then the time to build a server came, and with it the decision to choose the best expression tool.

We needed a solution that allowed us to build and maintain a powerful and simple solution with as few resources as possible. Primarily because we were limited in budget, but also because simpler software is easier to reason about and evolve.

At the time, we had come across Elixir and immediately felt it was the right tool to express ourselves in a new domain: the web. We discovered patterns and approaches that we absolutely fell in love with—patterns that we believe could inspire and enhance Swift's evolution, especially as it continues to grow beyond Apple platforms.

In this post, we'll walk you through what made us fall in love with Elixir, the incredible developer experience it provides, and the patterns we'd love to see influence Swift's future.

Erlang and Processes

We can't understand Elixir without talking about Erlang. Erlang is a programming language and runtime created at Ericsson in the 1980s to power their telecommunication networks. It was designed to build highly-concurrent, scalable, and fault-tolerant software. Sounds familiar? These needs are common across the modern web applications that we build today. Erlang comprises a runtime (BEAM), a programming language (Erlang), and a set of primitives to architect your apps (OTP - Open Telecom Platform). At the core of Erlang sits the idea of processes upon which almost everything builds. Joe Armstrong captured what led him to processes in his thesis. He refers to it as Concurrency Oriented Programming:

The word concurrency refers to sets of events which happen simultaneously. The real world is concurrent, and consists of a large number of events many of which happen simultaneously. At an atomic level our bodies are made up of atoms, and molecules, in simultaneous motion. At a macroscopic level the universe is populated with galaxies of stars in simultaneous motion.

When we perform a simple action, like driving a car along a freeway, we are aware of the fact that there may be several hundreds of cars within our immediate environment, yet we are able to perform the complex task of driving a car, and avoiding all these potential hazards without even thinking about it. In the real world sequential activities are a rarity. As we walk down the street we would be very surprised to find only one thing happening, we expect to encounter many simultaneous events.

If we did not have the ability to analyze and predict the outcome of many simultaneous events we would live in great danger, and tasks like driving a car would be impossible. The fact that we can do things which require processing massive amounts of parallel information suggests that we are equipped with perceptual mechanisms which allow us to intuitively understand concurrency without consciously thinking about it.

When it comes to computer programming things suddenly become inverted. Programming a sequential chain of activities is viewed the norm, and in some sense is thought of as being easy, whereas programming collections of concurrent activities is avoided as much as possible, and is generally perceived as being difficult.

I believe that this is due to the poor support which is provided for concurrency in virtually all conventional programming languages. The vast majority of programming languages are essentially sequential; any concurrency in the language is provided by the underlying operating system, and not by the programming language.

So the world (and agentic software) is made of concurrent processes that communicate with each other by passing messages. When I read that, I was fascinated. I had never stopped to see the world that way, but I was hooked by the idea.

Processes in Erlang are lightweight and CPU/memory-isolated runtime elements that can communicate by passing messages and form more complex structures holding state, build supervised trees, define error boundaries, and work across environments (among others). This might sound too abstract at this point, but throughout the blog post I'll make it more concrete with examples of how this materializes.

Parallelism

Modern CPU architecture comprises multiple cores, which presents programming languages with the challenge of using them in the most efficient way possible. Every programming language solves this problem differently, each with its own approach and philosophy.

Swift has introduced a novel approach with its structured concurrency model. Apple continues to iterate on this model to make concurrent programming safer and more intuitive. The introduction of async/await, actors, and task groups represents a thoughtful evolution in how we think about concurrent code. What's particularly exciting is seeing Swift adopt the actor model—a concept that has proven itself in distributed systems for decades.

Erlang's process-based mental model resonated particularly well with us. The idea that you can write concurrent code without constantly thinking about concurrency felt magical. Processes are isolated by default, communicate through message passing, and the runtime handles the scheduling across available cores. This approach means you can focus on solving your problem rather than managing concurrency primitives.

But what truly captured our imagination was how Erlang takes actors beyond just a concurrency model and makes them an architectural foundation. Tools like GenServer (Generic Server) provide a standard way to implement stateful processes with clean APIs, while Supervisors create hierarchical structures that define how your system starts, stops, and recovers from failures.

We'd love to see Apple explore expanding actors from a concurrency primitive to a fuller architectural pattern. Imagine Swift actors that could:

• Define standard patterns for stateful services (like GenServer)
• Build supervision trees that handle failure and recovery
• Provide built-in patterns for common architectural needs

Swift's actor model already provides excellent isolation and state management. Taking inspiration from Erlang's OTP (Open Telecom Platform), Swift could evolve to offer similar architectural patterns that make building resilient, distributed systems as natural as building a single-threaded application. The foundation is there—Swift's actors are already a powerful abstraction. The opportunity lies in building the architectural patterns on top.

Welcome Elixir

How does Elixir connect to all of this, you might wonder? José Valim, creator of Elixir, came from the Ruby & Ruby on Rails community motivated by making Ruby use all the CPU cores available. He came across Erlang and fell in love with its principles and foundation, but he realized that the language, the toolchain, and the ecosystem could benefit from modernization. He decided to build Elixir, a programming language that compiles to Erlang bytecode to run in the Erlang runtime. So in other words, Erlang and Elixir are two programming languages that compile to run on the Erlang VM. As you can imagine, the language draws a lot of inspiration from Ruby, and in many ways, it feels like writing Ruby but with a more functional touch to it. If you've used SwiftPM or Cargo (Rust), the developer experience is similar. You have a build system, mix, which takes care of managing your dependencies, building the project, spawning the test runner, or formatting the code, among others.

So with Elixir, you get the power and the simplicity of a battle-tested runtime (Erlang's) with a modern toolchain, language, and ecosystem that makes building for Erlang a true joy.

Tuist Meets Elixir

Having talked about Elixir, Erlang, and processes, it's time to talk about the patterns and experiences we discovered that we'd love to see inspire Swift's evolution. Note that some of the value that I'll touch on is a shared responsibility between Elixir as a programming language and Erlang as a runtime and framework, but I'll refer to it as just Elixir value. Let's dive into some day-to-day real impacts on how we are building Tuist.

A Build System That Doesn't Get in Your Way

The Elixir build system is absolutely amazing and represents a pinnacle of developer experience. Like any other build system, it'll take some time initially to build your project (i.e., clean build), but once it's built, it magically hot-reloads your changes, making the feedback loops incredibly short. Is there a bug in one of the web app routes? I change one line of code, and the change is picked up automatically. This developer experience has spoiled us—the ability to see changes instantly keeps the creative momentum going.

Additionally, because Elixir is functional, the reconciliation of the changes at runtime leads to expected results. The build system feels invisible in the best possible way—it's there when you need it but never gets in your way.

Swift has taken the first steps to unify the build system across SwiftPM and Xcode, and we're optimistic that it'll reach a similar level of developer experience that spans across layers. The potential for Swift to adopt hot-reloading capabilities, especially for server development, would be transformative. Imagine the productivity gains if Swift developers could experience the same instant feedback loops we enjoy with Elixir.

Read-Eval-Print Loop

Being able to open a console with access to your codebase symbols and the history of executed instructions can make a huge productivity difference in development. For example, locally we can just do the following to debug a particular organization:

One could say that you can come up with a similar query yourself with the help of an LLM, but if we are talking about a function that encapsulates more business logic, then things get trickier. You are forced to either write an entry point to that piece of logic when all you want is to iterate on a new idea that you came up with. The console is also able to hot-reload changes automatically for you, so you can keep typing, always assuming you'll be using the latest version of your code.

This tool can also be used in production, but we use it sparingly only in very exceptional cases and with read-only operations.

Server-Driven Interactive UI

I talked a lot about processes earlier, and if there's a good example of how cool they are, we need to talk about Phoenix LiveView. Phoenix is the Ruby on Rails of Elixir. It's the web framework that most Elixir projects use to build web apps. When it comes to doing UI, Phoenix proposes a quite unique model, LiveView, which allows us to build dynamic UIs without having to worry about managing API-provided client-side state or dealing with the cost of a JavaScript runtime setup (and its ecosystem).

Phoenix LiveView's model is absolutely brilliant. When you open a page, a process is created and bound to your connection, with a state that's then mapped to HTML that's presented in your browser. Since the state is on the server, you don't need to deal with syncing state between client and server. Any action that requires UI change is sent to the server, the new state is calculated, mapped to a new representation, and Phoenix LiveView takes care of sending the diff to the client. In our particular context, having a single source of truth for UI state was crucial, and LiveView delivered this beautifully.

The Swift community is pushing Swift to new environments like the browser using WebAssembly, and we can't wait to see the answer the community comes up with to build dynamic UIs. Perhaps we'll see Swift-native solutions that bring similar server-driven UI capabilities, combining Swift's type safety with real-time reactivity.

For example, our preview page uses LiveView. You'll notice that we fetch the state, assign it to the socket connection, and then use it in the template. Because templates are compiled, the runtime has all the information it needs to optimize the diff that's sent to the client. The mental model is refreshingly simple yet powerful.

Real-Time UI

People are expecting more and more UIs to update in real-time as new data comes in. In the context of Tuist, we'll have a lot of things happening, from a new build that's pushing logs to our server, to a preview that's being built to be shared with other users.

Phoenix provides PubSub, whose default adapter leverages Erlang capabilities to discover and distribute messages across nodes. Let's say you are seeing the builds page, and a new build comes in. Erlang could receive a message saying that a new build has been created, and we can have LiveViews subscribed to those events updating their internal state accordingly and sending the diffs to the client.

Swift's distributed actors model draws a lot of inspiration from similar actor-based systems, and we believe it could be a great foundation to build real-time applications in Swift too. The conceptual similarities between Erlang's processes and Swift's actors suggest that Swift could evolve to provide similar built-in real-time capabilities.

This capability of Erlang is so powerful that companies like Discord and WhatsApp have built their infrastructure on it. At Tuist, we're investing more in making our features real-time, and this foundation also enables collaborative features where multiple people can interact with the same state—think of experiences like Figma.

Ease of Scaling

We are a small team, so it's important that as the need for scaling comes, we don't need to invest many resources into it. Both Swift and Elixir excel in this area—they're languages designed to scale elegantly.

With Elixir, we can build powerful solutions like real-time capabilities and collaborative experiences without complex setup. Most of our surfaces are a database schema, a small piece of business logic in between, and a LiveView. The simplicity is refreshing.

Testing is another area where scalability matters. Every test in Elixir is a different process, scheduled to run in parallel. If you want to run your test suite faster, you can throw more CPU cores at the problem. But what's particularly elegant is how Elixir's functional nature encourages writing tests that are naturally isolated. Since most of the time you're testing pure functions that take inputs and return outputs, there's little opportunity for shared state to cause flakiness. When you do need stateful processes in tests, you can spawn them in isolation.

This got us thinking about how powerful it would be if foundation APIs were designed with this principle in mind—actively discouraging global state that might leak across concurrent tests. Swift already has tools like TaskLocal that could play a role in scoping state to tests, but we don't see this being actively promoted as a pattern the community should adopt for test isolation. Imagine if Swift's testing frameworks and foundation libraries were architected to make the isolated approach the path of least resistance, with clear patterns and best practices for state isolation. The functional model guides this good behavior in Elixir, but similar outcomes could be achieved through thoughtful API design and community conventions that make shared mutable state difficult to accidentally introduce.

In Elixir, you can even define mocks scoped to each test's process tree, ensuring complete isolation. This pattern—where the foundation actively guides you toward scalable, flake-free testing—is something we'd love to see more broadly adopted.

In production, Elixir's concurrent nature allows scaling vertically by simply adding more memory and CPU. Erlang's scheduler ensures those resources are used optimally. We run our app on Fly.io, which makes it trivial to add machines in different regions to reduce latency for global users.

The beauty of both Swift and Elixir is that they make scaling feel natural rather than an afterthought. Swift's performance characteristics and Elixir's concurrency model are different approaches to the same goal: building systems that grow with your needs.

The Ecosystem

When comparing ecosystems, it's important to acknowledge that it's not quite a fair comparison—Erlang has been battle-tested in production since the 1980s, giving it decades to mature and develop specialized solutions. The Elixir ecosystem benefits from this foundation, with focused, well-established libraries for most server-side needs.

Swift's server ecosystem, by contrast, is young and vibrant. What excites us is the momentum we're seeing—more companies are investing in Swift on the server, bringing fresh perspectives and innovative solutions. The community's energy around pushing Swift beyond Apple platforms is palpable, and we're optimistic that this ecosystem will become increasingly diverse and robust.

For our current needs, we found everything required in the Elixir ecosystem. When we added ClickHouse to our infrastructure, Plausible had already built an adapter. When we needed OpenID Connect, Boruta was ready to go. This maturity meant we could focus on building rather than filling gaps.

But we're watching Swift's server ecosystem with great interest. As more teams adopt Swift on the server and share their solutions, we expect to see similar depth emerge. The quality of what's already available—from web frameworks to database drivers—shows that Swift's server future is bright. In a few years, we believe Swift developers will enjoy the same rich ecosystem that makes Elixir development so productive today.

The excellent documentation quality across the Elixir ecosystem has been crucial for our productivity, especially in an age of AI-assisted development. This is something the Swift community has always excelled at, and we're confident this tradition will continue as the server ecosystem grows.

Trade-offs and What We Miss

Choosing Elixir meant accepting certain trade-offs, and there are definitely things we miss from the Swift world:

Shared code between CLI and server: One of the most significant trade-offs is not being able to share models and business logic between our Swift CLI and Elixir server. In an all-Swift setup, we could have a single source of truth for our domain models, reducing duplication and potential inconsistencies.

Memory control for resource-intensive tasks: While Elixir excels at concurrent I/O-bound operations, Swift's more direct memory control would be advantageous for potential future resource-intensive tasks. If we ever need to do heavy computational work, Swift's performance characteristics would be ideal.

Compile-time guarantees: Swift's compiler catches entire categories of errors through static type checking. While Elixir's dynamic nature enables certain patterns like hot-reloading, we do miss the confidence that comes from Swift's type system, especially during large refactorings.

These are genuine trade-offs that we considered carefully. For our current needs—building a real-time, collaborative platform—Elixir's benefits outweighed these costs, but we remain excited about Swift's evolution in the server space.

Closing Words

In hindsight, Elixir was the right bicycle for the job of building the Tuist platform today. Our 4-person team feels incredibly productive, and the patterns we've discovered—from hot-reloading to server-driven UI to built-in real-time capabilities—have shaped how we think about building software.

But we're equally excited about Swift's future. As Swift continues to evolve beyond Apple platforms, we hope to see it adopt some of the patterns that make Elixir such a joy to work with. Imagine Swift with hot-reloading, built-in real-time primitives, or Phoenix LiveView-style server-driven UI capabilities. The combination of Swift's type safety and performance with Elixir's developer experience would be incredible.

We're keeping a close eye on Swift's evolution, and who knows? As the ecosystem matures and new capabilities emerge, we might revisit this decision in the future. For now, we're grateful for what both languages bring to the table and excited to see how they'll continue to inspire each other.

Thank you to both José Valim and the Elixir community, and to Chris Lattner and the Swift community, for gifting us with such wonderful tools for expression.

Grammar corrections provided by Claude Opus 4.

Unfortunately, we couldn’t open everything in the early days of the company because we hadn’t figured out where we could capture value. This left us with an itch. We knew this would be temporary and that we’d figure out a path back to openness, so I’m thrilled to announce that the Tuist Server is now source available.

Why we’re opening the source code

We love working with the community. Openness eliminates barriers and makes you more accountable, leading to a much better product. When you’re building in the open, every decision gets scrutinized, every bug gets reported, and every feature request comes with real use cases attached. If we want to build the best virtual platform team for mobile developers, this is the way.

We see building an open company as a long-term game. While closed source code combined with capital can give you an initial advantage and help you move fast in the short term, the momentum a project can build over time with its community is absolutely unbeatable. There’s no better example than Microsoft’s strategic investments in VSCode and TypeScript that have fundamentally shaped how developers work today. Our role models are companies like GitLab, Grafana, and Supabase, who’ve proven that you can build sustainable businesses while staying true to open principles. We aim to take a similar role in the mobile development space.

The mobile development ecosystem desperately needs this kind of openness. For too long, we’ve been stuck with proprietary tooling that doesn’t evolve fast enough or address the real pain points developers face daily. By opening our source, we’re creating transparency around our technical decisions and making ourselves more accountable to the community we serve.

Capturing value to fund development

But here’s the reality: you need to fund development. In other words, you need to capture some of the value you produce, or the project will eventually stagnate like so many promising open source initiatives we’ve seen over the years. I really enjoyed this talk from Penpot, where they emphasized that open source captures less value than proprietary versions, but it’s also true that the ability to produce value in open source is much higher because of the transparency and community trust it builds.

This is where many open source projects fail—they focus so much on being “free” that they forget sustainability. We’ve seen countless projects start with massive enthusiasm, only to fade away because the maintainers burned out or couldn’t afford to keep working on them. We refuse to let that happen to Tuist. Our commitment is to continue investing heavily in the development of Tuist with our full-time team, ensuring consistent progress and innovation.

So how do you capture value responsibly? Every company decides on the model that aligns best with their mission and capabilities. Some organizations prefer focusing on services, for example by offering premium support, educational material, or hosting as a service. Others prefer capturing value through product innovation, so they embrace a licensing model that allows them to draw clear lines around what’s free and what’s paid. Many successful companies do a thoughtful mix of both approaches.

At Tuist, we realized early on that what energizes us most is building product rather than providing services. We’re engineers at heart—we love solving complex technical problems and creating tools that make developers’ lives better. We used this self-awareness as our guiding principle to find our model.

Finding our model

Early on, we naively suffered from the free-rider problem. At the time, we thought developers would naturally pay for hosting the server or use our hosted instance, but the ease of self-hosting for both us and other companies—which could potentially put Tuist at competitive risk—turned out not to be a sustainable approach. So we bought ourselves some time and space to figure out the right model by developing some pieces as closed source. We knew this would be temporary until we could better understand our customers and their willingness to pay for value.

Thanks to that strategic pause, we’re now steadily capturing part of the market and understanding our customers much better, which allows us to start reverting the closing of some components. At the same time, hosting and maintaining an instance of Tuist is becoming increasingly complex—not because we made it intentionally difficult, but because it’s the natural result of solving more sophisticated problems that our enterprise customers face. Still, this complexity alone isn’t enough motivation for many organizations to pay us for hosting. We needed to find a step in between full open source and completely closed.

The challenge was finding a model that would let us be as open as possible while still ensuring we could sustain and grow the team working on Tuist. We didn’t want to fall into the trap of either giving everything away for free (and risking project stagnation) or being so restrictive that we lost the community benefits of openness.

Fair Core License

We then discovered fair source licenses, which aren’t traditional open source licenses but provide a compelling middle ground. One of the largest promoters of this approach is Sentry, and their success gave us confidence in the model. Fair licenses buy you crucial time by preventing the free ride issue while committing to defer open source by 2 years since the code has been contributed. This sounded like exactly what we needed—protection from free riding that allows us to focus on building the best product we can imagine, while creating software that will eventually be available under an OSI-approved license.

The beauty of this approach is that it aligns incentives properly. Companies that want to use Tuist Server commercially either pay us (supporting continued development) or wait two years and use it for free (by which time we’ve moved on to newer innovations). It’s a fair trade that respects both our need to capture value and the community’s expectation of eventual openness.

So today, the server has joined the tuist/tuist monorepo under the Fair Core License. Of all the fair licenses available, FCL also gives us the flexibility to place some features behind a paid license, which is crucial in our current phase where we don’t have many features that are directly monetizable yet. While the line we’ve drawn might seem strict today, our plan is to progressively lift restrictions as we develop more enterprise-focused features, until we can have distinct community and enterprise versions—or who knows, maybe infrastructure hosting is where we’ll capture most of our value, at which point we might embrace Sentry’s simpler license and offer all features as long as you don’t try to compete directly with us.

It’s a fluid model

We see FCL as an intermediate step in our journey, not a final destination. As the project matures and the needs of our users continue to evolve, we’ll regularly reassess opportunities to revisit and relax the license terms. For example, if we develop more sophisticated enterprise features—think advanced analytics, compliance tools, or enterprise integrations—we could adjust where we draw the line between free and paid. If we discover we can capture more value from the infrastructure and hosting side, we could potentially lift the licensing restrictions entirely and focus on our cloud offering, which we’re uniquely positioned to excel at since we developed the underlying software ourselves.

And who knows—if the mobile development market grows large enough and our business model proves sustainable, we could even eliminate the deferred open sourcing requirement entirely. But this is very far into the future. The model could eventually look similar to GitLab’s successful open core approach, where there’s a clear distinction between community and enterprise features.

The key is staying flexible and responsive to what our community and customers actually need, rather than getting locked into a rigid ideological position about licensing.

What changes for me?

I imagine many of you are wondering what this actually means for your day-to-day work with Tuist. The short answer is: probably not much. Let me break this down.

If you're a developer who loves contributing to open source projects, the Tuist CLI and all our core tooling remains exactly as it was—MIT licensed and completely open for contributions. You can continue submitting PRs, reporting issues, and helping shape the future of mobile development tooling without any additional friction. The server components now require a simple contributor agreement, but we've designed this process to be as straightforward as possible because we genuinely want your contributions.

For organizations evaluating Tuist, you can run the server locally for development and testing purposes. The source code is publicly available, you can inspect every line, and modify it for your needs. However, if you want to deploy it in your production infrastructure, you'll need to obtain a license from us to legally use it in that capacity. This licensing approach ensures we can continue investing in the platform while still maintaining transparency around our technical decisions.

If managing that infrastructure sounds overwhelming (and for many teams, it absolutely should), our hosted service remains the easiest path forward. We handle all the complexity while you focus on building great apps. This is where we capture value to fund continued development, and it's a model that's worked well for companies like GitHub, GitLab, and countless others in the developer tools space.

Closing thoughts

When you make a tool part of your development stack, you're placing tremendous trust in us to support your journey, and we've always felt deeply responsible for honoring that trust with an unwavering commitment to always be there for you. We focused on building a source of revenue so our passionate team could focus on Tuist full time without worrying about sustainability. We then announced our longevity commitment, which legally ensures that regardless of what happens to Tuist as a company, your projects and workflows won't get disrupted. We embraced a transparent pricing model and product design that actively fought against predatory enterprise practices like "contact sales" gatekeeping or feature-limited demo products that were unfortunately becoming the norm in our space.

We’ll continue open sourcing and gifting valuable projects to the community, like XcodeProj, Noora, Rosalind, and XcodeGraph—and who knows, maybe even the server itself will be fully open source in the future as our business model continues to evolve.

Tuist aims to be your virtual platform team for building incredible apps, and we believe this ambitious goal is only possible if we become more open and collaborative, not less. The future of mobile development is too important to build behind closed doors, and we’re committed to leading by example with the resources and dedication this vision deserves.​​​​​​​​​​​​​​​​

Between PR Opening and Merge

If you think of traditional workflows in Swift app development, which closely mirror workflows in other technologies, once a PR is opened, two main things happen. First, your peers review the code to ensure it's correct. Second, you trigger one or multiple CI jobs that run automated checks against your changes. If both give the green light, you merge the PR.

Whether through Tuist's optimizations like binary caching or selective testing, or in the near future with swift-build optimizations, combined with the decreasing cost of Mac infrastructure, the financial and time cost of running automated checks will become minimal. In other words, you'll get CI results in minutes or even seconds. This sounds idealistic, but in the world of agents, where fast feedback is crucial, we believe this will become reality.

What does this mean? If you automate code review using AI tools like Claude Code or GitHub Copilot, which analyze code patterns and best practices, what remains is ensuring that the changes do what they're supposed to do. This requires compiling, launching, and using the app— and this is where Tuist Previews become essential.

Previews: A Tool to Manually Test Your Changes

When we introduced previews, we drew inspiration from platforms like Vercel, Cloudflare, and Netlify, where you get an ephemeral environment accessible via URL to see your changes live. We also took cues from Shopify's "tophat" culture, where developers are required to test changes as part of reviewing PRs. We loved this concept and brought it to the mobile app world through Tuist.

For previews to succeed, they need to be available no slower than the longest wait between CI checks or review approvals. Let's say both happen in under 5 minutes. If your preview takes 10 minutes to build, authors will likely merge without peers manually testing the changes. That's why we're heavily invested in cutting build times so that preview generation is comparable to CI check times, while also reducing the costs of creating previews (since CI typically charges per build minute).

The second crucial piece is ensuring previews are seamless to run. We designed them to be URL-centric. When someone shares a URL with you, you should be able to install the preview just by tapping the URL, or pasting it in the terminal if you have the CLI installed. And if the app supports physical devices and your device ID is in the signing certificate, you can install it on your device too.

Many people compare previews with nightly builds because, as I pointed out in Building a Business Around Tuist, people iterate on their mental models gradually. Both nightly builds and previews are tools to build and share apps. The difference is that while nightly builds are distant in time and space from code changes—making it difficult to correlate feedback with changes—previews are immediate. They happen right at the PR level, where feedback can be provided in context and easily addressed. Compare this to getting a Slack message days later saying, "Hey, I found something in build 233." Finding the PR that introduced the issue becomes increasingly difficult as merge throughput increases.

If you haven't tried previews yet, it's remarkably simple. Build your project with xcodebuild, Fastlane, or your tool of choice, then run one command to share the app:

The metadata necessary to correlate the preview with the Git forge is automatically collected. In other words, Tuist knows which PR the preview belongs to.

Time for Feedback

Getting previews into people's hands is just half the equation. We're actively working to eliminate friction through features like on-the-fly signing and bringing the experience to the web so you don't need simulators or even Apple devices. But there's more we can—and will—do. The natural next step after testing an app is reporting feedback, and this closes the development loop.

This is where things get truly exciting. Imagine you're using a preview and discover an issue. Wouldn't it be powerful if the preview provided built-in tools to report that feedback? What if that feedback automatically included contextual information to help developers understand the issue? For example: redacted traces of server requests, user navigation paths through the app, logs, or even a recording of the last few minutes leading to the issue.

These are just examples, but you get the idea. We're exploring the development of a Tuist Development SDK that integrates into your app's development builds, closing the loop with a feedback tool that seamlessly integrates with previews and the AI-powered coding world that's taking shape.

What If You Could Automate the Feedback Process Too?

Here's where we get truly forward-thinking. Having built infrastructure to distribute previews, feedback building blocks, and the Tuist SDK, we have all the ingredients for something transformative:

• Push your changes
• Get CI and AI feedback about your code
• Get AI feedback about your app's runtime behavior

Wouldn't that be revolutionary? We know the web is already moving in this direction, and we're eager to bring the same experience to app developers. We're doubling down on previews because we believe they can unlock a world of possibilities in this new era that's unfolding before us.

The future of app development is being written right now, and we're thrilled to be part of shaping it. With curiosity as our compass and innovation as our engine, we're building the tools that will make tomorrow's development workflows feel like magic compared to today's.

You can start using previews today with Xcode projects or generated Tuist projects.

I'll be candid: we've seriously considered entering the CI space ourselves to provide Tuist users with a premium, reliable solution. However, the deeper we analyzed this domain, the clearer it became that the industry is experiencing a fundamental transformation. We're witnessing the emergence of a new paradigm—one where Tuist is strategically positioned to operate at a higher abstraction layer above this evolving landscape.

Understanding the CI Stack

From a user's perspective, CI appears straightforward: a service integrated with your repository that executes workflows triggered by specific actions (typically repository events like code pushes) and delivers results through logs, artifacts, and status updates. However, if we deconstruct CI into its fundamental layers, we discover three distinct components, starting from the foundation:

• Infrastructure Layer: The bedrock requiring physical hardware and virtualization technology to run tasks in isolation. Apple's ecosystem adds unique complexity here—most tasks require Apple hardware running macOS, creating scarcity since few cloud providers offer managed Apple infrastructure.

• Orchestration Layer: The middleware connecting infrastructure to Git platforms like GitHub, triggering workflows based on repository events. This layer manages pipeline execution, defining the sequence and logic of tasks within each workflow.

• User Interface Layer: The customer-facing experience for workflow management, providing real-time execution feedback, manual triggers, and analytical insights (such as average execution times and success rates).

While you might not have previously considered these architectural details, this layered approach fundamentally defines how CI systems operate.

The Mobile DevOps Movement

Several years ago, I encountered the term "Mobile DevOps" and found myself puzzled. My initial reaction was: "Isn't Mobile DevOps essentially just Fastlane?" I questioned why this concept was suddenly gaining traction and what was driving its emergence. Initially, the movement seemed unclear, but as I gained deeper industry insights, I recognized this as a strategic evolution aimed at expanding the addressable market. In business terms, companies were seeking to grow beyond traditional CI boundaries to capture larger market opportunities.

DevOps makes intuitive sense in backend engineering, where teams manage production infrastructure and orchestrate complex deployments. This need spawned an entire ecosystem: foundations, open-source tools like Kubernetes, and specialized conferences. However, mobile development operates differently. Developers spend most of their time in Xcode, while CI workflows typically focus on building, testing, releasing, and linting code. For years, Fastlane successfully abstracted these needs and cultivated a thriving ecosystem around them.

Yet the appetite for capturing this value persisted. Companies invested heavily in proprietary solutions designed to create ecosystem lock-in and cross-sell additional products. We've seen everything from proprietary pipeline formats to visual pipeline editors, to custom step ecosystems that—lacking community contribution incentives—quickly became outdated. Today's landscape includes release automation, test analytics, caching solutions, and more—all under the Mobile DevOps umbrella. However, for many practitioners, these remain fundamentally CI companies, which creates both opportunities and challenges due to entrenched mental models.

It's worth noting that many providers outsource infrastructure and virtualization to third parties, avoiding hardware management complexities. While this simplifies operations, it significantly impacts margins, making orchestration and UI the primary value-capture layers for most providers.

The runs-on Revolution

GitHub fundamentally disrupted the market years ago, with other platforms like GitLab and Forgejo following suit. Their decision wasn't merely to become CI providers—they opened up the architectural layers, enabling users to bring their own infrastructure or leverage specialized third-party providers.

This shift has profound implications that deserve more discussion. GitHub Actions (and equivalents on other platforms) offers tight UI integration that external CI providers simply cannot match. Third-party providers are constrained by available APIs, primarily limited to updating commit statuses and adding code annotations. Meanwhile, GitHub can ship features like declarative permissions, dynamically generating workflow-scoped tokens with precise permission boundaries.

The GitHub Actions ecosystem represents another strategic advantage. Initially, I assumed it was proprietary, but using Forgejo via Codeberg revealed that their CI solution supports GitHub Actions composition. Fundamentally, these are Node.js/JavaScript functions with configuration files declaring action behavior. GitHub's unique position allows them to incentivize developer contributions through a simple mental model: build an action, host it in a repository, and enhance your developer profile. This ecosystem effect is difficult to replicate. I'm curious to see how Dagger's attempt to decouple actions from CI providers evolves, though their Docker-centric approach may face challenges with Apple's macOS and hardware requirements.

This new model birthed a different category of companies—those focused exclusively on providing the fastest, most reliable infrastructure for CI needs. At Tuist, we recently adopted Namespace for our CI requirements and will soon leverage it for product features requiring ephemeral macOS environments. The setup process is remarkably simple: install a GitHub app and update the runs-on attribute in your workflow files.

The runs-on attribute represents one of the most elegant narrow waists I've encountered recently. With a single line change, you can switch infrastructure providers within GitHub Actions. This benefits users by creating competitive pressure on runner providers to deliver superior service or risk losing customers. This stands in stark contrast to the traditional model where organizations found themselves trapped, facing days or weeks of migration effort that often resulted in vendor lock-in and price exploitation. Technology should prioritize user and organizational needs—not vendor profits.

A Market in Transition

The comprehensive mobile CI solution market is experiencing a gradual decline. The transition's pace depends on infrastructure providers' ability to effectively market themselves within new ecosystems like mobile development. Additionally, this mental model shift—where teams return to GitHub Actions while paying only for infrastructure usage—will take time to permeate the industry. This approach isn't just superior; it's typically more cost-effective than traditional models where companies operate with constrained margins.

I've written previously about the importance of owning your automation, and it bears repeating. While vendor lock-in is inevitable to some degree—even excellent developer experience creates switching costs—it exists on a spectrum. When companies recognize market decline without innovation capabilities (hello, innovator's dilemma), desperate attempts to increase lock-in often follow. Stay vigilant and maintain ownership of your automation. A key indicator of automation ownership is pipeline simplicity. Tools like Mise enable predictable environment provisioning, while Fastlane or even bash scripts can handle automation logic. This agency is crucial in a rapidly evolving space, particularly as the infrastructure-as-a-service market accelerates. More providers will enter, prices will continue declining, and service quality will improve. If you're skeptical, I encourage you to explore Namespace's dashboard.

An Emerging Landscape

This transformation naturally drives mobile CI companies to reinvent themselves through concepts like Mobile DevOps—evident in their expansion beyond traditional CI offerings. Suddenly, we find ourselves in a more competitive landscape, which I believe benefits the entire mobile ecosystem. The CI space had grown stagnant: everything revolved around pipelines, providers monopolized affordable macOS environments, and innovation stalled around familiar concepts (YAML pipelines, nightly releases, CI-driven deployments). The industry craves innovation, especially given the revolutionary changes in AI and agentic coding experiences.

Every company is placing strategic bets on this emerging landscape. Some maintain narrow focus—perhaps on release management or launch time optimization. We initially maintained a narrow focus too, but we're gradually expanding for one compelling reason: AI is dramatically reducing software production costs and democratizing development. Yet current workflows often require indirection and complexity that diminish the space's appeal. We need to reintroduce magic to mobile development! Imagine agents that test your changes and provide runtime intelligence, or systems that identify flaky tests and automatically open PRs to resolve issues blocking your team.

Is this Mobile DevOps? I don't believe so—that term has served its purpose. What’s emerging is something more modular and layered. We look to platforms like Vercel and Expo as our north stars, not just for their seamless repository integration and comprehensive tooling, but for how they abstract away infrastructure complexity while delivering a first-class developer experience.

This is where the new model shines: you can now choose any macOS runner provider in an increasingly commoditized space, thanks to the “runs-on” revolution. The infrastructure layer becomes interchangeable, and on top of that, we (and others) can build a specialized layer that provides mobile-specific insights, mobile previews, and developer-centric features. Tuist is designed to work regardless of which runner provider you choose, ensuring you’re never locked in and always able to benefit from innovation at every layer.

In this sense, the real transformation is about decoupling: the infrastructure layer is separated from the developer experience layer. This empowers teams to select the best underlying compute for their needs, while still enjoying a rich, mobile-first platform experience—on-the-go releases, preview sharing via simple links, and proactive notifications about potential test flakiness. This is the essence of the “runs-on” revolution, and it’s what sets this new era apart from the Mobile DevOps of the past.

Looking Forward

The future holds tremendous promise, and this market transition represents the best possible outcome for our ecosystem. Organizations will simultaneously reduce costs and receive superior service, while infrastructure becomes more affordable and accessible, enabling companies like ours to compete alongside industry giants undergoing their own transformations. The result? The innovation our industry desperately needs.

For established CI providers, this shift presents both challenges and opportunities. Those who recognize and adapt to this new paradigm—focusing on their unique value propositions while embracing the infrastructure-as-a-service model—will thrive. The key lies in understanding that the market isn't disappearing; it's evolving. Success will come to those who can navigate this transition while continuing to deliver exceptional value to their users.

The mobile development landscape is ready for its next chapter. Are you?

What follows is a curated, non-exhaustive list in no particular order.

We are developer tooling nerds, so expect the updates we're excited about to be focused on the developer experience.

New testing capabilities

In Xcode 26, Apple has invested heavily in tools for writing and debugging UI tests. From recording UI interactions and getting the code written for you, to built-in editor capabilities for adjusting the generated code—we think these new tools are amazing. They've also added support for recording videos of your UI tests during execution, so when you see the test results on completion, you can more easily debug what happened. This is much better than just looking at logs or execution traces. I recommend watching the talk Record, replay, and review: UI automation with Xcode - WWDC25 to learn more about these improvements. Note that all these improvements only work with XCTest, but hopefully they'll make them work with Swift Testing soon.

Additionally, they added an API that allows you to catch fatalError() and precondition() calls from your tests, plus an attachment API so you can attach information that might be relevant later for debugging tests.

We think these improvements are fantastic, and you might want to explore pairing their adoption with Task Locals to scope state to each test. This way, you can take advantage of all the cores in your Apple Silicon to increase test performance through parallelization.

Having these capabilities is great for Tuist. While Apple focuses on improving their foundations and making them more capable, we go the extra mile by using those APIs to make them more accessible via the web. We make them even more useful by correlating them with information from other sources (like GitHub) and bringing insights close to where developers spend their time, like Slack. We'll soon extend our insights feature to include insights from your test runs, surfacing the most relevant information from your test results and giving you the option to download the result bundle and open it with Xcode if you need to dive deeper.

A new #playground macro

With LLMs presenting developers with an opportunity to rethink how we develop, Apple has noticed the need for an isolated space within your project where you can play with your project's code building blocks without going through the scheme-based compilation cycle. Think of this as previews, but for non-UI code.

Traditionally, SwiftUI previews have been known for being unreliable, especially in large modular projects with many implicit dependencies where the preview panel can't reliably build the part of the graph necessary for the preview to work. Will it be the same case for playgrounds? We'll see once people start using them.

Our feeling is that with the default move to explicit modules and the introduction of a content addressable store (CAS) (more on this later), these are steps toward making SwiftUI previews more reliable, and potentially in-code playgrounds too.

Xcode improvements

Apple shipped many incremental improvements in Xcode. A few that caught our attention:

• They're tracking many more metrics from your production apps if users opt into them. They expanded the list of supported metrics and added recommendations based on what Apple considers a good baseline.
• Months ago, Apple unified and open-sourced the build system that powers Xcode and SwiftPM, taking the opportunity to make it extensible. While it's not very user-facing, users will benefit transitively through more reliability and performance since it eliminates the need to reconcile SwiftPM and Xcode's build systems (both use the same one now). This is great news for the ecosystem, and the best part is that it's open source.
• They're defaulting to explicit modules now, which should lead to faster and more reliable builds, and through CAS, optimizable builds in the future.

Apple is taking steps in what we believe is the right direction and gives us ideas for how Tuist should evolve to augment the new capabilities of these tools.

Container

Apple has released their own open-source CLI to run Linux containers on macOS: container. It's written in Swift and builds on another open-source project of theirs, containerization, which builds on Apple's virtualization framework. If you've used Docker or Podman before, they serve similar roles—you can start Linux containers from images. However, unlike Docker, containerization uses Apple's virtualization framework. This provides stronger isolation, as each container has its own kernel, reducing the risk of kernel-level attacks.

Thanks to their use of VIRTIO drivers, they can achieve fast boot times and low memory usage, making VMs nearly as lightweight as traditional containers.

I can't help but wonder why Apple invested in their own open-source solution when we already have Docker and Podman. But I guess as Swift spreads to other ecosystems like web servers or Swift executables that run on Linux OSs, controlling the developer experience of using Swift in those environments at a lower level makes sense.

If you want to give it a shot, you can install it and then run the following command to build your Swift package on Linux using Swift 6.1:

Content Addressable Store (CAS)

When Apple open-sourced their unified build system, we were excited to see Apple investing in a content addressable store. We thought we'd see a bigger announcement this WWDC, but it was just a soft release, perhaps because it's not yet stable.

You might not be familiar with the concept, but you're probably familiar with the consequences of the build system not having it and doing everything through derived data: unreliable incremental builds and features like SwiftUI previews. A build system with a content addressable store works such that for build tasks, it can get a fingerprint knowing all the inputs and outputs of a build task. If the build system can assume it has all the information about inputs and outputs, then it can calculate a hash and look up the result of a previous build task by that hash. The problem is that due to how Xcode projects and the build system are designed, they're not fully hermetic and support implicit imports, which means files being built might depend on something the build system doesn't know about, causing the build system with CAS to fail compilation.

So before we get there, we need to move to a hermetic world at the build system level with explicit modules. I believe this is why Apple has made explicit modules the default in Xcode 26. You can try to opt into CAS by setting the following build setting, but it failed for us in a recently-created project:

We believe this is a multi-year effort, but the future looks bright because it'll bring not only stability but also native build-time optimizations by sharing those artifacts across environments. Sounds familiar? Yes! This is what Bazel does. At Tuist, we'll start investigating how we can hook into that system to provide the fastest latency possible, potentially partnering with some providers and enhancing those capabilities with the best and most actionable metrics to optimize projects further.

Small bites

• The Xcode editor annotates the end of compiler directives to show which directive they belong to.
• The attention to detail that Apple has put into Liquid Glass is quite impressive, and this is a testament to that.
• Xcode download size has decreased by 24% and workspace loading performance has been boosted by 40%. So if you have a large workspace, this is a reason to be happy.

Things we theorized about that didn't happen

Last year we saw frequent git conflicts being mitigated with buildable folders, so we wondered if Apple would continue addressing long-lasting issues by finally settling on a user-facing graph format that's unified across apps and packages. Developers are pushing Swift packages to be that format, trying to run away from the inconveniences of Xcode projects. That push has manifested in Swift packages starting to look more like Xcode projects, but in a DSL that wasn't designed for that purpose—the format might suffer as a result.

Part of me was expecting to see a decision there. I saw some people mentioning a Project.swift file, but it didn't happen. My bet is that before we get there, we need better sandboxing capabilities, perhaps a subset of Swift that can be evaluated quickly, and a migration path for people to start adopting it. With swift-build being open source, I think that's a natural next step.

We also wondered if Apple would do anything in the area of developer productivity, and while we see signs of that, it's still too early. Their toolchain is becoming more capable, but the legacy of past decisions—like the design of derived data, which led to many projects accidentally building—is a hard place to move from. But it's slowly happening.

Seeing these things being solved at a lower level would be great because we can focus our efforts on areas where Apple hasn't traditionally been good or shown interest—like making dev tools accessible via the web, or correlating their data with data from other places where developers spend time to provide new developer experiences that would be hard to imagine Apple building.

Closing words

There are many more improvements that span platforms and areas, so we recommend checking them out on the developer platform or in the app. We believe the ecosystem is more thriving than ever, developer tools keep getting better, and we couldn't be more excited to keep augmenting these capabilities with integrations, new insights, and optimizations to make teams more productive.

This post has been written by a human, and its grammar has been edited by Claude Sonnet 4

Two months ago, we announced the redesigned Tuist dashboard and today we are releasing the building blocks that we created to build it: a complete design system for building web applications with Phoenix LiveView, including all the Figma design files and the fully accessible components.

Building blocks for LiveView

When we started building the new dashboard, we evaluated several ways to implement the beautiful designs from our designer Asmit.

As a starter, our server is implemented in Elixir using Phoenix. All pages are built with Phoenix LiveView and therefore server-side rendered. This allows us to iterate much faster than if we had to deal with client-side state management, which is why we decided to build the new dashboard with LiveView as well.

Using server-side rendering is amazing for us, but it also comes with some challenges when building a highly interactive user interface like our dashboard. We had a few important principles that we wanted to follow while bringing our design system to life:

• It needs to be accessible: We want our tools to be accessible to invite everyone to use our tools, benefit from them, and share ideas to make the product better every day.
• It needs to be keyboard-navigatable: Being developers ourselves, we use our keyboard a lot to navigate the tools we use every day, and we want to make sure that our tools feel great to use with the keyboard.

Both of these are solved by so many different libraries in the JavaScript world, but there is a lack of good solutions for LiveView, while the bundled JavaScript functionality is not sufficient to meet our requirements.

• It needs to be as close to the web as possible: The web is designed to last. As a small team of four, we want to focus on building features rather than chasing breaking changes. Modern CSS has improved dramatically—we use plain CSS without post-processing. While we embrace web standards for JavaScript, we still bundle our code because loading external dependencies (like Zag) from CDNs within a library would require consumers to configure CSP headers and handle version management—complexity we want to avoid.

In the end, we decided to build our design system on plain CSS while building our own hook system based on Zag, a library of state machines for building UI components that is agnostic to what rendering framework is used. It has been amazing to work with, and I'm happy to have our components be fully keyboard-controllable.

The result is a complete set of LiveView components that handle focus management, ARIA attributes, and keyboard interactions out of the box. No more wrestling with other dependencies and hand-writing focus trapping logic.

The quick start

For detailed setup instructions, check our full documentation on HexDocs, but here's a quick start to get you going if you just want to try it out. There's also a Storybook available to explore the components and their available properties.

1. Add the dependency to your mix.exs file:

2. Import the styles in your app.css file:

3. Add the JavaScript hook to your app.js file:

That's it! You can now use the components in your LiveView templates. As a helper, we also expose a use Noora macro that automatically imports all components.

The Figma files

We're not just open sourcing code - we're releasing the entire design system, including the Figma files with all of our tokens, designs and examples. You can find them directly on Figma, ready to explore before installing Noora and building your website with it.

What's next?

We are excited to release this first version. It's been in production for a while now, has received a lot of love and attention, and we are genuinely looking forward to seeing what you build with it. We will continue to push new components and updates to existing ones to power all of the new stuff we are working on, and are also welcoming contributions in the form of bug reports and pull requests.

We will also update our Noora documentation page which is currently focused on the CLI version of Noora to include the web version as well. This didn't quite make the cut for the initial release, but we will have it ready soon. We are also going to update the Storybook with more real-world examples from our own usage patterns building Tuist.

Looking further into the future, we are keeping a close eye on what's possible with web components and how we can leverage them to make Noora for the web completely agnostic of where you use them, decoupling it from Elixir and LiveView and allowing other server-side frameworks such as Vapor to use Noora as well.

The links, all in one place

• GitHub
• Figma
• Hex
• HexDocs
• Storybook

You might have heard of the concept of data-informed decisions—the idea that you back your decisions using data. The more and better data you have, the better your decisions can be, and this principle applies to developer environments too.

Many disciplines in the tech industry follow this approach: product, marketing, sales, and even engineering in production systems. However, some disciplines and domains have traditionally refrained from backing decisions with data, and app development productivity is one of those. Why, you might ask? In this blog post, I'd like to distill that for you and share examples of how having the right data can help you take a different approach to your development setup.

The problem: Xcode's proprietary ecosystem

Have you ever heard of the concept of narrow waist? It's the idea that a concept, interface, or protocol solves an interoperability problem. TCP/IP is a narrow waist between the application layer and the transport layer. Shipping containers are the narrow waist between goods and transport mechanisms.

Often, these narrow waists are created by data formats like Markdown, which many editors and tools can interact with. When you choose Markdown, you know it's synonymous with having access to an ecosystem of tools that can work with it.

But Apple created their own ecosystem. Even though they're not the only ones building tools for developers—like build systems or test runners—they refused to adopt and, in some cases, evolve existing standards. Instead, they leaned into Xcode-scoped proprietary formats. These formats were optimized to be interacted with from Xcode, and their usage outside of that context required extensive reverse engineering. This is something we had to do with tuist/xcodeproj, and Spotify had to do with XCLogParser.

When you have to reverse-engineer an undocumented format, the incentives to build a narrow waist are minimal. But by not building it, you prevent developers from having access to an ecosystem of tools. As a consequence, you create a strong dependency on Apple's investment in developer tools. Sure, they make amazing tools, but other people do too—perhaps you don't need to build everything yourself.

The result is that everything happens within Xcode. Any state, whether it's the result of a build or tests, doesn't "escape" that environment.

The infrastructure challenge: where to store and process data

Let's assume you've gained access to the data. You've hacked your way through Xcode projects, used community tools to convert the format into a JSON payload, and you're ready to use it. The next natural question is: where do I place the data, and what do I do with it?

Storing it locally wouldn't be useful enough because you'd only be able to see your own data and compare how it changes over time within your environment. As we'll see later, there are many interesting insights we can derive once we make the data escape an environment. So you need a place to store the data and a publicly accessible API to push it to. You need a server.

At this point, you'll most likely need to sit down with a backend or infrastructure engineer from your company to spin up a data-ingestion pipeline or an instance of XCMetrics. But as I said earlier, the incentives to maintain narrow waists or tools that work with proprietary formats are minimal. With Spotify no longer using Xcode's build system, the project is no longer actively maintained. So chances are you give up.

Your project will continue growing. Every year, you'll pitch to your leadership about getting faster Apple Silicon—which your engineers and Apple will be happy about—and hope that things are just fine.

But even though you can't directly observe your dev environments, people talk about their feelings in private or group conversations. They joke about those flaky tests continuously making PRs red and requiring retries, or SwiftUI previews breaking again in the most recent Xcode version, or having to frequently delete derived data every time they change between branches. If you've been on a team working on an Xcode project, I'm sure you've been in one of these conversations.

Sooner or later, the unproductivity becomes so obvious that you find yourself in a desperate leadership decision, which typically ranges from adopting React Native or Flutter to asking the most senior people on the team to explore new build systems.

The power of data: insights you can gain

Before we dive into what Tuist is doing to change the state of things, I think it's important to stop for a second and reflect on which questions we can get answered once we collect and process the data.

The most obvious metric is build times, and it's the one organizations are most interested in because it has the highest impact on productivity. If you get the build time per scheme, target, and file, you can see not only how they evolve over time but also how different decisions impact build time. For example, Apple Silicon has multiple cores, but their presence doesn't mean they're being used as effectively as possible. You might need to make changes in your graph or enable new Xcode features such as explicit modules to allow the build system to parallelize more.

What about how frequently people clean derived data, which translates to clean builds? If people are cleaning derived data too frequently, this negatively affects productivity, and it's important to understand why people clean in the first place. Are they getting an error they don't understand? Was an Xcode feature not working as expected?

Another metric directly connected to productivity is flakiness. If tests are flaky, people need to retry CI in their PRs, and whenever they do, they're increasing the time it takes to get their changes merged. Detecting whether a test is flaky requires storing two metrics for each uniquely identified test: a hash and a status. If, given the same hash, we get different results, we might consider the test flaky. By persisting this information, you can have a flakiness scoreboard so you know which tests are causing the most harm to your dev environment and prioritize fixing them.

What if you invest in new laptops, a new version of Xcode or Swift, or introduce a caching system like Tuist's? Then you can see the impact it's had on your team and do some mathematics to know if the investment was worth it. Without data, none of this is possible.

Building the missing infrastructure

We can't influence Apple to give up on proprietary formats and build more narrow waists. We've seen it's costly for the community, but unless there's a mindset change, it's very unlikely to happen.

What we're doing with Tuist is trying to map those proprietary formats into standards that people can build tools upon. We did that with XcodeProj to read, update, and write Xcode projects, XcodeGraph to have an in-memory representation of a project that's much nicer to work with than vanilla Xcode projects, and Rosalind, which generates a schema with the internal structure of an Apple bundle. In other words, we build narrow waists in the Apple ecosystem so that others can build tools and come up with new ideas and improvements to make everyone's development experience better.

Once you have a narrow waist you can build features that are easy to adopt, and this is where Tuist comes in: we package the infrastructure management and make that data useful and actionable into a server product that has a strong focus on developer experience. It's plug-and-play. We also provide an API and soon data-ingestion capabilities so that you can build your own apps upon Tuist, or extract data from your projects into your data pipelines.

Remember XCMetrics that I mentioned before? Unlike it, you don't need to deploy anything. You sign up, create a project, make a one-line change in your project, and you're good to go.

Perhaps Apple will change their strategy and embrace industry standards like OpenTelemetry. If that ever happens, we'll be the first ones celebrating because it'll be a win for the entire ecosystem. But until that happens, we think the ecosystem and teams need the narrow waists that we're building. It's important that we do so while building an incentive system to keep giving teams those tools to improve their workflows.

This post was written by a human and its grammar reviewed with Claude 4 Sonnet.

Among all the factors at play, one of the most critical—because it directly affects the feedback loop—is build time. Build performance tends to degrade as projects grow, often due to unreliable incremental builds, derived data resets, or changes in the project graph or toolchain (e.g., explicit modules) that can impact parallelization. Understanding build times is essential for making optimizations and improving development velocity—but doing so is far from straightforward.

While the toolchain provides data—like the build graph—raw output alone isn’t enough. First, you need to make that data accessible. Second, data that’s isolated in time or scope may not reveal much. But if you persist it over time and correlate it with the team activity—tying it back to specific developers or workflows—then meaningful insights start to emerge.

At Tuist, we don’t want to just help teams optimize workflows through better tooling; we also want to empower them with actionable data to make smarter decisions—whether to boost productivity or improve developer happiness.

That’s why we’re thrilled to introduce Tuist Build Insights: Xcode build analytics for collecting and analyzing build data across any environment—including local development.

👉 If you’d like to see it in action, check out the video below:

Integration

To get started with build insights, you will need a Tuist account and a project. The best way to get started is to use our CLI and run the tuist init command.

Once you authenticate, you will need to add a tuist inspect build command in your Xcode scheme build post-action – unless you use generated projects, in which case we generate the post-action for you:

For more details how to set up build insights, head over to our docs.

Inspecting individual builds

After you include tuist inspect build in your Xcode build post-action, build your app in Xcode and once the build is finished, you will see the build directly in your project dashboard.

When you go to a given build detail, you will see something like this:

Let's break down what's included in the build detail:

• Metadata such as git branch, whether a build was clean or incremental, build duration, Xcode version, and more.
• Errors and warnings: Listed errors and warnings flagged during the build. You get a readable message along with a link directly to the source file in GitHub. No need to parse the obscure xcodebuild output anymore from your CI logs.
• Module and file breakdown: Ran into a long build? Tuist now lists out how long Xcode took to build individual modules and files, so you can focus on the outliers.

The build detail comes especially handy when you need to inspect a build that occurred in a different environment than yours – such as from the CI – or when analyzing build performance of a particular build. No need to upload and download .xcresult bundles anymore. What's more, you can easily send a link to your colleagues, so they can inspect the build themselves.

However, build insights are not limited to inspecting individual builds. Where this feature really shines is when the data is analyzed over time. Something you can't get with Xcode.

Tracking builds

Especially in larger organizations, having the data to assess the health of the developer environment is crucial to ensure developers are not hindered by slow builds. While organizations usually track the duration of CI pipelines, they often lack insights into the local developer environment. And on the CI, the numbers can be often misleading since the measurements are usually bundled with the rest of the pipeline.

Tuist helps you to answer questions such as:

• How often do engineers run clean builds?
• How long does it typically take to build the app on incremental builds?
• How does the build time vary between different Xcode versions and devices?

All of these questions, you will be able to answer by going to the "Builds" page in the Tuist dashboard:

In the "Builds" page, you have access to filters filters such as:

• Scheme
• Build – incremental or clean
• Environment – local or CI

You can use these filters to powerfully slice the data, like getting the number of local clean builds that occurred in the last 30 days, along with the average build time.

Do you want to play with an actual dashboard? Our Tuist dashboard is open for anyone, so you can see the build analytics that we track when working on the Tuist CLI and the upcoming iOS app: https://tuist.dev/tuist/tuist/builds

Wrapping up

Tuist build insights is a powerful tool to take Xcode's data, make it readily available in your browser, and analyze the data over time to simplify inspecting individual builds in arbitrary environments and to understand how productive your developer environment.

How are we going to improve build insights further?

We will:

• Include a link to builds from your CI workflow in the GitHub Tuist report
• Add deeper analytics to help you surface areas of improvement, such as adding suggestions for which module to split to optimize the parallelization of your build
• Couple the build data with binary cache optimizations

Sounds exciting? Take this feature for a spin and let us know your feedback or ideas for how to improve build insights further 💜

In October 2023, Marek and I agreed we'd build a business to fund the development of Tuist and lay the financial groundwork needed to work full-time on what we like the most: crafting developer experiences for app developers and building a community who would join us in that effort.

At the time, we had the community and a CLI that teams loved and used every day. We had experience at Shopify building solutions for app developers, from tools like tophat, Shipit Mobile, and Mac infrastructure, to building runtime libraries for React Native. We had the necessary ingredients to transform Tuist into a platform to help teams build better apps faster. We only lacked one experience: business.

We'll admit it felt intimidating at first, but we were so passionate about what we wanted to achieve that we threw ourselves into understanding and navigating what it takes to get a business off the ground. Since then, we've learned a lot—sometimes by accident, other times by reading—but regardless, we always tried to follow our instinct and did what we believed was best for the project, its community, and what aligned most closely with the type of company we wanted to build.

What follows is a non-exhaustive list of our learnings that you might find useful if you are transitioning or considering leveraging your development skills to build your own company, either as an indie developer or as a small company. Remember that every company is different, so what worked for us might not work for you. If we had the chance again, we'd absolutely do it again, because regardless of the challenges and the many ups and downs that come with it, it's extremely rewarding being able to create an environment where people can show up and help advance a certain ecosystem. Let's dive right in.

From collaboration to competition

Many people associate gratis with open source. Tuist was both, which is very inviting to contributions, collaboration, and also to donations. Once you build the brand, the project can be the catalyst for other brands. Being associated with open source and recognized community projects is attractive.

But things change when you break the "open means gratis" mental model. You go from being something others want to be associated with to something that has the potential to become a competitor, so dynamics naturally change.

And there's something unique to this kind of competition. It's usually a competitor with limited financial capital but with high social and human capital. This is abstract and hard to measure, but social capital can truly make the difference between thriving or not, and this is core to the way we shaped and continue to shape Tuist. Our interactions with people go beyond "selling," "marketing," or "supporting." We give our hands to everyone. We collaborate with the people who show up. We share how we see the ecosystem and tell them what we are doing to get to a better position. We do so without expecting anything in return, which naturally builds unique momentum and value.

We like to say that we are a tiny fish with little financial capital in an ocean of whales, but with human capital that can move mountains.

We've seen companies evolving their relationships with us, and we'll continue to see that, but we believe that's a natural part of the process. We're embracing it as a positive sign that we are on the right path to having an impact in the ecosystem. And to be honest with you, being able to do so with little capital is exciting because it brings out the most creative and human versions of ourselves.

About markets

Building a company has taught us a lot about markets and business models. For us, we just want to have fun without being too worried about how to fund being able to do this full-time. We believe financial success is a consequence of having an environment where people can craft something for fun, not something easily achievable if you have it as your main goal.

The reality is that it's the goal for many companies, often because there's a set of hidden incentives beyond the company, and this leads to a market-based perception of ecosystems. Let us unfold for you the mental model that we've formed.

Ecosystems are markets—groups of people or companies that can be your customers. The larger the market, the better, and companies will do their best to capture most of it. Having a single company in a market is not good because innovation stagnates, though companies often prefer to be the only ones. Once they are in this dominant position, they can roll out practices that no one can challenge.

Because markets invite competition, companies design products to create vendor lock-in. Some do it through ecosystems and social capital. Why don't you leave GitHub? Because your developer CV is there. You get the idea... At some point, they reach a ceiling. They keep raising capital and making promises that they can break that ceiling through diversifying their offering, but then they force the product in ways that consumers can feel. At the same time, other players join the space. Those players can get capital easily because it's a known market, and then they try to push the prices down and attract customers through cheaper prices. Then, if the vendor lock-in is not effective, customers move on.

At the same time, software commoditizes through open source, which means what was once your competitive asset is no longer one. As we learned through Tuist, once you build an open-source commodity and steward it, it becomes more attractive for the market.

We think CI is a good example of this. It's a highly commoditized space. GitHub and GitLab changed the space by not only building CI into the Git forges, which gives them a unique development experience advantage, but designed it in a way that you can bring your runners and shift the cost to you. Then many companies emerged to provide those runners. They first built on existing cloud providers, and then they rolled out their own hardware. But once the market becomes very saturated, nothing prevents a company like AWS or Cloudflare from providing those runners for you because doing it reliably and fast is indeed their strength. You can't compete with AWS or Cloudflare providing containers close to where you need them because that's a muscle that they've built for years.

What does this all mean? That you need to know well what differentiates you. In the context of CI, for instance, you might have noticed that some companies try to offer more than just pipelines, environments, and build logs. Buildkite, for example, is placing a strong focus on building a top-notch product.

For Tuist, we had to decide what our strength would be. There are not that many options in the dev productivity and app quality space for app developers, and Apple could solve some of the problems that we are solving, so what are we going to do differently to stay relevant and continue thriving? In our case, we decided that we'd focus on the following things:

• Community: We'll continue building on open source, hence why our long-term plans are to open source everything, and create ecosystems of extensions for the toolchain.
• Developer experience: We want to build a product that's a joy to use thanks to our attention to detail. Sounds familiar? Attention to detail is what makes Apple products stand out, and it's the reason why we've built a design system for our CLI and dashboard, Noora. Top-notch experiences are not an afterthought.
• Innovation: We should thrive on innovation. There are many workflows that are not possible in app development, and others that feel broken. Why aren't we able to get a preview by tapping a button? And why are releases still triggered from a CI pipeline? We need answers for these questions. Innovation requires creating a culture where new ideas are embraced and given the time, space, and love so they can emerge.

These are the traits that we see making us unique in our space. Now, what's our space? That's a good question... By saying you belong to a particular market, everyone can immediately understand what you're all about. "I do CI," or "I do analytics..." But we don't fit into any of the pre-established markets. We would say we are creating a new one, but we don't like the idea of markets either because they constrain what you do. We see ourselves as something more fluid. We solve problems and challenges that we think need a solution or a better one, and sometimes that means we'll step into other domains. Are previews the same as nightly builds? They are builds, but closer to where collaboration happens. Will we do CI? We'll figure out how to provision runners for some features, and since that's a base step for CI, we'll provide runners too. CI has already been solved by GitHub. These are just some examples. The core element around which everything gravitates is "apps"—first in the context of Apple ecosystem, which we know well, and potentially exploring others once we feel the time is right.

Why would anyone pay for this?

Providing a solution to a problem is not enough. First, the shape of your solution needs to be something people are used to paying for. Tuist started as a CLI. Trying to charge money for a CLI? Not a great idea. You typically don't pay for a CLI. This is a mental model that would take a tremendous effort to change.

A server? That's a different story. We'd pay for a solution on a server. Preferably, we'd be ok with being the product to get it for free, but if they ask us for money for a server solution whose value we perceive, we'll pay for it.

That meant strategically that we had to focus on problems whose solutions require a server. Moreover, we agreed we'd do so following a model where any client-side technology would be open source and free of charge, and the server would augment it to provide different types of insights. Take, for instance, running tests. Running a test suite just tells you what passed and failed, and how long it took. Store that information over time (in a server database) along with a fingerprint that captures whether it changes or not, and you've got a solution to detect flakiness. We made an exception to this rule which we aim to phase out once we can secure the business: cache.

But we don't want to end here. Our server is closed source, but long-term we want everything to be open. But if we open everything, what do we charge for, right? We are still figuring out what the right model will be, but it'll most likely be a mix of paying for our hosting and a very small subset of features being under a slightly restrictive license to support contributions from larger enterprises for control over the platform. Most of our user base will be able to self-host if they want, as long as they are okay with the responsibilities that come with it. Our hosted instance will come with reliability, updates, speed, security, and support to help you focus on what matters. Many companies in the space try to maximize revenue from everyone, hence the classic "contact sales" or "check this demo" approach to products. We consider that to be inaccessible and hindering to innovation, so we want to take a different approach. Time will allow us to do that.

Mental models

Once people build an idea of what you are, it takes an enormous amount of effort to change. For many people, we are still an Xcode project generator. For another good portion of users, we are still just solving frequent merge conflicts. Many haven't realized that most of our features work with any Xcode projects, so you don't need a generated project. We'll continue to improve and support generated projects for as long as modularization continues to be complex within Xcode and there are no good alternatives.

This transition that we mentioned before—from a pure CLI solution to an ecosystem of solutions with a server at its core—came with a transformation of the product that we need to socialize. And believe us, this takes time and a lot of reminding about how we are evolving and how we see the space. We do that through our blog posts, videos, and content in various social channels. It never feels like enough, but it's remarkable how solidified some models can get in people's heads.

This not only applies to the shape of the product but to people's understanding of a problem space. They are so attached to a particular established solution that they forgot what brought them to the solution in the first place. It has a name: cargo culting. And similarly, influencing it takes time and a lot of energy. To give you an example, many are still using Fastlane's abstractions for building projects. Some might not be needed—they could just be an xcodebuild invocation from a bash script—and if you mention this idea, they look as if you were telling them to replace their build system. Moreover, many of these things happen because of social effects. We humans are social species, so trying to use logic in such a setup is a recipe for frustration. For example, we continue to evangelize the idea that SwiftPM is not always the best solution to model a project if you want a great DX for your team. Often, this feels like sending messages into a void, but sooner or later, people will be present and recognize that pain and will be able to connect it with the many times we talked about how challenging that approach can be. You won't believe this, but we've seen teams going from Tuist to SwiftPM and back to Tuist. We are the first ones to believe that if there's an official solution that works great, you should adopt it, but if there's not, we are honest about it.

Another learning is that people iterate on their mental models incrementally. In other words, they need new ideas to be connected with existing ones. For example, if you are suggesting Mise as an installation tool, you need to connect it with Homebrew, which many people are familiar with, and explain how it's more suitable. Or previews, which many people want to connect with nightly builds, which they are most familiar with. So business-wise, you need to find a good balance between pushing innovation while integrating that with the tools and mental models of people. Quite a challenge, isn't it?

Security

When projects are gratis and open source, companies' security concerns are few to none, even though risks exist. But a company that offers paid solutions changes everything. Suddenly, security becomes a priority. We had to go through the process of being SOC 2 certified, performed penetration tests, and found ourselves in extensive processes with security teams going through checklists of questions.

We care about security, and going through the process helped us improve the overall security of the company, but many aspects felt disproportionate.

First, the process can feel like a checklist where checking off items doesn't necessarily mean you are safer. It's more about making yourself liable through your proofs, such that in case something happens, there's someone responsible. The way we see it is that you build a liability chain: customer > auditor > company. And if something goes wrong, well, these things happen because humans make mistakes, so you'd better have insurance. Throughout the process, there were many times when we felt the approach was more procedural than substantive. And it doesn't matter if you just deal with low-sensitivity data, as is the case for Tuist, where we store information and binaries that are already in the apps that end up being shipped to the App Store. The process is the same for you, a small company that's just getting started, or a company with thousands of employees and in-house departments. And you sadly can't skip this if you want to convert customers.

Sales

Our only experience with sales was when I was younger and worked at family cafes selling coffees and churros. We guess this would be our version of "it all started in a garage." Customers came, and they knew what they wanted. We provided them with a great product and a very human service, and they most likely came back and told others about it. It seemed simple, and most of what we learned there applies to selling software too. We are humans at the end of the day.

Through Tuist, we learned a few things in the area of sales. First, many of the things that you read out there might not work for you because every market is different. So we learned by trial and error. We tried to send emails—the sales lingo for this action is "cold outreaches." Developers, our target, don't typically respond well to that. Developers like to build and avoid bureaucracy. They don't like to see an email in their inbox that says, "Hey! I want to sell you this product." They dislike going through procurement processes so much that they can go as far as building a solution themselves or working around your system. Not everyone is like that, but you can see a pattern. Developers won't make the final purchase decision—that's more of a manager or director responsibility—but they are the ones who can influence the decision, so understanding the psychology is crucial. We are developers ourselves, so we have a good sense of what we'd love to see.

There are different approaches to reaching developers. We've seen some companies applying techniques that connect to very basic emotions through their solutions. If you've ever been sold insurance, you know what we're talking about... Fear is in everyone; it's our tool for survival. And if we say that by not using our tool, your business might not be going as well as you'd like it to go—there you go, the fear of failing. Who likes that? Even if the connection between the two is tenuous, one thing we learned is that in business, many approaches are possible. Another approach we've seen consists of leveraging our social traits. We, as humans, tend to compare ourselves with each other. In the real world, you can compare your salary, your net worth, your cars, your iPhones... But in the software world, you need to come up with something else, and then you can even build your marketing on it. We prefer not to take that route.

So, with the quick tools out of the equation, how did we manage to get people to pay for Tuist? We focused on solving concerns that we noticed large companies have, like unproductive development environments, and solved them the best way we could, with a product that's very enticing to use. Apple solved people's needs to stay connected, as did Android, but they focused on solving it in the most beautiful way possible. That's similar to what we are trying to do. When you use Tuist, the value and the perceived value need to be as high as they can be—so high that you are inclined to pay for it if we ask for it and that you tell others about it. Like, "Hey! I used Tuist's cache, and now I have this amazing dashboard that helps me make decisions. Until that point, I was on the verge of having to transition my entire suite to React Native because leadership was questioning our ability to deliver."

What's key is that once the developer is convinced Tuist can be the solution to their problems, the process to witnessing the solution with their project needs to be as short as possible. They'll most likely do this in some spare time that they have here and there, so if the process is quite long, they'll most likely drop it, and you'll never be able to sell anything. For that reason, we invested in a new "get started" workflow that takes you through all the necessary steps, including creating an account. We are also making most of Tuist's features work with Xcode projects so that the changes you need to make in your project are as few as possible.

Some of our deals were closed motivated by leadership's pressure to reduce the costs of CI or deliver features faster. Apple's ecosystem has solidified the idea that feedback cycles can take time and that every new year hardware can help cut time, although it's expensive for companies. But leadership doesn't always understand this. They see other ecosystems like the web being faster and cheaper, and they can't comprehend why. Many decide to move to React Native motivated by that. In fact, Shopify did that, and while engineers might have mixed feelings about this, it's their approach to meet the demands of the market.

Dev environments and app quality

If we asked you what makes a healthy dev environment, you'd have a hard time coming up with a concrete definition for it. However, if we asked you if you'd use AI to enhance your dev environment, you'd most likely be inclined to say yes, even if you don't know what "better" is, because everyone is doing it. Do you see our point?

Take test coverage. A high test coverage doesn't necessarily mean the software does what it's supposed to do. However, there seems to be a consensus that that's the case, and we use the number to measure ourselves against ourselves and against others: what's your test coverage? How much higher did it get?

With productivity—something we help improve in dev environments—there isn't a direct number you can put on it. There are endless frameworks that have attempted to quantify it, but since there are many factors that contribute to the speed of delivering software, it's rare to see a company valuing investment in this domain. For instance, we were chatting with a friend who recently joined an AI-first company. They've given all developers access to Cursor and Graphite, but even if that means developers write code faster, other elements in the software delivery chain are preventing any productivity boost. In fact, they can no longer do continuous delivery with confidence.

As mentioned earlier, companies take productivity seriously if they have FOMO—for example, everyone is talking about Cursor and its productivity wins, and you want them too—or financial pressure, like paying a lot for costly CI macOS environments and wanting to cut costs. But a lot of it is just feelings. And depending on who you ask, different people experience productivity differently. For an iOS developer, waiting for a few minutes to see an app compiled is completely normal. A JavaScript developer would not deem it acceptable and would jump into figuring out ways to speed up compilation. So, in other words, the normalization of native app development being slow is our competitor.

With app quality, a territory we are stepping into, it's a similar story. What's a healthy app? An app that's lightweight, fast, and stable... but it goes beyond that. It's an accessible app, visually and linguistically, that supports many devices, that makes good use of the device's battery. The list is endless, and without numbers around many of these things, many developers and companies might not see the value in investing in tools that help with that unless there are clear metrics or benchmarks. For example, if your app is above a certain size threshold, a percentage of users might not install it.

Because of this, we are trying to understand how to measure some of these things, quantitatively and qualitatively, and provide teams and developers with those metrics so that they understand how it's impacting them. We are also encouraging developers to share their experiences. We said earlier that many times it's about feelings. We can talk forever about how challenging modular Xcode projects can be, but until you've experienced it yourself, or someone that you trust has experienced it themselves, it remains as something that doesn't or won't happen to you.

Marketing

There are many schools of marketing, and like many things in life, you can attempt to buy things with money—from paying people to talk about you to sponsoring conferences to place your logo. Done sporadically, this has a positive effect creating brand awareness, but doing too much of it can indeed have a negative effect. People can get tired of seeing you everywhere, and it feels forced. Developers don't typically respond well to that. Moreover, if you stop paying, and your logo fades, so does people's remembering of it. It lasts until you stop paying.

We sometimes do a bit of that, but not all the time for the aforementioned reasons. We lean on word-of-mouth marketing. But how do you get people to talk about you without paying them? Or how do we build a solution that creates natural advocacy?

This might sound trivial, and we're sure there are lengthy books written about it, but we get people to talk about us by being human and sharing our passion. We treat everyone as best as we can. They feel the joy we have about the app development space, and it has a contagious effect. They are happy with what they see to the point that they tell others about it, and this compounds. We share how our vision evolves and the things that we learned along the way, like this post that's a bit different from the type of content that you typically find on the Internet. We favor slow and deep content over attention-seeking content that just attempts to hack the algorithm of social networks. We don't feel like participating in those dynamics.

We share a lot of our work as open source and support others in building their own tools and businesses on our foundation. We don't see the space as a competition ground but as a collaborative space where having many players is indeed positive. The more, the better. Our social accounts are just syndication of content that we publish in our blog and community forum.

We show ourselves as we are. If we feel vulnerable, we talk about it. If we feel a space would benefit from some innovation, we share how we'd shape it. There's really no playbook that you can follow top to bottom—it's more about people who share the same values and principles talking about what Tuist believes in and aspires to be.

This has worked well for us, and we continue to see people and companies that come to us because they read about us, were told about us, or had Tuist on the list of tools that they were planning to use. We believe building a strong and long-lasting brand takes time, and while money can speed things up in certain moments, nothing can beat team, passion, and humanity.

The Tuist we want to shape

If you wonder what we want Tuist to look like years from now, we want it to be the best toolchain to help you build great apps fast. It'll hold your hand from the moment you've got an idea, offering you many templates to choose from, making the start more accessible, to doing releases, even on the go from an app. And we want this to span across other mobile platforms and technologies such as Android and potentially React Native. Shapes of this already exist in the web with platforms like Vercel. As development becomes more complex due to the surface of technologies, tools, frameworks, platforms, and products, building the muscle to help you stay focused, be productive, and ship the best apps to your users will get trickier and will require significant investment. While you could build those tools yourself, you can plug Tuist into your repo and App Store Connect, and we take care of the rest.

Sounds ambitious, we know, but we believe we are on the right path. Deciding to start the business was the best decision we could have made for Tuist. We've built a very talented team of people who are unique at their craft and a community that's also excited about evolving the experience of building and releasing apps with the world.

We are figuring out the boring stuff and creating an innovative environment where everyone enjoys doing their best work, and we innovate without having to worry about new ideas having to be immediately monetizable.

If you are going through something similar, want to evaluate Tuist for your project and support us, or you just want to chat, you can reach out to us at contact@tuist.dev. We'd love to hear from you.

This post was written by a human and its grammar reviewed with Claude 3.7 Sonnet.

• Duplicate assets across bundles
• Unused binary symbols
• Unoptimized resources
• Legacy code and dependencies

A bloated app size doesn't just consume storage—it creates real business impact. Large apps face:

• Higher abandonment rates: When storage on a user's device is low, apps taking a lot of storage are the first ones to go.
• Lower conversion rates: Especially when downloading an app on cellular, a large download size can put away users.
• Exclusion of users: Large apps disproportionately affect users with storage limitations or bandwidth constraints.

For developers in markets where mobile data is expensive or connections unreliable, an unnecessarily large app can effectively lock out potential users.

Today, we're excited to announce a new Tuist feature that helps you keep your app's memory footprint small even as your app grows: Tuist Bundle Analysis.

See the feature in action 👇

Analyze your bundle

To analyze your bundle, use the new tuist inspect bundle command:

This command works with .ipa, .xcarchive, or .app files. After the bundle is analyzed, you'll receive a link to a comprehensive visual breakdown of your bundle:

The interactive visualization, file breakdown, and module breakdown help you dive deep into your bundle, making it easier to identify possible areas of improvement.

Tracking bundle size on the CI

How do you know when your bundle size is growing too large? By integrating bundle analysis into your CI pipeline, you can monitor how your app's footprint evolves with each build. You can set up a CI workflow to automate this process and analyze a bundle on each PR. We automatically collect Git and other metadata to make it easier to find specific bundles directly in the Tuist dashboard.

Once integrated, you'll have access to historical size data visualized in clear, actionable charts:

This makes it easy to spot concerning trends or celebrate optimization wins—and hold your team accountable for maintaining a reasonable app size.

Open-sourced foundations – Rosalind

We are strong believers in open source at Tuist. That's why the core of the bundle analysis is done locally using our new library, Rosalind. This library uses a standard schema with pre-defined categorization of the bundle contents. When you run tuist inspect bundle with a --json flag, you'll get the raw JSON output that comes directly from Rosalind. This is your gateway to build custom automations on top of what we offer.

We can't wait to see what you come up with Rosalind – and we're committed to maintaing and updating the Rosalind schema to help you in your efforts.

Start optimizing your bundles today

There's a lot more that we have in store for the bundle analysis, such as expanding our GitHub app to warn you directly in the PR when the bundle size significantly increases, adding more insights into how you can optimize your bundle size, and giving you the tools to make individual teams accountable for their part of the bundle size.

Bundle size isn't just about technical optimizations—it's about creating a better experience for your users and being a good platform citizen. With Tuist's bundle analysis, you now have the tools to ensure your app stays as lean as possible while still delivering all the features your users love.

Ready to get started? Run tuist inspect bundle and discover opportunities to optimize your app size!

For more details, head over to our documentation.

LLMs are here to stay. Many developers are exploring how they can have a positive impact on how we code, and that exploration gave birth to a concept you might have heard of: vibe coding. Unlike the approach to coding that we know and have used for endless years, vibe coding proposes that you partner with an LLM letting it write and iterate on the code with context from you and the codebase you are interacting with. Whether the future of vibe coding will have the shape that we are seeing today, and whether it'll be used for coding entire projects, is yet to be seen since we are just at the beginning of loads of creativity and mental energy going into the space, however, what's becoming more and more clear is that the idea of having an AI-powered copilot is here to stay, and for certain tasks, it can indeed save you a lot of time. Editors like VSCode, Cursor, Zed, or Windsurf, have built on this idea, and are continuously exploring new UI and UX patterns that can unlock new ways of approaching code.

If you are developing apps using Xcode, you might understandably wonder, where is vibe coding in Xcode? When will it come? With WWDC around the corner, we'd like to walk you through some work that's being done by the community to bridge that gap, and take the opportunity to talk about the exciting opportunities ahead as Apple prepares to enhance the Xcode experience with AI capabilities that could surpass what we see in other ecosystems.

A vibe-coding copilot

Vibe coding requires a chat interface that's plugged into your coding interface to write code for you, and also to gather context from the editor. There are editors like VSCode whose extensibility allows a tight integration, and there are others like Xcode, which were not designed with a high degree of extensibility in mind, yet it hasn't prevented developers to push the boundaries of what's possible and bring the same experience to Xcode. Two of the most popular options are Alex, which presents itself as an Xcode AI Coding assistant, and CopilotForXcode, an open source project developed and maintained by GitHub to integrate Xcode with their copilot offering.

It's quite impressive to see what they are capable of doing despite the limitations of the IDE, but they managed to workaround those using the system accessibility APIs. From the two, Alex is the most actively maintained, and the experience that they provide is quite close to what you'd get from other vibe coding editors.

This opens up exciting possibilities for how Apple might approach AI integration - whether by embedding a thoughtfully designed chat interface into Xcode's UI, or by expanding the extensibility of the existing interface to allow applications like Alex to seamlessly integrate and access runtime information, which would enhance the assisted experience quite significantly. Given Apple's history of refining technologies before bringing them to market, we're eager to see their unique perspective on this space. And this brings us to the importance of having up-to-date and relevant context while interacting with the LLM.

Context

For LLMs to do a great job at the tasks you ask them to do, they need a lot of context. Some of that context can be provided by you via the prompts, for example if you want to vibe-code a UI, you can describe what the UI is for, what kind of data you plan to present, and even ask to populate the UI with some mock data for the purposes of prototyping. However, that's often not enough. The editor needs additional context to output code that can be integrated, and in the case of an Xcode codebase, compiled by the Swift compiler leading to an app that runs. For example, the version of Swift that your project is using, the structure of the Xcode project where it might need to add some files to the file group and to a sources build phase, or the schemes that are available to build a runnable application.

This notion of LLMs talking to the outside world is a need that Anthropic realized, and that led to the definition of a protocol, Model Context Protocol (MCP), which many called the USB-C of LLMs. MCP aims to be a standard protocol for how LLMs can interact with the outside world, either to gather additional context, or even run tasks in your system, like building and running an app in the simulator. While MCP got popular among code editors, it's true that since it's coming from Anthropic, there are some companies like OpenAI that are hesitant to adopt it, and others that are proposing new protocols, leading to a bit of an unfortunate situation for the ecosystem where there are multiple protocols for achieving the same thing.

The lack of MCP support in Alex (CopilotForXcode just announced support for it) hasn't prevented the community from going ahead and building MCP servers for Xcode app developers. From all of them, one that's getting a lot of traction and it's quite actively developed is Cameron Cooke's XcodeBuildMCP, which you can plug into Claude desktop or other code editors like Zed or Cursor. With it you can do things like building and running an app, or managing your simulators. Some of this functionality is already built into Alex, but once they support MCP servers, you can think of MCP servers like XcodebeBuildMCP as "extensions" of vibe-code editors.

So we have solutions that bring the coding experience closer to Xcode, we have MCP servers that can bridge LLMs with the Xcode and app development world, what's missing you might guess... Well quite a lot indeed, and some changes in foundational pieces in the Apple ecosystem, without which the vibe coding experience will lag behind.

Built-in extensibility

There's a limit to how much Alex or CopilotForXcode can do and read through the accessibility API. On one side, this is excellent for Apple because it puts them in a unique position to build a more tightly integrated experience that could redefine developer workflows, and this is something that we know well at Tuist (wink, wink). Apple has consistently demonstrated their ability to take emerging technologies and elevate them through thoughtful integration with their platforms. While AI development may not have been their primary focus historically, Apple's track record of transforming industries when they do decide to fully enter a space is impressive. Imagine if instead they started layering Xcode, opening the bottom-most layers, and giving developers the tools to extend it. Sounds familiar? That's what Microsoft did with VSCode, and what has given the explosion to editors like Windsurf, Cursor, or Void, and we'll most likely see more in the years to come. Xcode's extensibility has historically been limited by design, but there are encouraging signs that Apple recognizes the tremendous value in opening up their developer tools. With the growing importance of AI in development workflows, this year could mark a turning point where Apple embraces a more open approach to their tooling, unlocking a world of new coding possibilities for app developers.

Thanks to that, extensions like Alex or CopilotForXcode wouldn't have to rely on a high-level API like the accessibility, they could hook into the internals of Xcode and even use their internal APIs for interacting with Xcode projects, for example to add a source file to a target, or to know which files are compiled as part of a target.

Shorter feedback cycles

When doing vibe coding, there's an agent mode, where you give the interface a set of requirements, and they go ahead and do the work for you. This is often referred to as "agentic" AI. This mode requires having a way for the AI to verify that the changes are valid, similar to how you do when you hit compile or run the tests, to make sure the code compiles and does what it's supposed to do. If those "checks" run fast, the agent can iterate fast based on your input, however, if they are slow, or even worse, they are unreliable, it can completely spoil the "vibe" in the coding.

Sounds familiar? This is the scenario that developers face every day in their day-to-day development, and that motivated the creation of Tuist in the first place: unreliable builds caused by implicit configuration, frequent deletion of derived data in the aim of making a compilation work, one-line changes that trigger long compilations... Many of us might have normalized all of that as inherent to building apps with Xcode. This has led some organizations to explore alternative approaches using JavaScript runtimes. Attempting to vibe-code gives us a fresh perspective on developer experience and highlights opportunities for enhancing performance in ways that Apple is uniquely positioned to address.

While the current "vibe" coding experience has room for growth, Apple is already laying the groundwork for significant improvements. Last year they introduced explicit modules - a forward-thinking move that shows their awareness of what's needed for better tooling integration. They're also working on a sophisticated content addressable store, which demonstrates Apple's commitment to building the foundation for next-generation development experiences. So while other runtimes like the web platform, where you can throw React or web components and see them being reloaded in seconds, we are insanely far from enabling the same experience in Xcode. We need to finally move on from all that implicitness that brought teams the convenience to modularize, and introduce more explicitness and dynamism into the toolchain such that you can iterate in a small part of your apps.

Who knows... perhaps we move in the direction of doing code-injection escaping the compiler all together, but once again, this is another area where language convenience, like being able to reference a symbol without the full symbol identifier, might come at the cost of once more, not being able to enable certain developer experiences.

Runtime context

Another piece of information that will be useful as well will be runtime context. A few weeks ago the developers behind the Elixir programming language and the Phoenix web framework introduced Tidewave, which they presented as a technology to expose runtime context from web apps to MCP-compatible code editors.

When your software is running, there's a lot of runtime context in it that might be useful to further enhance the vibe coding experience. For example, imagine being able to debug your API client by sending requests through Claude and asking it to verify the responses and iterate on the code based on what they see in the responses. These are just some examples, but you get the idea. The more context, the better, and runtime context can be quite useful.

In that sense, using runtime solutions that model problem spaces very declaratively can play a key role in enhancing your vibe coding experiences. And there's no better example than Point Free's architectural approach. Your application state lives in a store, and the mutations that are possible are known at compilation-time, so you could trigger those mutations, not by interacting with UI, but by chatting with an LLM. Wouldn't that be cool? The agent could navigate the app, and who knows, even reach user scenarios that you didn't think of and write some tests for you. The possibilities are endless.

In that regard, we wonder if Apple will introduce an official framework that can be used by other frameworks and libraries to have a unified way to share context with the outside world. Ideally, they'd expose an MCP server, but we all know Apple likes to sometimes go the proprietary path and come up with proprietary solutions. This is a direction that sooner or later will be more deeply explored by the ecosystem.

Better documentation and examples

LLMs are trained with existing code examples and documentation. Therefore, the more and the better they are, the better the work that LLMs produce will be. Unlike the web, where there are plenty of open source projects and libraries to learn from, the number of open source projects and apps out there to learn from is quite limited. One could argue that Apple could use their own projects, but are they in a state where they can be used to train models? Only Apple and their engineers know, but that might not be the case. So if there are not that many references out there, this will unfortunately make LLMs not as good at writing Swift as they might be in other languages. And the same goes for the docs. The documentation of the frameworks and the programming language needs to be top-notch. It needs to cover in detail what the APIs are for, include multiple examples of how they can be used and the output that they'd produce in those cases, and also caveats that someone should be aware of.

It almost feels as if all your past investment into great docs and examples is finally being put into practice. The good thing is that if the LLMs are not doing a great job, you can blame someone else, but the reality is that a lot has to do with all that data it's been trained with. The push for vibe coding can finally be a wake up call for Apple to fill many gaps in their documentation, ensure they provide as many examples as they can, and expose an llms.txt endpoint that LLMs can use to improve their models.

Explicitness, explicitness, explicitness

The more explicit the context is and the dependencies between different pieces of context, the more likely LLMs will do a better job at their tasks. Take for instance this Swift evolution proposal, which introduced support for trailing commas in comma-separated lists. As a language addition, it's a great convenient improvement. However, it's only supported from the Swift version 6.1. In other words, to know whether that feature can be used, the LLM needs to know which Swift version a target in your Xcode project is compiled with, and if this information is dynamically resolved at build time based on the build configuration and a setting in an .xcconfig file, the chances that the LLM uses that information to use the right language features is very unlikely, so you'll force the agent into a trial-and-error approach to coding for you, which is slow and frustrating.

Therefore, I believe in this new world we are entering, it's crucial that we embrace explicitness, and that we make all that information accessible to LLMs, so the more open, the better. Otherwise we'll fall way behind in what "vibe coding" means in the web vs Swift app development ecosystem.

Closing words

It's early to know what vibe coding will look like in years from now, but it's clear that it's here to stay, and with so much creative energy and capital going to the space the concept is likely to evolve and challenge our approach to coding. Apple's thoughtfully designed solutions and mental models have served developers well for many years, and now they have an exciting opportunity to evolve these approaches for the LLM era, where high-quality, explicit, and accessible context becomes increasingly valuable. We can see vibe coding as an inspiring catalyst for Apple's next leap in developer tools, and given their history of transforming industries through careful innovation and integration, we're optimistic about how they'll enhance their already robust software ecosystem, potentially pioneering new approaches that align with their commitment to quality and providing developers with exceptional tools to build remarkable apps.

If this is a space that piques your interest, we recommend following the work that Cameron, Rudrank, and Thomas are doing bridging the gap between Xcode and AI.

This post was written by humans with grammar and style reviewed by Claude 3.7 Sonnet.

When you're building software, the user interface is usually the first thing people notice. Every app or tool is built from countless hours of hard work by developers, and it's the right developer tools that make the app development process smooth and efficient. A good UI isn’t just about looking nice—it’s about creating a smooth, efficient experience that helps users get things done quickly.

And if you want to see the new dashboard in action, you can take a look at the open Tuist dashboard (yes, we use Tuist with Tuist).

Why redesign

The value Tuist brings is really important to us. While our primary platform is the CLI, we also wanted to make sure the web interface was easy to use. Although our CLI saw a major upgrade, the web interface still had room for improvement. Other developer tools like Vercel, Supabase, and Buildkite have set a high standard, and we wanted to bring that same level of quality to the app development ecosystem. Through our exploration, we identified several challenges, including:

• Enhancing the overall navigation experience
• Adapting to the product changes
• Highlighting only the most important information

The first steps

Tuist's previous dashboard was built using the Untitled UI design system. While it's a great design system overall, as projects grow, you need new components that fit within the existing framework. This can make it tricky to work with components on the design side. When I joined Tuist, my goal was to create a more accessible, scalable, and open-source design system. We named it Noora. The Noora design system will be the foundation for shaping not just our dashboard, but also our websites, marketing materials, apps, and more. To keep the community in the loop, I started a redesign initiative on our community platform, where I updated the progress of the design system every two weeks.

Meet the new Tuist dashboard

This redesign wasn’t just about updating the UI; our goal was to make the developer experience more intuitive. We analyzed platforms like Supabase, Appwrite, Gitpod, AppSignal, Vercel, and Buildkite to understand how to structure data and prioritize what matters most to developers. Our focus was on reducing noise and presenting only the essential information.

After multiple iterations, experimenting with multiple design directions, we finally landed on a layout that felt easy to navigate and where the content was well-structured.

What’s new

Our updated interface design is now easier to use, more intuitive, and visually appealing—because we believe great design is not just about aesthetics, but about how well it serves you.

New UI

While all core functionalities remain, this new version of the dashboard introduces some exciting new capabilities—like creating organizations and projects, and inviting members directly from the dashboard. Previously, these features were available only via the CLI, but we're moving toward feature parity between the dashboard and CLI wherever it makes sense. The updated UI provides a cleaner, more modern workspace, helping you focus on what really matters: speeding up app development.

New onboarding flow

The updated onboarding flow allows you to create projects right after signing up on the web. We’ve also introduced a new accounts section where you can view your latest projects, billing details, settings, and more.

Updated color palette

We’ve chosen the OKLCH color space for our palette due to its superior accessibility, flexibility in color adjustments, and extensive color range. Unlike traditional color spaces, OKLCH aligns more closely with human perception, making it ideal for creating a visually balanced and accessible interface. For more in-depth information, check out this blog post.

Updated components

Buttons, inputs, tables, and other UI elements have been redesigned for a sleek, consistent look, ensuring the platform not only performs well but also looks fantastic. We incorporated a skeuomorphic style with a modern twist to bring depth to our dashboard. It’s like the good old days, but better.

Light and dark modes

Previously, our platform only offered dark mode, but now we’ve added light mode as well. You can easily switch between light and dark modes for a more comfortable experience, anytime you like.

What’s next:

We’re just getting started—and here’s a glimpse of what’s coming:

• Bring full feature parity between the CLI and dashboard: We’re working toward a seamless experience where developers can choose their preferred interface without sacrificing functionality.

• Expand our design across marketing surfaces and further invest in Noora for the CLI: We want our visual identity to be consistent across every touchpoint, and we’re doubling down on Noora to bring clarity and structure to the CLI experience.

• Make the design system open: We plan to share the Noora design system publicly—including the Figma file and source assets—to support and inspire other teams in the community.

Read more about our open source plans in our latest blog post — and we can't wait to see how developers use all this to create better, faster experiences for app makers everywhere.

If you are an app developer, you most likely want to automate certain tasks in your projects, such as publishing your app to the App Store or running tests from the terminal. Apple provides the foundational building blocks for these automations, which are included in the OS and in Xcode's toolchain. However, in many cases, these tools are too low-level, requiring a layer of convenience through defaults or the construction of more advanced workflows that connect these low-level components—potentially parallelizing some of the steps for improved efficiency.

In this comprehensive post, we'll explore a non-exhaustive list of relevant options that you might consider adopting for your projects. Each approach has its unique strengths and trade-offs, which we'll examine to help you make an informed decision based on your specific needs and constraints.

Fastlane: The established solution

Fastlane is a well-established solution in the automation space. If you're new to app development, this might sound unfamiliar, but virtually everyone who has been developing apps for a while knows about Fastlane and its capabilities.

Fastlane is a Ruby-based solution that provides a Domain Specific Language (DSL) for defining workflows, along with a set of low-level tools that fill certain gaps in the underlying Apple tools. It adds convenience through more sensible defaults and streamlined processes. Its greatest strength lies in its vast ecosystem of plugins, most of which were developed and are maintained by the community. These plugins are distributed as Ruby dependencies using Ruby's dependency management system, Bundler, and can be added with a single command or line of code.

One of the perceived downsides of Fastlane is that you might need to familiarize yourself with Ruby if you haven't written it before. The inconsistency between the language used by Fastlane (Ruby) and the one used to develop your app (Swift) might feel uncomfortable, and that explains the emergence of other solutions that aim to take on the role of Fastlane. However, by choosing an alternative, you'd be trading away Fastlane's extensive ecosystem—something that's not easily replicated by newer tools.

To use Fastlane effectively, you'll need to add Ruby and Fastlane as dependencies of your project, and then create a Fastfile, which is the place where you'll define your project's automation. With Mise, you can do this easily in your mise.toml file:

With a simple mise install command, you'll get the environment provisioned with the necessary dependencies. You can then create a fastlane/Fastfile where you'll declare what Fastlane calls "lanes." Think of lanes as workflows or tasks that encapsulate a series of related operations. For example, the following lane builds a project:

This example is quite simple, but in your actual tasks, you'll most likely add more steps that will run sequentially before or after the project builds. For instance, you might include steps to provision your environment to enable proper app signing, run tests, or perform post-build validation.

Sake: Swift-based automation

If you prefer to align the automation language with your application programming language (i.e., Swift), another interesting solution is Sake, which draws inspiration for its name and approach from the well-known Make build automation tool. A Sake setup is a Swift Package with a Command Line Interface (CLI) and API that provides a layer of convenience around lower-level tools.

Modeling your automation as a Swift Package allows Sake to leverage SwiftPM as both a build tool and dependency manager. This is particularly useful if you want to reuse Swift Packages implemented by the community, such as a Swift SDK to interact with the App Store Connect API.

Continuing with our example of building an app, we can implement the same logic as in the Fastlane example in a Swift Sakefile file:

The first thing you'll notice is that this is written in Swift, a language with which you're likely already familiar if you're developing iOS apps. Conceptually, the idea is similar to Fastlane, where you have tasks that are executed in sequence. In Sake, these tasks are declared as static variables in a @main struct.

Another aspect you'll notice if you run Sake for the first time is that it will take some time to fetch the dependencies and warm the build cache. If you're accustomed to scripts in bash or interpreted languages, this might initially feel like a degradation in developer experience. However, subsequent runs should be much faster once the dependencies are cached. Think of Sake as trading Fastlane's instant launch time for the ability to write your automation in Swift, a language you're already using for your app development.

swift-sh: Single-file Swift scripts

In a similar vein as Sake, there's another tool that allows you to write your scripts in Swift: swift-sh. Like Sake, swift-sh undergoes a dependency-fetching and building process, so cold runs will take time to complete. However, swift-sh completely abstracts away packages to the point that your workflow is literally one portable file with annotations at the top for declaring dependencies.

We can transform the previous script into a one-file swift-sh script:

Swift-sh achieves script portability by leveraging annotations placed next to imports. These annotations are then converted to a SwiftPM package in a global cache directory for you behind the scenes. One caveat of this approach is that since the files are copied into the cache directory, we can't obtain the root of the project's directory relative to the path of the script.

One option could be to make paths relative to the working directory, but that would couple the execution of the script to the root directory, which is not ideal for flexibility. In the above script, we decided to pass the path as the first argument when invoking the script: ./build.swift Automation/Automation.xcodeproj. This approach makes the script more versatile and usable from different locations.

We haven't discussed argument parsing yet, but in both Swift approaches—Sake and swift-sh—you can make use of Apple's excellent swift-argument-parser package to declare and parse command-line arguments. You can use this example as a reference for implementing more sophisticated argument handling.

Bash: Unbeatable portability

Perhaps the most obvious approach, but still worth mentioning, is writing your scripts in bash. Bash scripts offer unbeatable portability and launch time advantages. They run instantly on virtually any Unix-like system without requiring any additional runtime or dependencies.

The primary challenge with bash scripts is, well... writing bash. It's not the most enjoyable scripting language to use for complex tasks. The syntax might feel too verbose, and pieces of logic can be difficult to encapsulate and reuse effectively. However, Large Language Models (LLMs) are changing this landscape dramatically.

LLMs are becoming increasingly capable of writing code, and scripting code is something they can do very well, including bash. This approach is becoming so popular that developers have coined a term for it: "vibe coding." You can effectively "vibe code" your bash scripts, and it's easier than you might think. These scripts generally require low maintenance, but even when maintenance is needed—for example, to add functionality or optimize performance—you can also leverage LLM solutions to assist with these tasks.

Here's a simple bash script example that performs the same build operation:

Note in the example above that, similar to Sake, we can easily get the directory containing the script and use it to construct the path to the Xcode project. If you compare this approach to the Swift and Ruby versions, it's slightly more verbose but not significantly so. Things might become more complex as you add control flows and error handling, but you'd be surprised at how manageable these scripts can remain, especially with the help of modern tools and LLMs.

If you'd like to define a user-friendly interface for your bash scripts—for example, to pass flags and arguments—doing so in pure bash can result in a lot of boilerplate code. Fortunately, usage, created by the same developer as Mise, allows you to define that interface using comments in the script:

Note the change in the shebang line, which now runs usage bash instead of just bash. The "usage" tool will parse the #USAGE comments to construct the command-line interface for you, parse the provided arguments, and expose them as environment variables that follow the naming convention usage_$name. This approach significantly reduces the amount of boilerplate code needed to handle command-line arguments in bash scripts.

Other scripting languages: Python and JavaScript

Another automation approach that you might consider involves dynamic and interpreted languages such as Python or JavaScript. If your team feels comfortable writing in these languages, they can be excellent options for automation tasks. Like Ruby (e.g., Fastlane), these languages run scripts instantly without a compilation step, and they provide access to extensive ecosystems of libraries—perhaps not as mobile-tailored as the ecosystem that Fastlane has built over the years, but still rich and diverse.

You can leverage Mise to provision the environment with the runtimes necessary to run these scripts, such as Node.js or Python, and use the package managers of those ecosystems to pull in the dependencies your scripts require. In the case of JavaScript, there are modern runtimes like Deno that take a dependency-resolution approach similar to swift-sh, where the dependencies are declared directly in the scripts themselves. For example:

JavaScript runtimes like Deno provide you with an extensive standard library and ecosystem of packages that rival what Fastlane offers through Ruby. They also benefit from the widespread familiarity of JavaScript among developers, making them accessible to team members who might not be Swift or Ruby experts.

Closing words: Finding your automation path

There's no perfect solution that fits all projects and teams. If you value having access to a rich ecosystem of plugins specifically designed for mobile app development, then Fastlane might be your best choice. However, with LLMs now capable of generating automation code in languages that might otherwise be tedious to write, such as bash, Fastlane's plugins as units of encapsulation and reusability might not be as critical as they once were.

This shifting landscape means you might want to lean toward the side of portability, which bash scripts can provide. But once again, with tools like Mise being able to provision environments quickly and reliably, portability becomes less of an issue because you can reasonably assume developers will have the right environment to run the script.

What factors remain, then, in making your decision? The joy and efficiency of writing and maintaining those scripts is a significant consideration, which many teams might find in using Swift. With Swift, you'd be trading away the instant launch time of interpreted languages, but hopefully, this is something that Apple will address in the future, meaning it won't be as much of an issue long-term. However, don't expect the immediate responsiveness of running a bash, Ruby, or Python script.

Note that you can mix-and-match. For example, you can use Bash scripts for small workflows, and use Swift for more advanced ones such that you can leverage the expressiveness of the language. If you're curious about our approach at Tuist, we leaned into the portability and instant launch time of bash, while leveraging LLMs to help us write and maintain our scripts. This combination has proven effective for our specific needs and workflows.

Our final advice: Don't feel tempted to simply adopt what everyone else is doing, and don't be afraid to pursue a path that feels unconventional for your team. The low-level building blocks have become more capable over the years, so some of the abstractions the community has settled on might no longer be necessary for your specific use case. You'll often be surprised by how far you can go with a simple bash script and an LLM helping you in the process.

Regardless of which path you choose, we recommend leveraging Mise to provision the environments that your scripts depend on, and owning your automation such that it's not coupled to any particular platform. Remember: your automation belongs to your project and should serve your specific needs.

It’s been over a year, during which we’ve worn many hats and learned a lot about what it takes to build a company. Throughout that time, we thought deeply about the future of app development, the challenges that are ahead of teams, and the shape the company and the product should take to stay relevant and elevate the experience of building apps. We love openness, more so when more teams and developers are making Tuist an indispensable tool in their toolchain, so what follows is an owed unfolding of the future that we are envisioning for Tuist. Let’s dive right in.

From first line to lost momentum

Since the inception of mobile OSs like iOS or Android, the ecosystems have changed a lot. They offer many capabilities and manifest as many different platforms that developers are inclined to support to reach new audiences with their products. This growth, yet exciting, present developers with various needs and challenges that take the focus from the building momentum. From slow tooling to messing up with signing, or orchestrating a release, it’s just too much what a developer needs to hold in their heads when all they just want is to get the app out there and iterate.

Organizations that can afford it, throw a platform team at the problem. Developers and teams that can’t, try to get through it by plumbing different open source tools together, a process that takes time and ongoing maintenance cost. In some cases the building momentum is so spoiled that organizations fork their native efforts by introducing a dynamic runtime like React Native’s that brings them hot-reloading and over-the-air updates bringing them the lost momentum.

This is happening much earlier these days because of the broad set of products and platforms developers aspire to support from the early days of the project.

We believe Tuist can be that platform team—just virtual.

Escaping locally-scoped state

Unlike other ecosystems like the web, mobile has traditionally taken a local-first approach to tooling. Tools would run in an environment and the state, if any, would be scoped to that environment, which in the case of CI would get disposed on completion. This works for some workflows, like having a script that archives and exports an app signing it, but at certain point, you need state to escape that locality. Otherwise your ability to improve your dev environment is limited. For example, how do you know if your build times are getting better or worse if you can’t track them over time? Or how do you know if you have flaky tests in your suite if you can’t track consecutive results of the same test? With local-only tooling, you can't.

Moreover, development of apps is not isolated within your Xcode environment. You most likely collaborate with your peers through tools like GitHub, Slack, or Linear. Taking a more holistic approach to dev tooling makes it possible to build integrations that otherwise would not be possible, like clicking on a link that you received automatically in Slack and seeing the app launching right there. That’s when the magic starts.

When state escapes a local environment, we need to persist it in a shared space, and that naturally leads to a server and a storage solution that allows tracking the evolution of state over time and the dependencies between different pieces of state. Additionally, the server can do processing asynchronously, escaping the synchronous act of generating the state, and can interface with other services via HTTP or be interfaced. It unlocks a world of opportunities in enabling that virtual platform team that can provide you with top-notch experiences.

For many years, CI was the only server-side tooling mobile tools used. Some companies built open-source solutions that required a server too, and most recently, we are seeing more open source hapenning in the space (e.g. Tramline). We think this is great news for the ecosystem.

However, placing local state behind a company’s wall also means making the company behind that server the owner of your state. This is not necessarily an issue, but as we have seen in the past with many services, which ended up enshittifying and doing things like changing their terms to open new revenue streams with your data, or forcing you to abusive pricing through vendor-locking, the server-side dev tools are not free from these practices. In simple terms, companies reach a ceiling in a market that gets more and more saturated, so they try to squeeze more money out of you, and they are willing to do anything to get it. The product and you don't matter anymore.

At Tuist we agreed that we wanted to do things differently creating a framework that would prevent this from happening. Let me tell you about it.

Shifting value from software to infrastructure

Businesses consist of producing value and capturing part of that value that they produce. In the case of companies that have proprietary software, they try to capture as much value as they can relative to the value that they produce. But as we all know, software and infrastructure commoditizes, and we are starting to see that in the Mobile CI space, where new players propose lower margins pushing the prices down for everyone. This is when you start to see companies exploiting their leverage to squeeze more money out of you. The thing is, that it doesn't need to be like that.

There's another type of company: open source companies. Unlike closed-source companies, they can produce insanely more value than the proprietary companies because they get contributions from the community. Think about it, if your proprietary-software company is 5 developers, you are limited to the capacity of those 5 developers, potentially improved with AI technologies and agents. You get it. Compare that to a world of developers that might go the extra mile to contribute to the project because they believe in the mission. Not only this is good from the perspective of the ability to produce more value, but also the diversity of ideas that are coming to the project. If your 5 developers are based in some country, then your vision of the world will be very limited to the vision of the world from that country. Now, if you are getting contributions from many countries, it opens your perspective of the world. This morning I was listening to this podcast with Pratul Kalia about Tramline and it made me realize how myopic we might be regarding what's happening in the world. In particular, he talks about the lag between India and the US, and how the focus on mobile took a bit more years to arrive to India. In the case of Tuist, we are working a lot lately with communities in Japan and South Korea, which is introducing us to a world of ideas and opportunities that will lead to a much better product.

Open source companies capture way less value, often none, but since the value that they produce is much more, the net is higher than their proprietary counterparts. Open source companies play more of a long-term game, and not only address building a better product, who doesn't want that, but also minimizes the risk of enshittification.

If you open your software and permissively license it, decisions are made in public with the community. Any decision that would go against the values of the project or the community will be met with resistance. And if those decisions happen, like we've seen with projects like Terraform, the community quickly gathers, forks the project, and continues its development in the same spirit.

If we are building a virtual platform team, a one-stop shop for app developers, it must be open source. There's no other way, but that requires us to shift the capturing the value from the software itself, from somewhere else.

Shifting capturing of value from software to infrastructure

Most of the value that we are capturing these days is through the software itself. Hence why part of our software is not open source. If we open sourced everything, we wouldn't be able to capture any value and therefore the company and the project would die, which is not something we want. So we need to draw a line somewhere. We are still figuring out what the right place is, but we believe it'll be a mix of infrastructure, or in other words you pay us for a service that's fast, reliable, and available every day of the year, and we scale it based on your usage, and features that are tailored to the needs of large enterprises, which are usually the ones that can afford to pay for them.

As we add more capabilities to the platform, something which I'll talk about soon, hosting Tuist will become more complex. We won't make it complex intentionally, because it'll be unnecessarily complex for us too, but there'll be complexity that will get in the way, and that we'll develop a muscle to manage it at low-cost. Think of Supabase. At the core there's a Postgres database. But many companies, including us, pay them for hosting and scaling the database because what we want is building products, not managing and scaling databases. Think of Tuist the same way, you'll want to be building your apps, not managing a service that helps you streamline the process. And here's another thing, because it builds on an open source commodity, you can't go the path of abusive pricing, so prices will naturally be more fair than any other proprietary solution.

And what about everyone else that will host it for free? That's great news for us. We don't expect them to contribute capital. Financial capital is not the only form of capital. They'll contribute ideas, bugs, fixes, and share the word out there. They'll act as a marketing machine and help the product better every day. It's another form of capital.

When will that happen? When we've shifted enough value capturing to infrastructure such that organizations are willing to pay for it.

Alright...we need a server to further streamline development, a server brings a world of opportunities for developer experiences, and we are going to bet on openness to build a reliable piece of software that companies can safely build upon. Let's talk about the product itself and how we see developer experience getting better.

Product

Our north star developer experience for Tuist is that you'll be able to plug your account on Tuist with a repository in your organization, and that's it. We'll come with sensible overridable defaults such that you don't have to do any configuration work most of the time. This is something that BuddyBuild pioneered at the time when they proposed that pipeline YAMLs could be optional. They must be.

Over the years we've developed extensive knowledge over Xcode projects, so I strongly believe we are well positioned to build a zero-configuration developer experience. Moreover, we are going to take the idea a bit further, and we are going to make workflows triggerable through the UI. As you might have noticed, most of the workflows on mobile are CI-centric. There's a reason for that, virtualizing workflows remotely is costly, so costly that only CI companies have access to that, but we plan to change that. A developer should be able to create a new preview from any commit by just clicking a button, and once again, there should be no pipeline for that. We should be able to leverage the same capability to sign the apps for the users generating the right certificates and profiles for that. We'll sign on the fly. Signing will be an implementation detail that they won't have to think about anymore.

And because we'll invest in reducing the cost of virtualization, we believe it's time to reduce the indirection between Git forges (e.g. GitHub and GitLab). We'll provide cheap runners so that you don't have to move away from GitHub Actions or GitLab CI. And if you bring your AWS or Scaleway account, we orchestrate the provisioning so that their cost is tied to your cost account. And obviously, if you want, we'll provide those runners.

We'll look at app development more holistically. First broadening the phases of app development that we help teams with, including project creation, and app releasing. And why not, very far into the future we might integrate with analytics and error tracking platforms to help you have an insight into how your app is performing. We are building the infrastructure for that.

Then, we'll extend to other app ecosystems, like Android. The problems that we are solving are not specific to one ecosystem. The solutions might be, but we are putting a strong focus on ensuring the design is not that strongly coupled to the Apple platform. We are doing so because organizations have shared that they'd prefer to have one-tool-to-rule-them-all, and we believe we are very well positioned to deliver on that. And I believe that our bet on open source plays nicely with this idea because we can collaborate on bringing Tuist to new ecosystems. It'll require a good amount of social capital investment to make that happen, but once we get the ball rolling, we can plug the Tuist server into any app ecosystem.

We'll continue maintaining the solution that gave birth to Tuist, project generation, a feature many of our developers use and love, and upon which we can deliver optimizations such as caching, but we hope Apple gets those problems fixed at a lower level, which means we can plug directly into the foundations and add a layer of useful optimizations and utilities.

Open source won't be our unique strength. We are doubling down on our design. Many developer tools treat design as an afterthought. We are making it core and center. Tuist needs to feel like an enticing product that you want to have in your toolchain. Not only that, but we are building a design system such that when we open source the server, developers can use our pre-made components and design file to design their own features and contribute them to our server codebase. In other words, we are designing Tuist in a way where we take more of a steering role, providing guidance, and ensuring the building blocks are well-designed to enable collaboration and contribution.

We'll also double down on telemetry, something that's not common in the app ecosystem. Apps and processes can't be optimized without data. First, we are going to build open source tools to help with data collection. Second we are going to standardize them and make it available from a server through an API. You can consume it from a Prometheus backend, or build your own client. There'll be a well-documented and productized API for you to use. And we'll provide a UI that will make the data actionable helping you make decisions, in some cases make decisions for you, and provide the information in a data such that you can use it to contextualize your conversations with LLM technologies.

We are building the public infrastructure for productive app development

As more developers embark on the journey of building apps—whether as entrepreneurs or as part of the companies they join—it's increasingly important that the tools they rely on are accessible and part of a shared commons that can be collaboratively developed.

This belief is what drives us every day at Tuist. We’re not here to build private clubs for the few—we’re here to create public parks for the many.

Openness and open source are foundational to realizing that vision. We approach openness with curiosity and conviction, seeing it as the most powerful lever for building the toolchain we believe the app development world needs.

We see a clear need for a one-stop shop for app development. Just as dashboards have Grafana, metrics have Prometheus, and Postgres has Supabase, app development will have Tuist.

We’re not in a rush. We have the resources and the long-term commitment to make this vision real. And we're on the right path.

Fastlane Match proposed a solution for this in the context of certificates and provisioning profiles. What if they are encrypted under a private key in the same repository or in a separate repository that all the developers have access to? This is an approach similar to credentials in Ruby on Rails, which allows having a YAML file with encrypted values that the framework can automatically decrypt and expose at runtime when a private key is available. Wouldn't it be awesome if we could generalize Match's approach to work not only with certificates and provisioning profiles, but also with other sensitive data? Let us tell you that this is indeed possible thanks to Mise, a tool that we already talked about in the past. We'll guide you through how to set it up, and give you some examples of how to use it to encrypt certificates, and expose and obfuscate information into your apps. Let's dive right into it!

Setting up your "secret" environment

Mise is a frontend to your dev env. It might be the first time that you might have heard of this concept, but you can think of it as a tool that takes care of the things that you need for development, from provisioning the environment with the tools that your project needs, to dynamically configuring the environment with environment variables that you need to work on the project.

One of the features that they provide is secrets. They can decrypt secrets that are encrypted using a private key, and expose them in the environment as environment variables. The solution builds upon sops, a tool that solves encrypting and decrypting configuration files (e.g., YAML, ENV, JSON), and age, a tool to generate keypairs to use with sops.

The first thing that we'll need to do is installing both sops and age. We recommend pinning the version in your project's mise.toml file instead of installing them globally. Edit the file, and add the tools under the tools section:

Then run mise install to install the tools and make them available. The next step is to generate the keypair that we'll use to encrypt secrets. Run the following command:

We recommend prefixing the key with the name of your project or organization such that you can have multiple keys in your environment that can have a very granular scope, for example a single project, or a more generic organization-wide key. The command will output a file containing the private and the public key:

The last line represents your private key so keep it in a secure place and make sure you only expose it in trusted environments.

Once we have the key, the next thing we'll need is a file that will contain the secrets that we want to encrypt, and a couple of scripts to encrypt the file and edit the encrypted content. Let's start with the file containing the secrets by creating a .env.json file at the root with an empty JSON object:

Then we are going to create two Mise tasks for encrypting and editing. The first one will be at mise/tasks/env/encrypt.sh. Create the file with the following content:

Where the value passed through --age is the public key generated. Make sure you replace it with yours. The second task will be at mise/tasks/env/edit.sh:

Similarly, make sure that SOPS_AGE_KEY_FILE points to the file where you've decided to persist the key in development environments.

Make sure that you set executable permissions for the encrypt.sh and edit.sh scripts:

And then run mise run env:encrypt to encrypt the .env.json file. The last step needed to expose the secrets as environment variables is to add the following configuration to the mise.toml file:

Mise will automatically decrypt and expose the content from .env.json into the environment, so you can access the secrets using env. variables.

Editing the encrypted file

You might have noticed that we added a Mise task called env:edit to edit the encrypted file. Run the following command to edit the file:

You can replace code with your editor of choice (e.g. zed, cursor). The task will open the editor with an unencrypted version of the file and block the process until the edition finishes. On close, the process will then encrypt your changes automatically. Isn't that magic? Try to add some content to it, save it, and then close. For example:

If you then run echo $HELLO. You'll notice that the variable is exposed in the environment.

Continuous integration

Alright, we've got a setup to encrypt, decrypt, and edit sensitive data, which works if we have a key in the file-system, but what about CI environments where the key is not available in a file. In those environments you'll have to expose it as an environment variable MISE_SOPS_AGE_KEY. Just copy the value, and expose it in trusted CI environments. We recommend that you only do it in the steps that need to access the sensitive data to reduce the security risk. When invoking your automation through Mise tasks, you can assume the environment variables will be present:

There's an interesting side effect of using this approach to encrypting secrets. As we touched on in Own your Swift apps' automation, secret management is one of the features that CI providers offer and that creates vendor lock-in with them. Thanks to this, you can reduce the number of secrets that you expose to just one, the sops private key, and not only that, but you can use Git to keep track of the changes in the secrets. You won't see the value changes because they are encrypted, but you can use commit messages to track for example that "certificate x renovated due to expiration". Git is a powerful tool that gives you a record of changes for free, so moving away from it is generally a bad idea.

Use case 1 - Encrypting certificates

The most common use case for encrypting sensitive data is "certificates" that workflows might need to use for signing the app for distribution. As mentioned earlier, teams have traditionally used Match for that and automating the generation of certificates and profiles. If you only need it for just encrypting files, you might not need Match at all.

As you probably know, the signing certificate, containing the public and the private key, is typically a .p12 file. So how do we get that into our .env.json file if all we have is a file? Easy, you can Base64 its content:

Ensure that when you export the certificate from the Keychain by doing right-click on the certificate, it also includes the private key. In Keychain's UI you'll notice if you click on the certificate it'll show a dropdown with the private key.

Once you have the certificate in the pasteboard, you can run the edit command, and then place it in the encrypted .env.json file:

You can verify that the content is available by echoing it echo $BASE_64_CERTIFICATE.

The next step in the workflow that needs the certificate is to decode it and install it in the Keychain. If the script runs locally, you can use the default keychain. When that happens, you'll likely get a prompt from the system asking for your password to install the certificate. In CI, it's recommended to create a temporary keychain to avoid issues with prompts and permissions. You can use the following code snippet:

Note that the above step might be optional since some CI providers already do it for you.

That's really all you need. Xcode's build system, which uses the codesign tool internally, should be able to look up the certificate in the Keychain and use it for signing. Isn't it amazing that we replicated the core-most piece of functionality that Match provides?

Use case 2 - Encrypting runtime data

The second common use case in app development is encrypting runtime data. For example, you've got an API key to initialize an SDK or interact with your backend services, and you don't want to include that raw in your app's Info.plist. You might want to obfuscate them, but how do you pass the environment variable all the way to the build system to obfuscate its value at build time?

First, you'll need a tool to obfuscate the data at compile-time so that the value can't be easily read from the binary. For that, you can use the ObfuscateMacro. Add it to your project as a dependency and then create a static value:

Note in the code snippet that we hardcoded the value, which is not what we want. The secret is an environment variable, which we need to somehow pass to the compiler. Unfortunately, Xcode's build system nor Swift Macros have that capacity, therefore you'll have to run a script before the build process to generate the values.

To simplify the process, we created that script which does that automatically for all the environment variables whose name starts with SECRET_:

Create the script at mise/tasks/env/generate-secrets.sh and assign executable permissions with chmod +x mise/tasks/env/generate-secrets.sh and then invoke it with mise run env:generate-secrets Sources/Secrets.swift. Make sure you replace Sources/Secrets.swift with the path where you plan to keep your secrets, and the file is included in the project target from where you plan to read them. Note that you'll need a placeholder that you can run in development, so I recommend setting development values, and when doing releases, override using the script.

You'll then have to adjust the automation from secret environments to run the script before building the project:

Closing words

Note that this only covers part of the security. You'll have to make sure the information is not included in visible parts of the requests, for example the URL, making it easily accessible by any malicious actor. You'd be surprised how many apps include sensitive data in their Info.plist, and how easy it is to impersonate them from a different application. Imagine populating Firebase analytics pretending to be a different app. Now you no longer have excuses to add an extra layer of safety to your apps. You won't regret it in the future.

Check out this repository which contains an Xcode project exemplifying this setup.

Updates

• The post was updated on April 10th 2025 to suggest including the generate-secrets.sh script in the repo over piping the curl output through bash, which is unsafe.

Unlike SOC 2 Type I, which is a one-time assessment, Type II requires us to demonstrate consistent security practices over several months. This means our security isn’t just a snapshot—it’s baked into how we operate every day.

Here’s why we pursued SOC 2, how we tackled compliance, and what we learned along the way.

Why go for SOC 2?

Security isn’t just a nice-to-have—it’s a necessity. As more teams adopted Tuist, we found ourselves answering security questionnaires and explaining our security measures over and over again. We wanted a clear, industry-recognized way to show that we handle your data responsibly.

SOC 2 helps with that. It’s designed for SaaS companies like us and focuses on the security and privacy of customer data. Achieving compliance means we’ve implemented strong controls and had them independently verified.

Another reason we started early? Future-proofing. Security is easiest when it’s built into a company’s DNA. Instead of scrambling to meet compliance as we scale, we’re setting a strong foundation now—so security never becomes an afterthought.

What is SOC 2 Type II?

SOC 2 is a security and compliance framework developed by the American Institute of CPAs (AICPA). It evaluates companies on five Trust Services Criteria:

• Security – Protecting systems and data from unauthorized access.
• Availability – Ensuring services are reliable and accessible.
• Processing Integrity – Making sure systems operate as expected.
• Confidentiality – Safeguarding sensitive data.
• Privacy – Managing personal data responsibly.

SOC 2 has two types of audits:

• Type I – A one-time assessment of security policies and controls.
• Type II – A long-term audit (6–12 months) proving those controls are consistently followed.

We went for Type II because we didn’t just want to pass a one-time check—we wanted to show we take security seriously, every day.

Picking the right compliance tool

We needed a compliance tool that worked well with our stack—Supabase, GitHub, Google Workspace, and Tigris. After evaluating:

• Vanta
• Drata
• Tugboat Logic

We landed on Vanta. It had the best automation, worked smoothly with our existing tools, and didn’t require overly intrusive permissions (some alternatives wanted full GitHub access—not happening).

Finding the right auditor

Once we had Vanta set up and running, we needed an independent auditor to review our security practices. Vanta connected us with several options, and we picked one that specializes in SaaS security audits.

The process started with a scoping call, where we determined which systems and processes would be reviewed. Then, we set a date for the audit’s Type II snapshot—a point in time that proves our policies were in place and working as intended.

Preparing for the audit

The months leading up to the audit were all about proving that security was part of our daily workflow. Vanta’s osquery agent helped us track:

• Device security – Ensuring all company laptops had encryption, screen locks, and proper access controls.
• Policy enforcement – Creating and refining security policies for access control, data management, and asset tracking.
• Compliance checks – Verifying we had proper logging, monitoring, and security controls in place.

Another key step was reviewing our vendor security. If we were being audited, we wanted our vendors to meet the same standards. So we asked for SOC 2 reports from any service we relied on that handled sensitive data.

Open security policies

We believe in transparency, which is why we’ve made our security policies public in the Tuist Handbook.

This includes:

• How we manage access control.
• How we protect user and project data.
• Our incident response process.

Security shouldn’t be a black box. By sharing our policies, we make it clear how we operate and hold ourselves accountable to our users.

Making SOC 2 work for us

One thing we didn’t want? Mindless checkbox compliance. Every security control we implemented had to make sense for Tuist—not just to satisfy an auditor.

For example:

• Access Reviews – Instead of a rigid quarterly review, we built security checks into our onboarding/offboarding process to ensure permissions stay up to date.
• Incident Response – Rather than a generic playbook, we tailored our process to match how we actually work and respond to security events.
• Security Training – We kept it practical. Sure, we still had to sit through the “don’t reuse passwords” training video, but we focused on real security risks our team faces.

Launching the Tuist Security Center

We’re also launching the Tuist Security Center, a hub where you can:

• Learn how we protect your data.
• Request a copy of our SOC 2 audit report.
• Get in touch with our security team at contact@tuist.dev.

Security is an ongoing effort, not a one-time project. We’ll continue improving our security posture, refining our processes, and making sure Tuist stays a trusted tool for developers everywhere.

If you’re working toward SOC 2 yourself, we hope this breakdown helps. It’s a big effort, but it’s worth it—not just for compliance, but for building a truly secure product. 🚀

To assist teams with challenges related to generated projects, we created XcodeGraph, a data structure that standardizes the representation of Xcode projects and workspaces. This enabled us to extend some of our solutions—such as our graph visualization tool and selective testing—from generated projects to any Xcode project.

We knew it would be a powerful tool, but its potential exceeded our expectations. With the emergence of LLM-based technologies and, more recently, the MCP protocol standardized by Claude—which Mattt discussed on his popular blog NSHipster—we couldn’t help but wonder: Could we leverage MCP to transform developers’ LLM-based chat apps and code editors, like Cursor, into Xcode project experts capable of answering questions that would otherwise be difficult or impossible? The answer is yes.

In this blog post, I’m excited to announce a new CLI feature: the Tuist MCP server, which allows you to chat with your Xcode projects and workspaces.

What is MCP?

MCP is a protocol proposed by Claude that enables LLMs to interface with the outside world. Editors like Cursor or Zed, as well as chat apps like Claude—acting as clients—can interact with MCP servers using various transport protocols, including standard input. In simpler terms, a client can spawn a process and communicate with the server through its standard input pipeline.

The server can provide resources, prompts, and tools to respond to actions (e.g., building an app). It can even enable more agentic behaviors by allowing the server to interact with the model via sampling.

This might sound abstract, so let’s make it practical. LLMs lack knowledge of your specific development environment, including your projects, but they do understand Xcode projects and workspaces in general. What if you could let them "see" your projects and workspaces? That’s where resources come in. Tuist can transform your Xcode projects and workspaces into a serializable graph and share it with the LLM, allowing you to tap into its expertise to better understand your projects.

Still sounding abstract? Let’s explore a concrete example together.

Setting up your environment

Install the latest version of Tuist and run any of the following commands to configure either Claude to connect to the Tuist MCP server:

For any other clients that support the Model Context Protocol protocol, you can configure them using the tuist mcp command with standard input as the transport protocol. The Tuist MCP will list projects you’ve recently interacted with as resources. Select the one you want to use to provide context, and then try asking questions like:

• What are the direct and transitive dependencies of a specific target?
• Which target has the most source files, and how many does it include?
• What are all the static products (e.g., static libraries or frameworks) in the graph?
• Can you list all targets, sorted alphabetically, along with their names and product types (e.g., app, framework, unit test)?
• Which targets depend on a particular framework or external dependency?
• What’s the total number of source files across all targets in the project?
• Are there any circular dependencies between targets, and if so, where?
• Which targets use a specific resource (e.g., an image or plist file)?
• What’s the deepest dependency chain in the graph, and which targets are involved?
• Can you show me all the test targets and their associated app or framework targets?
• Which targets have the longest build times based on recent interactions?
• What are the differences in dependencies between two specific targets?
• Are there any unused source files or resources in the project?
• Which targets share common dependencies, and what are they?

You can watch the video in action here:

Closing thoughts

Languages as an interface to technology are not only here to stay but are poised to redefine how we interact with the digital world—and we’re only beginning to unlock their vast potential. At Tuist, we’re excited to empower you to bridge this emerging landscape with your projects and development environment. Our commitment is to keep you in full control, ensuring you decide precisely what data you share and with whom.

Exposing the graph of your most recently accessed projects is just the first step in this journey. Looking ahead, we plan to expand the scope of available information, incorporating details automatically gathered by the server from your build and test runs, as well as the resulting artifacts. As always, our mission is to handle the heavy lifting behind the scenes, freeing you to concentrate on what truly matters: crafting exceptional applications with greater speed and efficiency.

If this piques your interest, we invite you to explore our implementation and consider contributing new resources or tools to the server. Your input can help us enhance the features we deliver to the Tuist community. Additionally, we’ve created a dedicated repository, awesome-swift-mcp, with other valuable MCP-related resources in the context of development with Swift.

Stay tuned for more exciting developments from the Tuist team as we continue to push the boundaries of MCP awesomeness. We’re eager to see how you’ll harness these tools to shape the future of app development!

Sooner or later, action becomes necessary—especially if you aim to maximize your CI and engineering resources, safeguard your team's building momentum, and keep pace with business demands. In this post, we’ll explore key areas where optimizations can be implemented, along with potential challenges that may emerge when accelerating your test suite. Let’s dive in.

Run tests in parallel

Modern hardware, such as Apple Silicon-powered laptops and CI environments, boasts multiple cores, enabling true parallelism—running multiple tasks simultaneously. While parallelism is a powerful tool, it’s not always necessary, as many applications are I/O-bound, meaning they spend time waiting for input/output operations to complete rather than taxing the CPU. In testing, for example, while one test awaits the completion of an asynchronous operation, the test runner can leverage shared resources to execute other tests concurrently.

In Swift Testing, parallel execution is enabled by default. However, with XCTest, you may need to opt in via the test plan settings. If you’re using xcodebuild, you can control parallelization with these options:

One might assume parallelization is the ultimate solution for speeding up test execution. Yet, as soon as you enable it, new challenges surface that you may not have anticipated.

Environment limitations

Parallelization has its limits. For instance, UI tests often rely on simulators, which are resource-intensive and can’t be spawned indefinitely. You might hit a ceiling where adding more parallel tasks yields diminishing returns due to hardware or system constraints.

Code not designed for parallel access

Functional programming advocates for avoiding shared mutable state to ensure determinism—a principle that also facilitates parallelization by scoping state to individual functions. While Swift supports functional programming, shared mutable state often creeps in via static variables or singletons. When you increase parallelization, this global state can lead to two issues:

• Data Races: Multiple threads accessing the same memory simultaneously can cause crashes or undefined behavior during test execution.
• Race Conditions: Tests whose outcomes depend on execution order may become flaky, as detailed in resources like JetBrains' guide on flaky tests.

To fully harness parallelization, you’ll likely need to refactor your code to eliminate shared state. This involves scoping state to each test and passing it explicitly to the logic under test. To avoid verbose dependency injection, consider libraries like swift-dependencies from Point-Free or Apple’s swift-service-context. These tools allow each test to instantiate its dependencies, providing a clean API for runtime access.

For data races, enabling Complete Concurrency Checking in Swift 6 is invaluable. While often touted for app stability, it’s equally critical for reliable parallel test execution, catching potential races at compile time.

Parallelization across environments

When single-environment limits—like the number of available simulators—cap your parallelization, you can distribute tests across multiple CI environments. For example, if one environment supports only 4 simulators, adding a second environment doubles your capacity to 8.

To achieve this, decouple building from testing. Use the build-for-testing option in xcodebuild to compile your scheme without running tests:

This generates an .xctestrun file in the default DerivedData directory (~/Library/Developer/Xcode/DerivedData/). This file bundles everything needed to run tests and must be transferred from the build environment to each test-running environment. To locate it, use:

In a CI system like GitHub Actions, cache the file with:

Restore it in test environments with:

Then execute tests with test-without-building, specifying the .xctestrun file:

Dynamic test splitting isn’t supported natively. Use test identifiers (e.g., test case names or targets) to group and distribute tests manually.

To estimate total execution time, use this formula, assuming tests within each environment run fully in parallel:

Total time = ( Total tests / ( Environment parallelization limit x Environments) ) x Average time per test

For example, with 200 UI tests averaging 5 seconds each and a per-environment limit of 4 simulators:

• 1 environment: Compilation time + 4.1 minutes
• 2 environments: Compilation time + 2.08 minutes
• 3 environments: Compilation time + 1.38 minutes
• 4 environments: Compilation time + 1.04 minutes

Run fewer tests

Running an entire test suite for every commit is not necessary. If you change a few lines of code in a pull request (PR), you should only run the tests that are directly or transitively connected to the change. The question is: how do you identify these tests?

Solutions have emerged in this ecosystem and others to solve this problem, often referred to as selective test running. One such solution is XcodeSelectiveTesting by Mike Gerasymenko, which uses the Git repository to determine changes in files and combines that information with the project's graph to identify the tests that need to run. By default, it compares against a baseline branch, but it can alternatively compare against a locally persisted changeset.

We also provide a solution that takes a different approach. Instead of relying on Git, we use fingerprinting to obtain a hash of the modules that have changed. We also handle persisting the information for you, ensuring that the incrementality of selective testing works across branches and commits, not just from a branch and the base reference. You can use it with generated projects as well as standard Xcode projects.

Speed up compilation

Before tests can run, the code must be compiled—a costly step in clean CI environments. Optimize this with build systems like Bazel or Tuist Cache, which cache build artifacts to skip redundant compilation in clean builds.

Closing words

Rapid feedback on pull requests empowers developers to iterate quickly and meet business goals. While multitasking during long CI runs is an option, it often hampers focus and productivity. The closer you get to instant feedback, the better your team can perform.

If your CI pipelines haven’t been revisited since their inception, it’s time to invest in optimization. Your team, business, and customers will reap the rewards of faster, more efficient workflows.

In this post, we’ll explore why these conflicts occur in Xcode projects, examine the various solutions that have emerged to address them, and provide actionable steps you can take to eliminate this common source of frustration for developers.

Why do conflicts exist?

Xcode projects are a directory with the extension .xcodeproj that contain a file project.pbxproj. Back when Apple introduced Xcode in 2023 as part of Mac OS X 10.3, projects were small, and collaboration following trunk-based development was not that common as it is today. For context, Linus Torvalds released Git in 2005, and GitHub was founded in 2008. So at the time, conflicts did not exist, and Apple decided to create a monolithic file where all the project description would be stored, project.pbxproj. The project.pbxproj is a property list file that was not designed to be edited directly. Instead, the changes are done using Xcode's UI, and Xcode is the one responsible for translating those changes into the project.pbxproj file. Group and file references (for example, to reference Swift files) are among the building blocks that represent the hierarchical structure of the project. For example:

These lines update whenever a file is added, removed, or relocated in the project hierarchy—common actions in a pull request (PR). This frequent updating is a primary driver of merge conflicts.

To address this, Apple introduced workspaces in Xcode 4 in 2011, enabling teams to split targets across multiple projects. The idea was that distributing project.pbxproj files across smaller projects would reduce conflicts. While no hard data confirms their adoption rate, workspaces likely didn’t gain the traction Apple anticipated.

In September 2016, with the release of Xcode 8, Apple added comments to project.pbxproj files (e.g., /* Framework.framework */). This made conflicts easier to resolve by providing context, compared to cryptic identifiers like 6CA84C022D8DAA1200086F24. Yet, in 2025, teams still grapple with these issues—not because solutions are lacking, but because awareness or implementation lags.

Let’s dive into practical strategies to mitigate these conflicts.

Splitting a monolith into multiple projects

Since 2011, one effective approach has been organizing your workspace into multiple projects. For instance, you could create a project per domain or feature, each containing its source files, tests, and a demo app. Check out Tuist’s modular architecture guide for inspiration on structuring your projects efficiently.

While this reduces conflicts by distributing the dependency graph, it may slightly increase Xcode’s indexing and build times due to the added complexity of resolving inter-project dependencies. You’ll also need to explicitly define these dependencies to ensure Xcode’s build system links products correctly.

Project generation

Tools like Tuist and XcodeGen (How DoorDash uses XcodeGen to eliminate project merge conflicts) offer an alternative by introducing domain-specific languages (DSLs) in Swift or YAML to define projects. Instead of listing every file (e.g., one per line), they use wildcard patterns like /Sources/**/*.swift, reducing the file’s churn and thus the likelihood of conflicts.

The popularity of project generation stems from this pain point. Tuist, for example, not only minimizes conflicts but also simplifies modularization and optimizes workflows. If conflicts are your only gripe, project generation might be overkill. But if modularization complexity or slow workflows also frustrate you, tools like Tuist are worth exploring.

Using SwiftPM as a project manager

In 2015, Apple introduced the Swift Package Manager (SwiftPM), initially a dependency management tool. By September 2016, with its integration into Xcode, developers began using it to link local and external dependencies. What started as a dependency manager evolved into a de facto project manager for many.

Frustrated by project.pbxproj conflicts and modularization woes, developers migrated their project graphs to SwiftPM. Like project generation, SwiftPM uses wildcard patterns (e.g., Sources/**/*.swift), lowering conflict risks. However, this shift trades one annoyance for another: Xcode can become sluggish, with tiny graph changes triggering slow, asynchronous processes—or worse, leaving your project in an inconsistent state requiring a clean of derived data.

Synchronized groups (buildable folders) in Xcode 16

In 2024, Apple introduced synchronized groups in Xcode 16, akin to wildcard functionality. These groups reference a directory, and Xcode syncs all files within it, allowing exceptions (e.g., excluding a file or tweaking configurations).

In Xcode, these are called “folders.” To convert a group, right-click it and select “Convert to Folder”:

Before converting, use a tool like XcodeGroupSync to align your groups with the file system. Skipping this step risks compilation or runtime errors from missing files or misconfigurations. This feature is a low-effort, high-return investment for teams.

Closing words

Source control merge conflicts in Xcode projects, driven by the project file, have plagued developers for years. Fortunately, you have multiple options to tackle them: splitting projects, adopting project generation tools like Tuist or XcodeGen, leveraging SwiftPM, or using synchronized groups in Xcode 16. Each solution has trade-offs, but they all aim to streamline collaboration and reduce frustration.

Start small—experiment with synchronized groups or a multi-project workspace—and scale up based on your team’s needs. By addressing this pain point, you’ll boost productivity and make your development process smoother. Have a favorite solution? Share it with us on Mastodon!

Since a business's ultimate goal is to grow and stay relevant, they need to adapt accordingly. Some design their business environment to foster innovation. This becomes more challenging as the company grows, and is in fact what makes open source companies outcompete their closed-source counterparts. Other companies focus on building ecosystems where more players are incentivized to keep their business relevant. I'd say it's the proprietary version of the open-source ethos. If you think of Apple's app store, that's what it is. And last but not least, some companies invest in creating seamless experiences that increase customer retention. The integrated nature of their solutions provides such value that customers choose to stay.

Continuous integration

What does all of this have to do with Swift apps' automation? A lot more than you might think. Last year, while chatting with an app developer, he shared that they were renovating their contract with their CI provider, that the price had increased significantly, and that there was a company that even offered to take care of migrating their pipelines. I was surprised by this situation in CI, especially considering there are many choices these days to choose from. What opportunities might we be missing as an ecosystem?

This brings me to an interesting dilemma, which you can apply to many aspects of life, and is closely related to how services evolve over time, sometimes prioritizing profit over values. If you find yourself in a position where a service price increases substantially, and you feel constrained in your options, should it be your responsibility to maintain flexibility, or should that be the responsibility of the service provider? Ideally both parties would work together on this, but in today's world, maintaining your own flexibility is valuable.

We've reached this position partly because we've often entrusted CI providers with full ownership of our automation. It's completely understandable. When you're reading docs on how to set up a CI pipeline, you don't have time to think deeply about the long-term implications of choices made based on those suggestions, but some of them implicitly create strong dependencies on the service provider, which can eventually limit your options.

In this post, I'd like to share why taking more ownership of your automation might be beneficial in today's CI landscape, where dependencies naturally form and what you can do about it with today's tools, and share a bit about our approach to CI and our future plans.

Why owning your automation is a good idea

There are several benefits to owning more of your automation:

• Portability: In a world with many options, it's valuable to maintain flexibility to move between providers if needed (e.g., when your needs or circumstances change).
• Debuggability: If you own your automation, you can debug it easily because your automation is environment agnostic. You can run it locally or in any CI provider. At the end of the day, those should just be macOS environments with the development tools installed.
• Flexibility: When relying heavily on specific CI providers, you're constrained by the DSL of their pipelines and their capabilities. Many choose YAML as a format, which isn't always the most expressive language for complex automation needs.

Moreover, Git platforms like GitHub, GitLab, and Codeberg have incorporated CI capabilities where you can bring your remote build environments with services like Cirrus Runners and Depot. Thanks to that, you have a CI experience that's more tightly integrated with the platform where developers are already spending their time.

The provisioning of macOS build environments might get commoditized too by cloud providers like AWS, so at that point you might be able to just add your AWS credentials to your Git platform and voilà.

Because the space is changing rapidly, especially with projects like Dagger, we think the time is perfect to start thinking about taking greater ownership of your automation. Let's talk about pipelines first.

CI pipelines

When you think about the capabilities of a CI provider and how they're reflected in your pipelines, we can group the steps into the following categories:

1. Installing environment tools: Like Fastlane, swiftlint, or tuist. In many cases, you find steps that run brew install, and in other cases, you use steps from the provider, like with GitHub Actions where you have actions/setup-xxx steps that encapsulate the installation of tools.
2. Caching needs: Pipelines also allow declaring cacheable directories along with the logic for calculating a hash to store and restore them.
3. Core action: Every job usually has a core action, that's either a call to the language toolchain (e.g. swift test) or to some script that extends the underlying command with some pre and post logic and defaults. In the context of Swift app development, it's common to find invocations to Fastlane lanes, bundle exec fastlane build.
4. Exposing secrets: That are configured through their UI, exposed as environment variables to the pipeline, and filtered out from the logs.
5. Job composition: Then there are some pipeline primitives to combine jobs (e.g. run this one after that other one completes, or run these two things in parallel). This is an area where some companies have invested more than others, for example by providing a visual editor for the pipeline.

Let's talk about how you can take more ownership of each aspect.

Installing tools

It's common to see repositories having an install.sh script, or steps in the README.md that developers can execute or follow to install the tools. In some cases, the same script is run on CI, and in other cases, they use community steps that come with caching capabilities built-in. As we covered in this post, this is something that you can solve with Mise, and have a unified solution that works across environments (local and CI). All you need is a mise.toml file with the tools your project depends on:

So all you need in your pipelines and in your local environment is a mise install command. Simple, isn't it? Mise also supports installing any SwiftPM package that's publicly available in a repository by using the convention:

And even install tools written in other programming languages by pulling the binaries using UBI or letting Mise compile them from the source, for example Go or Rust CLIs.

A side advantage of adopting Mise is that you minimize issues related to inconsistent versions, and you can adopt tools written in other languages or that run in other runtimes, like Fastlane and Ruby, without worrying too much about whether developers will be able to provision their environment successfully. That's all delegated to Mise.

Mise all the things!

Caching

This is one of the more challenging aspects. Not because it's impossible to solve, since you could use a CLI to store and restore artifacts using an S3-compliant storage, but because the process would be quite involved and you'd need to build your own hashing function.

We started working on addressing this with cache, a tool that brings declarative caching capabilities to any scripts. We are drawing inspiration from usage regarding the design.

Action

This is an area the Swift ecosystem solved a long time ago with Fastlane, and it's something that many organizations use today. Fastlane provides sensible defaults to the underlying tooling, and has its own system for encapsulating and distributing shareable units of automation called lanes through Ruby gems.

Since Fastlane was created and popularized, a lot has changed, and we're starting to notice evolving preferences. Apple's toolchain has gotten better and more capable. We have LLMs that facilitate writing in languages like Bash, making scripts more portable without requiring a Ruby runtime. Note that by moving to something like Bash, you'd trade having access to an ecosystem of steps, but Bash has a registry too, Basher, and with LLM-based code editors being able to write most of your automation code these days, the need for sharing or accessing shared steps is not as pressing as it used to be.

At Tuist, all our scripts are bash. Once written, we barely touch them. You can model them as Mise tasks and use comments in the script to declare the CLI interface:

Secrets

Another capability of CI providers, one that in fact makes debugging pipelines harder, is exposing secrets and redacting them from the logs.

The former is something that Mise solves with their secrets capability. So your secrets can be part of your repository, but they're encrypted using a pair of public and private keys. This offers advantages over managing through your CI provider's UI, some of which don't have a record of the changes that happened in the past and the reasons that motivated them. With Mise's approach, that information is in the repo.

You can have one or multiple .env.json files, each representing an environment, and they are encrypted, so only the person (or the environment) with the private key can decrypt them.

Note that you'll need to be careful not to print their values through standard output. CI services redact the output, but by shifting secrets to your repo, that becomes your responsibility. This is something we (or Mise) might build tooling for in the future.

Job composition

Pipelines typically do things like run x and y in parallel, or on failure of x, run y. On top of this ability, CI providers build features like UI that allows you to visualize the concurrency and the timeline of the execution.

Note that concurrency is something that you can achieve within a single action. Most of the work that you'll do from there are IO-bound operations, like interacting with the network, or running a system process, and all runtimes provide a way to spawn multiple processes and wait for them to finish. In the context of Swift, this would be creating a task group and adding tasks to it.

Note that by doing that, we're making different tradeoffs:

1. The ability to retry individual steps.
2. The ability to visualize the pipeline execution.
3. The ability to work around concurrency limitations of underlying tools (e.g. number of simulators running)

We believe all of these challenges are solvable while maintaining flexibility, as Dagger is demonstrating, but exploring them in the context of app development is an opportunity that's still open.

What's next?

As you might have noticed, there are already many things you can do to increase your flexibility when working with CI providers, ensuring you can choose solutions that best fit your needs. While we're not yet at the ideal state in terms of tooling to maximize this flexibility, this is where we'd like Tuist to help. In the following months we'll explore:

• Bringing the declaration of caching needs closer to scripts and offering it as an open source commons that's platform and language agnostic.
• Building another open source tool and toolkit to redact secrets, and maybe hooking Mise into it to use it as a backend.
• Drawing inspiration from Dagger, and exploring what a Swift-based DSL that's CI-platform independent would look like. Unlike them, we won't virtualize using Docker, because for Swift apps, we need a macOS environment. We'll apply many of the learnings from building the generated projects' DSL. We'll use the toolchains for redacting the secrets and caching.
• Exploring alternative ways to enhance job composition. This is an area we're still exploring, so stay tuned.
• Also drawing inspiration from Dagger, we'll investigate if we can build a CLI-first experience for CI, where you can do things like piping logs to your terminal.

We strongly believe everyone should have the freedom to choose the CI provider that aligns with their values and needs, and we're excited to contribute tools that enhance this flexibility for developers.

Productivity goes beyond efficiency

When we think of productivity, we tend to think of achieving something in less time. However, in creative jobs such as software crafting, when someone doesn't feel slowed down by the tools they use, they are also inspired to explore new ideas, which transitively benefit the business. In other words, unproductive environments are poor grounds for innovation.

Developers' momentum is crucial

This is why we are so interested in productivity in the app development space—it's the way to impact the quality of the apps that organizations put out there.

But staying productive while building for Apple platforms is a challenge. When an app is small—one or two targets, a few dependencies, one product, and one platform to support—it's all fine. But how realistic is that? Very unrealistic. Sooner than later, momentum blockers knock at your door:

• A new dependency that comes with a Swift macro significantly increasing your compilation times.
• Recurrent random compilation errors that only go away once you clean derived data and waste your time in a clean build.
• One-liner PRs that need more than half an hour to get CI feedback.
• Tests unrelated to your changes causing your PR CI to fail, forcing you to retry and wait for another half an hour.

The manifestation of all this is usually teams unable to match the speed of other platforms (e.g., web), leadership being extremely concerned about it, and radical decisions like adopting React Native or swapping the build system with something like Bazel. Other times, if organizations can afford it, they throw more engineering resources at the problem, as if productivity were only directly correlated to the number of engineers. It's way more complex than that.

At Tuist, we love this domain. And the fact that Apple is not focused on this space makes app development productivity a sweet spot. I'm not writing this post to sell you Tuist, which of course I'd be happy if you do; I simply want to create awareness around the importance of protecting developers' momentum and what some common momentum drains are in app development.

In the following sections, I'll walk you through the most common momentum obstacles that we've seen in organizations:

1. Multi-repos

We've seen organizations, especially those with different products (i.e., multiple apps), scattering their targets across repositories. This comes with a versioning scheme and reliance on developers to follow it strictly (we are humans, we make mistakes). Changes are no longer atomic and span across repositories, releases need to be coordinated, and configuration needs to be made consistent through yet more tooling and processes (or alternatively, configuration becomes inconsistent across repos). Unless you have a strong need to share a piece of logic with other repositories or as an open source project, going down this path is a terrible idea. You'd be surprised to see how common this is in our industry.

What's the alternative? Monorepos. But monorepos make some classic assumptions and models fall apart. One of them is the idea that every commit should integrate everything in CI. That works fine if your monorepo is small, but if you change one line in app Foo, you don't want to be compiling app Bar in CI. This requires some investment on your end to be selective about what happens in CI, and this is something that Tuist helps you with. We selectively build and test based on the changes and try to optimize the process by reusing binaries across builds. This is what can make your 1-hour CI pipeline go down to minutes. Alternatively, you can make the investment yourself and leverage Git forge features like CODEOWNERS to improve the experience of working with monorepos, but I assure you it's worth the investment. Much better than having changes scattered across many repositories.

2. Slow feedback loops

When you change something, you want to see it instantly. This instant feedback loop is what keeps your ideas energized and what makes you stay hours building new ideas into your apps. Sadly, this instant feedback loop gets easily disrupted by the Apple toolchain:

• A cryptic error in Xcode
• A failing LLDB
• A failing SwiftUI preview
• A slow compilation

We've normalized all the above, but that's too bad if you ask me. We need to fight back and be more critical about how terrible this is for the ecosystem. There's some work on Apple's side to tackle this by making things more explicit and bringing capabilities of modern build systems into Xcode's, but things move slower than what the ecosystem really needs. Resources are scarce, and issues continue to pile up. A new version of Xcode comes out fixing one issue but introduces a regression somewhere else. Everything seems to be moving faster and more reliably outside of Xcode.

What does it take to improve the feedback and ensure things work more reliably? Embrace explicitness and consistency in your projects. Refrain from adding compile-time complexity, for example through script build phases, Swift Macros, or embeddable frameworks. The simpler and more explicit the compilation graph, the better for the reliability and performance of Xcode's build system, debugging tools, and editor. One thing that we don't cease to repeat is that the existence of a feature in Xcode doesn't mean it's the most suitable option at scale. For instance, while Swift Macros are cool, we'd use them sparingly. Or build scripts are something we try to avoid.

Hopefully with the above, developers will have to clean derived data less frequently (yay!). And if you still want a boost of performance in your feedback loop, you might consider something like Tuist binary caching and selective testing, which works with vanilla projects.

3. Friction while previewing

You've built a new feature or just fixed something, and you want to share that with the rest of the team, your leads, or the product designers who designed the feature in the first place? In the web ecosystem, you'd get a preview in seconds and share a link with your team that they can add feedback to. The frictionless nature of the process is an invitation to other people to participate in the feedback loop and help you shape the best work you can.

The same is not true when developing apps for Apple platforms. Sharing the app from the PR? Unthinkable. Building it locally if I'm a developer reviewing the PR? Too slow. The result? Trusting CI on their checks and reviewing the architecture of the code. But if the latter is something AI is going to be very good at, and there are signs of that because GitHub just announced that Copilot can be a reviewer too, how can humans support there? By manually testing the app:

• It feels slow
• It looks off on my iPhone 16
• The animation has too much delay

We need to match the web there. But we have nightly builds, Pedro... Nightly builds are terrible for this. Once the nightly build is created, you've lost the context of what has gone into it. If you have feedback, suddenly you have a new problem that you didn't have before—figuring out what introduced the bug that you are seeing, who authored that PR, and communicating what you saw with that person. Do you notice? It's just pure madness. That's why when we saw many companies rushing to build an App Center replacement, which is the easiest thing to do when you are a business and want to get customers, we didn't bother. It's not the right solution to the needs developers have.

Developers need a quick way to build and run apps to previsualize changes. You can build your own solution, use Shopify's tophat, or use Tuist Previews, but once you have something like this and educate not just developers but everyone, you'll make everyone part of the development process, not just developers, and this is a unique strength that you can have as an organization to build better products.

If web has got this, we can have it in app development too.

Imagine being on a PR and commenting, "Can you build a preview for me?" Or even better, chatting with your LLM of choice and saying, "Can I try the latest changes from main?" and getting an email with a preview link. We'll get there, and commoditization of virtualization is a key piece in enabling this.

4. Complexities

In large modular Xcode projects, complexity gets in the way. Complex errors like "framework not found" that people can't debug lead to cleaning derived data. Teams wanting to introduce new dependencies in the graph and not understanding the consequences of their actions can lead to unexpected behavior and bugs in the app.

Some complexity is accidental, other is inherent. Regardless of the type of complexity, if you don't compress it, you'll have a team of frustrated developers who waste their creative energy figuring out their tools and processes as opposed to building better apps.

We are big fans of the Ruby and Ruby on Rails mantra of optimizing for developer happiness. Usually, complexities, while an exciting challenge to understand for engineers, diminish any happiness in the process. Therefore, we find it quite useful to identify where complexity lies to ask oneself, "Is this fun?"

This question drives many of the product decisions that we make at Tuist and helps us determine which complexities we need to compress:

• Managing and evolving Xcode projects is not fun: We conceptually compress it with a DSL.
• Waiting for half an hour to get feedback in a PR is not fun: We conceptually compress the complexities to optimize the processes (it's just one command, tuist cache).
• Signing successfully is not fun: We'll conceptually compress the intricacies of managing certificates and profiles and signing for teams.

Eliminating complexities to make development fun should be an infinite game for teams. It's ours, so if you prefer to delegate that to us, we'd be glad to help.

5. Flaky tests

Flaky tests are non-deterministic tests—tests that sometimes pass and other times fail. Flaky tests are damn annoying. You open a PR, wait for a potentially slow CI to complete, just to see that a test unrelated to your changes failed. Then you retry because you are too busy and too far from that test to fix it, and move on. But someone else runs into the same issue, and another person too, and your team is wasting their time throughout the day. But it's all fine because your "test coverage" is high, and that's all that matters at the end of the day, right? I dare to say little to no flakiness is even better than high test coverage, which at the end of the day is not really an indicator of the quality of your tests or your business logic. This sounds too controversial, but I had to say it.

Flakiness is a momentum disruptor. A huge one. One that goes unnoticed and only becomes apparent when it's too serious.

And with Swift Testing encouraging parallelization, if you have flakiness in your codebase, it might become more apparent. Swift is not a functional programming language where state navigates deterministically in one direction. Global state will appear somewhere, making your tests and logic prone to race conditions, and voila—flakiness is there. If you think flakiness won't happen to you, think again.

Sadly, the tooling to address this is very scarce. Most of the tooling in the ecosystem consists of native apps, which don't have a shared globally accessible database where one can track how a test yields different results over time. Some CI platforms like Buildkite provide a solution for it, but since they don't have an understanding of the graph, they approximate a fingerprint to determine if a test has changed or not, disregarding the dependencies of the test. Tuist is graph-aware, so we can precisely calculate that at the module level and provide teams with a selective testing solution that's very accurate. And we just recently added support for Xcode projects, so you can use it in your projects already.

Closing thoughts

Your team is a valuable source of creative energy. Don't waste it. Really. Spend some time understanding what hampers their momentum, and invest in mitigating those factors. And if you need a hand with it, we'll be more than happy to help.

We are obsessed with making developers happy building apps, and we've made this our full-time job. Through our solutions, we've proved that abstracting the platform with something like React Native or replacing the build system with all the complexity of a build system like Bazel is not necessary. It's possible with your existing toolchain, believe us.

The challenges of modular Xcode projects

Managing a modular Xcode project in 2025 still presents unique challenges. At scale, configuring the right build settings and phases to link frameworks, libraries, and copy dynamic modules becomes increasingly complex. When your project contains dozens or even hundreds of modules, visualizing the dependency graph to make informed changes becomes difficult.

We've observed that your projects might occasionally compile successfully due to the build system sharing derived data across build steps. However, this can lead to unexpected issues with debugging tools or SwiftUI previews.

As applications expand to offer more products and support multiple platforms, modularization becomes not just beneficial but necessary. It's a sound architectural practice that enables you to use Swift access levels to define clear boundaries, making your applications more maintainable and allowing the compiler to optimize code effectively.

The industry's response

The ecosystem is actively addressing these challenges. The growing adoption of SwiftPM as a project manager demonstrates developers' desire for simpler solutions to complex modular projects. While SwiftPM brings clarity by avoiding the complexities of "build phases" or "build settings" terminology, it represents an evolving approach that continues to mature.

Companies like Bumble have contributed valuable insights by openly sharing benchmarks about developer experience challenges with large modular codebases using SwiftPM. These conversations are crucial for driving improvements in the ecosystem.

Project generation: Enhancing accessibility and performance

Since 2017, we've been working to address these challenges, first by creating XcodeProj for working with .pbxproj files, then developing Tuist as a project generator. Other tools like XcodeGen emerged with different approaches, giving developers options based on their specific needs.

In 2025, project generation continues to play a vital role by:

• Making modular codebase management at scale accessible to all developers
• Optimizing build times through features like cache without requiring the complexity of systems like Bazel

For teams dealing with extended CI turnaround times—sometimes exceeding an hour—these optimizations transform the development workflow and dramatically improve productivity.

An optimistic future

The future looks promising for iOS development tooling. The new swift-build system, with the swift-driver's content-addressable store (CAS), suggests that Apple is actively working on addressing core optimization challenges.

While we can't predict exactly how SwiftPM will evolve, Apple has both the expertise and resources to revolutionize their development foundations by incorporating lessons from ecosystems like Gradle and Bazel. The emergence of AI, LLMs, and innovative editors is creating exciting opportunities for Xcode to expand its capabilities and experiences.

At Tuist, we're committed to building a complementary productivity platform that extends these native foundations. We're continually expanding our feature set for standard Xcode projects, as demonstrated by our recent selective testing for Xcode projects feature.

The iOS development landscape is evolving rapidly, with multiple solutions working in tandem to create the best possible experience. As tools mature and new approaches emerge, developers will benefit from increased flexibility, improved performance, and smoother workflows.

If you're a developer, lead, or head of a mobile organization interested in designing a thriving development environment, let's chat. We're always eager to learn from and support organizations in making app development the most enjoyable experience possible.

While Tuist has had support for selective testing for a while now, it has been available only to those organizations that used Tuist to generate their Xcode projects and used the tuist test command to run their tests.

We're excited to announce that we're now making selective testing available to all Xcode projects, regardless of your setup, by extending the xcodebuild CLI:

That's really almost all you need to do to dramatically speed up running your tests on the CI or locally. And yes, this feature also works if you modularized your app with local packages 📦

Get started

If you want to see selective testing of Xcode projects in action, check out the video below:

To get started with selective testing, you need to first install Tuist. Once installed, you can run your tests almost as if you were using the xcodebuild CLI. The only difference being that you need to prefix the xcodebuild command with tuist:

Once your tests have run, Tuist will store your selective test results. Let's try to run the tests again:

...and that's it! You have now successfully used selective testing to skip running tests that have not been impacted by your changes.

If you want to test out this feature in a demo project, you can clone this repository and run the commands from above.

How it works

When you run tuist xcodebuild test, Tuist does a couple of things:

• Computes hashes for all your modules in your project
• Adds -skip-testing flags to the xcodebuild command with the modules that have not changed since the last successful run, based on their hash
• If the test command succeeds, Tuist stores selective testing results

Let's go step by step using the sample posted in the previous section. We can use the tuist graph command to see the structure of our project (and yes, tuist graph now also works for any Xcode project):

The important dependency relations are:

• AppFrameworkTests depends on AppFramework
• AppTests depends on App and transitively on AppFramework

When we run the tests for the first time, Tuist first converts your Xcode project to an internal representation called XcodeGraph (for more details, see our previous blog post on this topic). Then Tuist computes the hashes using the same mechanism as we do for binary cache, which has been battle-tested by now.

On the first successful run, we store the hashes we just computed – locally and remotely (if you have a Tuist project set up). On a subsequent run, Tuist can skip all tests if nothing changes. But what if something did change?

Let's say we change something in the App module. When we run the tests again, Tuist will recompute the hashes and compare them with the stored ones. Since the App module has changed and AppTests depends on this module, Tuist will run the tests for AppTests – but not for AppFrameworkTests as the hash for that module has not been impacted by our changes!

However, if we do update the AppFramework module, then Tuist will run the tests both for AppFrameworkTests and AppTests as AppTests transitively depends on AppFramework through App.

How much can Tuist skip in your project very much depends on how it's structured. The selective testing will be more effective if your project is modular and your modules are well-separated into separate layers, reducing interdependencies between them. For example, it's a good idea to have a "feature" layer where no feature can depend on another feature, only on the "core" layer.

Extending xcodebuild

Extending xcodebuild with selective testing is yet another step in meeting developers where they are by extending tools most of the community already uses, rather than building completely new abstractions. The main benefit of using tuist xcodebuild as of now is to get access to selective testing. However, we recommend opting in to using tuist xcodebuild now, so you continuously benefit from new improvements as we ship them, such as detailed analytics and insights of your tests and builds.

Optimizing projects and their interactions is key to making the most of one of the most valuable resources—engineering time. To achieve this, you need actionable insights that inform your decisions. That's why we're committed to providing you with valuable data to help you answer critical questions and create the most efficient development environment:

• Which test is the most flaky and disrupting workflow?
• What targets are becoming compilation bottlenecks, limiting parallelization?
• Which modules would benefit from additional testing?

You can expect these kinds of insights to be soon available in our Tuist dashboard, which is also getting a facelift. Here's a sneak peak, coming later this year:

Wrapping up

Selective testing is a powerful feature that can save you a lot of time and resources. It's available for all Xcode projects, regardless of your setup, and can be used both locally and on the CI. To learn more about how to use it, check out our documentation.

We're also always keen to hear your feedback – if you take selective testing for a spin, let us know how it goes at:

• Our community forum
• Slack
• Mastodon
• Bluesky

Among these contributors, some individuals have gone above and beyond. For a long time, we've felt a deep sense of gratitude toward them. Inspired by other community-driven projects like Dagger, we announced the Tuist Ambassadors Program in October 2024.

Today, I am honored to introduce you to our first Tuist ambassadors. But before we highlight them, let me share more details about the program.

The Program

Ambassadors are individuals passionate about Tuist and its mission. They are selected based on their contributions to the project and their ability to represent Tuist within the community. In recognition of their efforts, Tuist will publicly acknowledge their contributions and support their professional growth. Additionally, ambassadors will receive exclusive swag and assistance when attending events.

As we shape the direction of the project, we will collaborate closely with ambassadors to ensure alignment with our vision and goals. The role lasts for one year to allow for rotation, and we continuously welcome new ambassadors when we recognize outstanding contributions.

Meet the Ambassadors

Andy Kolean

Andy first engaged with Tuist by suggesting an enhancement to our graph command in this topic. He then followed up with an amazing contribution that introduced a solution to map Xcode projects and workspaces to Tuist’s internal models, specifically through XcodeGraph.

By bridging these domains, Andy’s work not only advances our mission to meet developers where they are but also enables a more high-level interaction with Xcode projects and workspaces. His contributions have had a profound impact on Tuist’s evolution.

Łukasz Lech

Łukasz has been making top-notch contributions to Tuist since 2020, from his home in the beautiful city of Wrocław, Poland. A strong advocate for Tuist, he has consistently highlighted its value in making Xcode projects and workspaces more manageable. He actively promotes Tuist at every opportunity, including at the Swift Heroes conference in 2024.

Loyle (Sang Hyeok Kim)

Tuist has gained significant popularity in South Korea, in large part thanks to dedicated contributors like Loyle. He not only delivers exceptional contributions but also plays a crucial advocacy role, spreading the word about Tuist within the Korean developer community.

Anıl Taşkıran

Anıl has been a long-time supporter of Tuist, especially in the Turkish community. He works at Trendyol, one of the largest e-commerce companies in Turkey, where he has been instrumental in introducing Tuist to his colleagues. Trendyol has been using Tuist for multiple years now and has been vocal about its benefits.

Closing Words

I couldn't be more proud of our ambassadors and the impact they have on the Tuist community. Over the coming months, we will continue working on new community initiatives to foster collaboration and innovation—key elements in building the most useful productivity tool for app developers.

Thank you to all our contributors, and a special congratulations to our first Tuist ambassadors!

In other ecosystems, like the web, workflows can run in Linux environments that can be easily virtualized with technologies like Docker or Podman. Even browsers can become containers with projects like WebContainers, in which you can run a NodeJS instance. StackBlitz leverages this technology to include interactive code examples in websites. Other projects like Replit or Bolt provide full-fledged AI experiences for creating and running code. As a project that likes to innovate in the developer experience space, we can't help but feel that we are lagging behind. But what would it take to catch up?

A macOS-dependent world

It's well known that developing apps for the Apple environment is tightly coupled with macOS as a host. Although Swift and its toolchain are taking a different direction to expand into new environments, Apple development remains heavily dependent on proprietary macOS tools and frameworks. Even UI technologies like SwiftUI remain in Apple's proprietary domain, making it difficult to port to other platforms or leverage it to create new AI-based coding experiences that build on SwiftUI internals.

Ideally, this wouldn't be the case, but with Apple being a hardware and service company, the likelihood of the toolchain breaking its dependency on macOS is very low. From a business perspective, such an investment makes little sense. However, who knows what the future holds? They might surprise us.

If breaking the dependency with macOS isn't an option, what's the alternative? Let's talk about virtualization.

Virtualization of macOS environments

Virtualization allows you to create isolated macOS environments on your machine. Apple released a framework called Virtualization to facilitate this. Docker and Podman are similar technologies for Linux environments. Docker revolutionized the way we build and run applications. Suddenly, your cloud provider didn't have to provide you with the exact environment you needed—you simply gave them your OCI image, and they ran it.

Most CI providers use virtualization to prevent polluting a host's environment. They create ephemeral environments for each build. The options to virtualize were quite limited and proprietary, with Anka being one example. These CI providers not only had to solve the problem of virtualization (which was delegated to third-party companies offering proprietary technology) but also had to develop the technology to orchestrate host environments and distribute workloads within them.

Unlike Docker environments, which cloud providers can provision in seconds via API, achieving the same thing in macOS is more costly. Images are not as lightweight as Docker images, so you can't pull them lazily since they can take minutes to download. Additionally, until recently, accessing Apple hardware was a manual process with data centers. AWS changed the game by providing APIs to spin up new machines. The complexity lay in maintaining a pool of Apple hardware, warmed with images and ready to run workloads.

As mentioned earlier, innovation in this space happened behind closed doors and was oriented toward building continuous integration. But thanks to the beauty of software, things are getting commoditized, which opens a world of opportunities.

Commoditization of virtualization

It's inevitable that software becomes commoditized through open source. Commoditization is the process of making goods or services more accessible and affordable to more people. Consider the process of building a web app today: you build it using an open-source framework and technologies, with an open-source programming language, that runs in open-source virtualization technology, on an open-source operating system, that most likely runs on proprietary hardware. macOS virtualization has been slow to commoditize, but that's changing.

Recently, we came across two efforts: Lume and macvm. Both are building technologies to commoditize macOS virtualization. macvm is also developing fugaci, a technology to orchestrate workload distribution using Kubernetes. We're getting closer to a point where an AWS key might be the only thing needed to bring CI to your organization, with solutions like GitHub Actions or Buildkite serving as frontends to runners. We're not far from that world.

This might not be great news for CI companies that have built their businesses around proprietary technologies. But for a small team of 4 people like us, who can't afford the cost of developing and maintaining such commodities, it's a game-changer. We can focus on innovating in the developer experience space rather than building yet another version of technology that others have built before.

Blurring local and remote environments

For many years, virtualization served CI businesses. CI is an easy way sell to investors and customers—you don't need to convince developers and organizations about its necessity. But what else could we do with virtualization? What can we learn from the web and other uses of Linux-based virtualization technologies? These are the questions we're interested in exploring and solving at Tuist.

Proprietary virtualization technologies and YAML naturally lead to automation that can't be debugged easily. Having to push code to see if a pipeline does what it's supposed to do is the result of investing in closed solutions. Now imagine this: you can have the same virtualization technology that you use in CI on your local machine. Suddenly, the same workflow that will run in CI is runnable locally, whether it's an xcodebuild command or your own workflow:

Let that sink in. Automation becomes easier to debug. What if you could then run the same workflow remotely with a version of Xcode of your choice?

The logs would be forwarded to your local machine, making it feel as if things were running locally. This is similar to the fly deploy command for deploying apps to Fly, where the image can be built remotely, but everything feels local. Isn't that amazing?

Why hasn't this happened before? We wonder the same... Virtualization is costly, so only companies with substantial resources could afford to innovate. Additionally, companies with resources often find it less risky to mimic other models and compete on the value-cost tradeoff than to innovate. Here comes Tuist: poor but sexy. We can innovate because we're not afraid to explore new domains, and the cost is decreasing.

If you thought that was enough, you're wrong. Have you noticed that most solutions in the space require you to trigger workflows either from a local environment or a CI environment? This is because they don't want to solve virtualization. But imagine if it were possible. You could enable workflows triggered from the web, just like triggering a GitHub Action workflow.

Let's say you're reviewing a PR and want to get a preview build. You could click a button, and a preview build would be triggered in a macOS environment, with the preview shared with you. Forget about those nightly builds or App Center replacements. Those models are fundamentally broken, yet we keep mimicking them and racing to create alternatives. This opens a world of possibilities—it could be a preview, a release, or even on-the-fly signing to allow someone to install a release on their device.

Closing Words

Apple decoupling app development from macOS is a dream that might never come true. However, the commoditization of virtualization technologies is a reality, and Tuist is going to leverage it to provide a better developer experience. Transitioning from being a purely client-side technology through our CLI to a web-based platform where the CLI is an interface to the platform positions us well to blur web and client boundaries in ways that ecosystems like the web have been doing for years.

While we don't have experience in building infrastructure, we have a strong appetite for learning about it and solving its challenges—not only to build better experiences ourselves but also to invite other companies and developers to innovate in the space, as we did with other commodities we've released in the past, like project generation and the XcodeProj parser.

I've been deep in the weeds connecting XcodeProj to XcodeGraph, turning raw .xcworkspace or .xcodeproj data into a delightful graph structure.

You might be wondering, "Why do we need a graph for something as 'simple' as an Xcode project?" Let's just say that once you start exploring advanced analysis, partial builds, or illusions hidden in tangly references, you'll be glad everything ends up in a single, coherent "map".

In this post, I'll walk through how the mapping process works, which pitfalls we cover, and why you might want to harness it for your own projects.

Why bother? The overgrown secret garden

Sometimes, your codebase feels like an overgrown secret garden: you open Xcode, spot multiple targets referencing frameworks, Swift packages, or script phases, but the big picture is elusive. XcodeGraph helps transform that hidden mess into a directed acyclic graph (DAG)—in simpler terms, a neat diagram of who depends on what. But it’s more than just a DAG: XcodeGraph provides higher-level models and user-friendly properties that abstract away the complexity, making the project structure easier to understand and interact with.

In contrast, XcodeProj offers a near 1:1 mapping of the .pbxproj format to Swift. It’s precise but low-level, exposing the raw details without much abstraction. That’s where XcodeGraphMapper comes in: it’s the pipeline that unifies this raw data into the more accessible structure that XcodeGraph provides.

The benefits are huge. Imagine wanting to only test modules that changed or to inspect a suspicious missing framework from a test target. Once your project is represented as a DAG with rich, user-friendly models, you can see those connections in a single pass. No more rummaging through thousands of lines in .pbxproj, just a straightforward structure to query or visualize.

Why Tuist & you should care

The XcodeGraphMapper will unlock many features that would have previously been reserved only to projects generated with Tuist to any Xcode projects – generated or not. Here are some examples of what XcodeGraphMapper makes possible:

tuist graph for everyone

We're enabling tuist graph for Tuist projects not generated with Tuist. Just run it and see your project's nodes and edges, maybe unearthing hidden complexities you never noticed.

Interactive graph & tools

Because it's a typed DAG, building a UI to click around each target, framework, or package is straightforward. Debugging cyclical references becomes a matter of visual search, not illusions.

Selective testing

Need to test only the modules that changed? Tuist uses the constructed DAG to detect which sub-trees your commit touches, so you can skip retesting the entire orchard.

Easier extensibility

We no longer rely on arcane .pbxproj hacks. The DAG is stable, letting you do custom scripts or auto-gen docs with minimal friction.

(And if you're curious to see real visual graphs in action, I wrote a post in the community forum about the XcodeGraphGenerator, plus a live demo here that shows what a friendly node-and-edge layout could look like. Check it out if you're a "pics or it didn't happen" type!)

A bird's-eye tour: step by step through XcodeGraphMapper

Step 1: Rummaging for .xcworkspace or .xcodeproj

First, the mapper checks if you handed it a .xcworkspace, a single .xcodeproj, or a directory containing one or both. Think of it like rummaging around your desk drawers, XcodeGraphMapper systematically hunts for the star of the show (e.g., "MyApp.xcodeproj") so it can read all your build settings and references. If it's a workspace, we open it and see if it references multiple subprojects. If you gave us a direct .xcodeproj, we skip the rummaging and dive right in. And if you toss a random directory at us, we'll see if there's a .xcodeproj or .xcworkspace inside, so illusions about "there's nothing here" don't fool us.

Step 2: Chitchat with XcodeProj

Once we find the target file, we hand it to XcodeProj, our best friend for reading raw project data. It extracts everything from the main PBXProject to build phases, Swift packages, script references, like collecting puzzle pieces scattered everywhere.

Step 3: Marshaling the troops (our mappers)

Now come the mappers:

• PBXProjectMapper merges project-level data into a top-level "Project" object, calling sub-mappers for each target.
• PBXTargetMapper captures each target's product, frameworks, Swift packages, resources, scripts, you name it.
• XCConfigurationMapper unifies build configs and .xcconfig references into typed "Settings."
• XCSchemeMapper scans .xcscheme for run/test actions, perfect for partial testing or environment variable analysis.
• PathDependencyMapper normalizes frameworks, .xcframeworks, or libraries into a domain "dependency" model so the graph sees them as a single node type.

By the end, each target, resource, or scheme is turned into typed domain models, leaving no illusions behind.

Step 4: One graph to rule them all

Finally, we gather all domain objects into a single adjacency list, the Graph. Targets or packages become nodes, edges connect them. We store conditions like "only watchOS" or "dynamic library" so advanced features can filter or visualize them with ease. No illusions left behind, just a neat map to reference.

Concurrency: Just enough magic to not block

You'll see async/await calls in the code, but we haven't gone full parallel mania, trying to parallelize every little call. Instead, concurrency is primarily used to avoid blocking on certain system calls (like retrieving the developer directory via xcode-select -p) or scanning large directories. That means we can yield the thread while waiting, so you don't beachball if the OS is in a mood.

We try to keep things straightforward: scanning, loading, and mapping in a single pipeline, step by step. It's simpler to maintain and still snappy enough for typical project sizes. Given our functional approach of mappers, we can easily parallelize more if needed – for now, parallelizing mapping of individual subprojects have been enough even for larger projects.

Edge cases & subtle quirks

Nested subprojects

Some folks place a .xcodeproj inside another .xcodeproj or do a container reference like "container:../OtherProject.xcodeproj." Don't worry, XcodeGraphMapper systematically follows those references. It's basically unstoppable (unless you form a cycle of references, in which case we throw an error and raise an eyebrow).

Local vs. remote Swift packages

Your package might be a local path or a remote Git URL pinned to a branch. Either way, we unify them under a single "Package" node in the final graph, so no confusion about which is which.

Schemes & scripts

Because we also read .xcscheme, we pick up test or run actions. That's how advanced commands figure out partial test runs or environment variables. We do the same for script phases, capturing them as typed "TargetScript" objects so you don't forget that magical "Run Script" step.

Odd build settings

If your codebase is truly bizarre (custom resource bundling, anyone?), we either parse it with general logic or skip it if it's unrecognized. We also throw typed errors if something crucial is missing. That means we fail fast if you reference a non-existent file or we can't find the path to a subproject.

A small example: MyApp + LocalLib + RemotePackage

Let's say you have a .xcworkspace with a "MyApp" target that depends on:

• A local static library LocalLib.a
• A remote Swift package RemoteKit pinned to version 2.1

XcodeGraphMapper sees your workspace, finds "MyApp.xcodeproj," merges them with the PBXTargetMapper, notices "MyApp" depends on LocalLib.a and also calls XCPackageMapper for RemoteKit. Boom! That yields nodes in your final graph:

MyApp → LocalLib.a → RemoteKit

If you run tuist inspect implicit-dependencies, you'll quickly see whether your tests also need "RemoteKit," or if you forgot to link "LocalLib.a" for a certain config. Simple and clear.

Looking to the horizon

• Parallel Parsing: Right now, we parse subprojects in a single pass. If you have a monstrous codebase, we might expand concurrency so illusions fall away faster.
• Deeper Data: Apple might add new frameworks or build phases, no illusions stay hidden once we add them to the mappers.
• UI Tools: A typed DAG is perfect for BFS-based lint checks, doc generation, or a "clickable" interface to roam your codebase.

Wrapping it all up

XcodeGraphMapper may sound niche, but it's the real hero bridging raw .xcworkspace or .xcodeproj references with the clarity of a graph-based approach. By the end of its pipeline, illusions vanish, references line up, and you're left with a single adjacency structure that's perfect for partial builds, advanced analysis, or simply not going bonkers rummaging through .pbxproj. If you're as excited about illusions turning into clarity, definitely stay tuned. We're just scratching the surface of what a well-organized DAG can do.

Thanks so much for reading, and huge thanks to Marek and the entire community for the encouragement and feedback. I can't wait to see how folks push these illusions aside in favor of a single, shining map.

Happy Coding,

Andy

Note: We're assuming that you have a Cloudflare account set up. The examples will be using GitHub Actions, but you can adapt them to any CI/CD system you prefer.

Build your DocC documentation

We'll first need to build the DocC documentation. The easiest way is to add the DocC plugin to your Package.swift:

You can check the documentation builds by running swift package generate-documentation. To make our lives easier on the CI, we'll generate the documentation into a specific directory and transform it for static hosting:

If you have multiple targets you want to generate the documentation for, we can leverage the new --enable-experimental-combined-documentation flag to generate a single documentation for all targets:

With this new flag, each target will have its own section in the documentation. In Swift 6.1, this flag will even create an index page:

We are very excited about this development as it will make it even easier to host documentation for packages with multiple products, which is quite common.

Set up Cloudflare pages

Let's first set up Cloudflare Pages by going to the Workers & Pages page and creating a new project. Once you have connected your GitHub account, you can import a repository that contains your DocC documentation:

You can also follow the official Cloudflare documentation. Note that since we will be deploying the documentation from GitHub Actions, we'll want to disable automatic deployment in the settings of the Cloudflare Pages project.

GitHub Actions pipeline

Now to the more interesting part. We will need a GitHub Actions pipeline that will build and deploy the DocC documentation to Cloudflare Pages. For this, we'll be using Cloudflare's Wrangler Action. To deploy from GitHub Actions, we will need to grab a Cloudflare API token. If you don't have a Cloudflare API token, you can grab one by following these steps. This token should be set as a CLOUDFLARE_API_TOKEN in your GitHub repository's secrets.

We'll use a Cloudflare example as a base to build out our pipeline:

This pipeline will deploy the documentation to Cloudflare Pages every time you push to the main branch. You can adjust the branches field to match your repository's branch naming convention. However, we still need to build the documentation. If your package is buildable on Linux, we can keep the ubuntu-latest machine and we'll need to set up Swift:

If your package builds on macOS only, you can switch ubuntu-latest to macos-latest and remove the Setup Swift step.

Before deploying, we'll reuse the step from the previous section to build the documentation and we'll update the deploy step to use the DocC artifacts:

...and that's it 🎉 Your DocC documentation will now be automatically built and deployed to Cloudflare Pages every time you push to the main branch. You can now enjoy your beautifully hosted documentation under your custom domain hosted on Cloudflare Pages.

If you want to see how we use this setup in practice, check out the XcodeGraph repository.

As a developer, this is generally not something you need to worry about. However, at Tuist, understanding this system has been on our backlog for some time, as we wanted to explore introducing optimizations and telemetry at a lower layer of the build process. The introduction of swift-build has shifted our focus, as it now makes more sense for us to explore that layer.

While working with one of Tuist's customers, we observed some unusual behaviors, including Xcode projects and xcodebuild processes hanging, without a clear explanation. This prompted us to investigate the communication between Xcode and XCBBuildService and build a small utility to help debug it.

XCBBuildService has been recently open sourced and rebranded as SWBBuildService.

The Format

Xcode spawns XCBBuildService as a system process and communicates with it through standard pipelines. Messages are formatted using MessagePack, a format similar to JSON but smaller and faster.

The types of messages exchanged can be found in the Mobile Native Foundation's XCBBuildServiceProxyKit project or in the SWBProtocol target of swift-build. Among others, you will find messages for:

• Requesting indexing information
• Pinging the service
• Listing the available sessions (since multiple can exist)
• Starting a build operation
• Notifying about the completion of a build operation

As mentioned earlier, you do not directly interact with these messages. Xcode and xcodebuild, acting as presentation layers, translate these internals into a debuggable UI or CLI output.

Debugging Messages with XCBLoggingBuildService

To facilitate debugging this communication, we built a new Swift package, XCBLoggingBuildService. It serves as a simple wrapper around XCBBuildService, logging the messages exchanged between Xcode and the service.

You can use it with Xcode or xcodebuild by following these steps:

First, clone and build the project the repository:

You can then use it with xcodebuild or Xcode

The logs are saved in /tmp/XCBLoggingBuildService.log. You can monitor them in real time using:

What's next

In the coming months, we'll explore the internals of swift-build, its extensibility, and the capabilities it offers for Tuist to optimize your projects and enhance telemetry for better decision-making. Of course, we'll document our learnings in this blog.

What is Mise?

Mise is a front-end for your development environment.
Okay, that might sound abstract, but if we talk about the problems it solves, it becomes clearer.
Almost every project has:

1. A set of tools it depends on.
2. A set of scripts to interact with the project from the terminal.
3. Environment variables to configure the interaction with the project.

Traditionally, developers address the first point with Homebrew, telling developers in the README.md file what additional tools need to be installed. However, this approach is not ideal. First, it’s manual, and second, there’s no mechanism to ensure the presence of not only the tools but the right version of the tools. The second point is usually handled with Makefiles, custom bash scripts, Ruby scripts run by Fastlane, or a mix of everything. If Fastlane is the tool, it requires developers to have Ruby installed, along with the Ruby dependencies (i.e., gems) installed via bundle install. Do you start to notice the amount of indirection? As for the third point, which is less common, it’s usually addressed by instructing developers in the README to introduce project state into a global environment, which is generally not a good idea.

Now, imagine simplifying all of the above to just one command:

Well, that’s what a front-end for your development environment is all about. Now that we’ve understood what Mise is, let’s walk through some of its features and how they can be valuable in the context of app development with Swift. Before continuing, make sure you have Mise installed on your system. You can install it by following these steps.

Dev tools

The first and most core feature of Mise is the ability to install and activate dev tools. Note that we say "activate" because, unlike Homebrew, Mise differentiates between installing a tool and making a specific version of it available. Thanks to this, you have control over which version of the tool is activated—either globally or scoped to a particular project. For example, let’s say we have a project that uses SwiftFormat, SwiftLint, and Tuist. We can create a mise.toml file with the following content:

Then, run mise install. This command will not only install the tools but also activate those specific versions. If you run swiftlint --version, you’ll see that it’s using the version specified in the mise.toml file. This might seem like a subtle detail, but inconsistent versions across environments are often a common source of wasted time debugging issues.

Backends

"How" to install a specific dev tool is determined by what Mise calls "backends." By default, Mise tries to use the asdf backend. asdf is another developer tool for installing developer tools, and the installation logic for each tool is declared in what they call plugins. For example, in the case of SwiftLint, there’s an official plugin that declares how to install SwiftLint.

But what if you want to depend on a Swift CLI contained in a repository that doesn’t have a plugin? Well, there’s the SwiftPM backend. In other words, Mise knows how to install it automatically without needing a plugin or a script that instructs Tuist on how to do so. If you’re familiar with Mint, think of the SwiftPM backend of Mise as Mint. The amazing thing about Mise is that you don’t need a tool per language or technology. You can use one tool to rule them all. In your mise.toml, you could declare the tool like this:

The backend will compile the CLI on the host, which may take some time and potentially fail if the required toolchain is not present. Therefore, it’s always recommended to provide binaries. However, as long as your CLI is not that big, this is a good way to get started.

Thanks to the dev tools in the mise.toml, you no longer need a lengthy list of steps in the README telling developers which tools they need to install.

Hooks

Let’s now talk about hooks. Some projects might require additional steps beyond installing tools. For example, if you’re using Tuist, you might need to run tuist install, or if you’re using Fastlane, you might need to run bundle install to install the Ruby dependencies. Mise allows you to define hooks that can run at certain moments, such as when cd-ing into a directory or after running mise install. The latter is particularly useful in the context of app development because it’s the place where we could install Ruby dependencies and SPM packages:

Environment variables

Mise also allows activating environment variables and secrets when entering a particular project. Unlike other ecosystems, using environment variables to configure Xcode behaviors is not that common. However, there’s a capability in Mise that can be quite useful in improving the ergonomics of your automation: Mise allows configuring the PATH environment variable, which is used by the system to resolve executables. Why is that useful? You might wonder. Well, if you’re a Fastlane user and are a bit tired of having to prefix your commands with bundle exec, you can use the following Mise configuration:

Tasks

Tasks are the last feature we’d like to talk about. At Tuist, we use them extensively across our repositories. Think of them as language-agnostic Fastlane lanes or Makefiles with superpowers. Tasks are scripts that you can invoke with mise run. They can be defined in the mise.toml file or in files following a conventional structure that’s then used to construct the full command name. We lean on using files to keep the configuration file tidy. For example, let’s say you’d like to have a task, build, to build the scheme MyApp of your project. You can create a file at .mise/tasks/build.sh with the following content:

You can run it with mise run build, or more interactively, run mise run and then select the task you want to run from the terminal. Cool, isn’t it?

There’s a lot to parse in the above script. Did you notice those annotations under the shebang? They are annotations used by Mise to provide extra capabilities. The description is used by Mise to show the description alongside the task name when listing the tasks, making it easy to recognize what the task does. You can also define aliases for the task. In the case above, we defined the alias b, which allows running mise run b. Last but not least, one of our favorites: the USAGE annotation. Usage is a specification to declare the interface of a CLI. Thanks to having a standard specification, it can be codified using comments, which Mise will use to parse and validate arguments for you, and then provide you with the values as environment variables. Thanks to that, we can turn our scripts into mini CLIs without having to include parsing and validation logic in the scripts:

Note that we wrote the above script in bash, but you could have chosen your language of choice, such as Ruby. By adding the tool to the mise.toml and updating the shebang to !#/usr/bin/env ruby, you can have the peace of mind that everyone will be able to run the script because Mise will take care of installing the right version of Ruby.

Some closing words

We think Mise is amazing. It’s a love letter to automation. When we gave it a try for the first time, we didn’t think twice about embracing it as one of our installation methods and making Tuist play an evangelist role in the Swift ecosystem. We recommend giving it a try in your projects and experimenting with it across local and CI environments. We bet you’ll find it as useful as we did.

This reconciliation effort had to happen at various levels, from frameworks to tooling. You might have seen Apple’s initiative to open-source Foundation. Foundation is so "foundational" to crafting software in Swift that Apple decided to decouple it from Apple platforms and make it open source.

One of the reconciliation layers that took longer to receive attention is the build system. With the recent announcement of Swift Build, Apple has signaled that this is finally changing.

In this blog post, we’d like to provide our perspective into what this might mean for the ecosystem, drawing from our extensive experience working with Xcode projects, and how it aligns with the plans we have for Tuist. But first, let’s talk about build systems.

Build Systems

A build system is software responsible for producing runnable or shareable software artifacts, such as a static library or a macOS app. Every modern programming language comes with a build system, typically integrated with other tools like test runners, formatters, or dependency managers. Rust has Cargo, Elixir has Mix, and Go has its go tool. In the Apple ecosystem, we have two: xcodebuild and SwiftPM. This duality exists as a consequence of reconciling two worlds.

Build systems require a representation of a project, which can be codified in the build system using conventions, serializable configuration files like Cargo.toml, or a mix of both. In the case of xcodebuild and SwiftPM, projects are represented in the hardly-serializable .pbxproj format and Package.swift files, respectively.

Build tools construct an in-memory representation of projects, typically resembling a graph. With this graph in memory, the build system can not only compile the project but also analyze it, optimize it, or even provide a foundation for coding experiences like language server protocols (LSPs).

In the Swift ecosystem, we’ve long had two graphs with significant overlap: one generic enough to work across many operating systems, and another tightly coupled to Apple’s OSs and Xcode. This resulted in duplicated efforts and challenges in delivering a great developer experience (DX). For years, the ecosystem suffered from features that either didn’t work, worked unreliably, or were simply slow.

A unified graph

With Swift Build, Apple is unifying the build system and the graph used by both SwiftPM and Xcode. If the toolchain is a stack of layers, with the build system sitting at the bottom of SwiftPM and Xcode, this unification is akin to pushing that layer down to share it across both tools. We think this is a great idea.

Note that the formats remain different—on one side, you have Swift packages, and on the other, Xcode projects. These are converted into a Project Interchange Format (PIF) before being passed to the build system.

The impact on developer experience

This unification will take time to fully materialize, but once it does, we believe the improvements to the developer experience will be unprecedented:

• Faster rollout of improvements: New features and improvements will only need to be implemented once, speeding up their availability.
• Increased reliability: Eliminating part of the reconciliation challenge should result in more reliable features, such as build determinism or SwiftUI previews.
• Extensibility: The new build system is designed to be extensible, making it easier for the community to add support for new platforms without directly contributing to the build system repository. Imagine selecting WebAssembly as a build destination directly from Xcode’s UI.
• Build-time optimizations: Apple is taking the opportunity to enable build-time optimizations similar to Bazel. Explicit modules were the first step in this direction, and the presence of a CAS (Content Addressable Storage) in the codebase suggests more optimizations are on the horizon.
• Foundation for new coding experiences: This unified build system can serve as a foundation for innovative coding experiences, pushing the boundaries of what’s possible in Xcode. AI is already proving that letting the market or ecosystem explore new ideas can be a catalyst for innovation.

We strongly recommend trying Swift Build in your projects and reporting any issues you encounter. Your feedback will help Apple refine this new foundation into something truly incredible.

How it relates to our plans

Tuist aims to improve the experience of building apps by extending Apple’s toolchain. An extensible foundation is something we’re very excited about because it unlocks new opportunities that feel more mature and aligned with the platform.

While the foundation provides all the information needed to understand and optimize projects, improving projects often requires a more holistic view of the data—how it evolves over time and how it connects to work happening in places like GitHub. That’s where our strength lies. We bring the server infrastructure, standardize the data, make it accessible to you, and build useful server features on top of it. This allows you to focus on checking out the code and building your apps with Xcode—or maybe Cursor in the future.

Reverse-engineering the internals of Xcode’s build system or Xcode projects is something we’ve done for many years. The possibility of not having to do that anymore is amazing because it frees up our creative energy to focus on other areas while supporting Apple in evolving this new open foundation.

The overlap between Swift Packages and Xcode Projects

You might have noticed that while the build system is being unified, there are still two formats with some overlap: Xcode projects and Swift packages. The former has its flaws, which have allowed us to build a thriving community at Tuist around generated projects. The latter is being used by many teams to address the shortcomings of Xcode projects. However, because Swift packages were never designed for this purpose, the developer experience starts to suffer at scale.

What will the future look like? It’s uncertain, but we doubt we’ll have two formats forever. Like xcodebuild, the Xcode project format was designed for Apple platforms and has accumulated a lot of legacy over the years, making it a nightmare to maintain at scale. On the other hand, Swift packages, where manifests need to be compiled and can easily introduce side effects, don’t seem ideal either—at least not without significant changes.

Perhaps we’ll see a Swift Build DSL, similar to Gradle’s Kotlin DSL, specifically designed for declaring build graphs without side effects. This DSL could be evaluated so that changes in it translate to graph changes almost instantly, Or who knows... perhaps PKL becomes the language. Regardless of the path, we at Tuist would love to see this developed in the open and would even like to take part in it if possible. We have many ideas from our experience understanding and optimizing Xcode projects that we’d love to contribute to the ecosystem.

Closing words

This is a move worth celebrating. Every new component that Apple makes open source is an opportunity for diverse ideas to emerge and for the entire ecosystem to improve. So, thank you to everyone who made this possible. We couldn’t be more excited about it, and we’re eager to see what the future holds for Swift.

Tuist Registry is a new feature that optimizes the resolution of Swift packages in your projects. Gone are the days when you had to install the full git history of any package you wanted to use – instead, Tuist Registry, built on top of the Swift Package Registry standard, allows you to download only source archives of the package versions you need – saving both time and disk space, locally or on the CI, and making the resolution more deterministic and reliable. The Tuist Registry mirrors the Swift Package Index and is available for any open source Swift package in the community – served from a global storage for low latency.

If you prefer to watch a video to learn more about the Tuist Registry, you can watch the following Tuist Registry walkthrough video:

Swift Package Registry

The Swift Package Manager has become the de-facto standard for managing dependencies in Swift projects. However, unlike some other package managers like Cocoapods or npm, SwiftPM does not have a central registry for packages. Instead, it relies on the package's source repository to host the package. While it does mean there's no need for a central authority for publishing and downloading packages, it also means there are some inefficiencies in how packages are resolved.

When you add a package to your project, SwiftPM needs to do a deep clone of any Swift package you want to use. This can take a long time to download and consume a lot of disk space, especially for projects with large git history. For example, a well-known app that moved to the registry reported that the disk space consumed by the registry resolution was 91 % smaller – going from 6.6 GB to 600 MB. The time to restore and save the cached dependencies on the CI, something done on every run, dropped accordingly from 2 minutes to just 20 s.

Apart from the performance and efficiency improvements, depending on the Git history and tags can lead to non-deterministic builds and potential security issues since the Git history is not immutable.

Luckily, SwiftPM now has the capability to centralize the resolution of packages thanks to the Package Registry Service evolution proposal SE-0292, which aims at addressing the following challenges:

• Reproducibility: A version tag in the Git repository for a dependency can be reassigned to another commit at any time. This can cause a project to produce different build results depending on when it was built.
• Availability: The Git repository for a dependency can be moved or deleted, which can cause subsequent builds to fail.
• Efficiency: Cloning the Git repository for a dependency downloads all versions of a package when only one is used at a time.
• Speed: Cloning a Git repository for a dependency can be slow if it has a large history. Also, cloning a Git repository is expensive for both the server and client, and may be significantly slower than downloading the same content using HTTP through a content delivery network (CDN).

While the registry has been used by some to allow organizations to distribute private packages through their internal registry, the usage to improve efficiency and developers' productivity remained unexplored until today.

Security

We take security very seriously at Tuist and the Tuist Registry is no exception. For a centralized registry, security is paramount. There are a couple of security measures that we have implemented to ensure the security of the packages in the registry:

• We only sync packages available in the Swift Package Index.
• Sources are always pulled directly from the original package repository.
• The swift CLI always verifies the downloaded package source archive checksums against the checksums provided by the registry.

Additionally, we're in the process of obtaining the SOC 2 certification to have a formal verification that our security practices are up to the highest standards. If you have questions around the security, shoot us an email at contact@tuist.dev and we'll be happy to answer them.

Get started

The Tuist Registry implements the Swift Package Registry standard and is thus compatible with any SwiftPM setup that you might have – regardless whether you use Tuist Generated Projects or not.

To start using the registry, first install Tuist. Then you need to have a Tuist Project. You can create one by running:

Additionally, you need to create a Tuist.swift file in the root of your project with the following content:

Afterwards, you need to run the following commands to enable the Tuist Registry:

...and you're done!

tuist registry setup automatically configures your project to use the Tuist Registry. When adding a package through the Xcode UI, you will now see the Tuist Registry as an option to resolve the package from (note the tuist.dev registry in the top right corner):

To learn more about the Tuist Registry, head over to our documentation.

Building a low-latency registry for open source packages

We implemented an API that complies with the specification to serve releases of all the packages listed at Swift Package Index, the default directory of community packages. Unlike decentralized resolution, developers get just the source code of every package version and do so from a global storage network that serves them with as minimum latency as possible. At the time of writing, we serve around 8.4K packages and 130k releases – and that number is growing every day.

When implementing the Tuist Registry, there were a couple of bugs that we found in the SwiftPM registry implementation. To fix these for anyone using the Swift Package Registry, we submitted the following PRs:

• Fix resolve failing when package from registry is referenced by name
• Fix registry resolution of major alternate package manifests
• Fix registry package swizzling when package name casing differs

All of these PRs have been merged and should be available as part of the next Swift 6.1 release. However, until then, we have fixed these issues in the Package.swift manifests when uploading a package to our registry. We plan to remove these workarounds when Swift 6.1 is used by the majority of the community.

Additionally, we also posted a PR to parallelize retrieving packages – both when using source control and registry resolution. Once this PR is merged and released, the SwiftPM clean resolution should be up to 2x faster. For anyone. We love to give back to the community and make the whole Swift ecosystem better for everyone.

Love letter to the community

The Tuist Registry is our love letter to the Swift community. It wouldn't have been possible without all the amazing work that the community has done. We're excited to see how the community will embrace the registry and how it will help to make Swift projects more efficient and reliable.

And always, feedback is welcome – if you have any suggestions or ideas on how to improve the registry, please let us know on our community forum or on our GitHub. We're looking forward to hearing from you!

This error occurs because macOS has a security feature called Gatekeeper, which is designed to ensure that only trusted software runs on the system. When you try to open your CLI, Gatekeeper checks if the software has been signed and notarized by Apple. If it hasn't, macOS will block it from running, displaying the error message mentioned above.

Homebrew, a popular package manager for macOS, attempts to apply an ad-hoc signature to the file using codesign --sign - to prevent this error from happening. However, we recommend you sign it with your own identity to ensure that the software is from a verified source.

All the code examples in this blog post are available in this gist.

What is code signing?

Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed. This is done using a cryptographic hash to validate the integrity and authenticity of the software. By signing your CLI, you provide a level of trust to the users and the operating system that the software is from a verified source and has not been tampered with.

What is notarization?

Notarization is an additional layer of security provided by Apple. After signing your software, you can submit it to Apple for notarization. Apple will scan your software for malicious content and, if it passes the checks, will issue a notarization ticket. This ticket is then attached to your software, indicating that it has been verified by Apple and is safe to run on macOS. Notarization helps to reassure users that the software is trustworthy and complies with Apple's security standards.

By signing and notarizing your CLI, you ensure that it can be opened and run on macOS without triggering security warnings, providing a smoother and more secure experience for your users.

Prerequisites

To sign and notarize your CLI, you'll need:

• A developer account, which at the time of this writing costs $99 per year.
• An app-specific password for your Apple ID.
• A macOS environment with the Xcode developer tools installed. Alternatively, you can use apple-codesign, which is a Rust crate that provides a CLI for signing and notarizing Apple artifcats from Linux environments.

Create a 'Developer ID Application' certificate

The first step is to create a 'Developer ID Application' certificate. You can head to the the certificates page and click on the 'Create a Certificate' button. Check the 'Developer ID Application' option and click on the 'Continue' button. To proceed, you'll need to generate a certificate signing request (CSR) and upload it. Once you've done that, you'll be able to download the certificate and install it in your local keychain by double-clicking on it.

Select the filtering option 'My Certificates' to ensure for each certificate you see the private key associated with it in a dropdown menu (screenshot below).

Sign the CLI

Once you have the pair of certificates, you can sign your CLI with the following command. $CERTIFICATE_NAME is the name of the certificate you want to use to sign your CLI, which you can find in the keychain:

Notarize the CLI

To notarize your CLI, you'll first need to zip the CLI binary:

And then upload it to the notarization service through their API:

Once the submission is accepted, your CLI should be ready to be distributed to the users.

Apple's documentation recommends to staple the notarization ticket to the binary. However, this doesn't work with standalone binaries, but since it's not mandatory, you can skip it.

Signing from non-interactive environments (CI)

Signing from a local environment is the easy part. However, when signing from a CI environment, there are a few things that you need to take into account to ensure that the signing process is successful. Many organizations and developers prefer to use Fastlane Match, which abstracts those intricacies away. But it's not as intricate as people think, so we are going to share how you can do it with a bash script.

Exporting the certificate and private key

To sign from other environments, you'll have to export the certificate and the private key that you generated. It's crucial that you export the private key as well since it's required to sign the CLI. It's something that's easy to do wrong, so make sure when exporting that you've selected 'My Certificates' in the keychain, and for each entry, you can see both the certificate and the private key. Then right-click on the certificate and export it as a .p12 file. We recommend setting a password for the .p12 file to add an extra layer of security. Store the password in a secure place, and make sure that the CI environment has access to it.

You can then turn it into base64 to expose it as an environment variable in the CI environment (e.g. BASE_64_CERTIFICATE). Alternatively, you can keep it encrypted in the repository and decrypt it in the CI environment:

Setting up the signing environment

In CI, you'll need to create a temporary keychain, set it as the default, and unlock it. Otherwise, the use of the system or login keychain, if it exists in remote environments, will most likely fail. Then, we base64-decode the certificate (and its key) and import it into the keychain:

Conclusion

By following the steps outlined in this guide, you can ensure that your CLI is properly signed and notarized for macOS. This not only helps in preventing security warnings but also builds trust with your users by ensuring that your software is from a verified source. Remember to regularly update your certificates and keep your signing and notarization processes up to date with Apple's guidelines to maintain a smooth user experience.

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 a Tuist Server, 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

At Trendyol, our journey with Tuist began as we needed to organize our large and complex project structures across multiple teams and domains. Even after introducing selective unit testing to accelerate our feedback loop by up to 80%, both local and CI builds continued to stretch beyond 30 minutes, affecting the pace at which developers could iterate.

As Turkey's leading e-commerce platform and a super-app serving more than 10 domain teams and 170+ developers across iOS and Android, speed at scale is supreme. To further optimize our workflows, we took the next logical step: leveraging Tuist Cache to improve build times and deliver a better overall developer experience.

Choosing Tuist

Originally, our motivation with Tuist was to enable caching for local development. Although CI speed matters, it's the local feedback loops that directly influence a developer's ability to experiment quickly. Once we began using the Tuist Server, we saw immediate benefits. With effective caching, Xcode no longer needed to spend significant time indexing files, making the IDE feel noticeably more responsive. Builds became faster, and the everyday frustration of waiting on incremental builds greatly decreased.

The approach

After speeding up compilation, we turned our attention to tests, which we could further optimize by running them selectively. At the time we started exploring this, Tuist had not yet shipped selective testing, so we built a plugin leveraging git diff and tuist graph to identify only the modules affected by code changes. This allowed us to run a more focused set of unit and UI tests.

Integrating selective testing with binary caching can be a game-changer. Here's how the two work together:

1. Change detection: We identify which files and modules were changed since the last build.
2. Targeted caching: Modules not impacted by the recent changes are retrieved from the Tuist cache. Instead of rebuilding everything, these modules reuse cached outputs.
3. Significant time savings: After a month-long proof of concept, our build times were reduced by 65%. In controlled comparisons, setups with Tuist caching consistently outperformed those without it.

This synergy between selective testing and binary caching dramatically improved developer productivity. Where we once faced slowdowns, we now had a seamless, accelerated workflow.

Moving forward, we'll work closely with the Tuist team to integrate our solution with their selective testing feature. Their implementation, which relies on a more accurate change detection system based on file-system fingerprinting, will further enhance the precision and efficiency of our testing workflows.

The results

From a developer's perspective, these enhancements have a tangible impact on everyday work. With selective testing and binary caching, developers spend less time waiting on builds and more time iterating on features or exploring solutions. Shorter feedback loops mean they can validate ideas quickly, focus on delivering quality, and better manage the complexities of a growing codebase without feeling slowed down by repetitive processes.

For example, consider a developer looking to write and run UI tests. Thanks to Tuist's caching capabilities, generating and opening a clean Xcode environment and starting to run UI tests now takes around 30 seconds, an experience that would have been nearly impossible before, when the same process took at least 15 minutes for a project of this scale.

Additionally, our CI build times have been reduced by 65%, decreasing from 30 minutes to just 10 minutes. This significant improvement allows our CI pipelines to run faster, enabling quicker integrations and deployments.

"Our CI build times have been reduced by 65%, decreasing from 30 minutes to just 10 minutes."

What's next

Our Tuist instance is self-hosted within our internal infrastructure. This setup ensures ultra-fast cache transfers over our internal network and guarantees compliance with our security standards. As a result, we enjoy the performance benefits of caching without any external dependencies or potential security concerns.

Our work with Tuist shows how investing in the right tools can lead to significant improvements in developer productivity and experience. We'll continue refining our strategies, exploring new techniques, and integrating with other testing methodologies. As we learn and evolve, we're committed to sharing our insights with the broader community.

"Tuist shows how investing in the right tools can lead to significant improvements in developer productivity and experience."

Additionally, TestFlight brings a lot of overhead to upload builds – such as going through the app review or having to sign the app in the PR workflows – which can be quite cumbersome for open source projects. This is where Tuist Previews come in. They offer a streamlined way to test the latest changes in PRs, making it easier for maintainers and contributors alike.

Recognizing the potential for open source apps, we partnered with Thomas Ricouard and integrated Tuist Previews in the new IcySky app. IcySky can now benefit from all the features that Tuist Previews offer and we get to iterate with Thomas and IcySky's contributors to make Tuist Previews even better.

Contribute by testing changes

Let's consider a common scenario: a user raises an issue that they found in the app. A contributor creates a PR that should fix the issue. But does it really?

Ideally, the issue author would test changes from the PR to confirm the issue is actually gone. But in most project, that would mean they'd need to set up the development environment and build the app on their device. That can often be a cumbersome process, especially for newcomers. But with Tuist Previews, the PR includes a preview link with the app pre-built:

Now, they can just click a link to see the changes on their simulator. The only prerequisite is to have Xcode and the Tuist macOS app installed. Contributors can then use the macOS app to test changes in multiple environments, such as iPhone or Apple TV:

And to make it easier to test the latest changes that have been merged to main, use a README badge to make the latest preview easily accessible by anyone:

To see Tuist Previews in action, you can watch the following video:

Set it up

Did the above pique your interest? Here's a few of steps to start using Tuist Previews in your open source project.

1. Install the Tuist CLI – if you haven't already, install the Tuist CLI.
2. tuist auth – authenticate and create an account if needed. We recommend using GitHub for authentication which is required for some features.
3. tuist organization create {organization-name} – it's recommended to create a Tuist organization unless you're working on a personal project. Run to create one.
4. tuist project create {organization-name}/{project-name} – create a new project in your organization. The full project handle follows the same convention as GitHub.
5. Create a Tuist.swift file in the root of your project with the following content:

6. tuist project update {organization-name}/{project-name} --repository-url {your-repository-url} --visibility public – connect your Tuist project with the GitHub repository and make its visibility public to make it accessible to developers outside of your Tuist organization.
7. tuist project tokens create {organization-name}/{project-name} – create a token for your project. This token will be used to authenticate with Tuist in your CI – copy this token and set it as a secret in your repository.
8. Install the Tuist GitHub app in your repository to get PR comments.
9. Add tuist share NameOfYourApp --configuration Debug --platforms iOS to your CI script to share a Tuist Preview. This needs to be done after you build the app. You can find an example of a CI script with tuist share in the IcySky repository. Ensure that the CI steps with tuist share has the TUIST_CONFIG_TOKEN environment variable defined with the value from step 6.
10. Add a badge to your README, so that you and contributors can easily download the latest version.

... and that's it – you have now made testing changes easier for maintainers, contributors, and users! All Tuist features are free for open source projects, so you can start using Tuist Previews today with no strings attached. To learn more about Tuist Previews, you can find our up-to-date documentation here.

Additionally, to see Tuist Previews in action, head over to the IcySky repository, including the PR for the initial Tuist Preview support. Huge thanks to Thomas for taking the time to set everything up and give us feedback. It means a lot 💜

And if you have feedback to share, we'd love to hear from you at our community forum 😌

Some developers normalize this as an inherent challenge of Apple native development. Others introduce dynamic runtimes like React Native, which can hot-reload code and skip most compilation cycles. Some organizations even consider absorbing the cost of replacing Xcode's build system.

For years, we have invested in solving this challenge using the most native and cost-effective approach possible through Xcode primitives. We believe that unproductive development environments can negatively impact organizational productivity and the quality of shipped applications. Our goal is to help organizations prevent such inefficiencies.

In this blog post, I'll share how Tuist addresses these challenges and the potential impact on your projects. Let's begin by discussing project graphs.

Your Project is a Graph

Your project forms a compilation graph that the editor uses to provide a coding experience and that the build system uses to generate build products. Traditionally, this graph was statically codified in .pbxproj and peripheral files like .xcconfig or test plans. The build could be dynamically configured during operations like build or test.

This landscape changed with the introduction of Swift Package Manager (SPM). Suddenly, projects gained references to another graph—the package graph—which was dynamically generated by SPM and reconciled at build-time with closed-source code.

How can we optimize this? Simply put, we need to skip compilation steps in the graph. However, Xcode's build system doesn't allow direct manipulation of internal graph processing, unlike build systems like Gradle.

You can add tasks to the graph via build phases or SPM plugins, but what's truly desired is a function that takes a graph as input and returns an optimized graph output. The image below captures this concept:

If optimizations were this straightforward, Apple would have implemented it already. To understand why it hasn't happened, we need to discuss hermeticity.

Hermeticity in Xcode Projects

Bazel effectively demonstrates the importance of hermeticity in build systems. In essence, hermeticity means a build system should produce identical output given the same input, regardless of the execution environment. This enables artifact caching and sharing across different machines—a critical feature in distributed systems.

However, Xcode's build system lacks hermeticity. Examples that break hermeticity include:

• Implicit dependencies relying on heuristics rather than explicit declarations
• Shared caches like derived data that can cause varying build behaviors
• Dependencies on external states like environment variables, system files, or user-specific configurations
• Non-hermetic scripts dependent on external commands with unpinned versions

Hermeticity isn't just about build optimization—it's crucial for making incremental builds more deterministic and improving features like SwiftUI previews. If the editor cannot determine the relationship between a change and the binary graph, previews simply won't work.

Optimizing Xcode projects would require Xcode to evolve its graph toward encouraging hermeticity and discouraging implicit configurations. While Explicit Modules represent a step in this direction, significant progress remains ahead.

Encouraging Explicitness and Mutating the Graph

Tuist introduces a Swift DSL for declaring project graphs. When users define their projects, they're essentially mapping out the module graph. The tuist generate command transforms this graph into an Xcode workspace and projects.

This subtle capability is key to project optimization. By generating Xcode workspaces and projects, we can optimize them during the generation phase.

While we can't completely solve hermeticity, we can encourage it through our APIs, particularly at the dependency level. By designing APIs that promote explicit dependency declarations, we can mitigate non-hermetic behaviors.

Our approach offers several advantages:

• Graph mutation using native Xcode project and target primitives
• A language that discourages non-hermetic configurations
• Utilizing XCFrameworks as compilation units

Caching and Selective Test Execution

By constructing a Merkle Tree that changes when a target changes, we can create unique identifiers for each target. This enables powerful workflows:

Tuist also introduces selective test execution. By persisting tests at the target level with associated hashes, the system can determine whether tests need re-execution.

Accelerating Feature Delivery

The combination of selective test execution and caching can yield significant CI improvements—up to 70% and beyond. Developers can optimize their Xcode projects without costly build system replacements or platform abstractions.

By declaring projects using a Swift DSL, teams can achieve optimizations, cleaner project structures, and more reliable Xcode performance. The impact on team productivity and business value delivery can be substantial.

Interested in learning more? Schedule a call with the Tuist team for a comprehensive walkthrough.

First, we need to meet developers where they are. If you prefer using Homebrew to install Tuist, we'll make it an official installation method. If you work with Fastlane, there will be a lane that seamlessly integrates Tuist. And most importantly, if you’re working on an Xcode project and want to introduce Tuist without overhauling your workflow, we’ll make that easy for you, too.

Accessibility also means breaking down language barriers. In many parts of the world, language can be a hurdle, and we don’t want that to stand between developers and Tuist. We’re committed to creating resources in multiple languages, fostering local communities, and helping developers everywhere learn how to scale Swift app development with Tuist. Communities have brought us this far, and we’re dedicated to giving back and nurturing these connections.

Pricing that’s accessible: open, fair, and transparent

But accessibility goes beyond tools and language. Pricing plays a crucial role, and it’s something we need to address today. All around us, we see a trend of closed, one-on-one negotiated pricing models, restrictive demo versions, and opaque pricing tactics that sales reps often leverage through fear. We believe this inaccessibility is detrimental, and we want to be part of changing that norm.

Everyone should have access to tools that enable faster, better app development, no matter their background or financial situation. If you're an indie developer just starting out, you shouldn’t have to pay for features that could significantly improve your daily work and app quality. It’s as simple as that. If we truly want to impact the ecosystem, we must ensure that everyone in it can access the tools that make this possible. We’re not a traditional sales-driven company—we’re here to empower, not exploit.

Our business model is straightforward:

• Through usage measurement, payments reflect the value derived from the tool.
• Thanks to large enterprises, we can afford to keep costs low or even free for indie developers and small startups.
• We’re committed to open-sourcing more, driving innovation, and enabling use cases we can’t even imagine today.

Join us in reversing this trend

If you share our mission of promoting accessible and sustainable tools in the Apple ecosystem, we’d love to collaborate with you.

If you're an organization or developer paying a hefty price for a valuable service with a pricing model you find unfair, or if there’s a tool you wish you could add to your setup without going through sales hurdles, let us know at contact@tuist.dev.

Our team will work with you to develop the feature, and in return, you’ll get lifetime access to it—yes, free forever, as long as there are no high underlying costs of infrastructure. Together, we’ll build something that’s more accessible for the entire ecosystem, and you’ll benefit from it at no cost.

Where possible, we’ll aim to make the client-side code open source, creating a commodity for the community, while the server side enhances the tool and sustains Tuist. You win, we win, and the ecosystem wins.

Deal? Let’s make the Apple ecosystem a more accessible, inclusive place for everyone.

In a few moments, you have the fix ready in SwiftUI. You run linters, format the code, and prepare a PR for review.

But then CI kicks in. The 100-module project needs to compile – and only after building the 30 external packages and parsing the SwiftSyntax tree for dependencies. Fifteen minutes pass, and the project is still compiling. You scroll through Mastodon, make a latte, and come back half an hour later, expecting to see a green checkmark. But CI is red. Flaky tests strike again.

You don’t have the time (or the context) to dig into the flakiness, so you hit retry, check your emails, read a new Swift newsletter, and follow some rants about Swift's concurrency model. Finally, CI is green. But wait – there’s a conflict in .pbxproj because another PR was merged while you were away. Fixing that will take another 30 minutes.

After 1.5 hours, you get the green checkmark and can merge your PR. The five-minute task has taken over an hour. Welcome to Xcode development.

Leadership weighs In

This is happening more often. Eventually, leadership asks questions. During your 1:1, your manager raises an important topic: React Native.

Leadership is concerned about the iOS team’s velocity compared to the web and Android teams, who adopted Develocity. As the team lead, you’re asked to weigh the costs and benefits of adopting React Native or other tools to catch up.

The team is skeptical about React Native. They’ve heard of companies that adopted it only to regret it, with valuable engineering resources diverted to support the migration. The app relies heavily on platform-specific features that would be cumbersome to handle in a cross-platform setup. In other words, enthusiasm is low.

At some point, you remember hearing about Bazel at a conference. It replaces Xcode’s build system, caches steps, and runs tests selectively. But setting it up is complex and maintaining it could strain your team’s resources. You’ve also heard of companies reverting their Bazel setups because the people who implemented them left. Not ideal.

Migrating to SPM? Perhaps, but after reading Bumble’s blog, you see that it introduces its own challenges. React Native starts to look like the most viable option, despite the cost.

There must be a better way

This is a common scenario in the Tuist community. Teams are frustrated with Xcode’s implicit configuration and the complications of managing a large build graph. Many try SPM, but this just adds another build graph to maintain. Sticking to the “Apple way” doesn’t always help either.

Xcode and Xcode projects are legacies. When configured well, they can be powerful tools for development. However, decisions made for convenience years ago now limit productivity, like linking binaries implicitly from system directories. It’s convenient – until it breaks and you’re waiting on a new Xcode update to fix it.

If only the build system were more explicit and flexible. This is where Tuist comes in. We might be new to you, but let me tell you: you can reduce these headaches for free. Trendyol cut CI times by 70% by adopting Tuist, which improved developer happiness by making it easier to manage the project graph.

Giving Tuist a try could save you hours. While not widely talked about, it’s an open-source solution developed over seven years, trusted by large organizations to deliver software faster.

Getting started with Tuist

Defining your project with Tuist’s Swift DSL feels natural and intuitive. The APIs mirror Xcode’s terminology, abstracting complex parts like linking dependencies and mapping build settings. Migrating the project only takes a week, and suddenly, builds are 20% faster – just from a cleaner, more explicit configuration.

Even LLDB, which had been flaky, starts working smoothly. And best of all, team members can now add or remove modules as needed. The platform team finally has a foundation for defining architecture and rules, giving everyone a productive development environment.

Speeding Up Compilation and Testing

Remember the original problem of waiting 1.5 hours to merge a simple fix? While Tuist minimizes conflicts, flaky tests and slow compilation times remain issues. But Tuist has solutions for these too, without replacing Xcode or adding the complexity of cross-platform tools like React Native.

By signing up with tuist auth, creating a project with tuist projects create, and configuring your CI pipeline to use tuist cache, you enable caching for external Swift packages. In CI, Tuist reuses binaries, reducing those 30-minute waits to about five minutes. Tuist even caches test results, so only relevant tests run after code changes. It feels like magic.

Going further with metrics and tripwires

Flakiness, cache inefficiencies, or bundle size increases can still arise. Tuist has built-in metrics and tripwires to prevent regressions. At the end of each run, you get a URL with a detailed project report:

Use it for free

If these challenges sound familiar, consider giving Tuist a try. Our advanced features are available under a free tier, and you can explore with a small project by running tuist init. Even our team uses Tuist daily, leveraging Xcode projects to their fullest potential.

If you’d like to see Tuist in action, have questions, or want to discuss how it could transform your project, schedule a call with us. We’d love to help.

If you would like to see it live, ask us questions, or walk you through how Tuist could impact your project, you can schedule a call with us and we'll gladly help you.

Innovation through an Open Source Philosophy

Tuist challenged us to create a unique and distinctive website for their product, one that aligns with the open-source philosophy of the project and its community. This approach, championed by its creators, Pedro Piñera and Marek Fořt, promotes shared responsibility and invites contributions for continuous improvement. Moreover, they view joy as the driving force behind their product, paying attention to details with the goal of creating simple yet powerful emotional experiences. As product designers, how could we not want to contribute? Let’s dive in!

Build Better Apps Faster

Now, what exactly is Tuist? This was one of the main insights we needed to address, as it is a product for developers, thus very technical in terminology and functionalities. It had to be understandable so that anyone visiting the website could grasp its benefits and advantages before considering its adoption.

Tuist is a platform designed to enhance developers' productivity when building their products through key solutions such as Tuist Projects, Tuist Cache, Tuist Tests, and Tuist Runs.

To further scale and evolve their product, they needed to connect these functionalities with potential clients, explaining to companies what needs they addressed and what these features entailed, in order to find their tailor-made solution plan.

Ultimately, they were ready to elevate Tuist to a new level, but their website was not keeping pace with their product.

A Design that Evokes Orderly Emotions

They required a distinctive design tailored to their product’s needs, evoking emotions in an attractive and powerful manner. Emotions that were measured and orderly, guiding and explaining the entire narrative of their product and philosophy.

In a market context where all websites were homogeneous and repetitive, we had a significant opportunity to stand out.

Our approach focused on two clear axes: firstly, giving a unique and distinctive personality to the Tuist brand, where a range of purples harmonized with powerful colors like lime and complementary shades, providing the dynamism and energy the brand required.

Additionally, we created unique, clear, and simple illustrations to support the more technical content.

Furthermore, we undertook exercises in visual hierarchy and storytelling to ensure all elements aligned with the product’s discourse and were on the same level.

The result was accompanied by a Design System that has allowed Tuist to continue scaling and evolving its brand universe.

Connecting the Product’s Purpose with the Brand

A brand's transformation is never-ending, just as we expect to continue seeing Tuist evolve and advance as a product. Guinda Team

Our marketing site design system is now publicly available in Figma and licensed under CC BY-SA 4.0. Feel free to use it as inspiration for your own projects!

Our principles

These are the principles that guide our pricing philosophy:

1. We charge per usage

Many traditional companies hide their prices behind a "contact sales" button, leveraging your lack of bargaining power to charge as much as possible. We believe that's unfair. Every company should pay the same rate based on usage. Put simply, if your organization is larger, you’ll likely use Tuist more and pay more than a two-person startup—no hidden fees, just straightforward, usage-based pricing.

2. You don't pay if you don't use it enough

If you’re an indie developer or a small company that doesn’t use Tuist extensively, you don’t have to pay anything. We believe that’s fair—no financial barriers should stand in the way of using Tuist. We’re here to help people build better apps, and when you’re just starting out, you may not have the budget for costly tools. Don’t worry; with Tuist, you can get started without the expense.

3. We aim to be the cheapest at every scale

We want to be the cheapest and most transparent option in the Swift app development ecosystem. If you think we are not, please let us know.

Our model

We’re a commercial open source company. We build open source software and develop paid extensions that fund even more open source development. Our open source and paid products are complementary—each provides value on its own, with no strings attached. If Tuist provides value to you, great! It’s free to use. If your usage grows, even better—we’re here to support you at scale. And if you decide it’s no longer the right fit, we’ve made it easy for you to move on.

This model grew out of seeing too many companies burden customers with “contact sales” banners and choices that lock them into platforms. We wanted a different approach: transparency in our pricing, openness in our intentions, and a commitment to building something enduring. This model is our answer.

Thanks to this model, we’ll keep building more open source tools for the Swift ecosystem and supporting local communities dedicated to creating better apps.

So we want to give back to the community by recognizing these people and their contributions. And we are doing so by introducing the Tuist Ambassadors program.

What is the Tuist Ambassadors program?

Once a year, we'll select a small group of Tuist Ambassadors who have been nominated by the community for representing Tuist, building bridges between the core team and all Tuisters, and leading by example in their own communities.

Tuist Ambassadors become recognized leaders and advisors in the Tuist community and strong advocates for the values of the project. They are not only Tuist experts: they lead, support, and inspire others. They play a pivotal role in advancing our shared goals.

What are the benefits of being a Tuist Ambassador?

• Visibility and recognition: You'll be recognized as a Tuist Ambassador on the Tuist website and in the project's communication channels. You'll get a special role in the community forum.
• One-of-a-kind Tuist swag: Ambassadors get our iconic Ambassador jacket and a custom patch for each Ambassador batch year.
• Access and influence: Ambassadors are more tightly integrated into the shaping process and have the ability to provide early feedback before releases are out. They also join periodic calls with the Tuist team to discuss roadmaps and provide feedback.
• Amplify Budget: Tuist supports Ambassadors who speak at external events, covering eligible expenses and providing other logistical support where appropriate.

What do you need to do to become a Tuist Ambassador?

The following criteria will be used to evaluate potential Tuist Ambassadors:

• Highly knowledgeable about Tuist - recognized expertise in the Tuist tech and able to articulate the benefits and vision behind Tuist.
• Have contributed to the Tuist project in a meaningful way, and/or is an active user of Tuist within their organization.
• Technical and direct tone, not "salesy."
• Do not come across to other community members as pushing another product, service offering, or agenda.
• Regularly produce technical content for the community such as presenting on community calls or contributing a blog post (at least once every six months).
• Represent Tuist at public events such as meetups or industry events (at least once every six months).
• Actively help other Tuisters in the community forum
• Provide feedback on Tuist features and releases
• Be a model Tuist Ambassador: respect our code of conduct, especially when critical of Tuist or defending Tuist against others' criticism; remain respectful, constructive, and fair

How to nominate someone?

The nominations for 2025 are now open. If you know someone who you think would be a great Tuist Ambassador, please fill out the nomination form.

In January 2025 we'll announce the new Tuist Ambassadors.

If you are new to using Swift on the server, one of the things you'll have to figure out is how to and where deploy your app. Historically, there has been many options to deploy your app. Some large-scale organizations resorted to tools like Kubernetes, which provided them with a lot of flexibility to deploy, scale, and manage their apps, and an independence from cloud providers. However, Kubernetes is not the easiest tool to use. So if you are a solo developer or a small team, you might want to look for something simpler.

You could always get your own server, SSH into it, and manually set things up there, but you want a system that is able to roll new versions out automatically ensuring there's no downtime. This would be hard to achieve through a manual configuration.

Simpler and an automatic alternative those models were using platforms like Heroku or Fly that made it easy to deploy your app. They made it as easy as running a git push or fly deploy command against them server. Those platforms are often referred to as PaaS (Platform as a Service). Their developer experience is top-notch, but since they sit between you and the infrastructure, you might have to pay an extra cost for the convenience they provide. What if the great DX could be achieved without that extra cost? That's the question that the Basecamp Team, in their process of moving away from the cloud, asked themselves when they created Kamal. They started referring to it as #nopaas.

What is Kamal?

Kamal is a Ruby-based CLI, that can deploy containarized applications to your own SSH-accessible server. All you need is an OCI-compliant (e.g. in a Dockerfile), a registry to push and pull the image from, and a server what can be accessed through SSH. Kamal will take care of the rest with an intuitive and well thought-out CLI.

Don't let the Ruby part scare you. You don't need to know Ruby to use Kamal. All the configuration is done through a very intuitive YAML-based configuration file.

In this post, we'd like to guide you through the process of deploying a Swift on the Server app using Kamal to an infrastructure provider like Hertzner.

Installing Kamal

The first thing you'll need to do is to install Kamal. If you have a Ruby setup already, for example to run Fastlane, you can use Ruby's gem install kamal command to install it. Alternatively, as suggested in the documentation, you can run it through a container, which eliminates the need to have Ruby installed on your machine:

Create a server on Hetzner

If you don't have a server yet, you can can create one on Hetzner or any other provider that gives you SSH access.

When you create a server, you'll be asked for the following information:

• Location: This will depend on where most of the request to your app will come from. In our case, we are going to select eu-central for the sake of this tutorial.
• Image: Select Ubuntu 20.04, although Kamal should work with other Linux distributions.
• CPU: Select the smallest one from either x86 or ARM64, which is enough for a small app.
• Networking: Select Public IPv6. Later on you can add a Public IPv4 if you need.
• SSH keys: This is a very important part since it will allow you to access the server. If you don't have an SSH key yet, you can generate one following this tutorial.

There are a handful of other options, from which we recommend you to enable backups in case you need to restore the server. Then scroll down to the bottom, give it a name, which in our case will be swift-on-server, and click on Create & Buy Now. In a few seconds you'll have your server up and running with the IP addres to access to it.

Make sure you can access to it by running:

Create a Swift on the Server app

If you don't have a Swift on the Server app yet, you'll need to create one. You can follow either this tutorial if you plan to use Vapor, or this other one if you plan to use Hummingbird.

Note that projects created by both frameworks include a Dockerfile (Hummingbird and Vapor) to build and run your apps. This is a requirement for Kamal, so if your project doesn't have one, you'll need to create it using those as a reference.

To make sure your app runs fine when containerized, you can run it locally:

If those commands succeed, you should see a log indicating that the app is running in some port.

Adding Kamal configuration

Once you have Kamal installed, a containarizable Swift on the Server app, and a server to deploy it to, you can start adding the Kamal configuration. Create the file config/deploy.yml in your project with the following content:

You'll have to create a file at .kamal/secrets with the following content to indicate the environment variables that Kamal will use to read the registry credentials:

By default, Kamal will use the hub.docker.com registry to push and pull the image, which is free for public images. GitHub and DigitalOcean also offer registries, so you can use them if you prefer ensuring that you set the registry.server URL in the configuration file.

Once you have the configuration file in place, you can run the following command to set up the server and accessories:

Once the server is setup, you can deploy your app by running:

Once the app is deployed, you can access it by visiting the IP address of the server in your browser. Remember that for IPv6 addresses, you'll have to wrap them in square brackets. For example: http://[2a01:4f8:c013:44ae::1].

Isn't it awesome? 🤩 With a single command you can deploy new instances of your app without any downtime. And not only that, you can use kamal rollback to roll back to a previeous version in case something goes wrong, or kamal app logs to see the logs of the app in real-time.

Bonus

As a natural next step, you might want to set up a domain to point to the IP address of the server, and configure the Kamal proxy to provide HTTPs automatically for your app. For the latter, all you need to do is to add the following lines to the config/deploy.yml file:

With the above configuration, Kamal will automatically request a certificate from Let's Encrypt and configure the proxy to serve your app through HTTPs.

Closing words

At Tuist we love simplicity and automation, and we believe that Kamal embodies that spirit for deployments. When you are getting started, or even if you are at the size of a company like 37Signals, the company behind Kamal, you might want to keep your infrastructure engineering and financial costs low without compromising the developer experience. We belive Kamal is unique in striking that balance, and can help you stay focused on what you do best: building your Swift on the Server app.

Until next time 🚀

At Tuist, we've engaged with numerous developers and companies about their experiences scaling app development, particularly in the context of Xcode and its projects. These conversations have highlighted common challenges and patterns that arise as projects grow. While we've shared insights within our Slack community, we believe it's important to reach a broader audience. Our goal is to equip developers and organizations with the knowledge to identify these challenges early and to provide a vision for how Apple could enhance the developer experience. But first, let's explore the topic of scaling.

Scaling

It's true that if you're a solo developer working on a small app with just one target in your Xcode project, you might assume you won't encounter many challenges. However, you'd be surprised to learn that these challenges can arise sooner than expected. The term “scale” doesn't have a strict definition; its meaning varies depending on the context. At Tuist, we think of scaling development as the process of ensuring that development remains enjoyable and productive, no matter the size of the app, project, or team involved. By decoupling these variables, you set the foundation for healthy, motivated teams, which often leads to better ideas—and ultimately, better apps.

Did you know that Ruby on Rails is designed to optimize for developer happiness? Apple takes a similar approach with Xcode, especially when you're just getting started. But as your project grows, the fun and ease of development can begin to fade. So, why does this happen? To understand this shift, we need to examine a principle that Apple consistently applies in its tools, and which we believe plays a key role in why things stop being fun after a certain point: convenience through implicitness.

Convenience through implicitness

Xcode and Xcode projects were once much simpler. Initially, there was only one platform to support: OSX. However, with the rise of open-source software and platforms like Git, the cost of producing software dropped, sparking an era of remarkable innovation. This innovation gave birth to new platforms, and as a result, Xcode and its projects had to evolve to meet the growing demands: sharing code, compiling a new programming language like Swift, supporting multiple platforms, and more. Managing such a vast ecosystem of app developers is no small feat, and Apple did an impressive job. They navigated the rapid pace of change while ensuring developers could transition smoothly.

However, in addressing some of these challenges, Apple introduced a reliance on implicit behavior and side effects as part of the system's design. While this approach worked well in practice, it also created a form of technical debt that developers continue to bear—and which still surfaces in the design of newer tools and systems. This may sound abstract, but let's break it down and make things more concrete.

Sharing code

Sooner or later in the life of the project, you need to share code within your app, whether through frameworks or libraries you've created to use with extensions, or to enforce access boundaries and improve your app's architecture. You'll also likely rely on third-party packages from other developers. You can think of your project as a directed acyclic graph (DAG), where each node represents a module—often modeled by an Xcode target, like a library or framework. Now, here's the challenge: managing this graph is hard. Adding or removing a module can create ripple effects throughout the entire system. For example, a dynamic framework might require certain upstream targets to embed it, or transitive static symbols leaking through a dynamic module could force their Swift module interfaces to be exposed elsewhere in the graph.

If this sounds too abstract, think of it this way: you can't just drag and drop modules in and out of the project without consequences. With one or two modules, you might get by, but as the graph grows, so does the complexity of the relationships between modules—and with it, the risk of breaking something. Some developers we've spoken to have described this issue as “needing to learn how Xcode works.” But we don't think developers should have to. Modularization is a standard requirement in almost every project, and it should be simple by default.

Did you know that your project might compile successfully purely due to side effects from previous compilation steps? One of your targets might resolve an import from another target not because it's declared as a dependency, but because it was already present in derived data.

Then there are the common questions developers face: Should this module be static or dynamic? Should it be a framework or a library? Can this product type embed dynamic frameworks? And what about dynamic libraries? What are the implications of linking a static library transitively? These are questions we ask ourselves frequently, and often have to answer by reverse-engineering Xcode-generated projects and validating outputs with App Store Connect. Surprisingly, this crucial knowledge—rarely discussed in depth—can have serious implications for your app, from runtime crashes to unnecessarily bloating its size.

In this case, the convenience of implicitness manifests as longer build times or build errors. Implicitness, along with things like mergeable libraries, are additional variables that introduce build-time complexity and variability, which can not only impact build performance but also make certain features, like Swift Previews, work inconsistently.

My Swift previews stopped working

We've seen countless developers give up on Swift Previews. At some point, their Previews simply stopped working, and they couldn't pinpoint why. While the exact causes are hard to determine—largely due to Xcode being closed-source—we can still make educated guesses about where the issue might be.

Imagine you're working in the Xcode editor with a preview open, and you change a line of code, either in the preview or in the transitive code it depends on. The editor must figure out what needs to be compiled and when in order to refresh the preview. As you might imagine, the larger and more implicitly linked the project graph becomes, the more difficult this task is for Xcode, leading to inconsistencies. It's ironic that features like implicit linking and embeddable frameworks, which were designed for convenience, can also introduce frustrations. It's no surprise that Swift Previews tend to work more reliably with dynamic frameworks, which are more self-contained, compared to libraries that require additional exposure of Swift modules or headers.

Our advice to teams has always been to make implicit dependencies explicit, eliminating variables that the build system would otherwise need to resolve, such as whether an embeddable framework should be static or dynamic, or whether an import Foo statement means the target intends to depend on Foo. Developers are often surprised when we recommend against using certain newly announced features. After all, who would expect these innovations to impact their projects negatively?

That said, we're optimistic about the future. Xcode's build system, while it may need to take a few steps back to reassess the path forward, is in the process of laying a more solid foundation. This will support exciting, compiler-dependent features like Swift Macros, enabling them to truly shine. In a sense, Apple is fixing the plane while flying it—because the business demands it—but we believe that a strategic “landing” to gain perspective would greatly benefit the entire ecosystem in the long run.

If any of this still seems abstract or exaggerated, let's pause and examine a phenomenon we've been observing for quite some time.

SPM as a project manager

Have you noticed developers turning to Swift Package Manager (SPM) as their project manager? While part of the motivation is the appeal of describing dependencies in Swift, we believe the real excitement comes from SPM's ability to propose an alternative way of defining a graph of modules. With SPM, you don't have to worry about whether something is static or dynamic (unless you want to) or if resources need to be bundled and copied. Like Tuist, SPM conceptually simplifies the complexity of linking, which naturally excites developers. Who wouldn't be? It's so appealing that many developers have tried replacing their Xcode projects entirely with SPM. Did Apple foresee this? Probably not. What seemed like a promising future for developers has turned into yet another challenge for Apple to tackle.

Apple now faces the task of reconciling two languages for defining module graphs: the one implicitly and "explicitly" codified in Xcode projects, and the one explicitly defined in Swift Packages. We say "explicitly" in quotes because, unsurprisingly, implicit behavior has also made its way into SPM. For example, packages that depend on XCTest are automatically discovered by SPM, even when they extend or wrap APIs. Additionally, Apple has to juggle two different build processes that must integrate as seamlessly as possible with Xcode. As many developers have experienced, this hasn't gone as smoothly as hoped. Package resolution can sometimes fail, leaving Xcode in a strange state, or result in invalid resolution states that are hard to recover from.

Xcode was originally designed with the assumption that all the information needed to code and build a project was contained within the Xcode project itself. But with the introduction of SPM, this assumption was upended. Now, the module graph is resolved asynchronously and communicated back to Xcode, which must adjust its UI accordingly. Reconciling these two approaches has been challenging and costly to maintain, making the system prone to regressions.

Let's not forget that when you add a dependency, SPM tries its best to make sure it works in your project, even if that means sometimes passing flags to avoid over-optimizations that could cause compilation issues. While this ensures your project builds, it can come at the cost of increased app size.

While we may not fully understand how Apple engineers manage to reconcile this internally, we recognize the complexity involved. Still, we remain optimistic: imagine if the time currently spent resolving these integration challenges could be redirected toward enhancing features. It's an exciting prospect, and we believe the groundwork being laid today will lead to a more streamlined and robust future for both Xcode and SPM.

What if the plane could be landed?

Imagine for a moment that Apple could pause, step back, and simplify the existing complexities, rather than adding more systems and languages that need to be reconciled. What might that future look like? It's an intriguing question—one we think about a lot, and we'd like to share our thoughts with you in this blog post. Admittedly, this vision is quite idealistic, and in reality, there are many factors beyond the technical that could make it difficult to achieve. But in a world where those obstacles didn't exist, here's what we'd love to see:

A unified graph language

This applies to both local and remote targets—we don't see a reason why there should be two separate systems. The need to reconcile them creates a problem that shouldn't exist in the first place. Ideally, the language used should be fast to evaluate and free from side effects. Is Swift the right choice for this? We're not sure. On one hand, being able to declare things in Swift is fantastic—it's one of the main reasons developers love the language. But on the other hand, side effects are inevitable, and they go against the principle of predictable behavior. Swift doesn't seem to enforce this strongly enough. Bazel developed its own language, Startlark, to avoid such issues—could something similar be an option here?

An optimizable build system

A build system should be hermetic, with steps that are cacheable. As codebases grow larger, especially with the increasing number of supported platforms, faster hardware can only do so much. The pace at which compilation times are slowing down far outstrips hardware improvements. We've seen companies where CI turnaround times stretch to an hour—and no, it wasn't Meta. This could happen to any team if a small app becomes successful and evolves into a large, complex project.

Implicitness as an invalid state

Implicitness should never have been accepted as a valid state in Xcode projects, and it certainly shouldn't have carried over into SPM. The build system should enforce explicit declarations—if something isn't explicitly defined, the compilation should fail immediately. Developers shouldn't have to wait minutes only to get a "framework not found" error. The system should construct the graph, analyze it, and fail right away if something is wrong. Developers' time is invaluable and shouldn't be wasted. And yes, this means rethinking how derived data stores build artifacts.

Default to automatic static/dynamic and framework/library decision

Developers shouldn't have to worry about whether something should be static or dynamic, or whether it should be a framework or a library. With knowledge of the module graph, the destination platform, and the build configuration, the build system should be able to make these decisions deterministically, while still giving users the option to take control when necessary. Apple already knows, for example, that iOS apps can't include dynamic libraries—so why put developers in the position of having to dig up this information and make these choices themselves?

Apple has taken a step in this direction with .automatic linking in Swift Packages, but what about project modules? This is why we advocate for a unified language that spans both local and remote modules—it needs to be consistent across the board.

Atomic output products

By making output products fully atomic, you enable developers to easily share artifacts that others can simply drag and drop into their projects—no fuss, and everything just works. You might be thinking, "Isn't that already the case with XCFrameworks?" It was definitely a step in the right direction, but it's not entirely atomic. For example, if a dynamic XCFramework links a Swift library statically and the symbols aren't private, you'd have to distribute the transitive Swift modules separately because you can't include more than one .swiftmodule in an XCFramework.

And what if someone shares a static pre-compiled binary with you that causes duplicated symbols or bloats your binary size? Ideally, Apple's system could detect this, wrap the static binary in a dynamic one, and ensure everything works smoothly.

More documentation

We need more comprehensive documentation on the various product types (e.g., app, framework, library, extension), valid graph configurations—such as including extensions in apps—and addressing inconsistencies across platforms, which ideally should be eliminated. While this knowledge is currently codified in Xcode's “create target/project” template, it should be accessible elsewhere.

Even better, a new language could reduce the need for extensive documentation. Instead of thinking in terms of “embed this framework into this bundle,” “make this target static,” or “share this dynamic framework with the extension,” developers could simply express it as, “my app has an extension, and they both share utilities in this module.” Wouldn't that align more closely with developers' mental models?

Closing words

It would be fantastic if Tuist's project generation feature were unnecessary. This would signal that Xcode's fundamentals have evolved to meet the current and future needs of companies and developers. We don't believe the solution is to replace Xcode's build system with another like Bazel. Instead, we'd love to see Apple invest in enhancing the existing system. If communicated well, the community would understand that this may come with some initial pain, but ultimately lead to a more reliable and faster app-building experience—exciting more developers and enabling them to work more efficiently.

Tuist, like CocoaPods before it, had to adopt project generation because there were no better alternatives. While we will continue to support organizations in this way, we envision a future where we can evolve into an extension of the build system, adding extra capabilities through a server and database. We're already moving in that direction, but we also need to devote significant energy to managing and simplifying the complexity that exists in Xcode projects.

We love Swift, but we also have a deep appreciation for Elixir and Erlang. These languages demonstrate how modeling a problem space can significantly impact the simplicity of the solutions you create. Erlang's approach with processes is a prime example, and we believe Apple's ecosystem is ready for a language that can elevate Xcode to where it deserves to be.

Apple and the Xcode team, you've done an incredible job. We admire Xcode and many of its features, which are ahead of many other editors. However, the current foundation limits some of that potential. So, shall we land that plane?

Meeting developers where they are: GitHub integration

One of the principles we embrace at Tuist is to meet developers where they are.

• We chose Swift over YAML for the manifest format because developers love writing in Swift. This choice also unlocks many possibilities that aren't achievable with YAML.
• We integrated with and aligned ourselves with the Swift Package Manager because it has become the standard for managing dependencies in the Swift ecosystem.
• We added support for binary caching using Xcode project primitives instead of asking developers to change their build system.

But where exactly are Xcode developers? While they spend a large portion of their time in Xcode, they also spend significant time on platforms like GitHub or Slack, collaborating with their peers. Should we meet them there? We think so!

Traditionally, meeting developers on these platforms meant teams had to develop and maintain complex CI workflows that pushed data to these platforms. Although this approach worked, it exposed organizations to malicious actors because secrets were often revealed in CI workflows. Furthermore, the absence of a place to store data over time limited what teams could do with these integrations. Imagine being notified when a pull request introduces a regression in build times or when a newly introduced test in the codebase is flaky.

At Tuist, we had the most crucial element to enable this type of developer experience: a server that persists information from your projects and runs over time. However, we were missing one key piece—the integration of our server with one of the platforms where developers spend most of their time, GitHub. That’s why we’re excited to announce that Tuist now integrates with GitHub. With a simple command, you can connect your remote project with a GitHub repository.

You also need to install the Tuist GitHub app in your repository.

Once you integrate with GitHub, Tuist can automatically post your test results and previews that you can run with a single click.

Implicit dependencies: Developers' worst nightmare

Xcode can resolve dependencies implicitly. Imagine this scenario: a developer adds the following line to a source file:

Suddenly, the module containing that source file depends on Network. This seemingly small change is a frequent cause of build-time slowness and Xcode instability. Implicit dependencies introduce new variables that must be resolved, not only during the build process but also while editing—when you're trying to load SwiftUI previews or get LLDB to work. In other words, Xcode's editor and build system are unexpectedly faced with new questions that need quick, reliable, and deterministic answers. And this isn't something that's widely discussed.

Unfortunately, Tuist can't fix this issue due to how Xcode builds artifacts. However, many organizations that adopt Tuist report improved build times. This isn't because of Tuist itself but because the process of adopting Tuist often involves reviewing the dependency graph and converting implicit dependencies into explicit ones. Our frequent advice is to embrace explicitness as much as possible and remove uncertainties from the build system.

Since we can't configure Xcode's build system to disallow implicit dependencies and tweaking build settings didn't produce the desired results, we decided to add a new command that uses static code analysis to catch implicit dependencies. It won't catch every instance, but it will identify many of them. We hope this command helps you detect implicit dependencies early in your development process.

If you have a Tuist project, you can use the following command:

The command will output any implicit imports it finds and fail if any are detected. Magic 🪄, right? Special thanks to Gorbenko Roman for leading the development of this feature. He's already planning an even tighter integration with Xcode.

Other changes

• Hilton Campbell added support for detecting when dependencies are outdated and a tuist install is required.
• Hilton Campbell also fixed a bug that caused false positives reporting side effects with static dependencies.

What's next

We are working on a new website, which we plan to release soon, and we are starting to work on Tuist Workflows and Swift-based automation solution that blurs environments, decouples organizations from proprietary CI YAMLs, and takes a CLI-first approach to automation. We expect the infrastructure and technology work required to enable this feature to be the foundation for many other features in the future.

Today, we are excited to announce that the Tuist app for macOS is finally here!

Download the app

How the Tuist app streamlines the Tuist Previews flow

Until now, you would share and run Tuist Previews exclusively with the CLI:

Clicking on the Preview link wouldn't do anything. This changes now. After you install the Tuist app on your Mac, opening the link in the browser will automatically run the shared app in the simulator that you selected in the menu bar app.

To select a simulator, choose one from the list in the menu bar app. You can also pin your favorite simulators, copy their names and identifiers, and launch them.

Check out the video below to see the new app in action:

Future Preview Improvements

Wondering what else is coming to Tuist Previews? Here are some of the features we're working on:

• Run builds on your device, not just simulators: We are laying the groundwork to enable this functionality while simplifying the signing process for you. We want to ensure that signing complexities don’t detract from your experience, and we have the solution to make it seamless.
• Download the latest builds of apps from your organization: Want to try out the latest version of an app? You’ll soon be able to do so directly through the app. Imagine having a badge in your repository’s README.md that opens the app with just a click — mind-blowing, right? We’ll support that too.
• Android previews: We are exploring our path into the Android ecosystem and figuring out how we can provide value there. Android Previews might be one of the first steps in this direction.

Do you have any suggestions or want to get involved? Let us know on our GitHub or join the Slack community. The app is completely open source, and you can find it here.

The Future of the macOS App

Although the macOS app is currently focused on previews, we don’t plan to stop there. We’ll continually seek out opportunities to enhance Tuist by leveraging the native capabilities of the platform, aiming to make your development experience even more enjoyable. We are committed to developing a flexible and well-documented API, enabling any contributor to extend the app’s capabilities and even build their own clients using Apple’s robust technologies.

However, Swift Macros quickly revealed a serious challenge: they can significantly increase build times, causing slow feedback cycles both locally and in CI environments. This blog post aims to explain where the build time slowness comes from, what potential solutions we might see Apple adopting, and what we can do in the meantime to mitigate the issue.

What is a Swift Macro?

A Swift Macro is an executable that receives and outputs an abstract syntax tree (AST) via standard input and output. This process is called Macro Expansion. When a Swift Macro is added to an Xcode project, Xcode builds the Swift Macro into a static binary and then invokes it when the compiler encounters a piece of code that references a macro. Swift Macros typically depend on SwiftSyntax, a package for working with AST representations of Swift code. The compiler needs to compile SwiftSyntax along with its more than ten transitive dependencies and then link them statically against the binary to ensure the executable runs instantly.

To back this blog post with data, we created a Swift Macro and used the hyperfine tool to measure the time it takes to create a clean release build of a recently-created Swift Macro:

The above test on a MacBook Air M2 from 2022 with 16GB of RAM yielded the following results:

~3 minutes seems reasonable, but the times get worse when you add more Swift Macros to your project.

A non-API-stable SwiftSyntax

If you add multiple macros that depend on multiple SwiftSyntax versions, Swift Package Manager will fail to resolve the dependencies due to conflicting versions. As PointFree recommends, authors should be as flexible as possible in their dependence on SwiftSyntax.

Softening the version requirements of SwiftSyntax in the Swift Macros might help, but it requires SwiftSyntax to be API-stable, which will hopefully happen according to this comment after the Swift 5.9-aligned release. Even with that in place, you'd still have to rely on Apple doing a good job of making the API stable—which I think is a fair assumption—and on developers adjusting their Swift Macros to soften the version requirements.

What if we pre-compile SwiftSyntax?

Even with the above, you wouldn't get rid of the X minutes it takes to compile SwiftSyntax. One might think that Apple could provide a pre-compiled version of SwiftSyntax, but as of today, there are two large obstacles:

• SwiftSyntax is not ABI stable, so they would have to solve that first.
• Swift is not ABI stable on non-Darwin platforms (e.g., Windows, Linux).

What this means is that even if Apple made SwiftSyntax ABI stable, providing binaries of the package wouldn't work in non-Darwin environments. Will Apple invest in that effort? That's a big question that only Apple can answer, but past work on non-Darwin platforms was traditionally done by the community.

WebAssembly to the rescue

There's a technology that ticks all the boxes for what a Swift Macro needs:

• A way to run safely in a runtime.
• A way to ship a compiled version of it that runs in any version of the runtime.

That technology is WebAssembly, and Kabir Oberai had the brilliant idea to support that as the technology to run Swift Macros. And thanks to the WasmKit runtime, the problem is not only solved for the Darwin platform but also for Windows and Linux. There's an ongoing conversation in the Swift Community forum, so hopefully, we'll see this technology being adopted soon, which will require Swift Macro authors to compile their Swift Macros to .wasm binaries and ship them alongside the source code.

What Tuist is doing

Tuist is uniquely positioned to solve this problem thanks to our ability to optimize a source's dependency graph with binaries generated from previous builds. As soon as Swift Macros came out and we started seeing the build time issues, we extended caching to support Swift Macros too. Adopting this is very straightforward if you are using Tuist Projects. All you need to do is run the following command to fingerprint and store your Swift Macros, frameworks, and bundles:

And the next time you or anyone on your team generates an Xcode project, they'll be using a previously-generated binary. It feels truly magical to see how fast the build times are after adopting this feature.

If you want to see this in action, you can play with one of the Tuist project's fixtures:

1. Clone the repository: git clone https://github.com/tuist/tuist.
2. Install the repository dependencies: mise install.
3. Choose the example directory: cd examples/xcode/generated_framework_with_native_swift_macro
4. Install the project dependencies: tuist install
5. Cache the dependencies: tuist cache
6. Generate the Xcode project: tuist generate

The following image shows the generated Xcode project where all the dependencies, including the Swift Macros, have been cached:

Closing

There are three possible solutions we might see Apple adopting:

1. Making SwiftSyntax ABI and API stable, and Swift ABI stable on non-Darwin platforms.
2. Using WebAssembly to run Swift Macros.
3. Supporting fingerprint-based binary caching in Xcode and Swift Package Manager.

(1) would be highly beneficial for the community, but it will test Apple's willingness to invest in other platforms or leverage the community to make that happen. (2) would show Apple's willingness to embrace web technologies, avoid reinventing the wheel, and help advance the web ecosystem, but Apple hasn't had a good record of doing that in the past. (3) would be the most pragmatic solution, but it would require Apple to make a significant investment in the build system, which has been historically slow to evolve, and there are many projects out there that accidentally build through implicit configuration that might break if such a feature is introduced.

Regardless of what happens, Tuist will continue to address these challenges in the simplest and most fun way. If you are interested in learning more about Tuist, you can check out our documentation.

When a developer has something built and running and wants to share it with their team, for instance, to gather feedback, they have to jump through hoops to get it in front of the right people. Isn't it crazy that something that's right there in your environment can't be easily shared with others?

Fortunately, that's no longer the case. We just released a new version of Tuist, 4.23.0, which introduces a new feature called Previews.

The current state of collaboration

Traditionally, teams have relied on platforms like Visual Studio App Center—which Microsoft has scheduled for retirement—and Apple's TestFlight. While TestFlight is excellent for sharing apps with testers, it's less effective for broader team sharing. To build, sign, and distribute apps, teams must set up and maintain scripts and continuous integration pipelines, which is both time-consuming and costly.

Additionally, the recipient must have an Apple account (which is a reasonable assumption), be invited to a group, and only then will they receive the builds to test. These builds might have a versioning system detached from the codebase context, making it difficult to correlate feedback with the code that generated the build. For instance, encountering a bug in TestFlight build number 455 prompts questions like: Was this build generated from a commit in main? From a PR? Or was it built and pushed by a teammate from their local environment? This uncertainty is problematic.

We believe collaboration needs a much simpler, web-centric approach:

• Sharing a build should be as easy as sending a link.
• It should be possible to share something running right in the simulator.
• Builds should include associated context to facilitate forwarding feedback to the appropriate person.
• Complexities like signing should not be a hindrance.

These principles are embodied in Tuist Previews, which we believe will herald a new era of collaboration for development teams.

Tuist Previews

Tuist Previews make it easy to share apps with anyone. Once the app is built, you can effortlessly turn it into a link with a single command:

The command will output a link that anyone can use to run the app with another simple command:

Xcode projects support

We are gradually weakening the dependency with Tuist projects. Features like Previews and upcoming features will work directly with your Xcode projects. This means that you can use Tuist to build and run your apps, even if you don't use Tuist to generate your projects.

What's next

This is just the beginning of Tuist Previews. We are eager to hear your feedback and prioritize it alongside some of the following features we have in mind:

• Device support: Previews currently work only on simulators, but we plan to add support for physical devices. We are developing open-source technologies and infrastructure to abstract away the intricacies of reliably signing apps. Our goal is to prevent any complexity from affecting the developer experience.
• macOS app: Non-developers may not feel comfortable running a command-line tool to use an app. We are building a macOS app that will make it easier to run and share apps. This app will serve as the foundation for more features that need to integrate natively with the macOS platform.
• Feedback: We aim to include metadata in previews and give developers the option to integrate an SDK that will allow users to report feedback. We'll handle forwarding that feedback to the appropriate team member.
• Releases: When you want to share the app with Apple, that's a release! We'll provide tools for this process, abstracting away any complexity, including signing, and offering remote environments so that you don't need to deal with intricate CI pipelines.

Tuist Previews is a love letter to simplicity and continues to shape Tuist as an Omakase experience for app developers. We're excited to see how teams leverage this feature to build better apps faster. If you have any feedback or ideas, please share them with us on GitHub or Slack.

• Asana scaled their iOS codebase with Tuist
• Bumble chose it over Bazel and SPM to scale their development
• Trendyol made Tuist their modularization cornerstone

During this journey, we've learned a lot about the challenges teams face when building apps. And we built solutions for those challenges, like slow build or test times, stretching Tuist's original focus around Xcode's complexities. This left organizations and developers confused about what Tuist is and what it does. Therefore, we decided to revisit our mission and vision and share it with all of you.

From idea to top-notch apps

Apps usually start with an idea or a business need. Ideas can fade away if they're not validated quickly, and potentially great apps may never see the light of day. Unfortunately, the Apple platform has grown in complexity over the years, creating challenges and friction that developers and organizations need to navigate. Luckily, the community has built excellent open-source tools to assist developers with various challenges they face. However, developers still have to do the job of gluing these tools together into workflows that are a joy to use, sometimes in programming languages they are not familiar with, and maintain them indefinitely.

We believe there must be a better way: an "omakase" for app developers. We envision an integrated experience with sensible defaults and the right extensibility points. This experience would hold your hand from the moment you start your project until you ship it to your users, helping you scale your development and your team. It would be an experience that can be easily ported from one project to another, from one team to another, and from one organization to another. We are building that experience with Tuist.

We are shifting our focus to empower teams to build better apps faster.

Meeting developers where they are

Our strategy has always been to meet developers where they are by integrating with the official tools and APIs provided by Apple and equipping them with superpowers. A good testament to this work is our caching feature, which leverages Xcode primitives to achieve this. We will continue with this approach, minimizing abstractions as much as possible, aligning with Apple's direction, and embracing the languages and tools that developers are familiar with and love, such as Swift.

Moreover, we are taking the approach of meeting developers where they are even further. We believe that ignoring the fact that developers spend significant time on platforms like Slack, GitHub, and GitLab is a mistake. Developers often spend a substantial portion of their time there collaborating with each other and with other teams and roles. It is crucial that their workflows integrate seamlessly with these platforms, so that anyone in the organization can access the information they need to make informed decisions without having to install developer-specific toolchains. Therefore, we are embracing the web platform and URLs as units of collaboration. Developers and organizations that want to extend Tuist's capabilities further will be able to do so by plugging their projects into a server, and voila.

Tuist becomes a unified toolchain that encompasses both the client (CLI) and the server (formerly Tuist Cloud).

The lifecycle of an app

The toolchain will reflect the lifecycle of apps, from their creation to their release. The CLI, the dashboard, and our documentation will all mirror this lifecycle. We believe it’s crucial for developers to feel comfortable understanding and using the toolchain. Long-term, we aim for Tuist’s interface, which is very client-centric today, to evolve as follows:

• tuist init: Create a new project from community or Tuist-provided templates.
• tuist build: Build my project reliably and quickly, collecting insights.
• tuist test: Test my project reliably and quickly, collecting insights such as test coverage, performance, and flakiness.
• tuist lint: Validate the project or the artifacts generated from builds.
• tuist share: Share this app with my team or external people for feedback.
• tuist workflow: Run a Swift-based workflow locally, or manage the ones running remotely.
• tuist release: Trigger a release of my app to the App Store or any other distribution channel.

Drawing inspiration from the Ruby and Ruby on Rails communities, from which we have learned a lot, we will design the interface of Tuist to optimize for joy and invest in Swift extensibility to foster a vibrant ecosystem of plugins and integrations. More on this in the coming months.

Embracing openness

The best organizations that we aspire to be like have one thing in common: openness (e.g., Supabase, GitLab, PostHog). Being open is what has brought us to where we are. It’s how we built trust with our users, created a foundation for diverse ideas, fostered collaboration, and, without a doubt, developed high-quality software that lasts and solves real problems. We are committed to doubling down on this value.

We are working on establishing a path and timeline to open-source everything we do without compromising our ability to build a sustainable business. We are documenting how we are building the company in a public handbook that is available for everyone to read. We believe that having a handbook will enable a frictionless and asynchronous remote work environment, attracting the best talent from around the world. As first-time founders on this journey, we also aim to inspire others to start their own companies and share their learnings with the world.

We will also commoditize some pieces of technology that we’ve noticed are common across many organizations to help elevate innovation at different layers of the stack. We believe that by doing so, we can help organizations focus on what differentiates them rather than on focusing on zero-sum game. Expect a handful of open-source projects from us in the coming months.

A simple and open pricing model

The features that require a server are part of a paid plan, ensuring we can work on the project full-time and continue to support you with the challenges you face. Today, we are pleased to announce our plans publicly, focusing on simplicity and openness. We believe users shouldn’t have to figure out which plan works best for them. Everyone has access to every feature in each plan and simply pays based on usage and the level of support they desire from us.

• Tuist Air: For individual developers and small companies that don't need a dedicated support channel.
• Tuist Pro: For medium to large companies that need a dedicated support channel.

Only enterprise models are privately discussed, as they are tailored to the needs of large organizations (e.g., custom terms, SLAs, and support).

What's next

We are beginning to work on the vision outlined above. To achieve this, we are developing foundational technology that we will open source in the coming months. Additionally, we are undergoing a website redesign with the amazing Guinda team to reflect the new vision and make it easier for you to understand what Tuist is and how it can help you.

We will also double down on investing in our community to provide the Apple ecosystem with the best toolchain for building better apps faster.

Understanding Flaky Tests

If you've written tests before, you might know that tests might yield inconsistent results across runs. These are often referred to as "flaky tests". In other words, flaky tests are not deterministic. They might fail due to race conditions or dependencies on the environment in which they run.

Flaky tests can be quite frustrating and time-consuming. Imagine this scenario:

1. You change one line of Swift code in your project.
2. You push the changes upstream.
3. After waiting half an hour for results (unless you're using Tuist cache to reduce those times), you see that your CI pipeline has failed due to a failing test unrelated to your changes.
4. Developers commonly retry the build to see if the test passes the second time.
5. Meanwhile, another contribution lands, causing conflicts in your branch.
6. After an entire hour, you're still trying to see if your changes pass on CI.
7. Finally, after 1.5 hours, your changes are green and ready to be merged.

That's 1.5 hours of your time for a single line of code change. This is a significant problem that many companies don't address because tools to detect flaky tests are not widely available. But we're here to change that.

Why Flakiness is Worth Solving

Tuist's aim is to help teams build better apps faster. If a codebase contains flaky tests:

1. The team wastes time.
2. They might ship bugs to users because tests are not reliable.

Flaky tests are detrimental to the team's productivity and the quality of the software they ship. Therefore, we felt it was a challenge we had to help solve.

The Tuist team set out to provide a solution in three phases:

1. Bring awareness by detecting flakiness.
2. Help teams prevent flakiness when introducing new tests.
3. Provide tools to automatically or manually disable tests.

We're thrilled to announce that the first phase is now available in Tuist for anyone to use.

Detecting Flaky Tests

You might wonder how we solved this issue. A test is flaky if it produces different results when run multiple times without changes. The key question is: how do we know if a test has changed?

In a standard Xcode project, this information is hard to obtain outside of Xcode's build system. An approximation could be made through static analysis of imports, but this could be inaccurate for projects using dynamic features like compile-time resolved macros or compiler directives.

Fortunately, Tuist has a great foundation to build upon. Our hashing logic, used for cache and smart test runs, allows us to determine if a test has changed. We consider a test unchanged if the hash of its containing module remains the same. We persist these results over time.

This happens automatically if you run your tests with tuist test. We recommend adopting this over other abstractions, as it provides access to smart test runs and analytics to understand your projects and make informed decisions. With this information, Tuist can provide a list of tests detected as flaky. In this iteration, we just provide the list of tests for which we've noticed inconsistencies. In the future, we plan to include a score indicating how flaky a test is, based on its run history.

What's next

This is just the beginning of our work in this area. We'll iterate with teams to ensure the detection feature works well with XCTest and Swift Testing. We'll also refine the user interface to present actionable information. After that, we'll focus on preventing flakiness, which will be seamlessly integrated into the tuist test workflow. Finally, we'll provide tools to disable flaky tests, such as rules for automatic disabling or a command for manual disabling.

We believe this is a crucial feature for any team that wants to ship reliable software. If you want to try it create an account and run tuist test in your project. We welcome your feedback and look forward to hearing from you.

As a commercial open source company with open source at its core, we understand how challenging it can be to find support for your project to ensure its sustainability and continued contribution to society with common goods that benefit everyone. Therefore, we are thrilled to announce that we are offering Tuist our paid features completely free for open source projects.

Please note that Tuist has basic support for Swift Packages, allowing you to test Tuist against your existing Swift Packages to better understand the workflows and how features like binary caching can enhance your projects. It’s truly magical to experience! If your project still uses Xcode primitives such as .xcodeproj or .xcworkspace, or another generation tool, we have put together some migration guidelines to facilitate the process. The migration is well worth it.

How to join the program

The only requirement is to include a note in the README.md of the repository and send us a link to the repository along with your account handle at contact@tuist.dev. We’ll set your plan and you are good to go.

What’s coming to Tuist

Build and test optimizations are just the beginning for Tuist. There are other challenges and areas that traditionally require organizations to invest significant time and resources, often absorbing substantial complexity themselves. We aim to alleviate this burden by providing support early in the app development lifecycle, before Xcode projects become unmanageable and unproductive. We have many ideas for future enhancements, but we’ll save those for a future blog post.

Documentation V1 - Docusaurus

The first version of Tuist documentation was powered by Docusaurus, a NodeJS tool for generating static documentation satisfies. The framework provided us with all the tools necessary for creating a good documentation: a search engine, a sidebar, and a clean layout.

Moreover, we were quite strict about the importance of updating the documentation as part of making contributions. In other words, "I'll do it in a different" PR was not an option. This was a good practice that helped us keep the documentation up-to-date. However, that strictness faded away as the project grew and the number of contributors increased. The result was a documentation that was outdated and hard to navigate.

Because the tool required to set up the right version of NodeJS in the environment, and have a bit of knowledge about the underlying technology (e.g. installing dependencies with npm or running commands through npm run) we started to ponder whether that'd feel as unnecessary friction for contributors. Around the same time that we were thinking about the contributors' friction, Apple released Swift DocC, a tool for generating documentation for Swift projects. We thought that it'd be a good opportunity to revamp the documentation and make it more accessible to contributors.

Documentation V2 - Swift DocC

As part of the effort to release Tuist 4 we thought it'd be a good opportunity to revamp the documentation and make it more accessible to contributors. We decided to use Swift DocC for generating the documentation. Many aspects of it read well in paper:

• It's writen in Swift
• It's tightly integrated into Xcode
• It can generate documentation from in-code documentation
• It's open source
• It has the notion of tutorials

However, the more we used it, the more we realized that it was not a good fit for our needs. In hindsight, we should have done a better research before making the decision, but we trusted the tool because it was developed by Apple. Here are some aspects that turned out to be not good for us:

• The tool generates an actual SPA using Vue. Even though search engines are supposedly able to index SPAs, the indexing of Google degraded significantly having pages that were not indexed at all. Apple seems to be aware of the issue and they have plans to work on but it seems to be a low priority.
• It has no support for i18n. We want to set up a localization pipeline for our documentation site to ensure that languages are never a barrier for users and contributors. Sadly, Swift DocC doesn't have support for that. Not only that, but uses very proprietary formats that might complicate the integration with translation tools that expect more standard formats like Markdown.
• Little extensibility and configurability: Which means that you can't do things like generating content dynamically, customizing the <head/> section of the generated pages, customizing the routes, or changing the favicon. As a consequence, we had to have some scripts that worked directly with the output artifacts.

So while we were able to generate a documentation site that had the look-and-feel of Apple. We ended up with a tool that would limit us in the future. Moreover, we learned that the hesitance of contributors to update the documentation was not due to the tooling but rather to the lack of a culture of updating the documentation. In fact, with the introduction of Mise as a tool to manage the project's system dependencies, installing NodeJS and running npm install was not a big deal anymore.

Moreover, with the rush to release Tuist 4, we didn't have the time to properly organize the documentation and the content, so we end up in a terrible spot with content that was outdated, pages that were missing content, and a navigation that was hard to follow.

We decided to go back to the drawing board and think about what we wanted from the documentation.

Documentation V3 - VitePress

We had been following the amazing work the Vue ecosystem does with their tools. One of theme, VitePress, is a tool that they use to generate the documentation website for all their projects. It's aesthetically pleasing, it's extensible and configurable, it outputs a SSG site, it supports i18n, and it's actively maintained. It had everything we needed.

Like many times in the pass, we were confronted with the decision between choosing the right tool for the job, even if that meant choosing a technology stack other than Swift and Xcode, or sticking with the existing "official" options and trying to make them work. However, since we are limited in resources and getting involved in a project that's mainly steered by Apple would be a big commitment that would distract us from our main goal, we decided to go with VitePress.

It took us almost an entire week to go through all the versions of the documentation website pulling content from the old documentation, updating it, and organizing it. We also took the opportunity to add new content and improve the existing one. We also organized the content in the following sections for ease of navigation: Guides, Reference, Contributors, and Server. The result of the work is already available under docs.tuist.io.

We have to admit that the experience working with VitePress has been top-notch. As an example of how powerful is extensibility is, we could use a tool like SourceDocs to turn in-code documentation into Markdown pages and dynamically load the content using VitePress built-in APIs for data-loading.

Preventing the same mistake

We made the mistake of being less strict about updating the documentation as part of making contributions. We learned that the tooling was not the problem, but rather the culture. Since we were limited in resources, it was a huge stretch for us to supervise documentation contributions on top of code contributions, our natural reaction was to ignored what it's indeed one of the most important parts of the project. We learned that we should have invested more time in creating a culture of updating the documentation as part of making contributions.

Going forward, we'll require every PR to have documentation updates. Since we have the priviledge of having people working full time on the project, we'll be able to supervise the contributions and ensure that the documentation is updated. We'll also be more strict about the quality of the documentation. We'll require that the documentation is clear, concise, and easy to follow. We might consider introducing some automation to ensure certain style guidelines are followed.

Feedback

Give it a read and let us know what you think. We're always looking for ways to improve the documentation and make it more accessible to users and contributors. On behalf of the Tuist, we'd like to apologies for having disregarded the documentation for so long. We hope that the new documentation is a step in the right direction and that it helps you get started with Tuist.

Better support for Objective-C packages

One of our long-standing issues in our backlog were problems trying to integrate Swift Packages with Objective-C code in them. The Swift Package Manager, which was designed as a package manager for packages with Swift code, succumbed to the complexity of integrating Objective-C code. To make them work, the Swift Package Manager has some logic for generating module maps and passing the right build settings to the dependent targets. This is logic that Tuist didn't have, and therefore users had to manually figure out what were the right settings to pass to the dependent targets.

Luckily, that's no longer needed from Tuist 4.1.0. Marek did an amazing job going deep into understanding Swift Package Manager's logic and porting it over to Tuist. If you were having issues with Objective-C packages, you can try again with Tuist 4.1.0. Please, note that there might be package scenarios out there (we look at you Google), that are convoluted and that might require additional work from us. If so, please, file an issue and we'll look into it.

Add support for visionOS to our resource synthesizing templates

As you might know, Tuist supports generating code interfaces to access resources and leverage the compiler's type safety. This is a feature that we call resource synthesizing. In Tuist 4.1.0, we added support for visionOS to our resource synthesizing templates. If you are building an app for visionOS, you can now use the resource synthesizing feature to access your resources in a type-safe way.

How to update

You can use Mise to install the latest version and pin it to your project. To do so, run the following command:

Happy Xcoding!

On April 21st, 2017, we created the first commit in XcodeProj, motivated by the itch of overcoming the challenges of collaboration on a modular Xcode project. XcodeProj would later become the foundation of Tuist. We drew inspiration from the Swift Package Manager DSL, but we oriented its design towards maintaining and evolving Xcode projects, abstracting their intricacies.

This work made us realize that project generation, which we perfected over time, was the perfect foundation to build an integrated solution for many of the challenges that organizations face. Many organizations found in Tuist the right balance between cost and investment. Tuist is approachable thanks to its Swift-based DSL and the Xcode concepts that developers are already familiar with. Teams can focus on building architectures that meet their needs without being held back by brittle, conflict prone Xcode project files.

After almost 7 years of trying to understand the problem space, talking to a lot of companies and the challenges they face, and pouring days and nights into building the best developer tool in the space, we are thrilled to share with you something that we’ve been working on for the past months: a new major version of the project, Tuist 4, which marks an inflection point in the project's sustainability. But before we dive into the heart of this major release, we need to talk about sustainability.

Long-term sustainability

Ensuring the sustainability of open source development is a critical concern, especially in the context of the Tuist project. Historically, open source software has often been perceived as a free good, similar to products used in traditional businesses as loss leaders to entice customers into purchasing non-free goods. However, the reality is more nuanced.

Open source, with its near-zero marginal costs due to economies of scale, has the potential to create a high consumer surplus. This surplus can be justified for products, particularly intellectual property, and has historically been funded through government-sponsored research and development efforts or private foundations and volunteer contributions in the open source community.

However, the uniqueness of software lies in its ongoing maintenance requirements. Unlike pure intellectual property, software is a product that needs continuous updates, bug fixes, and improvements. Consequently, the traditional free good model often falls short when it comes to software. There is a pressing need to secure ongoing funding to ensure its maintenance and development.

Tuist, as a project, has reached a level of popularity that necessitates substantial maintenance efforts. Relying solely on volunteer contributions or donations has proven insufficient to meet these demands. Consequently, a new approach is required to sustain Tuist effectively.

To address this challenge, we are embracing a commercial open source model for Tuist, with a server serving as the inaugural commercial complement. This model offers several key advantages:

• No Resource Starvation: Tuist's costs are covered by its selling price, eliminating the resource scarcity that can plague a zero-priced open source model. It ensures the project's financial sustainability.
• No Hidden Costs: Open source remains genuinely free under this model, with no restrictive licensing terms or unexpected financial burdens on users.
• No Predatory Pricing: While open source may be free, it doesn't enable predatory pricing practices. Competitors can freely use the codebase to offer their solutions, fostering healthy competition and preventing monopolies.

Unlike the conventional loss-leading strategy where free and paid offerings are identical or substitutes, our approach views them as complementary components of the Tuist ecosystem. Our paid offering represents the first step in this transition, helping us secure the necessary resources to sustain Tuist's ongoing development and guarantee its long-term viability.

By embracing the commercial open source model, we are striking a balance between the benefits of open source collaboration and the sustainability of the Tuist project, ensuring that it continues to thrive and serve the community effectively.

Paid features

We introduced a set of paid features via a server by leveraging the project-generation foundation. Organizations can easily self-host the server or use our hosted version, leaving updates, maintenance, and support in our hands. The service is generally available and we already have organizations using it. Key features include:

Binary caching

Clean builds, which occur locally when developers clear derived data and commonly during CI builds, might require compiling targets that haven't changed since they were last built. When builds take place within the same environment, Xcode's build system can handle this incrementally, making the process fast. However, this incrementality doesn't extend across different environments, leading to situations where organizations' CI pipelines can take up to 30 minutes and more. This is far from ideal from a developer productivity perspective.

The efficiency of the cache is closely tied to the modular architecture of the project. A highly modular architecture with weak dependencies among nodes can result in significant reductions in build times, potentially up to 90%. Additionally, we can cache Swift Macros and multi-platform targets as well.

Selective testing

At some point in the project's journey, building and testing all the targets with every CI commit becomes inefficient. The time required is directly proportional to the project's size, and while slight improvements can be made with new processor generations, as demonstrated with M processors, CI providers struggle to keep up with the pace. When organizations reach this point, some opt to create their own in-house selective testing solutions, but this entails a significant time investment that detracts from product development. Moreover, without a tool to mitigate the inherent complexity in Xcode projects, the resulting logic can become unreliable and cause frustration among developers.

We offer a selective testing solution that works seamlessly across different environments. It utilizes the same hashing logic employed by binary caching to uniquely identify binaries in the cache, this time to determine whether a target has changed and, consequently, whether its tests and those of dependent targets need to run. The best part? It operates automatically, requiring no additional configuration or complexity.

Return of investment

Supporting Tuist is a cost-effective investment, as it will likely save your team more than it costs. Your contributions support Tuist's development and other vital open-source projects in need of sustainability. We're committed to fostering a sustainable open-source ecosystem where developers can earn a living from their work. If you want to get rough estimates of the potential savings, you can use our calculator below.

Next steps

We have more ideas to tackle challenges, but our initial focus is on getting organizations on board, understanding their needs, and prioritizing development accordingly. Additionally, we aim to provide actionable metrics for project and build data, helping teams ensure their projects are future-proof.

If you're eager to begin using our paid features, we recommend reviewing our documentation and ensuring that tuist cache runs successfully with your Xcode project. You may need to make some adjustments to eliminate implicit configurations that could potentially hinder reliable caching.

At Lapse speed is our top priority, Tuist has accelerated our development feedback loop massively. We mostly try to ship to the App Store every single day, so ensuring fast iteration speeds for feature development is of utmost importance. Our average build time for an internal QA build or for our PR workflows used to be around 30 minutes on the CI, and when we added macros to the project this increased to 53 minutes. Since we started using Tuist's paid features with our modularised codebase (220 modules including dependencies) we’ve seen builds as quick as 8 minutes, with the average build time now being 13 minutes with macros! This has also dramatically impacted local development, we now no longer need to rebuild all those modules we’re not working on, which has resulted in much faster iteration speeds for the whole iOS team. Head of iOS at Lapse - Alex Little

Tuist 4

In addition to our paid features offered by the server, we are introducing a major new release of Tuist, Tuist 4. With this release, we are placing a strong emphasis on sustainability.

We have observed that over the years, we have developed and maintained features and components of Tuist that are peripheral to the core of the project. For instance, the version manager "tuistenv" has seamlessly handled the installation and activation of Tuist versions. Additionally, we have implemented contributor tooling that introduced unnecessary friction and created a significant dependency between contributors and the core maintenance team. We have not critically evaluated their necessity until recently.

Mise as the default installer

Users used to install tuistenv which we renamed to tuist during installation, to deterministically install and activate versions of Tuist across various environments. While it served its purpose well with minimal maintenance, we felt that it was somewhat disconnected from Tuist's core mission. We believed that there were other tools available that could perform the same tasks more effectively and efficiently. In particular, we explored Mise, a tool capable of installing system tools, allowing version scoping and activation on a per-project basis. The experience was outstanding, aligning perfectly with the developer experience (DX) that Tuist aims to provide. Furthermore, Mise can serve as a versatile tool to install other dependencies commonly used in the Swift ecosystem, such as Sourcery, Ruby, Swiflint, and Swiftformat. All a project needs is a .mise.toml file at the root, a mise install command, and voilà, all the necessary versions are installed and activated.

Starting from Tuist 4, Mise becomes the default installer, with Homebrew as an alternative for teams that prefer an intermediary step using a tool already prevalent in their development environments. Alternatively, teams can pull the binaries from GitHub releases. Tuist assumes the role of an advocate, emphasizing the importance of version determinism across different environments. Development organizations can save countless hours by avoiding non-deterministic version discrepancies that can easily occur with tools like Homebrew, especially when Mise provides a more deterministic solution. We believe Mise strikes the right balance between convenience and determinism, which is why we have chosen it as our new installer.

We would like to express our gratitude to @jdx, the creator and maintainer of Mise, for the outstanding work they have done with the tool and their ongoing support to ensure Tuist and Xcode developers have the smoothest experience possible.

Dependencies

When Apple integrated Swift Packages into Xcode, they introduced a new post-XcodeProj-open phase in the Xcode project to resolve dependencies asynchronously. This product decision seemed consistent with Apple's approach to make their solutions as convenient as possible. However, it came at the cost of providing teams with limited flexibility over the developer experience, dependency integration, and optimizations.

Shortly after its release, the downsides of this idea became evident. Package products determining their static/linking nature had cascading integration effects, which Apple addressed by introducing an "automatic" linking option. Delegating these responsibilities to the build system increased dependence on Apple and the underlying build system for optimization. This strong dependency wasn't desirable, especially for large-scale projects.

This motivated us to take a different approach, where we aimed to provide users with more control over integration, making it compatible with Tuist for easy binary caching of dependencies. We introduced a Dependencies.swift file where users could define their package dependencies. A tuist fetch command would resolve these dependencies using the Swift Package Manager. At generation time, we would convert them into Xcode projects, integrating, validating, and optimizing them alongside the rest of the graph. Although this feature came with ongoing maintenance costs, especially with new SPM features like Swift Macros, our experiments with binary caching showed that the investment was truly worthwhile. Tuist users embraced Dependencies.swift. When tuist generate completed, they had an optimized Xcode project ready for compilation. Additionally, they could delete derived data without worrying about invalidating package resolution. Through Xcode project generation, we enhanced developers' experience using the Swift Package Manager at its core.

However, the use of Dependencies.swift distanced us from SPM's default interface, Package.swift, which had cascading consequences. For instance, we couldn't utilize tools like Dependabot for automated dependency updates. To address this, we made changes in Tuist 4. Now, your dependencies are defined in a Package.swift file at the root of your project. Furthermore, you can use the #if TUIST compiler directive to include integration settings in the same manifest file. Additionally, we renamed tuist fetch to tuist install to align it with the industry's naming convention for dependency installation.

To learn more about dependencies in Package.swift, you can check out our documentation.

Swift DocC documentation website

Tuist previously utilized Docusaurus, a NodeJS-based tool, to generate a static documentation website. While it served its purpose well, we realized that it introduced friction for contributions. This was because it required developers to have Node.js installed, a certain level of understanding of the ecosystem, and performing documentation-related tasks from a different editor or tool than what they used for contributing to Tuist or working in Xcode.

Around the same time, Apple introduced Swift DocC, a tool for statically generating documentation specifically for Swift projects. It was seamlessly integrated into Xcode and the Swift Package Manager, resulting in documentation that mirrored the style and appearance of Apple's official documentation sites since they also employed the same tool. Thus, we contemplated the idea of switching to Swift DocC. This decision would offer tighter integration into our contributors' workflows and align visually with other Apple tools.

Consequently, we made the choice to adopt Swift DocC as our documentation-generation framework and tool, embarking on a comprehensive overhaul of our documentation. During this process, we took the opportunity to eliminate outdated documentation, bring certain sections up to date, and restructure it for enhanced navigability. Additionally, we introduced new tutorials and incorporated the API documentation generated from the ProjectDescription models into the documentation. Moving forward, we are committed to ensuring that these new documentation elements seamlessly integrate with the existing content, creating a more cohesive and user-friendly documentation experience.

ProjectDescription API improvements

ProjectDescription is the framework that exposes all the models developers use to describe their projects, workspaces, and configurations. Despite our best efforts to maintain consistently designed and highly readable APIs, in line with Swift frameworks, inconsistencies gradually crept in over time, and readability suffered in some areas. With major versions providing the flexibility to introduce breaking changes, we seized the opportunity to reevaluate all the APIs.

In particular, we made many initializers from models private and introduced static functions that are more descriptive and offer us greater flexibility for future API iterations, without the risk of introducing breaking changes. Additionally, we made the models' attributes public and mutable to enhance usability when working with the models from manifest files. Moving forward, we will closely monitor API changes to avoid falling into the same inconsistencies that led us to this point.

If you are in the process of migrating a project to Tuist 4, I recommend reviewing our documentation, which includes information on all the available models.

Many more changes have been incorporated into Tuist 4, which would significantly extend the length of this blog post. If you desire a detailed list of these changes, we recommend consulting our release notes on GitHub or reviewing the comprehensive list of issues and pull requests.

Remaining faithful to Tuist's open-source model

Introducing an additional source of funding to the project might raise concerns among users – what if every new feature becomes exclusive to paying users, and we end up adopting the loss-leading models commonly seen in traditional companies? To prevent this scenario, we are committed to embracing the open-source philosophy in the way we manage the company, ensuring accountability.

To fulfill this commitment, we will begin publishing a monthly report at the end of each month. In this report, we will openly share our financial status and how the funds are being utilized to sustain Tuist. We call it Monthly Sustainability Report. Key points we will address include:

• How we have addressed issues and pull requests for both, the CLI and the server.
• The number of contributions we have made to other open-source projects on which we depend.
• The number of contributions paid through our bounty program.
• The areas on which we plan to focus based on users’ feedback.

Each report will include a discussion topic, inviting developers to join the conversation and share their thoughts, ideas, concerns, and questions. Additionally, we will continue to make decisions by consensus with the core maintainers team, which includes representatives from companies that use Tuist.

A brand-new logo

As Tuist 4 marked a significant milestone in the project's history, we took the opportunity to undergo a logo redesign to align ourselves more closely with the icons used by Apple for their developer tools. We enlisted the talented services of Matthew Skiles for this task, and he crafted a beautiful logo that now represents our new online identity.

In this new logo, Matthew skillfully preserved Tuist's identity through the choice of colors and the iconic shell, while also incorporating elements that give it a distinct developer tooling feel. The result is truly impressive, and we couldn't be happier with the outcome. If you're in need of a design for your app icon, we wholeheartedly recommend Matthew. It was an incredible experience collaborating with him.

Strengthening our partnership with Codemagic

Since the early days of Tuist, Codemagic, a CI/CD platform designed for mobile teams, has been a staunch supporter of Tuist through sponsorships and valuable resources for the community. With the release of Tuist 4 and the paid features, they are taking their support to the next level by offering us an exceptional CI/CD service and environments. As a result, we will be transitioning all our CI pipelines to run on Codemagic. We are incredibly grateful for this support.

If your company is in search of an excellent CI/CD solution for your mobile projects, we wholeheartedly recommend Codemagic. They are currently offering Tuist users a discounted annual price of $2990, down from $4788. To take advantage of this offer, simply use the code TUIST2024 when purchasing Codemagic fixed price annual plan.

Closing words

We wouldn't be here if it weren't for the ongoing support of maintainers, sponsors, and users who showed up and believed in us. So, from the depths of our hearts, we want to express our heartfelt gratitude for standing by us. Tuist wouldn't be the same without you.

The first seven years were dedicated to understanding Xcode, its intricacies, and laying the foundation for project generation. This foundation enabled us to assist organizations in overcoming their challenges. This new phase is all about continuing to do what we love for as long as possible because organizations value the tool. It's going to be an amazing journey ahead!

Thank you ❤️

Tuist 4 owes its existence to the contributions of fantastic and talented builders who strive to enhance the tool for everyone. To everyone on this list, and to anyone who also contributed to Tuist but whom we couldn’t capture in GitHub contributions, my heartfelt thanks. I also extend my gratitude to the core maintainers team, Daniele, Mike, Marek, and Kas, as well as to everyone who was once part of the core team and contributed to steering the project. You are all amazing.

<img alt="mohitsaxenaknoldus" src="https://avatars.githubusercontent.com/u/76725454?v=4&s=117" width="117"/> |<img alt="sampettersson" src="https://avatars.githubusercontent.com/u/5459507?v=4&s=117" width="117"/> |<img alt="saim80" src="https://avatars.githubusercontent.com/u/316606?v=4&s=117" width="117"/> |<img alt="SergeyPetrachkov" src="https://avatars.githubusercontent.com/u/7995896?v=4&s=117" width="117"/> |<img alt="setoelkahfi" src="https://avatars.githubusercontent.com/u/1797197?v=4&s=117" width="117"/> |<img alt="JCSooHwanCho" src="https://avatars.githubusercontent.com/u/51935215?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | mohitsaxenaknoldus |sampettersson |saim80 |SergeyPetrachkov |setoelkahfi |JCSooHwanCho |

<img alt="st-small" src="https://avatars.githubusercontent.com/u/1850189?v=4&s=117" width="117"/> |<img alt="steprescott" src="https://avatars.githubusercontent.com/u/1131458?v=4&s=117" width="117"/> |<img alt="rist" src="https://avatars.githubusercontent.com/u/295229?v=4&s=117" width="117"/> |<img alt="kalkwarf" src="https://avatars.githubusercontent.com/u/1033839?v=4&s=117" width="117"/> |<img alt="stevelandeyasana" src="https://avatars.githubusercontent.com/u/38225497?v=4&s=117" width="117"/> |<img alt="stephanecopin" src="https://avatars.githubusercontent.com/u/7003579?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | st-small |steprescott |rist |kalkwarf |stevelandeyasana |stephanecopin |

<img alt="sujata23" src="https://avatars.githubusercontent.com/u/1849089?v=4&s=117" width="117"/> |<img alt="c0diq" src="https://avatars.githubusercontent.com/u/172535?v=4&s=117" width="117"/> |<img alt="tejassharma96" src="https://avatars.githubusercontent.com/u/8764853?v=4&s=117" width="117"/> |<img alt="tosbaha" src="https://avatars.githubusercontent.com/u/971530?v=4&s=117" width="117"/> |<img alt="NataliaKurek" src="https://avatars.githubusercontent.com/u/19759844?v=4&s=117" width="117"/> |<img alt="nivanchikov" src="https://avatars.githubusercontent.com/u/1830010?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | sujata23 |c0diq |tejassharma96 |tosbaha |NataliaKurek |nivanchikov |

<img alt="oronbz" src="https://avatars.githubusercontent.com/u/1288090?v=4&s=117" width="117"/> |<img alt="Austinate" src="https://avatars.githubusercontent.com/u/4790464?v=4&s=117" width="117"/> |<img alt="wogus3602" src="https://avatars.githubusercontent.com/u/46857148?v=4&s=117" width="117"/> |<img alt="BalestraPatrick" src="https://avatars.githubusercontent.com/u/3658887?v=4&s=117" width="117"/> |<img alt="PaulTaykalo" src="https://avatars.githubusercontent.com/u/119268?v=4&s=117" width="117"/> |<img alt="pavm035" src="https://avatars.githubusercontent.com/u/6092412?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | oronbz |Austinate |wogus3602 |BalestraPatrick |PaulTaykalo |pavm035 |

<img alt="petrukha-ivan" src="https://avatars.githubusercontent.com/u/93926277?v=4&s=117" width="117"/> |<img alt="platonsi" src="https://avatars.githubusercontent.com/u/46824695?v=4&s=117" width="117"/> |<img alt="Arafo" src="https://avatars.githubusercontent.com/u/560392?v=4&s=117" width="117"/> |<img alt="OhKanghoon" src="https://avatars.githubusercontent.com/u/18064037?v=4&s=117" width="117"/> |<img alt="enlivn" src="https://avatars.githubusercontent.com/u/78372052?v=4&s=117" width="117"/> |<img alt="rmnblm" src="https://avatars.githubusercontent.com/u/5942764?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | petrukha-ivan |platonsi |Arafo |OhKanghoon |enlivn |rmnblm |

<img alt="RomanPodymov" src="https://avatars.githubusercontent.com/u/10789692?v=4&s=117" width="117"/> |<img alt="schinj" src="https://avatars.githubusercontent.com/u/7895596?v=4&s=117" width="117"/> |<img alt="cheskapac" src="https://avatars.githubusercontent.com/u/2336961?v=4&s=117" width="117"/> |<img alt="dcramps" src="https://avatars.githubusercontent.com/u/643865?v=4&s=117" width="117"/> |<img alt="euriasb" src="https://avatars.githubusercontent.com/u/3721257?v=4&s=117" width="117"/> |<img alt="fossabot" src="https://avatars.githubusercontent.com/u/29791463?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | RomanPodymov |schinj |cheskapac |dcramps |euriasb |fossabot |

<img alt="ibrahimoktay" src="https://avatars.githubusercontent.com/u/36792481?v=4&s=117" width="117"/> |<img alt="jimmy-li-houzz" src="https://avatars.githubusercontent.com/u/96756372?v=4&s=117" width="117"/> |<img alt="kimxwan0319" src="https://avatars.githubusercontent.com/u/67373938?v=4&s=117" width="117"/> |<img alt="MariusDeReus" src="https://avatars.githubusercontent.com/u/9931253?v=4&s=117" width="117"/> |<img alt="mustiikhalil" src="https://avatars.githubusercontent.com/u/26250654?v=4&s=117" width="117"/> |<img alt="ronanociosoig-200" src="https://avatars.githubusercontent.com/u/51952707?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | ibrahimoktay |jimmy-li-houzz |kimxwan0319 |MariusDeReus |mustiikhalil |ronanociosoig-200 |

<img alt="sh-a-n" src="https://avatars.githubusercontent.com/u/2219548?v=4&s=117" width="117"/> |<img alt="sonuvryahoo" src="https://avatars.githubusercontent.com/u/61445098?v=4&s=117" width="117"/> |<img alt="vendulasvastal" src="https://avatars.githubusercontent.com/u/42235915?v=4&s=117" width="117"/> |<img alt="tatagrigory" src="https://avatars.githubusercontent.com/u/5187973?v=4&s=117" width="117"/> |<img alt="tuistbot" src="https://avatars.githubusercontent.com/u/34792320?v=4&s=117" width="117"/> |<img alt="tzxdtc" src="https://avatars.githubusercontent.com/u/19767846?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | sh-a-n |sonuvryahoo |vendulasvastal |tatagrigory |tuistbot |tzxdtc |

<img alt="jihoonahn" src="https://avatars.githubusercontent.com/u/68891494?v=4&s=117" width="117"/> |<img alt="ThiemeFM" src="https://avatars.githubusercontent.com/u/143395823?v=4&s=117" width="117"/> |<img alt="takinwande" src="https://avatars.githubusercontent.com/u/4744429?v=4&s=117" width="117"/> |<img alt="tiarnann" src="https://avatars.githubusercontent.com/u/10522081?v=4&s=117" width="117"/> |<img alt="vkrol" src="https://avatars.githubusercontent.com/u/153412?v=4&s=117" width="117"/> |<img alt="victor-sarda" src="https://avatars.githubusercontent.com/u/6460866?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | jihoonahn |ThiemeFM |takinwande |tiarnann |vkrol |victor-sarda |

<img alt="VilleWitt" src="https://avatars.githubusercontent.com/u/522544?v=4&s=117" width="117"/> |<img alt="vcoutasso" src="https://avatars.githubusercontent.com/u/44986513?v=4&s=117" width="117"/> |<img alt="in4lio" src="https://avatars.githubusercontent.com/u/976061?v=4&s=117" width="117"/> |<img alt="khramtsoff" src="https://avatars.githubusercontent.com/u/3510864?v=4&s=117" width="117"/> |<img alt="SpectralDragon" src="https://avatars.githubusercontent.com/u/6003467?v=4&s=117" width="117"/> |<img alt="wangjiejacques" src="https://avatars.githubusercontent.com/u/2981971?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | VilleWitt |vcoutasso |in4lio |khramtsoff |SpectralDragon |wangjiejacques |

<img alt="wojciech-kulik" src="https://avatars.githubusercontent.com/u/3128467?v=4&s=117" width="117"/> |<img alt="Buju77" src="https://avatars.githubusercontent.com/u/266349?v=4&s=117" width="117"/> |<img alt="neakor" src="https://avatars.githubusercontent.com/u/1827517?v=4&s=117" width="117"/> |<img alt="zzzkk" src="https://avatars.githubusercontent.com/u/12541603?v=4&s=117" width="117"/> |<img alt="aegzorz" src="https://avatars.githubusercontent.com/u/810539?v=4&s=117" width="117"/> |<img alt="aniltaskiran" src="https://avatars.githubusercontent.com/u/16738729?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | wojciech-kulik |Buju77 |neakor |zzzkk |aegzorz |aniltaskiran |

<img alt="abbasmousavi" src="https://avatars.githubusercontent.com/u/1249875?v=4&s=117" width="117"/> |<img alt="dbarden" src="https://avatars.githubusercontent.com/u/104456?v=4&s=117" width="117"/> |<img alt="danielmoro" src="https://avatars.githubusercontent.com/u/6289001?v=4&s=117" width="117"/> |<img alt="DarkoDamjanovic" src="https://avatars.githubusercontent.com/u/11902775?v=4&s=117" width="117"/> |<img alt="Primecutz" src="https://avatars.githubusercontent.com/u/42585232?v=4&s=117" width="117"/> |<img alt="cieslakdawid" src="https://avatars.githubusercontent.com/u/4325222?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | abbasmousavi |dbarden |danielmoro |DarkoDamjanovic |Primecutz |cieslakdawid |

<img alt="decanus" src="https://avatars.githubusercontent.com/u/7621705?v=4&s=117" width="117"/> |<img alt="denil-ct" src="https://avatars.githubusercontent.com/u/95201442?v=4&s=117" width="117"/> |<img alt="francuim-d" src="https://avatars.githubusercontent.com/u/86049208?v=4&s=117" width="117"/> |<img alt="dxmvsh" src="https://avatars.githubusercontent.com/u/44325936?v=4&s=117" width="117"/> |<img alt="dever25" src="https://avatars.githubusercontent.com/u/32138530?v=4&s=117" width="117"/> |<img alt="navartis" src="https://avatars.githubusercontent.com/u/7813723?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | decanus |denil-ct |francuim-d |dxmvsh |dever25 |navartis |

<img alt="Dmitry-Pliushchai" src="https://avatars.githubusercontent.com/u/59007906?v=4&s=117" width="117"/> |<img alt="ElonPark" src="https://avatars.githubusercontent.com/u/13270453?v=4&s=117" width="117"/> |<img alt="bogren" src="https://avatars.githubusercontent.com/u/2457281?v=4&s=117" width="117"/> |<img alt="eito" src="https://avatars.githubusercontent.com/u/775643?v=4&s=117" width="117"/> |<img alt="MrCloud" src="https://avatars.githubusercontent.com/u/486140?v=4&s=117" width="117"/> |<img alt="gcacoutinho" src="https://avatars.githubusercontent.com/u/17842860?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | Dmitry-Pliushchai |ElonPark |bogren |eito |MrCloud |gcacoutinho |

<img alt="Smponias" src="https://avatars.githubusercontent.com/u/14213855?v=4&s=117" width="117"/> |<img alt="alvarhansen" src="https://avatars.githubusercontent.com/u/482293?v=4&s=117" width="117"/> |<img alt="andruvs" src="https://avatars.githubusercontent.com/u/19372247?v=4&s=117" width="117"/> |<img alt="anlaital-oura" src="https://avatars.githubusercontent.com/u/133648611?v=4&s=117" width="117"/> |<img alt="a-sarris" src="https://avatars.githubusercontent.com/u/78614622?v=4&s=117" width="117"/> |<img alt="Gladkov-Art" src="https://avatars.githubusercontent.com/u/5657130?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | Smponias |alvarhansen |andruvs |anlaital-oura |a-sarris |Gladkov-Art |

<img alt="astromonkee" src="https://avatars.githubusercontent.com/u/44421303?v=4&s=117" width="117"/> |<img alt="ajevans99" src="https://avatars.githubusercontent.com/u/30383071?v=4&s=117" width="117"/> |<img alt="batuhansk" src="https://avatars.githubusercontent.com/u/9626765?v=4&s=117" width="117"/> |<img alt="BenjaminPrieur" src="https://avatars.githubusercontent.com/u/4921255?v=4&s=117" width="117"/> |<img alt="bhuemer" src="https://avatars.githubusercontent.com/u/1212480?v=4&s=117" width="117"/> |<img alt="csjones" src="https://avatars.githubusercontent.com/u/637026?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | astromonkee |ajevans99 |batuhansk |BenjaminPrieur |bhuemer |csjones |

<img alt="cconstable" src="https://avatars.githubusercontent.com/u/564781?v=4&s=117" width="117"/> |<img alt="acosmicflamingo" src="https://avatars.githubusercontent.com/u/67525430?v=4&s=117" width="117"/> |<img alt="cruisediary" src="https://avatars.githubusercontent.com/u/2609775?v=4&s=117" width="117"/> |<img alt="Killectro" src="https://avatars.githubusercontent.com/u/1429690?v=4&s=117" width="117"/> |<img alt="danrevah" src="https://avatars.githubusercontent.com/u/7808742?v=4&s=117" width="117"/> |<img alt="kevinrandrup" src="https://avatars.githubusercontent.com/u/5884570?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | cconstable |acosmicflamingo |cruisediary |Killectro |danrevah |kevinrandrup |

<img alt="kientux" src="https://avatars.githubusercontent.com/u/4200743?v=4&s=117" width="117"/> |<img alt="UniekLee" src="https://avatars.githubusercontent.com/u/2877482?v=4&s=117" width="117"/> |<img alt="lucabartoletti" src="https://avatars.githubusercontent.com/u/838925?v=4&s=117" width="117"/> |<img alt="luciav-github" src="https://avatars.githubusercontent.com/u/72014503?v=4&s=117" width="117"/> |<img alt="lm2s" src="https://avatars.githubusercontent.com/u/221489?v=4&s=117" width="117"/> |<img alt="mpodeszwa" src="https://avatars.githubusercontent.com/u/7826664?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | kientux |UniekLee |lucabartoletti |luciav-github |lm2s |mpodeszwa |

<img alt="MartinStrambach" src="https://avatars.githubusercontent.com/u/11178869?v=4&s=117" width="117"/> |<img alt="MarvinNazari" src="https://avatars.githubusercontent.com/u/926772?v=4&s=117" width="117"/> |<img alt="Mstrodl" src="https://avatars.githubusercontent.com/u/6877780?v=4&s=117" width="117"/> |<img alt="MatyasKriz" src="https://avatars.githubusercontent.com/u/6033733?v=4&s=117" width="117"/> |<img alt="Speakus" src="https://avatars.githubusercontent.com/u/849294?v=4&s=117" width="117"/> |<img alt="michaelmcguire" src="https://avatars.githubusercontent.com/u/429790?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | MartinStrambach |MarvinNazari |Mstrodl |MatyasKriz |Speakus |michaelmcguire |

<img alt="michalsrutek" src="https://avatars.githubusercontent.com/u/35694712?v=4&s=117" width="117"/> |<img alt="mgray88" src="https://avatars.githubusercontent.com/u/411747?v=4&s=117" width="117"/> |<img alt="akaDuality" src="https://avatars.githubusercontent.com/u/3120680?v=4&s=117" width="117"/> |<img alt="MagnificentMiles" src="https://avatars.githubusercontent.com/u/151460175?v=4&s=117" width="117"/> |<img alt="gaetanomatonti" src="https://avatars.githubusercontent.com/u/19956801?v=4&s=117" width="117"/> |<img alt="Arclite" src="https://avatars.githubusercontent.com/u/184375?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | michalsrutek |mgray88 |akaDuality |MagnificentMiles |gaetanomatonti |Arclite |

<img alt="mangofever" src="https://avatars.githubusercontent.com/u/724343?v=4&s=117" width="117"/> |<img alt="grdsdev" src="https://avatars.githubusercontent.com/u/5923044?v=4&s=117" width="117"/> |<img alt="Tulleb" src="https://avatars.githubusercontent.com/u/5658984?v=4&s=117" width="117"/> |<img alt="haeseoklee" src="https://avatars.githubusercontent.com/u/20268101?v=4&s=117" width="117"/> |<img alt="eltociear" src="https://avatars.githubusercontent.com/u/22633385?v=4&s=117" width="117"/> |<img alt="woin2ee" src="https://avatars.githubusercontent.com/u/81426024?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | mangofever |grdsdev |Tulleb |haeseoklee |eltociear |woin2ee |

<img alt="unxavi" src="https://avatars.githubusercontent.com/u/3817679?v=4&s=117" width="117"/> |<img alt="jesus-mg-ios" src="https://avatars.githubusercontent.com/u/85997060?v=4&s=117" width="117"/> |<img alt="mo5tone" src="https://avatars.githubusercontent.com/u/8422976?v=4&s=117" width="117"/> |<img alt="jinuman" src="https://avatars.githubusercontent.com/u/26243835?v=4&s=117" width="117"/> |<img alt="Juanpe" src="https://avatars.githubusercontent.com/u/1409041?v=4&s=117" width="117"/> |<img alt="JulianAlonso" src="https://avatars.githubusercontent.com/u/5766613?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | unxavi |jesus-mg-ios |mo5tone |jinuman |Juanpe |JulianAlonso |

<img alt="nagra" src="https://avatars.githubusercontent.com/u/869660?v=4&s=117" width="117"/> |<img alt="avbangar" src="https://avatars.githubusercontent.com/u/52976276?v=4&s=117" width="117"/> |<img alt="kevin58332" src="https://avatars.githubusercontent.com/u/47673410?v=4&s=117" width="117"/> |<img alt="codeOfRobin" src="https://avatars.githubusercontent.com/u/5009041?v=4&s=117" width="117"/> |<img alt="santos88" src="https://avatars.githubusercontent.com/u/144450?v=4&s=117" width="117"/> |<img alt="spqw" src="https://avatars.githubusercontent.com/u/101190846?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | nagra |avbangar |kevin58332 |codeOfRobin |santos88 |spqw |

<img alt="dankinsoid" src="https://avatars.githubusercontent.com/u/30962149?v=4&s=117" width="117"/> |<img alt="kyungpyoda" src="https://avatars.githubusercontent.com/u/44656036?v=4&s=117" width="117"/> |<img alt="oozoofrog" src="https://avatars.githubusercontent.com/u/3011832?v=4&s=117" width="117"/> |<img alt="dp221125" src="https://avatars.githubusercontent.com/u/10572119?v=4&s=117" width="117"/> |<img alt="thelvis4" src="https://avatars.githubusercontent.com/u/1589385?v=4&s=117" width="117"/> |<img alt="tovkal" src="https://avatars.githubusercontent.com/u/5960675?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | dankinsoid |kyungpyoda |oozoofrog |dp221125 |thelvis4 |tovkal |

<img alt="orbitekk" src="https://avatars.githubusercontent.com/u/4222449?v=4&s=117" width="117"/> |<img alt="woohyunjin06" src="https://avatars.githubusercontent.com/u/30452977?v=4&s=117" width="117"/> |<img alt="lo1tuma" src="https://avatars.githubusercontent.com/u/169170?v=4&s=117" width="117"/> |<img alt="softmaxsg" src="https://avatars.githubusercontent.com/u/3723817?v=4&s=117" width="117"/> |<img alt="zdnk" src="https://avatars.githubusercontent.com/u/2551911?v=4&s=117" width="117"/> |<img alt="Andrea-Scuderi" src="https://avatars.githubusercontent.com/u/8319309?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | orbitekk |woohyunjin06 |lo1tuma |softmaxsg |zdnk |Andrea-Scuderi |

<img alt="roanutil" src="https://avatars.githubusercontent.com/u/9873566?v=4&s=117" width="117"/> |<img alt="cpisciotta" src="https://avatars.githubusercontent.com/u/38054839?v=4&s=117" width="117"/> |<img alt="cristi-lupu" src="https://avatars.githubusercontent.com/u/41613812?v=4&s=117" width="117"/> |<img alt="david-all-win-software" src="https://avatars.githubusercontent.com/u/70285087?v=4&s=117" width="117"/> |<img alt="DavidBrunow" src="https://avatars.githubusercontent.com/u/1452879?v=4&s=117" width="117"/> |<img alt="dcordero" src="https://avatars.githubusercontent.com/u/2320840?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | roanutil |cpisciotta |cristi-lupu |david-all-win-software |DavidBrunow |dcordero |

<img alt="dogo" src="https://avatars.githubusercontent.com/u/1487375?v=4&s=117" width="117"/> |<img alt="griches" src="https://avatars.githubusercontent.com/u/798117?v=4&s=117" width="117"/> |<img alt="GermanVelibekovHouzz" src="https://avatars.githubusercontent.com/u/81903043?v=4&s=117" width="117"/> |<img alt="PierreCapo" src="https://avatars.githubusercontent.com/u/26744253?v=4&s=117" width="117"/> |<img alt="iainsmith" src="https://avatars.githubusercontent.com/u/993745?v=4&s=117" width="117"/> |<img alt="myihsan" src="https://avatars.githubusercontent.com/u/7414906?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | dogo |griches |GermanVelibekovHouzz |PierreCapo |iainsmith |myihsan |

<img alt="L-j-h-c" src="https://avatars.githubusercontent.com/u/77208067?v=4&s=117" width="117"/> |<img alt="havebeenfitz" src="https://avatars.githubusercontent.com/u/31866271?v=4&s=117" width="117"/> |<img alt="mfcollins3" src="https://avatars.githubusercontent.com/u/104274?v=4&s=117" width="117"/> |<img alt="nicholaskim94" src="https://avatars.githubusercontent.com/u/7912759?v=4&s=117" width="117"/> |<img alt="zhuhaow" src="https://avatars.githubusercontent.com/u/1287724?v=4&s=117" width="117"/> |<img alt="baekteun" src="https://avatars.githubusercontent.com/u/74440939?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | L-j-h-c |havebeenfitz |mfcollins3 |nicholaskim94 |zhuhaow |baekteun |

<img alt="jakeatoms" src="https://avatars.githubusercontent.com/u/3605966?v=4&s=117" width="117"/> |<img alt="jrescabias" src="https://avatars.githubusercontent.com/u/78204502?v=4&s=117" width="117"/> |<img alt="danibachar" src="https://avatars.githubusercontent.com/u/6380777?v=4&s=117" width="117"/> |<img alt="apps4everyone" src="https://avatars.githubusercontent.com/u/1915802?v=4&s=117" width="117"/> |<img alt="chojnac" src="https://avatars.githubusercontent.com/u/304027?v=4&s=117" width="117"/> |<img alt="shahzadmajeed" src="https://avatars.githubusercontent.com/u/1209459?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | jakeatoms |jrescabias |danibachar |apps4everyone |chojnac |shahzadmajeed |

<img alt="pavel-trafimuk" src="https://avatars.githubusercontent.com/u/5096762?v=4&s=117" width="117"/> |<img alt="AlbGarciam" src="https://avatars.githubusercontent.com/u/45308839?v=4&s=117" width="117"/> |<img alt="xoxo-anastasi-xoxo" src="https://avatars.githubusercontent.com/u/28875920?v=4&s=117" width="117"/> |<img alt="davebcn87" src="https://avatars.githubusercontent.com/u/477473?v=4&s=117" width="117"/> |<img alt="morozkin" src="https://avatars.githubusercontent.com/u/16591888?v=4&s=117" width="117"/> |<img alt="esttorhe" src="https://avatars.githubusercontent.com/u/2642850?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | pavel-trafimuk |AlbGarciam |xoxo-anastasi-xoxo |davebcn87 |morozkin |esttorhe |

<img alt="ffittschen" src="https://avatars.githubusercontent.com/u/7734806?v=4&s=117" width="117"/> |<img alt="FranzBusch" src="https://avatars.githubusercontent.com/u/3491887?v=4&s=117" width="117"/> |<img alt="Jake-Prickett" src="https://avatars.githubusercontent.com/u/26095410?v=4&s=117" width="117"/> |<img alt="miscampbell" src="https://avatars.githubusercontent.com/u/3660489?v=4&s=117" width="117"/> |<img alt="bolismauro" src="https://avatars.githubusercontent.com/u/771999?v=4&s=117" width="117"/> |<img alt="moritzsternemann" src="https://avatars.githubusercontent.com/u/3034168?v=4&s=117" width="117"/> | :---: |:---: |:---: |:---: |:---: |:---: | ffittschen |FranzBusch |Jake-Prickett |miscampbell |bolismauro |moritzsternemann |