Blitz: a macOS GUI plus MCP server for App Store Connect submission
Native macOS App Store Connect tool with MCP. Submit iOS apps to App Store with AI agents
At a glance
- What is it?
- Blitz wraps App Store Connect submission, in-app purchase setup, screenshots and simulator control in a native macOS app, and exposes roughly 35 tools over MCP so an AI agent can drive the workflow. The interesting part is not the GUI, it is that the same operations become callable from Claude Code, Codex or Cursor.
- Who is it for?
- Adopt Blitz if your team already submits iOS apps from a Mac and you want an MCP client to drive submission, IAP setup and screenshot upload instead of clicking through App Store Connect. Do not adopt it if you need a headless Linux CI path, or if an unsigned ad-hoc build cannot pass your release process.
- Can I use it commercially?
- Yes. Apache-2.0 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 64 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 submission chores Blitz is built to absorb
App Store Connect is a web console. Submitting an app means creating a version, attaching in-app purchases and subscriptions to that version, uploading screenshots for every required device size across every locale, and only then triggering review. Blitz targets exactly that sequence. The README frames the pitch as automating "the painful parts" of getting an app submitted, and the feature table lists submit for review, version and pricing and listing management, IAP and subscription creation, screenshot upload across device sizes and locales, TestFlight tester and build management, and iOS Simulator control.
The audience is narrow and identifiable: iOS developers on macOS who already own the submission workflow and are tired of the console. The second audience is newer. Because Blitz ships an MCP server, the same operations are exposed to Claude Code, Codex, Cursor, or any MCP client. That is the claim worth examining, since it changes who the tool is for. It is not a replacement for App Store Connect. It is a local macOS surface over it, with two front ends: a GUI for a human, and a tool list for an agent.
Two front ends over one local workflow, plus a bundled CLI
The architecture visible in the repository is a Swift app built with Swift Package Manager, bundled into a .app by scripts/bundle.sh. Inside that bundle sits an App Store Connect helper binary built from a pinned git submodule at deps/App-Store-Connect-CLI-helper. The README ties that helper to asc-cli, described as a scriptable CLI for edge-case ASC operations, auto-installed, sharing authentication with the app, and available in every Blitz agent session.
So the data flow is layered. An MCP client calls one of the roughly 35 tools. The app translates that into either a direct App Store Connect API operation or a call into the bundled helper. The GUI is a third path to the same operations. Authentication is shared across all three, which is the practical detail that makes the agent story work: you do not configure credentials once for the GUI and again for the CLI.
Simulator control (boot and shutdown, touch and swipe, live screen capture) sits alongside the submission tools rather than in a separate product. That is a deliberate placement. An agent that can boot a simulator, capture the screen, and then upload the resulting image as a screenshot has a closed loop without a human moving files around.
Building and running it from source
The documented requirements are macOS 14 or later, Xcode 16 or later, Node.js 18 or later, and Go 1.26 or later. Node and Go are there because of the bundled helper, not the Swift app itself.
The README gives this build sequence:
git clone https://github.com/blitzdotdev/blitz-mac.git cd blitz-mac git submodule update --init --recursive swift build swift build -c release bash scripts/bundle.sh release open .build/Blitz.app
The submodule step is not optional. Skip it and the helper binary has no source. Two environment variables are documented for overriding that source: BLITZ_ASCD_SOURCE_DIR points at a different source directory, and BLITZ_ASCD_PATH points at a prebuilt compatible helper binary. For signed builds, the README says to copy .env.example to .env, fill in Apple Developer credentials, and rerun bash scripts/bundle.sh release.
Release verification is documented in three ways. Download Blitz.app.zip and SHA256SUMS.txt from a GitHub release and run shasum -a 256 -c SHA256SUMS.txt. Or build locally and compare with bash scripts/verify-build.sh v1.0.20, which the README notes works because CI builds use ad-hoc signing, so checksums match when you build with the same toolchain. Or audit the public GitHub Actions workflow at .github/workflows/build.yml. That third option is the honest one: it does not ask you to trust a checksum, it asks you to read the build.
Telemetry is on in release builds and off in source builds
This is the section most reviews would skip, and it is the one that decides whether some teams can use the tool at all. According to the README, official GitHub release builds may embed a build-time analytics endpoint and token and send anonymous product telemetry. Source builds, forks, and debug builds stay off by default unless you explicitly embed analytics config while bundling.
What is recorded: app launches, Blitz project type inventory, create and import events, and MCP or App Store Connect tool usage events. Each event carries an anonymous device ID stored at ~/.blitz/analytics/device-id, app version, OS version, event name, timestamp, and where applicable a source field (blitz_managed or agent_direct), a normalized command type, success, and duration. The README states that project names, paths, bundle IDs, CLI arguments, App Store Connect form values, file names, prompts, terminal contents, and user content are never recorded.
That is a defensible split, and the source-build default is the right one. But it means the binary you download from GitHub and the binary you compile yourself are not the same artifact in behaviour, only in code. If your policy forbids outbound analytics from a developer machine, build from source and do not embed the config. App Wall sync is separately described as opt-in.
Where the design constrains you
Blitz is a macOS 14+ application. There is no documented Linux or Windows path, and nothing in the material suggests a headless server mode. If your release pipeline runs on a Linux CI runner, Blitz is the wrong tool, full stop. The MCP server appears to be local to the app, so an agent on a remote machine cannot reach it without something else in between.
Distribution has a second constraint. CI builds use ad-hoc signing, which the README states directly in the verification section. Ad-hoc signed apps are fine for local use and awkward for managed fleets, where Gatekeeper and MDM expectations differ. The README covers signed builds for developers with Apple Developer credentials in .env, but it does not describe notarization or a distribution certificate flow beyond that.
The third constraint is the helper. asc-cli is described as covering edge-case ASC operations, which implies the MCP tool set does not cover everything. Around 35 tools is a lot, and it is still a subset of what App Store Connect exposes. The README does not enumerate which operations fall outside the tools and require the CLI. That gap is the main thing a prospective user cannot resolve from the documentation alone.
How this differs from fastlane and from the raw API
The obvious comparison is fastlane, which has driven iOS submission from a Fastfile for years. The difference is the interface, not the destination. fastlane is a Ruby-based automation framework configured in code and executed from a terminal or CI runner. It is headless by design and fits a Linux or macOS CI pipeline. Blitz is a GUI application with an MCP tool surface, and its automation story is an agent session on the same Mac, not a YAML or Ruby file in a repository.
That distinction matters in both directions. A fastlane lane is reviewable in a pull request and reproducible on a clean runner. An agent session is neither, unless you keep the transcripts. Conversely, an agent session can react to a submission failure by inspecting state and retrying, which a static lane cannot do without you writing the retry logic.
The second alternative is the App Store Connect API directly, or the asc-cli that Blitz bundles. The bundled helper is itself a fork of an existing open source CLI, pinned as a submodule. If your team is comfortable scripting, using that CLI without Blitz removes the GUI, the MCP layer, and the telemetry question in one step. You lose the agent integration and the simulator control. You keep a scriptable, auditable submission path.
Licence, upgrades, and what to check before committing
The repository is Apache-2.0. That is a permissive licence with an explicit patent grant and a requirement to preserve notices, which is generally the easiest category to adopt inside a company. It is not legal advice, and the practical question is not the licence itself but the submodule: deps/App-Store-Connect-CLI-helper is a pinned fork of a separate project, and its licence and update cadence are not described in the material provided. Check that before you depend on the helper.
Upgrade cost is low in the ordinary case. Releases are frequent and versioned, with v1.0.33, v1.0.34 and v1.0.35 all landing in April 2026, and the last push to the repository is dated 2026-07-14. The bundled helper is pinned, so upgrading Blitz may also move the helper, which is where behaviour changes would surface. If you build from source, that pin is yours to control through BLITZ_ASCD_SOURCE_DIR.
Two things are genuinely unverifiable from the material. First, whether the MCP server binds locally only or can be reached over a network. Second, the exact boundary between the roughly 35 MCP tools and the edge cases that require asc-cli. Both matter before an agent is allowed to press the submit button, and neither is answerable from the README as supplied.
Editorial conclusion
Adopt Blitz if your team already submits iOS apps from a Mac and you want an MCP client to drive submission, IAP setup and screenshot upload instead of clicking through App Store Connect. Do not adopt it if you need a headless Linux CI path, or if an unsigned ad-hoc build cannot pass your release process. Verify three things first: that your MCP client can reach the local server, that the bundled asc-cli submodule at deps/App-Store-Connect-CLI-helper covers the edge cases your release needs, and that scripts/verify-build.sh v1.0.35 reproduces the published checksum on your toolchain.
Community notes