blitz-mac: a native macOS App Store Connect client that AI agents can drive

The submission chore Blitz was built to remove

App Store Connect is a web console, and the work around it is a sequence of small, failure-prone steps: create a version, fill in localized listings, attach in-app purchases before submission, upload screenshots for every required device size, add TestFlight testers, then submit for review. Each step has its own screen and its own validation rules. The README frames the project's reason for existing in one line: "If you are fighting App Store Connect to get your app submitted, Blitz automates the painful parts."

The intended user is an iOS developer on a Mac who wants an agent to do that sequence. Blitz is a native macOS GUI, and the same actions are exposed through an MCP server so a client such as Claude Code, Codex or Cursor can call them. That combination, a desktop app plus an agent-facing tool surface, is the specific thing being sold here. It is not a general CI system and it is not a cross-platform tool.

How the MCP server, the GUI and the bundled asc-cli fit together

Three pieces are visible in the repository. The Swift sources under Sources/ build the macOS application. A submodule at deps/App-Store-Connect-CLI-helper provides the App Store Connect helper binary that gets bundled into the app; the README describes it as "a pinned App Store Connect helper fork" and notes two environment variables for overriding it during development or CI, BLITZ_ASCD_SOURCE_DIR and BLITZ_ASCD_PATH. The third piece is the MCP surface, advertised as roughly 35 tools, which is what an MCP client connects to.

The README also lists a bundled CLI, asc-cli, described as a "Scriptable CLI for edge-case ASC operations" that is auto-installed, shares authentication with the app, and is available "in every Blitz agent session". That is a deliberate division of labour: the GUI and MCP tools cover the common path, and the CLI is the escape hatch for operations the tool surface does not model. The Dockerfile packages a separate npm package, @blitzdev/blitz-mcp, with blitz-mcp as the entrypoint, which suggests the MCP server can run outside the Mac app as well.

One design decision worth flagging: bundling a helper fork rather than calling Apple's API directly from Swift means your App Store Connect behaviour is partly determined by that pinned submodule. The README is explicit that you can point BLITZ_ASCD_PATH at a prebuilt compatible helper binary, but it does not describe what happens when the helper and the app drift apart in version.

Building Blitz from source on macOS 14 or later

The README gives source build instructions with four requirements: macOS 14+, Xcode 16+, Node.js 18+ and Go 1.26+. Clone the repository, initialize the submodule that holds the helper fork, then build. The commands below are copied from the README's build section.

git clone https://github.com/blitzdotdev/blitz-mac.git
cd blitz-mac
git submodule update --init --recursive
swift build

That produces a debug build. For a release build the README uses swift build -c release, and to get a double-clickable application you run the bundling script, which the README says produces an ad-hoc signed app at .build/Blitz.app.

swift build -c release
bash scripts/bundle.sh release
open .build/Blitz.app

For a signed build, copy .env.example to .env and fill in the Apple credentials before running the bundling script. The example file expects APPLE_SIGNING_IDENTITY and APPLE_INSTALLER_IDENTITY for signing, and APPLE_API_KEY, APPLE_API_KEY_PATH and APPLE_API_ISSUER for notarization. Note that .env.example also carries Cloudflare R2 keys, which belong to a deploy path rather than the build itself.

If you would rather not build, the README points to blitz-mac.com for the download, and each GitHub release ships SHA256SUMS.txt. The documented verification is a single command run against both the archive and the checksum file.

shasum -a 256 -c SHA256SUMS.txt

The README offers two further verification routes: scripts/verify-build.sh with a release tag, which builds locally and compares the main executable checksum, and auditing the public GitHub Actions workflow at .github/workflows/build.yml. It notes that CI builds use ad-hoc signing, so checksums match when you build with the same toolchain.

Where Blitz stops being the right answer

The most concrete limitation is platform. This is a native macOS application, and the source build requires macOS 14+ with Xcode 16+. There is no Linux or Windows path documented, and the Dockerfile only wraps the MCP server package, not the GUI or the submission workflow it drives. If your release process is a headless CI job on a Linux runner, this is not the tool for that job.

The second limitation concerns telemetry. The README states that GitHub release builds "may embed a build-time analytics endpoint and token and send anonymous product telemetry", while source builds, forks and debug builds stay off by default unless you explicitly embed analytics config while bundling. The recorded events are app launches, project inventory events and MCP or App Store Connect tool usage, each carrying an anonymous device ID stored at ~/.blitz/analytics/device-id. The README is equally specific about what is never recorded: no project names, paths, bundle IDs, CLI arguments, App Store Connect form values, file names, prompts or terminal contents. If your organisation forbids any outbound telemetry from developer machines, the practical answer is to build from source rather than install the release, and the README supports that reading.

Third, the README does not document rollback. If a submission or a version change goes wrong, there is no described undo path, and App Store Connect itself is not a system that lets you retract a submitted build freely. Treat any submission-triggering tool with that in mind.

Blitz against fastlane and against the raw App Store Connect API

The obvious alternative for automating App Store submission is fastlane, and the difference in approach is structural rather than cosmetic. fastlane is a set of Ruby-based command line tools configured through a Fastfile, designed to run unattended in CI on whatever machine you point it at. Blitz is a GUI application on a Mac with an MCP server bolted on, and its automation story is an agent session rather than a pipeline script. If your requirement is "run the same submission steps on every merge, on a build agent, with no human present", fastlane matches that shape and Blitz does not.

The second alternative is calling the App Store Connect API yourself. That gives you complete control and no third-party helper in the loop, at the cost of writing and maintaining the version, listing, screenshot and in-app-purchase plumbing that Blitz already implements. The bundled asc-cli is Blitz's own answer to this: it exists precisely for the operations the GUI and MCP tools do not cover, and it shares authentication with the app. If you find yourself reaching for asc-cli constantly, that is a signal the MCP surface is not covering your workflow and you should weigh the direct API route.

Licence, maintenance and the cost of upgrading

Blitz is licensed under Apache-2.0, and the repository carries a NOTICE file alongside LICENSE, which is the standard pairing when a project bundles third-party components. The bundled helper fork under deps/ is a separate project with its own licence, and the README links asc-cli to its upstream repository. If you redistribute a build of Blitz, the Apache-2.0 terms plus whatever the helper fork carries are what you need to read. This is not legal advice; read LICENSE and NOTICE yourself.

On maintenance, the last push to the default branch was on 2026-07-14, and the most recent release listed is v1.0.35 from 2026-04-15. The repository is not archived. There is a CHANGELOG.md, and package.json carries a release script that bumps the patch version, commits, tags and pushes, so versioning is mechanical. The upgrade cost that matters is the pinned helper submodule: moving to a new Blitz release may move the helper with it, and the README's override variables exist because that coupling can be inconvenient. Budget for re-running scripts/verify-build.sh after an upgrade if you care about binary provenance.

Editorial conclusion

Adopt Blitz if you ship iOS apps from a Mac and already work inside an MCP client such as Claude Code or Cursor, because the agent integration is the whole point and the bundled asc-cli covers the operations the GUI does not model. Skip it if you are on Linux or Windows, or if your release pipeline must run unattended in CI, since the product is a macOS GUI and the Dockerfile only packages the MCP server entrypoint. Before committing, verify the SHA256SUMS.txt checksum of the release you download with shasum -a 256 -c, confirm whether the official build's telemetry is acceptable for your team, and check that the pinned helper at deps/App-Store-Connect-CLI-helper builds on your toolchain.

Frequently asked questions

Official sources

1. blitzdotdev/blitz-mac on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases