[opensourcedex]

App-Store-Connect-CLI is a free, open source cloud infrastructure management project written in Go and released under MIT. It has 8,211 GitHub stars, 716 forks and 89 open issues, and was last pushed 17 hours ago. On this registry it ranks #31 of 76 tracked projects in Cloud Infrastructure Management, with 5 head-to-head comparisons available. It gained 660 stars over the last 30 tracked days.

What is App-Store-Connect-CLI?

App-Store-Connect-CLI is a Go-based, MIT-licensed command-line tool that exposes the App Store Connect API so iOS, macOS, tvOS, and visionOS teams can automate TestFlight, builds, submissions, signing, analytics, screenshots, and subscriptions from a terminal, an IDE, or a CI/CD pipeline.

What it is

App-Store-Connect-CLI is an open-source, Go-written CLI for the App Store Connect API, published under the MIT licence and developed in the open with 7,270 stars, 613 forks, and 89 open issues at the time of this entry. It sits in the Infrastructure & Operations / Cloud Infrastructure Management category and targets the Apple developer ecosystem, with topics that name app-store-connect, apple, automation, cicd, cli, command-line-tool, developer-tools, devops, go, golang, ios, and macos. Its homepage is asccli.sh, and its last documented push was 2026-09-17. The project describes itself as fast, lightweight, and scriptable, and it is designed to drive iOS, macOS, tvOS, and visionOS release workflows from wherever the developer already works.

The concrete problem it solves is the gap between the App Store Connect API and everyday release work. Apple's release surface spans builds, TestFlight distribution, metadata, submissions, signing, analytics, screenshots, and subscriptions, and reaching it usually means either clicking through a web interface or hand-rolling HTTP calls inside bespoke scripts. This tool replaces that ad hoc scripting and manual effort with one binary and a consistent set of subcommands, and it is built to behave sensibly in both interactive and non-interactive contexts: it selects a default output of table when stdout is a TTY and json when stdout is piped, redirected to a file, or running in CI, while explicit flags always win. Authentication can be keychain-backed on a developer machine or config-backed where no keychain exists, which is the shape CI runners need.

Key capabilities

  • Authenticate with asc auth login using --name, --key-id, --issuer-id, and --private-key; individual API keys omit the issuer ID and pass --key-type individual.
  • Configure headless environments with --bypass-keychain for CI runners and shells where keychain access is unavailable.
  • Validate credentials with asc auth status --validate and asc auth doctor.
  • List apps with asc apps list, choosing --output table or --output json --pretty, and set a persistent default through ASC_DEFAULT_OUTPUT=markdown.
  • Install 25 Agent Skills through asc install-skills, pinned to reviewed commit f52c4f04323bb2dfb21ca8be82e6494e9cd0b4d8, requiring only git, verifying every installed file, preserving unrelated skills and lock entries, and rolling back the pack if a replacement fails.
  • Automate TestFlight, builds, submissions, signing, analytics, screenshots, and subscriptions through the same CLI.
  • Surface deprecation warnings that name the migration path and the command's long-term replacement.

Who uses it and how

  • Release engineers running headless CI jobs, where --bypass-keychain combined with config-backed authentication keeps pipelines working without a keychain.
  • Mobile teams shipping across iOS, macOS, tvOS, and visionOS who want build, TestFlight, and submission steps driven from the terminal rather than a browser session.
  • Automation and DevOps engineers scripting analytics pulls, screenshot handling, and subscription management inside existing shell or CI workflows.
  • Agent-driven workflows, where the global skill pack installed by asc install-skills covers builds, TestFlight, metadata sync, submissions, and signing across multiple projects.
  • Windows users who install through signed release binaries downloaded from the GitHub releases page while the WinGet package awaits acceptance, tracked in GitHub Discussion #1552.

Getting started

Install with brew install asc on Homebrew, or run curl -fsSL https://asccli.sh/install | bash on macOS and Linux; Windows uses winget install --id Rorkai.ASC --exact once accepted, with signed release binaries as the fallback. From there, asc auth login configures credentials and asc auth status --validate confirms they work.

How it compares

The facts for this entry name no similar tools and provide no list of paid products that App-Store-Connect-CLI replaces, so no licence, self-hosting, or cost-model contrast can be drawn here. Within this registry it stands alone as the scriptable CLI for the App Store Connect API.

When to use it — and when not to

Anyone running it must already hold App Store Connect API credentials, meaning a key ID, a private key file such as AuthKey.p8, and an issuer ID for team keys, and must choose between keychain-backed and config-backed storage. Teams that never touch Apple release infrastructure, or that prefer GUI-only workflows and hold no API keys, should not pick it up. The WinGet package is not yet accepted, the install section of the README is command-heavy, and 89 issues remain open, so prospective users should expect to track releases and read the documentation closely.

project readme (upstream, from github) — read inline

App Store Connect CLI

Latest Release GitHub Stars Go version from go.mod License Homebrew

A fast, lightweight, and scriptable CLI for the App Store Connect API. Automate iOS, macOS, tvOS, and visionOS release workflows from your terminal, IDE, or CI/CD pipeline.

Table of Contents

asc skills

Agent Skills for automating asc workflows including builds, TestFlight, metadata sync, submissions, and signing: https://github.com/rorkai/app-store-connect-cli-skills

Install them globally so they are available across projects:

asc install-skills

asc install-skills checks out reviewed commit f52c4f04323bb2dfb21ca8be82e6494e9cd0b4d8 and copies its 25 skills directly into the standard global agent-skills directory. It verifies the complete pack and every installed file before succeeding, preserves unrelated skills and unrelated lock entries, and pins the 25 ASC lock entries to the same reviewed commit so external checks cannot update them from a mutable branch. It rolls back the pack if any replacement fails. Only git is required; the command does not execute Node.js, npx, an npm package, or repository scripts.

git --version
asc install-skills

Quick Start

If you want to confirm the binary works before configuring authentication:

asc version
asc --help

1. Install

# Homebrew (recommended)
brew install asc

# Install script (macOS/Linux)
curl -fsSL https://asccli.sh/install | bash

# Windows (WinGet, once the package is accepted)
winget install asc

# Exact fallback when scripting
winget install --id Rorkai.ASC --exact

The WinGet package is tracked in GitHub Discussion #1552. Until it appears in winget search asc, Windows users can download the signed release binaries directly from the GitHub releases page.

For source builds and contributor setup, see CONTRIBUTING.md. Released binaries are self-contained and do not require a Go installation; source builds use the toolchain version declared by go.mod.

2. Authenticate

asc auth login \
  --name "MyApp" \
  --key-id "ABC123" \
  --issuer-id "DEF456" \
  --private-key /path/to/AuthKey.p8 \
  --network

Individual API keys have no issuer ID. Omit --issuer-id and pass --key-type individual:

asc auth login \
  --name "MyIndividualKey" \
  --key-id "ABC123" \
  --key-type individual \
  --private-key /path/to/AuthKey.p8

Generate API keys at: https://appstoreconnect.apple.com/access/integrations/api

If you are running in CI, a headless shell, or a machine where keychain access is not available, use config-backed auth instead:

asc auth login \
  --bypass-keychain \
  --name "MyCIKey" \
  --key-id "ABC123" \
  --issuer-id "DEF456" \
  --private-key /path/to/AuthKey.p8

3. Validate auth

asc auth status --validate
asc auth doctor

4. First command

asc apps list --output table
asc apps list --output json --pretty

Output defaults (TTY-aware)

asc chooses a default --output based on where stdout is connected:

  • Interactive terminal (TTY): table
  • Non-interactive output (pipes/files/CI): json

You can still set a global preference:

export ASC_DEFAULT_OUTPUT=markdown

And explicit flags always win:

asc apps list --output json

Compatibility

Commands are supported as documented. Deprecation warnings identify the available migration path and the command's long-term replacement.

Troubleshooting

Homebrew

  • Refresh Homebrew first: brew update && brew upgrade asc
  • Check which binary you are running: which asc
  • Confirm the installed version: asc version
  • If Homebrew is behind the latest GitHub release, use the install script from https://asccli.sh/install

WinGet

  • Refresh WinGet sources first: winget source update
  • Prefer the short install once available: winget install asc
  • If the short name ever becomes ambiguous, use the package identifier: winget install --id Rorkai.ASC --exact
  • Confirm the installed command resolves: Get-Command asc and asc version

Authentication

  • Validate the active profile: asc auth status --validate
  • Run the auth health check: asc auth doctor
  • If keychain access is blocked, retry with ASC_BYPASS_KEYCHAIN=1 or re-run asc auth login --bypass-keychain
  • Use asc auth login --local --bypass-keychain ... when you want repo-local credentials in ./.asc/config.json

Apple service health

  • Check Apple's developer services without credentials: asc system-status
  • Narrow unexpected API or upload failures: asc system-status --service "App Store Connect"
  • Poll only when requested: asc system-status --watch --poll-interval 30s
  • Use --issues-only for a concise incident view; summary counts still cover all matched services

Output

  • asc defaults to table in an interactive terminal and json in pipes, files, and CI
  • Use an explicit format when scripting or sharing repro steps: --output json, --output table, or --output markdown
  • Use --pretty with JSON when you want readable output in terminals or bug reports
  • Set a personal default with ASC_DEFAULT_OUTPUT, but remember --output always wins

Privacy and telemetry

asc sends pseudonymous command-level usage telemetry by default to help maintainers understand which commands are used and where reliability work is needed. Local events include a random installation ID, which lets events from one installation be grouped over time; it is not derived from an Apple account or machine identifier.

Telemetry includes the CLI version, operating system and architecture, registered command path, duration, runtime context, invocation source, a bounded outcome class, and the HTTP status when an API request fails. It may include a sanitized public flag name. It does not include raw arguments, stderr, error messages, flag values, response bodies, credentials, private keys, Apple account, team, or issuer IDs, app or bundle IDs, usernames, hostnames, repository names, or file paths.

Review or change telemetry at any time:

asc telemetry status
asc telemetry disable
asc telemetry reset-id

ASC_TELEMETRY_DISABLED=1 and DO_NOT_TRACK=1 also disable telemetry. See the telemetry reference for the exact event payload, runtime handling, collector endpoint, and all controls.

Support

  • Use GitHub Discussions for install help, authentication setup, workflow advice, and "how do I...?" questions
  • Use GitHub Issues for reproducible bugs and concrete feature requests
  • See SUPPORT.md for the support policy and bug-report checklist
  • Before filing an auth or API bug, retry with ASC_BYPASS_KEYCHAIN=1; if it is safe to do so, include redacted output from ASC_DEBUG=api asc ... or asc --api-debug ...

Wall of Apps

See the Wall of Apps →

Want to add yours? asc apps wall submit --app "1234567890" --confirm

The command uses your authenticated gh session to fork the repo and open a pull request that updates docs/wall-of-apps.json. It resolves the public App Store name, URL, and icon from the app ID automatically. For manual entries that are not on the public App Store yet, use --link with --name. Use asc apps wall submit --dry-run to preview the fork, branch, and PR plan before creating anything.

Common Workflows

TestFlight feedback and crashes

asc testflight feedback list --app "123456789" --paginate
asc testflight crashes list --app "123456789" --sort -createdDate --limit 10
asc testflight crashes log --submission-id "SUBMISSION_ID"

Builds and distribution

asc builds upload --app "123456789" --ipa "/path/to/MyApp.ipa"
asc builds list --app "123456789" --output table
asc testflight groups list --app "123456789" --output table

For macOS TestFlight distribution, upload the exported .pkg first, then add the processed build to a beta group:

asc builds upload --app "123456789" --pkg "./build/MyMacApp.pkg" --version "1.2.3" --build-number "42" --wait --output json
asc builds add-groups --app "123456789" --build-number "42" --version "1.2.3" --platform MAC_OS --group "Internal Testers"

--app is the App Store Connect app ID. If you use local Xcode build flags such as --archive-path, also pass exactly one of --workspace or --project plus --scheme; otherwise use a pre-exported .ipa or .pkg upload. Add --submit --confirm to asc builds add-groups when distributing to an external TestFlight group that needs beta app review submission.

Release (high-level App Store publish flow)

# Optional: preview the staging plan before submission
asc release stage --app "123456789" --version "1.2.3" --build-id "BUILD_ID" --copy-metadata-from "1.2.2" --dry-run

# Canonical upload + attach + submit command
asc publish appstore --app "123456789" --ipa "/path/to/MyApp.ipa" --version "1.2.3" --submit --confirm

# Monitor status after submission
asc status --app "123456789" --watch

Lower-level submission lifecycle commands (for debugging or partial workflows):

# Canonical readiness check
asc validate --app "123456789" --version "1.2.3"
asc submit status --version-id "VERSION_ID"
asc submit cancel --version-id "VERSION_ID" --confirm

Readiness validation also warns when localized app names, subtitles, descriptions, keywords, promotional text, or What's New copy still contains an unmistakable template marker such as Lorem ipsum, TODO, TBD, or FIXME. Lorem ipsum matches in any letter case. TODO, TBD, and FIXME match only in uppercase because their lowercase spellings can be ordinary product wording. The warning includes the locale, field, matched text, resource ID, and a remediation step. It is advisory by default and becomes blocking only with --strict:

asc validate --app "123456789" --version "1.2.3" --output json
asc validate --app "123456789" --version "1.2.3" --strict

Add the --deep mode when a release needs checks that Apple exposes only through its signed-in web app:

asc web auth login --apple-id "user@example.com"
asc validate --app "123456789" --version "1.2.3" --deep

Deep validation reuses the file-backed cache without opening a login, Keychain, password, or 2FA prompt. It checks App Privacy publication, relevant agreements, and the first auto-renewable subscription attachment; availability and required App Review fields still come from the public API. Paid-agreement relevance also uses the app's current public price so an upfront-paid app isn't mistaken for a free one. The private Apple endpoints can change without notice, so an unavailable or changed response is unverified, not a false blocker. Add --strict if CI must fail when a requested deep check can't be verified.

This lint intentionally does not judge platform names, roadmap language, or beta/demo wording because those phrases can be legitimate product copy and cannot be classified reliably offline. It also leaves shorter Lorem Ipsum product wording and ordinary localized TODO copy without marker punctuation unflagged; only template-like residue is reported.

Review status and blockers

asc review status --app "123456789"
asc review doctor --app "123456789"

Metadata and localization

asc localizations list --app "123456789" --type app-info
asc metadata init --dir "./metadata" --version "1.2.3" --locale "en-US"
asc metadata apply --app "123456789" --version "1.2.3" --dir "./metadata" --dry-run
asc metadata keywords audit --app "123456789" --version "1.2.3" --blocked-terms-file "./blocked-terms.txt"
asc apps info view --app "123456789" --output json --pretty

Use asc metadata keywords audit before sync or apply when you want an ASO-focused review of live keyword metadata across locales. It reports duplicate phrases, repeated terms across locales, overlap with localized app name or subtitle, byte-budget usage, and optional blocked terms from repeated --blocked-term flags or a text file.

Screenshots and media

asc screenshots plan --app "123456789" --version "1.2.3" --review-output-dir "./screenshots/review"
asc screenshots apply --app "123456789" --version "1.2.3" --review-output-dir "./screenshots/review" --confirm
asc screenshots list --version-localization "VERSION_LOCALIZATION_ID"
asc video-previews list --app "123456789"

Uploading screenshots for a single locale:

asc apps list
asc versions list --app "APP_ID"
asc localizations list --version "VERSION_ID" --output json --locale "en-US" | jsonpp
asc screenshots upload --version-localization "VERSION_LOCALIZATION_ID" --path "./screenshots/en-US" --device-type "IPHONE_65" --replace --max-screenshots 10

VERSION_LOCALIZATION_ID is the App Store version localization resource ID from data[].id, not the locale code from attributes.locale.

For local capture coverage across multiple devices, locales, appearances, and content fixtures, use a matrix plan. Targets must already be booted simulators; the command writes raw artifacts and an offline review report, without uploading to App Store Connect:

asc screenshots matrix --plan .asc/screenshots-matrix.json --max-concurrency 2 --output json --pretty

See docs/design/screenshots-matrix.md for the JSONC schema, isolated output layout, retry behavior, and review contract.

Signing and bundle IDs

asc bundle-ids capabilities list --bundle "BUNDLE_ID"
asc signing fetch --bundle-id com.example.app --profile-type IOS_APP_STORE --output .asc/signing
asc signing sync pull --repo git@github.com:team/signing.git --password-file ~/.config/asc/signing-sync-password --output-dir .asc/signing/pulled

signing fetch downloads public certificates and provisioning profiles. A usable signing identity also needs the matching private key; signing sync can verify that local identity and share it through an encrypted Git repository. For multi-target release testing, signing reconcile plans exact device/profile changes. signing run provides a temporary macOS keychain only for single-target archives. Multi-target exports must import the identity into a job-scoped keychain and install every reconciled profile for the job-exclusive macOS user. See the signing guide for setup, CI, rotation, security boundaries, and troubleshooting.

Workflow automation

asc workflow validate --output json
asc workflow run --dry-run testflight_beta VERSION:1.2.3

Verified local Xcode -> TestFlight workflow

See docs/WORKFLOWS.md for local compile validation with asc xcode build and a copyable .asc/deployment.json, .asc/workflow.json, and ExportOptions.plist that use asc builds next-build-number, asc xcode inject, asc xcode archive, asc xcode export --timeout 10m, and asc publish testflight --group ... --wait. Add --submit --confirm when distributing to an external TestFlight group that needs beta app review submission.

The asc xcode test command provides local unit/UI test execution with structured results and preserved .xcresult bundles; see the same workflow guide for an invocation.

asc workflow validate --output json
asc xcode inject --manifest .asc/deployment.json --set version=1.2.3 --set build_number=42 --dry-run --output json
asc xcode build --project App.xcodeproj --scheme App --destination 'platform=iOS Simulator,name=iPhone 17 Pro Max,OS=27.0' --no-code-signing --output json
asc workflow run --dry-run testflight_beta VERSION:1.2.3
asc workflow run testflight_beta VERSION:1.2.3

Replace the example Xcode destination with a simulator installed on the host.

Xcode Cloud workflows and build runs

# Trigger from a pull request
asc xcode-cloud run --workflow-id "WORKFLOW_ID" --pull-request-id "PR_ID"

# Rerun from an existing build run with a clean build
asc xcode-cloud run --source-run-id "BUILD_RUN_ID" --clean

# Fetch a single build run by ID
asc xcode-cloud build-runs get --id "BUILD_RUN_ID"

Apple Ads campaign management

Apple Ads uses separate OAuth credentials from App Store Connect:

asc ads auth login --name "Marketing" --client-id "SEARCHADS_CLIENT_ID" --team-id "SEARCHADS_TEAM_ID" --key-id "KEY_ID" --private-key ./ads-key.pem --ad-account "987654"
asc ads auth discover --output json
asc ads campaigns find --ad-account "987654" --file query.json --output json
asc ads reports apps campaigns --ad-account "987654" --file report.json --output json

See guides/apple-ads-playbooks.mdx for operator playbooks covering credential safety, org inspection, read-only smoke tests, reporting, raw API usage, and guarded mutations.

StoreKit Retention Messaging

Retention Messaging uses a dedicated In-App Purchase API key, separate from App Store Connect API credentials:

asc storekit auth login --name Production --key-id "KEY_ID" --issuer-id "ISSUER_ID" --private-key ./SubscriptionKey.p8 --bundle-id com.example.app
asc storekit auth doctor --environment sandbox --network
asc storekit retention-messaging messages list --environment sandbox --output json
asc storekit retention-messaging endpoint view --environment production

See docs/architecture/storekit-retention-messaging.md for the endpoint map, message and image requirements, environment variables, and the full sandbox verification sequence.

Commands and Reference

Use built-in help as the source of truth:

asc --help
asc <command> --help
asc <command> <subcommand> --help

Reference hierarchy:

  • asc --help: authoritative command and flag surface
  • docs/COMMANDS.md: generated top-level taxonomy map
  • asc docs show workflows: curated workflow recipes
  • asc docs show reference: repo-local quick reference template used by asc init

For full command families, flags, and discovery patterns, see:

Documentation

Acknowledgements

Local screenshot framing uses Koubou (pinned to 0.18.1) for deterministic device-frame rendering. GitHub: https://github.com/bitomule/koubou

Simulator UI automation for screenshot capture and interactions uses AXe CLI. GitHub: https://github.com/cameroncooke/AXe

The keyword difficulty methodology used by asc optimize keywords score is adapted from semihcihan's App Store Optimization CLI (MIT licensed). GitHub: https://github.com/semihcihan/App-Store-Optimization-CLI

Contributing

Contributions are welcome. See CONTRIBUTING.md for details.

License

MIT License - see LICENSE for details.

This project is an independent, unofficial tool and is not affiliated with, endorsed by, or sponsored by Apple Inc. App Store Connect, TestFlight, Xcode Cloud, and Apple are trademarks of Apple Inc., registered in the U.S. and other countries.

Frequently asked questions

Is App-Store-Connect-CLI free to use?

App-Store-Connect-CLI is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does App-Store-Connect-CLI do?

Fast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more

What is App-Store-Connect-CLI written in?

App-Store-Connect-CLI is primarily written in Go. Its source is publicly available at https://github.com/rorkai/App-Store-Connect-CLI, and it has 8,211 GitHub stars.