Phoenix.vu
AI Coding Agent for Xcode | Swift & iOS
We're a small product company; we have built a few coding tools already, and one pattern kept showing up: general-purpose AI coding assistants are everywhere, but almost none are built for Xcode. They live in a browser tab or a separate window; you paste code back and forth, and half the time the suggestion doesn't even compile in your project.
Then Alex Sidebar, one of the few tools that was genuinely Xcode-native and well-liked, shut down. Their team joined OpenAI to work on Codex, downloads stopped, and a real gap opened up in a space we already had conviction about.
So we built Phoenix.vu: an AI agent that lives inside Xcode, writes Swift, watches your build in real time, auto-fixes errors, and shows you a diff before anything's applied. Code stays local on your Mac; nothing gets uploaded. We figured: clear niche, real pain, a competitor just left the field; this should land.
Here's the part we don't have a clean answer for. Signups are low — not "slow ramp" low, more like "something isn't connecting" low. And of the small number who do sign up, we're barely seeing anyone come back and actually use it inside Xcode. Nobody's paid yet either.
So we are genuinely asking, not fishing for reassurance, and we don't know if that's a marketing problem or a product problem
For iOS/Swift devs:
Is an Xcode-native AI coding agent something you'd actually go looking for, or does it not register as a real problem for you?
If you'd never heard of Phoenix.vu until this post, why do you think that is — wrong channels, no reason to trust a new tool with real code, or just not a strong enough pain point?
What would make you actually open a new dev tool a second time, versus sign up once and forget it exists?
For other founders:
When you're marketing something genuinely new, how did you actually find out where your buyers pay attention — trial and error, or something more deliberate?
When growth stalls this early and the numbers are too small to read cleanly, how do you tell "wrong channel" apart from "wrong product" without just guessing?
If you've had a launch flop quietly like this, what's the first thing you changed — the message, the channel, or the product itself?
Looking to hear from you all; We genuinely just want to understand this better and figure out where to improve. Any perspective helps, even a small one.
A few people asked us privately what we meant by "your source code stays local" in the Phoenix.vu pitch — fair question, since every AI coding tool claims to care about privacy.
Here's the actual mechanics, no marketing spin: your project, your Swift files, your build errors, your whole repo — none of it gets uploaded anywhere. What leaves your machine is the inference context — the specific prompt and snippets the model needs to answer that request. Your codebase as a whole never touches our servers.
We built it this way because we're iOS developers ourselves, and most of us wouldn't put a client's proprietary codebase through a tool that ships the whole repo to train or store somewhere. That wasn't a compliance checkbox for us — it's the same bar we'd want if we were the ones handing over the code.
One user put it better than we could: "Knowing my code stays local and only inference context leaves made this an easy yes for our whole team."
We know "trust us" isn't really a thing in this space, so if anyone wants to dig into how the request/response boundary actually works, happy to get specific in the comments.
We launched phoenix.vu here last week, and someone asked us a question: 'Does specializing in Xcode actually reduce broken builds and iteration time, or is that just a pitch?. Honestly, we believe it does, that is one of the main reasons we built phoenix in the first place, to understand the xcode project, Swift/SwiftUI, and the build -- error-- fix cycel instead of treating them like a general coding problem.
But we are still new, and we don't have enough real user data to put a number on it yet. So what we are doing now is we are going to measure it, and next time someone asks, we will have a number or percentage to share.
For now, we would really like to hear from you. If you build for Apple platforms, what's the build error or iteration-time problem that actually costs you the most time right now? Not what you'd expect to slow you down, but what actually has- what actually drove you crazy this week. We’re reading the replies and using them to figure out what we should improve next.
The era of one-size-fits-all coding agents is yesterday's tools. 🔥
That's why we built Phoenix.vu: a next-generation coding agent specialized for the Apple ecosystem.
General-purpose AI tools treat every codebase the same. But shipping for Apple isn't the same as shipping for the web — Swift, Xcode, build systems, simulators, App Store workflows. It's its own world.
No more copy-pasting between Xcode and a chat window. No more losing the thread. No more broken builds from blind AI rewrites.
We believe the future of AI coding isn't one giant generalist — it's specialized agents that deeply understand your stack.
Phoenix is where we start: with the developers who ship for Apple.
👉 Try it today: https://phoenix.vu/
-
1Does the Xcode specialization noticeably reduce broken builds or iteration time versus general coding agents?
-
1
Yes, to an extent. Phoenix’s Xcode specialization helps reduce issues around Xcode project structure, build settings, Swift/SwiftUI, and the build/debug cycle. That can mean fewer broken builds and faster iteration, especially on complex projects. It’s not a guarantee, though—the advantage varies by project and task.
-
1That makes sense. Have you seen any concrete before/after signal yet — fewer build failures or less time spent getting from a change to a working build?
-
1
We’re still pretty early, so we don’t have enough real-world data yet to put a solid number on the improvement, so I wouldn’t want to claim a specific percentage yet. This is actually one of the reasons we built Phoenix in the first place, to make the Xcode build --error-- fix cycle smoother. We’re still new and learning a lot from our first users, which is helping us continuously improve the product.
-
1That’s fair, especially this early. I’d be interested in seeing what the first-user data shows. If you’re open to it, what’s the best email to reach you on?
-
-
-
-
Comment