asc-cli: App Store Connect Release Workflow from a Terminal
App Store Connect from your terminal & Agents. A Swift CLI for managing your iOS and macOS apps on App Store Connect. Submit versions, manage screenshots, track builds — with full AI-agent support via CAEOAS affordances.
At a glance
- What is it?
- A Swift CLI that wraps the App Store Connect API and adds a cookie-based route to Apple's private iris API for the first in-app purchase submission. The JSON output and CAEOAS affordances are built for agents; the iris session is the part that carries real risk.
- Who is it for?
- Adopt asc-cli if your release process is scripted and you need structured JSON for an agent or CI job, and if you can live with a macOS-only binary that depends on an undocumented Apple API for first-time IAP submissions. Do not adopt it if you need Linux runners, or if your team cannot accept a tool that stores an Apple ID session cookie in ~/.asc/iris/session.json.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 42 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap asc-cli Fills Between Xcode and the ASC Web UI
App Store Connect has a web interface and a public API. The web interface does not script well. The public API covers the common cases but leaves gaps that Apple has not filled, and the README names one of them directly: the public API "can't submit the first IAP for an app", because Apple requires that submission to ride along with a new App Store version, and the only path that accepts the flag is the iris private API. That single sentence explains why this project exists in the shape it does. A team that only needs to upload a build and submit a version could do that with fastlane or with a thin script over the public API. A team that ships an app with in-app purchases hits a wall on the first submission and has to click through the web UI, which is exactly the step that breaks an otherwise automated pipeline.
The audience is narrow and identifiable: iOS and macOS developers who already run their release steps from a terminal or a CI job, and who want the same steps available to an AI agent. The README frames the agent case as the reason for structured JSON output, and the CAEOAS affordances exist so an agent can pick the next action without learning the whole command tree. If you release once a quarter and click through the web UI, the cost of learning this tool exceeds the benefit.
Two Authentication Paths, Only One of Them Public
asc-cli has two credential systems and they are not interchangeable. The first is the standard App Store Connect API key: a key ID, an issuer ID, and a .p8 private key. `asc auth login --key-id ... --issuer-id ... --private-key-path ...` writes them to ~/.asc/credentials.json, with an optional --name alias so one machine can hold several accounts. Resolution order is documented as credentials file first, then environment variables (ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY_PATH, or ASC_PRIVATE_KEY holding PEM content). `asc auth use work` switches the active account, and `asc auth check` reports which one is active along with a source field.
The second path is iris, the private API behind the App Store Connect web UI. `asc iris auth login --apple-id you@example.com --interactive` prompts for the Apple ID password and a two-factor code, then saves a session to ~/.asc/iris/session.json that the README says lasts around 30 days. `asc iris status` verifies it and reports source: "srpLogin". This is cookie-based authentication against an undocumented endpoint. Apple can change it without notice, which means a pipeline that depends on iris is a pipeline that can break on a Tuesday for reasons no changelog will explain. The README does state that iris is additive and that CI scripts using the API key alone keep working unchanged. That is the right design, and it is also the honest boundary of what this tool can promise.
CAEOAS Affordances and the JSON Contract for Agents
The agent story is not a wrapper that shells out and parses human text. Commands emit structured JSON, and the JSON carries affordances the agent is meant to read. The clearest example in the README is IAP listing: `asc iap list --app-id <id>` enriches each in-app purchase with the correct submission affordance, which is `addToNextVersion` when the item should be queued via iris, `removeFromNextVersion` to dequeue it, or `submit` for an established app that can go to standalone review. The stated benefit is that the agent reads one affordance and runs it, with no need to learn the iris-versus-SDK distinction itself.
That is a real architectural choice, and it puts the routing logic inside the CLI rather than inside the agent. It also means the affordance vocabulary is a contract. If you build an agent against these field names and a later release renames or reshapes them, your agent breaks silently in the sense that it will simply stop finding the key it expects. Pin the version you build against. The README documents the IAP affordances in detail and mentions affordances as a general mechanism, but it does not enumerate the full set of JSON schemas for every command, so an integrator will end up reading the source or the live output to learn the rest.
Getting It Running: Homebrew, Login, Init, First Commands
Installation is one command on macOS: `brew install asccli`. Building from source needs Swift 6.2 or later, and the README gives the sequence: clone the repository, `swift build -c release`, then copy `.build/release/asc` into /usr/local/bin/. The runtime requirement is macOS 13 or newer, with a badge advertising macOS 15 and up; the two statements do not match, so treat the higher number as the tested configuration and expect the lower one to be aspirational.
The documented first-run flow is four steps. Log in with `asc auth login --key-id YOUR_KEY_ID --issuer-id YOUR_ISSUER_ID --private-key-path ~/.asc/AuthKey_XXXXXX.p8 --name personal`, where the name is optional and defaults to "default". Run `asc apps list` to find your app ID. Run `asc init --app-id <id>` to pin that app so later commands skip the --app-id flag. From there the command groups are `asc apps`, `asc versions`, `asc iap`, `asc iris`, plus the build, TestFlight, screenshot and reporting surfaces listed in the feature table. `asc init` can also auto-detect the app from a .xcodeproj bundle ID or search by name. Pinning writes to .asc/project.json, which is a per-project file, so a repository checkout carries its own app context. Account names must not contain spaces, and `asc auth update --vendor-number <number>` stores the vendor number that financial and sales reports need. That vendor number step is easy to miss and will only surface when a report command asks for it.
The Iris Dependency Is the Sharpest Limitation
The private API route is the most interesting feature and the weakest guarantee. Apple does not publish the iris API. The README describes it as the API that powers the ASC web UI, reached through a cookie session obtained by simulating a sign-in with an Apple ID password and a two-factor code. Sessions are described as lasting about 30 days, saved at ~/.asc/iris/session.json, and cleared with `asc iris auth logout`. Nothing in that arrangement is contractual. Apple can add a challenge, change the login flow, or invalidate the session format, and the CLI will need a patch.
There is a second, quieter cost. A stored Apple ID session is a different class of secret from an API key. An API key is scoped and revocable from the integrations page. An Apple ID session cookie is tied to the account holder, and the README does not describe any scope restriction on it. If your release machine is a shared CI runner, putting an Apple ID session on it is a decision you should make deliberately rather than by following the quick start. The tool does support the API-key-only path for everything else, and the README is explicit that iris is additive, so the sane default for a shared runner is to skip iris and accept a manual first-IAP step. The README also notes that iris unlocks web UI parity features beyond IAP submission, including creating apps and reading App Review Resolution Center rejection messages, so the temptation to enable it on CI will be real.
How It Compares to fastlane
fastlane is the obvious alternative and the difference is in the shape of the tool, not the feature list. fastlane is a Ruby toolchain with lanes, a plugin ecosystem, and a long history of wrapping App Store Connect. It runs on Linux as well as macOS, which matters if your CI runners are not Macs. It also carries a large dependency surface and a Ruby runtime to keep patched.
asc-cli is a single Swift binary with no runtime dependency beyond macOS itself, and its output is JSON rather than log lines, which is the reason it works as an agent backend at all. That is the actual trade. If your pipeline already has fastlane lanes doing build, sign, and upload, replacing them buys you little unless you are specifically trying to hand the release workflow to an agent. If you are starting fresh and your runners are Macs, the single-binary model is simpler to deploy and simpler to reason about. The iris route is not something fastlane gives you out of the box either, so the first-IAP problem is a genuine differentiator rather than a re-skin. What you give up is portability and the breadth of the fastlane plugin ecosystem, which covers integrations this project does not list.
Maintenance, Versioning and the MIT Licence
The project is MIT licensed, which permits commercial and closed-source use, modification, and redistribution provided the copyright notice and licence text are preserved. That is a permissive arrangement with no copyleft obligation, and it is the same licence fastlane uses. It does not grant any rights to Apple's APIs, and it does not change the fact that the iris endpoint is undocumented and used at your own discretion. Nothing here is legal advice; if you redistribute a modified binary, read the licence text yourself.
Versioning is worth noting because the release cadence is uneven. The supplied release list shows v0.18.0 in May 2026, v0.18.1 at the end of that month, and v0.18.2 in mid July 2026, with the last push to the default branch in early August 2026. Patch releases roughly a month apart suggest active but not frantic maintenance. The 0.x version number is the honest signal: the JSON schemas and the affordance vocabulary are not promised as stable, and a minor bump can change what an agent receives. If you build an integration on top, pin the version in your Homebrew formula or your build script rather than tracking latest, and re-read the release notes before you bump. The CI and codecov badges in the README indicate automated testing exists; they do not tell you what is covered, and coverage percentage is not a claim about correctness of the iris path, which by nature is hard to test against a moving target.
Editorial conclusion
Adopt asc-cli if your release process is scripted and you need structured JSON for an agent or CI job, and if you can live with a macOS-only binary that depends on an undocumented Apple API for first-time IAP submissions. Do not adopt it if you need Linux runners, or if your team cannot accept a tool that stores an Apple ID session cookie in ~/.asc/iris/session.json. Verify first that asc auth check reports the account you expect, and that asc iris status still shows source: "srpLogin" before you rely on the iris route.
Community notes