Three layers, in order of abstraction

"Automate App Store Connect" usually means one of three different things, depending on how much you want to build yourself:

Most teams don't pick exactly one — they use fastlane or a CLI for day-to-day releases and drop to the raw API only for something neither tool covers yet.

Layer 1: the App Store Connect API

Apple's App Store Connect API is a REST API authenticated with a JWT signed by a private key you generate in App Store Connect (Users and Access → Integrations → App Store Connect API). It covers builds, TestFlight, app metadata, screenshots, users, and more.

Going direct makes sense if you're building custom internal tooling with requirements neither fastlane nor a CLI wrapper meets — a dashboard, a Slack bot that reports review status, a bespoke release pipeline. For everything else, the setup cost (JWT signing, endpoint pagination, keeping up with API changes) is real overhead you don't need to carry yourself.

Layer 2: fastlane

fastlane is the long-standing standard for iOS/Android release automation. Its App Store Connect actions (`deliver`, `pilot`, `upload_to_app_store`, `upload_to_testflight`) sit on top of the same underlying API but expose them as a `Fastfile` you write once and run repeatedly — locally or in CI.

A typical release lane looks like:

lane :release do
  build_app(scheme: "MyApp")
  upload_to_app_store(
    submit_for_review: true,
    automatic_release: false,
    force: true
  )
end

fastlane's strength is breadth — it also handles code signing (`match`), screenshots (`snapshot`, `frameit`), and Android via `supply`. If your release process spans build + sign + upload + submit, fastlane is the tool most teams reach for first, and it has the largest community and plugin ecosystem to lean on when something's undocumented. We cover its screenshot-specific actions separately in the fastlane screenshots guide, including where a browser tool is faster for the design side.

The tradeoff is weight: fastlane is a Ruby project with a gem dependency tree, and `match`/`deliver` configuration has a learning curve. For teams already comfortable with Ruby tooling in CI, that's a non-issue. For a small, script-first workflow, it can feel like more than you need.

Layer 3: CLI wrappers

A newer category is single-binary CLIs that wrap the App Store Connect API without the Ruby/gem overhead — install one binary, authenticate with your API key, and run commands. asc (App Store Connect CLI) is one example: a Go binary (`brew install asc`) covering builds, TestFlight, submissions, metadata, screenshots, and signing with JSON-first, script-friendly output.

The appeal is speed to a working command. Where fastlane needs a `Fastfile` and Ruby setup, a CLI wrapper is closer to `curl` with sensible defaults — authenticate once, then run direct commands:

# upload a build and add it to a TestFlight group
asc builds upload --app "123456789" --ipa "./MyApp.ipa"
asc builds add-groups --app "123456789" --build-number "42" --group "Internal Testers"

# check review status without opening the dashboard
asc review status --app "123456789"

# full upload + submit in one command
asc publish appstore --app "123456789" --ipa "./MyApp.ipa" --version "1.2.3" --submit --confirm

This kind of tool is well-suited to scripts and CI steps that just need one or two App Store Connect actions — checking status, uploading a build, syncing metadata — without adopting fastlane's full toolchain. If your pipeline already leans on fastlane for signing and building, there's less reason to add a second tool on top; if you're starting from a bare CI script or a solo dev's terminal, a lightweight CLI can get you to "automated" faster.

What's actually worth automating first

Not every App Store Connect task is worth scripting on day one. In rough order of payoff:

  1. Build upload + TestFlight distribution. The most repetitive manual task, and the one CI can fully own. Automate this first.
  2. Checking review status. A one-line `review status` or API poll saves the "let me go check the dashboard" reflex, and can post to Slack when a status changes.
  3. Metadata sync across locales. If you localize your listing, scripting metadata updates avoids re-typing the same fields per locale by hand.
  4. Full submit-for-review. Worth automating once your build and metadata pipeline is reliable — but keep manual release (rather than automatic) as a safety valve until you trust it.

Where screenshots fit into automation

Screenshots are the one App Store Connect asset that's genuinely hard to automate end-to-end, because the interesting part — deciding what to show, what caption to write, how to frame it — is a design decision, not a data-transfer one. What CLIs and fastlane are good at is uploading the finished PNGs to the right device slot and locale; they're not good at producing a compelling screenshot from a raw app capture.

The practical split that works well: design in a purpose-built tool, upload with your automation layer. ezscreenshots handles the design side — drop your raw captures, pick presets for every required device size, add captions and backgrounds, and export the full set in minutes, no account or export limit, entirely in the browser. Then your `asc screenshots upload` or fastlane `deliver` step takes those exported files and pushes them to App Store Connect as part of the same pipeline. If you haven't automated the submission step at all yet, our submission checklist covers the manual version end to end first.

Automate the upload. Skip automating the design.

Screenshot design is a judgment call your CLI or CI script shouldn't be making. ezscreenshots produces the finished, correctly-sized set in minutes — then your automation layer just uploads it. Free, browser-based, no account.

Try ezscreenshots →

Summary