I’d be lying if I told you we aren’t thinking about how AI could impact the development of apps for the App Store. I’ve been keeping an eye on everything that’s happening and how solutions are challenging the lenses through which we’ve looked at some problems. This has given us some ideas for how Tuist could play a role there.

You might have noticed many tools for coding ideas or entire apps—tools like Lovable, V0, or even solutions for mobile apps. I don’t expect someone to build a GitHub today with these tools, but you can build POCs, features, and even projects just by chatting. The whole idea of being able to chat to build something, for example with your voice, is quite cool. I think of this as an accessibility tool, and one of Tuist’s responsibilities is to make building apps more accessible—for example, by managing the intricacies of Xcode for you.

However, I’m not aligned with the model where you don’t own the code, either locally or in a remote repository. I get it—it’s a way to monetize it. It’s similar in a way to those GUIs for designing and building websites that required a subscription to export your code. These experiences can and must run locally in my opinion. While many of the local solutions focus on integrating with existing dev environments, I believe local-first Lovables will emerge where the action happens locally, you own the code, and you choose the model.

Apple is doing a bit of this already with their Xcode 26 chat interface, but I believe editors as we know them today are going to change. When I use Claude Code, my editor is more of a tool to review the code and continue conversing with the agent. I don’t need auto-completion or the editor part taking most of my screen. What I need, though, is a way for the agent changes to be hot-reloaded instantly, and it makes me happy to think that we invested in half of that by allowing clean builds to be faster. Once CAS arrives, it’ll be even faster.

So it’ll take ages for Apple to realize things are changing and throw resources into challenging many assumptions baked into Xcode. Until then, I think there’s an opportunity for us, and that’s what I started tinkering with: Tuist Ignite (the name draws inspiration from GitHub Spark). The idea is simple: you run a command, and a coding experience opens in your browser. You can create a new project or add features to the project in the directory where you run the command from. Building? We know how to do it. Short feedback loops? We know that too. And common tasks like adding a dependency to integrate with GitHub? We can add that too. We could have a directory of plugins or formulas for these things that people can contribute to the repo—for example, a formula to set up RevenueCat in the project. I can’t conceive this experience being closed source. If we want to build a truly powerful alternative to Xcode for some types of tasks, this is the way forward.

Now, don’t get me wrong—Xcode doesn’t go away. You might still need it. In fact, we need its build system and Xcode projects internally. Think of Ignite as a new frontend to the same backend. And it’s a frontend that runs locally in your browser, but it can also run remotely—also in a browser or from a native client built for the task. VibeTunnel taught me the mental model of building your network such that you can connect to your localhost from anywhere.

Ignite is about grabbing that idea you had in your head and preserving its energy until it’s touchable—until you can feel it. And having an experience that’s welcoming to anyone regardless of your background. Because ideas can happen anywhere and by anyone, anyone should be able to prototype from anywhere. Most ideas will eventually be discarded, but some will get continued, and this is where an editor like Xcode comes into play.

When contributing an idea to an existing app, you are constrained by the existing project in terms of how things should be done. For example, if the project is written in Swift, you’d shape the idea in Swift. Well… not you, but the underlying agent. But if you don’t have anything, why wouldn’t you just go with React Native instead, which can hot reload changes relatively fast? I don’t know… those are questions I ask myself. Tuist is strongly tied to native development, but I keep an open mind and challenge my own assumptions and principles, and I think React Native is well suited for these kinds of idea ignitions.

Now the idea is built—you’ll want to have an extra check of confidence before you share it with the world. And this is where Tuist QA comes in. Acceptance and snapshot tests are costly to develop, maintain, and run. This is well known… Xcode 26 is making it easier to write them, but what about the maintenance? What about that UI test failing and you being unable to diagnose the issue because what the test is testing is implicit in the testing code itself? Good luck. We think there’s an opportunity to improve the state of the art there—an opportunity to pull your changes, build the app, and then use LLMs to navigate the app and test what you’ve implemented, which can be derived from the changes or your changelog. Once it comes back, you can keep iterating or move forward. The report will come with all the artifacts and data you need to diagnose the issue, from screenshots to the network requests that were sent. Because let’s not forget that diagnosing a UI or acceptance test remains tedious and convoluted these days. We’ve got a POC and it looks very, very promising.

Your idea is built, we know it works—you’ll want to share it with the world, won’t you? You’ll likely want to share it with a small circle, which means you need to build and sign the app, including the destination device IDs in the certificate. Sounds like a lot if you wanted to prototype something or you have no context at all around how signing works in the ecosystem. I feel you. But this is where our Tuist Previews feature will shine. From the same UI where you crafted your idea, you’ll be able to “Log in with Tuist” and click share. It’ll complete with a link that you can share with anyone, and if signing is needed, we’ll sign the app on the fly for you.

What sits at the core of all of this? Our experience working with Xcode projects and toolchain, which we built over the years. A development SDK that can expose runtime data to the Ignite and QA agents. Some context is available from the outside, but other context can only be retrieved at runtime, like the network requests that are happening. And last, we need ephemeral macOS environments, and that’s why I’ve been so excited and supportive of Namespace. It’s the only company that has a well-productized offering of macOS environments for developers. You call an API, and you get a Mac Mini. Our agentic features will be triggerable from anywhere—from a new comment on a PR to a button on the app while waiting for a flight at the airport. We are breaking the strict dependency of everything happening through a CI pipeline, because it’s extremely constraining and terribly limits the DX that one can build.

Oh! And we also need fast builds—otherwise the experience will be as bad through agents as it is when you interface with Xcode directly. Hence why we are investing in reducing the cache latency and preparing for when content addressable store lands in the Swift build system. Maybe next year? Or in a few years? Who knows… in this ecosystem, things are closer to how things are in life: slow.