Private beta · for Xcode projects
Big app. Small wait.
Quickfire rebuilds only what your edit touched, for iOS developers and the coding agents that build all day.
Thanks. We read every answer.
First build Quickfire maps how your app builds
Change a line of code Quickfire rebuilds only what it affects
How it works
- 1
One full build first
Quickfire builds your app once with Apple's tools and notes how every part of it fits together. This first build is slower.
- 2
Then, only what changed
Keep coding as usual: fix a bug, tweak a view, change some logic. On the next build, Quickfire works out which parts of your app the edit actually affects and rebuilds just those, with Apple's own compiler. Apple's build does a lot more work than a small edit needs, and on a big app that's where the minutes go.
- 3
Not sure? Normal build
When Quickfire can't prove a shortcut is safe, it runs Apple's normal build instead. The app you get is the same app, byte for byte.
Your agent waits on builds too
Coding agents rebuild after nearly every change, so on a big app much of their time is spent waiting on the compiler. Quickfire runs from the command line: no IDE, nothing to click. Your agent runs one command and gets the build, the install and the launch in the Simulator.
Faster builds mean shorter agent loops, and less time paying for an agent that's waiting.
# agent edited FeedRow.swift
$ quickfire run
› rebuilding 1 changed file
› compiled, linked, signed
✓ built and launched in the Simulator · 15 sThe same app, byte for byte
Quickfire changes how much work a build does, not what it makes: you get the same app Apple's build would give you. To check, we take an open-source app, IceCubes, rebuild each commit in its history both ways, and compare every file the two builds produce. On its last 38 commits, 36 were identical byte for byte, and none had stale code. See the results →
Your code stays on your Mac
Quickfire runs on your machine. No source code, file names or paths are ever sent to us. Your dashboard gets build timings only, and one command turns them off.
Why not Bazel, Tuist or compilation caching?
They're good tools. They solve a different part of the problem.
| What you change | What it speeds up | |
|---|---|---|
| Bazel | Rewrite your build in Bazel | Everything, after a large migration |
| Tuist | Generate your project from Tuist manifests | Reuses prebuilt modules; project generation |
| Xcode's compilation caching | Turn on a build setting | Reuses compiler results between builds; the rest of the build still runs |
| Quickfire | Nothing in your project | Everyday rebuilds as you code, on your existing project |
Quickfire uses compilation caching too, and builds on it. Caching alone saves compiler work, but the rest of the build still runs every time. Quickfire also skips the work your change doesn't need.
Quickfire works with the Xcode project you already have, and you can stop using it any time: your next build is just Apple's build.
Is it worth it for your app?
Big gains
Large apps whose incremental builds take minutes. Everyday edits to logic, types and views, and switching back to a branch you've built before.
Not faster yet
The first build of a new branch, merges and very large changes can be slower than Apple's build today. We're working on these.
No gain yet
Small and mid-size apps whose incremental builds already take seconds.
Not touched
Release, archive and App Store builds. Device builds and tests aren't supported yet.
What's next
Quickfire starts with faster builds on your Mac. Here's where it's going; when you join, tell us what you'd use.
Planned
Quickfire Cloud
A shared team cache: one teammate's build speeds up everyone's, including the first build of a new branch or a fresh checkout.
Planned
CI builds
The same speed-up on your CI, sharing results with your team's Macs.
Planned
Device builds and tests
Fast rebuilds for your app on a real device, and for test runs.
Exploring
Faster testing for agents
Once builds are fast, testing is the slow step. Ways for agents to see and use your app in the Simulator, without slow screenshot-and-guess loops.
Exploring
Hot reloading
See a change in the running app without waiting for a rebuild.
Questions
What do I need?
A Mac with Apple silicon, macOS 15 or later, and a supported Xcode (Xcode 27.1). Today Quickfire handles Simulator Debug builds of iOS apps.
Does it change my project?
No. Quickfire keeps its own data next to your build; your project files stay as they are.
What happens when Xcode updates?
Each new Xcode build is tested before Quickfire uses it. Until then, your builds run as Apple's normal build.
What if something goes wrong?
Quickfire falls back to Apple's build whenever it isn't sure. You can turn it off for a project with one command.
What will it cost?
Quickfire will be a paid subscription, priced per developer. Beta testers get a discount for sharing feedback and helping us improve it.
Does it work with my CI?
Not yet. Quickfire CI and a shared team cache are planned.
Is Quickfire made by Apple?
No. Quickfire is an independent tool for Xcode projects.
Your next build could already be done.
We're opening the beta a few people at a time, for feedback.
Thanks. We read every answer.