App-Store-Connect-CLI: asc: The Go CLI Making App Store Connect Machine-Readable
A JSON-first automation layer for Apple’s release pipeline, built for CI, AI agents, and the messy realities of 2FA, uploads, metadata, and submissions.

It has been a month of working on the App Store Connect CLI and it has grown beyond my imagination!
- asc is built for software agents and CI first, so its main product decision is predictable machine control rather than human convenience.
- The repo turns Apple’s messy release surface into reusable Go abstractions for auth, uploads, metadata resolution, and submission flows.
- Its exit codes are part of the product, because pipelines can react to structured failures without scraping text.
- The Wails Studio is not a bolt-on novelty, but evidence that one Go core can serve both terminal and desktop interfaces.
The first thing to understand about asc is what it is not. It is not another terminal convenience layer for a developer tapping through menus. It is a release system shaped for agents, CI, and other callers that need the same answer every time.
That shift matters because App Store Connect is full of brittle human assumptions. Sessions expire. 2FA mutates. Uploads are large, stateful, and easy to mess up. Metadata lives in a maze of app info states, version states, and submission paths.
Why this CLI exists at all
Rudrank Riyam’s public framing makes the intent plain. The project is not pitched as a side utility. It is a release tool meant to be put into pipelines and used repeatedly without drama.
That is why the README language, the command behavior, and even the repository extras point toward a machine audience. The tool favors JSON, non-interactive flows, and explicit outcomes. Humans can still use it, but they are not the center of the design.
| Dimension | asc | What that means |
|---|---|---|
| Interface | JSON-first CLI | Machines can parse it without guessing |
| Command style | Non-interactive | Pipelines do not stall on prompts |
| Scope | App Store Connect focused | Narrower than a full release suite |
| Runtime | Go single binary | Easy to ship and easy to script |
| Audience | Agents, CI, developers | Built for repeatable automation |
Built for machines, not menu navigation
The architecture starts with the command layer and then gets out of the way. The repo uses ffcli for composable routing, which fits a tool that has many subcommands but wants clean, predictable execution. Root help and version checks are fast paths, not afterthoughts.
That matters because a machine-friendly CLI has to be boring in the best way. It should fail clearly, exit cleanly, and avoid ambiguous interaction. asc treats the terminal as an API surface, not a conversational UI.
// simplified from cmd/exit_codes.go
func ExitCodeFromError(err error) int {
var apiErr *asc.APIError
if errors.As(err, &apiErr) {
if apiErr.StatusCode >= 400 && apiErr.StatusCode < 500 {
return 10 + (apiErr.StatusCode - 400)
}
if apiErr.StatusCode >= 500 && apiErr.StatusCode < 600 {
return 60 + (apiErr.StatusCode - 500)
}
}
return 1
}
That tiny mapping is a product feature. A pipeline can tell the difference between a bad request, a missing resource, and a service outage without scraping a stack trace. In automation, that is the difference between retrying intelligently and guessing.
How asc survives Apple’s complexity
The best engineering in asc is not flashy. It is defensive. Asset uploads are streamed in slices with io.NewSectionReader, which avoids loading huge files into memory. Symlinks are refused. Oversized assets are blocked before they become operational problems.
The same pattern shows up in Apple ID handling. The auth layer has to deal with session state, trusted devices, and two-factor flows that do not behave like ordinary web logins. asc turns that mess into explicit state handling instead of burying it under generic failure.
App info resolution is another example. Apple can expose multiple metadata states for what looks like the same app, so the code maps version state to the correct app info target. That is not just convenience. It prevents edits from landing in the wrong place.
The quiet superpower: exit codes that mean something
Many tools collapse everything into a single non-zero exit. asc does not. It translates API failures into ranges that encode meaning, which makes the tool easier to compose in CI and easier to debug in logs.
| Failure type | Generic CLI | asc |
|---|---|---|
| 404 Not Found | exit 1 | distinct 4xx-derived code |
| 429 or 422 style client error | exit 1 | separate client-side signal |
| 500 service error | exit 1 | distinct 5xx-derived code |
| Success | exit 0 | exit 0 |
This is a small implementation detail with a large behavioral payoff. A pipeline can branch on specific failure classes without parsing text, and an agent can decide whether to retry, escalate, or stop. That is machine readability in its most practical form.
Why the Wails Studio matters
The Studio is the surprise. A CLI project does not usually ship with a desktop front end, especially one built in Wails. But here the GUI is not a separate product. It is another shell around the same Go core.
That choice says something important about the codebase. The business logic is not trapped inside the terminal. It is portable enough to support a different interface without being rewritten. For infrastructure software, that is a serious design signal.

Thank you to everyone who starred, contributed, filed issues, and are putting asc cli in their pipelines. This is just the beginning.
How it compares to fastlane and Apple’s own tools
| Tool | Language / runtime | Strength | Trade-off |
|---|---|---|---|
| asc | Go | Lightweight, JSON-first, agent-friendly | Narrower scope than a full release suite |
| fastlane | Ruby | Broad ecosystem and many lanes | Heavier mental model and more moving parts |
| altool | Apple native tooling | Official baseline for some uploads | More limited and less expressive for complex automation |
The comparison is not really about feature counts. It is about interface philosophy. fastlane is the broad automation platform. Apple’s tools are native but constrained. asc is narrower, faster to reason about, and better aligned with the way CI and agents actually consume tools.
That is why the project feels timely. It takes a messy, high-friction platform and expresses it as something software can trust. In the age of agents, that may be the most valuable feature of all.





