For most of the last decade, releasing an iOS app lived on my todo list as a half-day task I postponed until I couldn't. Build, archive, screenshots, version notes in three languages, attach the build, fill in marketing copy, queue for review. Each step is small. The total adds up to a Saturday I never enjoyed.
The actual release on Lovio earlier this week took one prompt and a final hands-on click. I didn't pre-build anything by hand. I didn't open Xcode. I didn't open App Store Connect until the very end. I typed a sentence into Claude Code, then I clicked Submit for Review when it was ready. That was the whole thing.
The CLI doing the work is asc, an unofficial App Store Connect CLI built by Rudrank Riyam, agent-native by design. I've been thinking about why that 'by design' phrase matters. Not because asc is the only useful agent-native tool out there, but because using it for actual releases has clarified what I want from every other CLI in my stack.
The pain it removes
An iOS release used to mean a long sequence of click-heavy steps across two web UIs and one desktop app. Each step has its own quirks, its own chances to forget which language you've already written the description in. Most of it is patient typing on autopilot. The most error-prone part is the easiest part.
Most of us used fastlane for years. It worked. But fastlane was designed for a CI pipeline you author once and then forget about. When something changed in App Store Connect, you waited for a plugin update or wrote new ruby. The mental model was static automation, periodic maintenance. It rewarded the team that owned the pipeline and quietly punished anyone who only releases once every few weeks and has to re-learn the script each time.
asc's mental model is different. It treats the CLI itself as a thing that gets driven, every time, by an agent that has different context than the last invocation. The shape of every command, the structure of every output, the way errors are reported, all of it is optimized for a model that is encountering the tool fresh and reading just enough of `--help` to know what to call.
My actual workflow
The release is split across two pieces. Build and TestFlight push happens earlier in the week, usually right after a feature lands. asc handles that part too, with `xcode` for local archive and export and `publish` for the upload, but I run that piece separately because I want the build sitting on TestFlight for a couple of days while I dogfood it.
When I'm ready to ship to the App Store, my prompt is exactly this:
Claude CodeOpus 4.7 with xhigh effort · Claude Max──────────────────────────────────────────────────────────────› bump version and add to app store, write change description and update description if needed. use brand voice.────────────────────────────────────────────────────────────── Opus 4.7 │ ⚡ 33% │ main │ lovio ▶▶ auto mode on (shift+tab to cycle)The agent reads it, knows the project context from the skill packs that are loaded in Claude Code, and starts executing. The actual sequence: pull the latest commits to understand what's new, draft release notes through my brand-voice skill so the copy reads like Lovio rather than a generic changelog, run `asc validate` against the current submission to catch missing screenshots or empty metadata, create the new App Store version, attach the build, write release notes for every language I support, update the marketing description if it shifted, and tell me everything is queued.
Then I open App Store Connect in the browser, do the final hands-on check, and click Submit for Review myself. That click stays manual. Apple won't let me undo a bad submission, so the human gate is worth the ten seconds it costs and the small bit of friction it adds.
Why agent-native is more than marketing language
The thing that makes asc work as well as it does isn't a single feature I can point at. It's a set of small decisions that compound:
- Subcommands are predictable verbs. Every group reads the same way: `asc <noun> <verb>`. An agent that has seen `asc apps list` can confidently guess `asc versions create` and be right.
- Output is structured by default. Tool calls do not end with the agent parsing a human-pretty table. They end with a JSON object the next call can branch on.
- Errors include the operation and the offending field, in machine-readable form. If an agent gets back "validation failed", it can read which field, why, and propose a fix without me having to tell it.
- Operations are idempotent or fail loudly. Running the same release twice does not double the version. Running it on a build that has already been submitted gets a clear refusal, not a half-completed second attempt.
- It ships its own skill pack. `asc install-skills` drops a set of pre-written context files into Claude Code, Cursor, Windsurf, and any agent supporting the skills format, so the model does not have to discover the API shape on its own.
None of those design choices are exclusive to asc. They are decisions you can make about any CLI. But most CLIs I use were not designed this way, because most CLIs were designed for me to type at, and I am tolerant in ways an agent is not.
When the user is a model with no memory, the API of your CLI matters more than its features.
What this changes about CLI design
There is a category of CLI tools that work fine for agents because the agent is patient and forgiving. There is a smaller category that work well for agents because the tool was designed to be driven by something that does not get tired. The cost of the first category is real but invisible. Every time the agent runs an operation against a tool that returns a flaky table, hides errors in stderr, or accepts the same flag spelled three different ways, it burns context window and accuracy.
asc is not alone. playwright-cli is the other one I reach for constantly. Different domain, browser automation instead of App Store metadata, but the same instinct in how it was built. Predictable verbs. A YAML snapshot of page state after every command so the agent always knows where it is. A skill that installs into Claude Code or Cursor so the agent picks up the API shape without me explaining it. Both reward an agent for thinking carefully, instead of punishing it for being patient.
The contrast I notice now is with the older CLIs that were never designed with agents in mind. The big cloud CLIs, most of the SaaS-vendor CLIs of the last decade. They work for an agent, eventually, but a lot of the agent's effort goes into navigating their human-facing quirks, and that is the kind of work where small drift in the model's attention compounds into a wrong call.
I do not yet know whether the right move is to wait for vendor CLIs to retrofit themselves into agent-friendly shapes, or to write thin shims, or to lean on local MCP servers that present cleaner surfaces over the existing tools. My current bias is to take whatever shape the vendor ships and build a small skill pack on top, the way asc ships its own. That keeps the seam visible: this is the tool, this is the agent's understanding of the tool, this is where they are glued together.
What I would ask for next
There is one thing I would happily pay for. A first-class diff mode for App Store metadata. `asc diff` exists, but the killer version is 'show me what would change if I ran this prompt right now'. A dry-run that produces a side-by-side of current and proposed metadata, in the same place the agent runs, before anything is written.
I had a second item drafted. Something about asc registering my brand-voice skill as the default voice for release-notes, so the agent would not have to mediate. Then I realized I was asking for the wrong thing. That composition is exactly what a custom skill is for. One short skill that prompts asc and calls the brand voice in the right order, and the seam disappears without asc having to know my brand exists. The agent layer is the right place for that kind of ownership to live.
What I want from the tool is what only the tool can do. The composition I want around the tool, I write a skill for.
The diff mode is a nice-to-have. The reason I love asc is that for the first time in years of releasing iOS apps, the App Store side of the work is not where my Saturday goes.
A small generalization
If you ship anything that an agent can drive, the most useful design constraint you can impose on yourself in 2026 is to assume the user has never seen your tool before and will not remember its quirks tomorrow. That assumption is right for agents. It also turns out to be right for most of your human users on the second visit, six months in, when they have forgotten all the muscle memory they had the first time.
asc is in a small set of CLIs that take that constraint seriously and ship. I want the set to grow.