Getting It Into People's Hands

I had a working game on my iPhone. I had thirty-four Linear issues telling me what to build next. I had Claude Code humming along with a rewritten engine. Logically, the next step was to ship this thing to another human and see what they thought.

This post is about the two days it took me to cross the gap between "it runs on my simulator" and "my wife has it on her phone." Which, when I describe it like that, sounds trivial. It is not trivial. It is in fact the wall that kills most side projects, and the wall I nearly smacked into for the first time.

v1.0.0

The UI overhaul shipped as PR #9 on 2026-03-22:

v1.0.0 — UI overhaul, project rename, settings panel (#9) — 106 files

The project was six days old. The game had no backend, no leaderboards, no economy, no zones. It was still called "AyaEscape." And I tagged it v1.0.0.

In retrospect: absurd. I was so excited I wanted to mark the moment with a real-sounding version number. Within a few days I'd walked it back to 0.0.1 for the actual TestFlight beta, and since then I've been trying to stay under 0.1.0 until the game has its first real public release. Every version bump triggers an App Store review, and the first one took a week and a half, so burning a version on enthusiasm is a real cost.

Small, funny detail. Useful rule: save the version bumps for when they mean something.

Apple is far behind

Here's the thing nobody tells you about shipping to TestFlight. Apple's developer portal (App Store Connect, Xcode Cloud, certificate management, provisioning profiles) has essentially no programmatic interface that a solo dev can use from the terminal. There's no CLI. No MCP integration. No curl-friendly API worth the effort (there's a creaky App Store Connect API but it's geared at enterprise automation, not "I want to add a TestFlight tester without leaving my editor"). If you want to ship an app, you open the browser and click through forms.

And the forms ask for things. Things like:

• Encryption compliance declarations (ITSAppUsesNonExemptEncryption in your Info.plist, plus a form you fill out every build)
• Export compliance classification (your app uses HTTPS, which technically counts as encryption, did you know?)
• App icons with no alpha channel (Apple rejects transparent icons; I learned this by getting rejected)
• Privacy manifest declaring what data you collect and why
• Content rights declarations
• Age rating questionnaires with questions about violence, gambling, mature themes
• Version string that has to match your project file
• Build number that has to monotonically increase
• Primary language, primary category, secondary category, keywords...

I had no prior iOS shipping experience. Zero. So every field that Apple asked for became a mini-investigation: Claude, Apple is asking for X, what do I do?

If you're a developer reading this, you already know how that sentence feels. You've said a version of it yourself. For me, the first time I said it out loud was at 22:00 on a Sunday night, with Xcode's validation dialog open on one monitor and Claude Code on the other, and I genuinely did not know what the right answer was.

Claude had the answer. Not because it had all of this in its training data, but because it could crawl the web. Apple's official docs, Stack Overflow threads, Apple Developer forum posts, community blog posts from people who'd hit the exact same error two months ago. It pulled from all of them, reconciled the conflicts, and gave me a concrete answer.

This is worth pausing on. The old workflow was "read the docs, find the relevant section, apply it." That presumes documentation exists and is complete. Apple's developer bureaucracy is not documented in a single place. It's scattered across Xcode dialog text, App Store Connect help popovers, WWDC session transcripts, blog posts, and Stack Overflow.

Now I ask Claude. Claude figures out which of those scattered sources has the answer, fetches them, and gives me one paragraph. I verify by reading the sources it cites. Two minutes instead of forty.

If you're shipping an iOS app as a solo dev and you are not using an AI pair for the Apple bureaucracy, you are working twice as hard as you need to be. Full stop.

The naive design workflow

Day 7 also included design work. The UI overhaul PR had a new settings panel with a real visual design. At this point in the project, my design workflow was painful.

It's funny in retrospect and also a useful baseline for how much this has improved since.

Step 1: I'd open Codex (the ChatGPT / OpenAI code interface) and ask it to write me a prompt. Not for the design directly, but a prompt for the design. I'd describe what I wanted and Codex would draft an image generation prompt.

Step 2: I'd take that prompt and paste it into GPT's image generator. I'd get back a mood board, six or so small images showing different visual directions.

Step 3: I'd pick one direction and refine the prompt until the image generator spat out a full settings panel mockup.

Step 4: I'd download the PNG and open it in Photoshop.

Step 5: I'd slice the full panel into individual asset PNGs: one for each button, one for each slider track, one for each icon. Manual slicing. Pixel-perfect boundaries. The stuff a real designer does in Figma in two minutes but that I was doing by hand in Photoshop because I didn't know the shortcuts.

Step 6: I'd go back to Claude Code and struggle to implement the SwiftUI views that consumed the sliced assets. The assets were the wrong sizes, or had the wrong anti-aliasing, or didn't match the expected naming convention.

Six steps. Multiple tools. Half a day for one settings panel.

It's funny in retrospect how hard I was taking this. Six days into the project I thought this was the pipeline for ever. I thought every screen in the game would take half a day of Codex → GPT → Photoshop → Claude.

Since then, everything changed. The current workflow is a single Python script that generates a full zone's worth of game art in three hours, and the UI is generic and grows from JSON config rather than being asset-dependent. I'll cover that transformation in post 9 (the AI art pipeline post). For now, the relevant point is that the naive workflow on day 7 was so painful that it forced the automation breakthrough three weeks later. If something hurts six times, it's telling you to build the tool.

CLAUDE.md becomes real

One more thing from this stretch. On 2026-03-23 I committed:

Consolidate AGENTS.md workflow rules into CLAUDE.md

One file changed. Looks like housekeeping. Was actually a turning point.

Before this commit, project rules lived in multiple places: AGENTS.md had some workflow guidance, the Xcode project file had implicit conventions, my memory had opinions, and some rules only existed in the exact chat where I'd last articulated them. New Claude Code sessions would read bits and miss things. It was a mess.

The consolidation into CLAUDE.md made it the single source of truth that every Claude Code session reads at the start of every conversation. From this day forward, any operational rule, code convention, tool preference, or "gotcha" gets added to CLAUDE.md. It grows with the project.

Why does this matter? Because without CLAUDE.md, every new session starts from zero context and has to rediscover the project's conventions. With CLAUDE.md, a new session knows immediately that GameRuntime has zero UIKit imports, that platform full-01.png files need a specific assetScale formula, that jumpStrenght is a deliberate misspelling ported from the original codebase (don't "fix" it), and that version bumps require explicit approval. All the project's sharp edges, documented in one place that the model reads automatically.

If you take one thing from this post: treat CLAUDE.md (or your equivalent) as the brain of your project. Every time you explain something to Claude more than once, write it into CLAUDE.md. Every time Claude makes a mistake because it didn't know a convention, write the convention into CLAUDE.md. It's boring, it's tedious, and it compounds faster than any other single workflow improvement I've found.

First testers

The game shipped to TestFlight on 2026-03-24. My first tester was my wife. Not because she's the target demographic for a vertical climber arcade game (she isn't particularly), but because she was in the room when I got the TestFlight invite working, and I was excited, and I handed her my phone.

My second tester was Or, the friend from post 1 who was in the car when this whole thing started. Or is also not the target demographic but he was genuinely invested in whether the project would actually ship, so he played it immediately and reported back.

It felt unreal.

I'd been staring at this game on my own phone for eight days. Handing it to someone else and watching them play it, even for 30 seconds, even with the janky placeholder art, even with no real objective other than "climb as high as you can before the camera catches you," was the moment where "side project" crossed over into "real thing." A stranger could have picked up that phone and had an opinion about the game. For the rest of that week I walked around thinking "there's a thing I made that exists on someone else's phone and they have an opinion about it."

Every developer who's ever shipped something knows this feeling. If you haven't had it yet, you should chase it. Not because the thing has to be good (mine wasn't), but because the feeling resets how you think about your own work. Shipping, even badly, is the thing.

Legal hygiene that already mattered

One last detail from this stretch. Even on day 7, I was thinking about App Store guidelines, privacy, and legal compliance. Not because of a specific threat. Because I didn't want to get caught later.

App Store Connect rejected my app icons the first time because they had alpha channels. Learned that, fixed it, moved on. But it planted a seed: Apple has rules, the rules are numerous, and "I'll deal with it later" isn't a strategy. Every subsequent PR I reviewed carried a small "does this touch a guideline?" question in the back of my head. Age-gating, encryption compliance, privacy manifest updates, third-party SDK policies. All of them got handled as they arose, not batched for a final cleanup pass.

When you do it all, you really do it all. Indie game dev means you're also the legal department, the QA team, the marketing team, and the tester. Compliance is just one more hat, and it fits better if you put it on early.