Process
AI writes the code. It still isn't garbage.
That is the thing worth hiring, so this page explains how it's true rather than asking you to take it on faith. Hire me to build an app for you, your team, or your company — from an idea with no repository, or from wherever yours has stalled.
Below is the actual process: two verification loops priced differently, evidence that comes from outside the code, guarded store submissions, and a person approving everything that goes out. It is how my own apps get shipped, not a diagram I drew for a sales page.
Nothing here is hosted: you choose which machines it runs on and whose AI account it uses, and you choose before we start. There is no product and no waitlist — just me, and a way of working I'll apply to your project.
The premise
I don't hand-write Swift or Kotlin. That is the least important thing about this.
I should say that plainly, because it sounds like a disqualification and I don't think it is. What I know is systems: how a thing is supposed to behave, where a design will fall over, and how to take an implementation apart until it either holds up or breaks in front of me.
Agents write the code. My job is to not believe them.
That distinction is the whole difference between this and a vibe-coded app. Vibe coding means accepting output because it compiled and the screenshot looked fine. Both of those are evidence of almost nothing. A build that compiles can still crash on launch — a scripted device tour caught exactly that on my Android port after a green build said everything was fine.
So the pipeline is not built to generate code faster. It is built to make claims checkable, cheaply enough that I actually check them every time instead of when I remember to.
Speed
Verified and fast are not opposites. That is the whole claim.
The assumption behind "AI-built app" is that you trade quality for speed, and the assumption behind "carefully built app" is that you wait months. I am arguing you don't have to pick, and the only honest way to argue it is with a number and its caveats attached.
Both numbers are measured on Dancing Robot, from deciding to do the thing to it being on the store. The gap between them is almost entirely Apple's review queue, which is the part neither of us controls — so treat ~36 hours as the number to plan around and the same-day case as what happens when review comes back fast.
I want to be exact about what this is not. It is a feature on an app that already exists and already has a release pipeline pointed at it. A new app from scratch is a different number, and I would rather work out a real one for your project than let you anchor on this one.
The speed does not come from skipping the checks. It comes from the checks being cheap enough to run every time, so nothing waits for a human to remember them.
Platforms
Two halves, honestly at different stages.
The iOS side has real production mileage behind it. The Android side is newer and is being proven on an actual submission rather than a demo. I'd rather say that plainly than imply both halves are equally battle-tested.
iOS
Proven · 15+ releases through App Store review- Xcode build triage and compiler-error passes
- Simulator verification, scripted UI tours, screenshots
- App Store Connect submission and reviewer-reply drafting
- Privacy manifest, SDK, and App Tracking Transparency checks
Android
New · first submission in Play review now- Gradle build triage and Kotlin/Java error passes
- Emulator and device verification via scripted instrumentation tours
- Play Console track staging, release notes, and edit-transaction submission
- Data safety form, permissions, and CMP consent checks
Verification
Two loops, priced differently.
Most "does it work?" questions are not visual, and answering them with a screenshot is slow and expensive enough that you stop asking. So the cheap loop answers almost everything, and the expensive one runs only when the pixels are the deliverable.
Inner loop
Cheap · a few lines of text- Structured, gated event logs emitted by the app itself
- Answers "did it fire, and with what arguments?"
- Numeric extraction from recordings for tuning parameters
- Carries about 95% of the checks
Outer loop
Expensive · run deliberately- Screenshots, screen recordings, UI snapshots
- Answers "does it actually look right?"
- Scripted tours that drive the app to the screen in question
- Reserved for when appearance is the thing being judged
- Scope the blocker from the repo, the store state, and what actually needs to ship next.
- Run verification loops against real builds — compiler output, runtime behavior on simulator or emulator, screenshots pulled from scripted tours rather than trusted from a log.
- Prepare the release: submission notes, privacy and data-safety checks, store metadata, and version-pinned policy URLs.
- Stop and wait for me on release decisions, reviewer and Play policy replies, privacy disclosures, and anything product-sensitive.
Step four is the whole point. Everything before it is tooling; the reason I trust the tooling is that it is not allowed to finish on its own.
Submission
Releases go out from a script, not from a console at 11pm.
Anyone can write a submitter for either store. What matters is having one that has actually been run, repeatedly, against real rejections — so both stores are driven the same way, and the tedious parts stop depending on whether I remembered them.
Screenshots are captured, not taken
Store screenshots come out of scripted device tours that drive the app to the screen in question, so the images in a listing match a build that actually ran rather than a staged moment from a simulator I happened to have open.
Disclosures are checked before, not after
Privacy manifests, tracking domains, Data safety answers, and consent configuration get reviewed as part of preparing the release. Each shipped version pins its own policy URL permanently, so the disclosures a build was reviewed against stay live even after the next build changes them.
This is not theoretical for me. One of my apps is ad-supported, so every release carries an ad stack, a consent SDK, an App Tracking Transparency prompt, and a declared list of tracking domains that has to match what the binary actually contacts. That is the part of submission where apps get rejected, and it has cleared review fourteen times.
It gets better every time it hurts
This is the part that compounds. Every release that goes sideways — a rejection, a crash a green build missed, an hour lost to a console quirk — gets written down and turned into a check that runs from then on. What you get is the accumulated version of that, not the one I started with.
Hard parts
Motion, 3D, and performance don't survive "looks fine to me."
These are the areas where an agent will confidently hand you something plausible and wrong, and where a human eye at 60 frames per second genuinely cannot tell. They are also most of what my two apps are made of.
Physics and game feel
Dancing Robot runs a 2D physics simulation with beat-synced timing windows and a live device-motion stream. "The throw feels wrong" is not a bug report you can act on, so instead of arguing about feel I plot it: a time-versus-position trace pulled from a screen recording shows phase drift and jitter that playback hides. Then the tuning loop runs on numbers, not vibes.
3D rendering
Unearth is a real SceneKit and Metal app, not a flat mock — procedural geometry, generated textures, and a brush that erodes dirt off a mesh while you turn it in the light. Every pot is seeded and generated fresh, which means the rendering path has to be correct for cases I have never personally looked at.
Performance and profiling
Instruments traces, memory graphs, build timing, and frame-level profiling, read as evidence rather than skimmed. This is the part of mobile work that most resembles the systems work I did on high-throughput services, and it is the part I trust myself on most.
Evidence has to come from outside the code
A test suite written by the same process that wrote the code agrees with the code, including everywhere the code is wrong. Generated work comes with generated tests, so a test count proves nothing — my two apps have a few hundred test functions between them and I would not ask you to be impressed by that number.
What counts is an oracle the implementation does not control: a scripted tour driving a real build on a real device and reporting what the app actually did; a screen recording measured numerically instead of watched; output diffed against a known-good artifact. That is the same gate I used migrating a 100k req/s service to Rust — make the bytes match, or it doesn't ship. The only test worth citing to you is one that has failed.
Whose account
There is no hosted service in the middle. You choose where it runs.
Mobile toolchains want to live on a Mac, not in somebody's cloud, so this is not a product you log into. It runs on real hardware — and which hardware, and whose AI account, are both yours to decide before we start rather than things you find out afterward.
My machines by default, yours if you'd rather
On mine: this is the normal arrangement and the faster one. The parallelism described above is a fleet of my own Macs, so builds, device verification, and release prep run at the same time instead of queueing behind each other. Practically, it means I work the way any contractor with a checkout of your repository works — your code is on my hardware for the length of the engagement, and I'd rather say that plainly than imply some arrangement where it never leaves your building.
On yours: if your code genuinely cannot leave your environment — regulated industry, client contract, a policy you don't get to argue with — the same toolchain runs on machines you own and administer. Expect it to be slower in proportion to how many machines you can give it, because that is where the throughput was coming from.
Your AI account or mine — you pick
On your account: if your company already has an agreement with an AI vendor — retention terms someone negotiated, a procurement review someone survived, a console your security team can actually audit — I work inside it. Your code gets processed under the contract you signed, not under a personal account belonging to a contractor you met last month. This is usually the part that unblocks a security review: what worries a competent CISO about AI-assisted contract work is not the AI, it is not knowing whose account the code went through.
On mine: if you don't have an agreement to work under, or simply don't want a contractor's usage landing on your bill, I bring my own and the tokens are my problem. Nothing for you to provision, no spend to explain to finance.
Either is fine by me. The point is that it's your decision rather than something you discover after the work is done.
Your credentials stay where they are
Signing identities, App Store Connect keys, and Play service accounts stay in your control. I don't need custody of them to do this work, and holding them would be a liability for both of us.
What I take away is what I learned
I keep a running journal of process failures and the checks they turned into, and your engagement will add to it — that is how the next client gets a better version. What goes in it is the lesson, never your code, your data, or anything that identifies you. Your project leaves you with a working pipeline; I leave with a sharper one.
Engagements
Three ways this gets bought.
I am one person, so I would rather be specific about the shapes that work than imply I can be anything to anyone. Mostly I build the thing.
Direct contract — the usual one
From scratch or from where you're stuck. An idea and no repository is a perfectly good starting point — both of my apps started that way. So is a half-built app that stalled, or one that works but cannot get through review. I do the work and you deal with me, not an account manager.
The reason this is worth more than it sounds coming from one person: the pipeline runs in parallel across machines, so builds, device verification, and release prep are not competing for one laptop and one pair of hands. Throughput here looks less like a solo contractor and more like a small team, without the coordination cost of one.
Subcontract and white-label
You are an agency or studio that has already sold mobile work and needs someone who can actually deliver it. I am comfortable working under your name, to your client's timeline, without being in front of the client.
Process work — usually after we've shipped something together
Your team ships already, but releases are unpredictable and nobody trusts the verification step. I set the loop up inside your codebase, prove it catches things, and document it so your team owns it afterward. A scoped engagement with an end, not a tool I hand over and invoice forever.
It ends up on your machines and under your accounts, and there is no seat fee waiting for you after I'm gone.
Send me what you're shipping and where it keeps stalling. If I'm not the right person, I will say so instead of taking the work.
Questions
Is this a product I can buy?
No, and an earlier version of this page implied otherwise. It is how I work. You can hire me to apply it, subcontract me, or have me set it up in your team — but there is nothing to license and no waitlist to join.
Does it support Android?
Yes, as of the Dancing Robot port. That build is in Play review now. The iOS half has more mileage on it, and I'll keep saying so until the Android half has caught up.
Does it replace human review?
No, and that's deliberate. It automates the repetitive engineering and submission work. Release decisions, reviewer and Play policy responses, privacy disclosures, and product-sensitive changes stay mine.
You said you don't write Swift. Why should I hire you for a mobile app?
Because the failure mode in mobile work right now is not "nobody can produce Swift." It is that the code gets produced and nobody checks it properly. I design the system, define what correct means, and verify it adversarially. If what you need is a hands-on-keyboard Swift specialist, I will tell you that early rather than take the work.
Whose AI account does my code go through?
Whichever you prefer. If you have a vendor agreement, I run the toolchain logged into it, so your code is covered by retention and privacy terms your company already negotiated — that is usually what a security review wants to hear. If you'd rather not provision anything or have my usage on your bill, I bring my own account and absorb the cost. Ask before we start and it is a non-issue either way.
Why has this page changed names twice?
It was "iOS Builder" until it covered Android, then "Mobile Builder" until I admitted I was not building a platform to sell. Both old links still work and redirect here. I would rather rename a page than leave it describing something that isn't true.