Blitz: Autopilot for App Store Submission

TL;DR

• Automates the App Store submission checklist - metadata, screenshots, IAPs, and submission - from a native macOS app (the README).
• Lets an MCP client (Claude Code, Codex) drive the workflow so repeatable steps are scriptable and observable (the README).
• Best for iOS/macOS developers who can run Xcode and macOS runners; not for Linux/Windows-only CI (the README).
• Common use: boot simulator, capture pixel-accurate screenshots, attach IAPs, and submit a build with an agent doing the clicks and API calls (the README).
• Main difference: a local MCP server exposing ~35 tools so an agent can complete the entire flow from GUI plus CLI helpers (the README).

The scene: a reviewer emails, the upload bar freezes at 82 percent, and the release window is in ten minutes. My hand hovered above the mouse. I had two options: throw more people at the problem or hand it to an autopilot and hope it knows how to land. The autopilot, in this story, is Blitz.

Situation - late-release panic, but make it a runway

I opened the MCP terminal, watched a spinner, and read “Upload failed: 403 Unauthorized” in plain letters. The release window was not an abstract deadline; it was a 10-minute runway with the team huddled behind me. The metaphor is simple: Blitz is the autopilot and the ground crew for App Store delivery - it steers while it also checks the landing gear. The README calls it a native macOS App Store Connect tool exposing agent hooks via MCP (the README). That is the moment you notice the difference.

Task - in one sentence

Task: Blitz is a native macOS App Store Connect client that exposes MCP tools so an agent can drive uploads, screenshots, IAP attachments, and the final submit, all from a local macOS environment (the README).

Real-World Use Cases

• Local debug and iteration: build a debug app, drive the simulator, and capture screenshots for multiple locales using Blitz’s simulator controls (the README).
• Release artifact creation: bundle a signed release, verify checksums, and produce an auditable artifact for the release pipeline (the README).
• Agent-driven submission: let an MCP client fill metadata, attach IAPs, upload screenshots, and submit a build for review (the README).
• IAP management at scale: create IAPs, set statuses to Ready to Submit, and attach them to versions before submission (the README).
• CI augmentation on macOS runners: integrate Blitz into macOS runners to standardize pre-release checks and verification steps (the README).

Walkthrough - the painful before, the precise after

# Before (manual web UI)
1. Open App Store Connect, use browser forms for metadata.
2. Upload device screenshots one by one for each locale and device.
3. Create in-app purchases, remember to attach them to the version.
4. Click Submit and cross your fingers.

# After (Blitz + MCP agent)
git clone https://github.com/blitzdotdev/blitz-mac.git
git submodule update --init --recursive
npm run build:app:debug      # launches .build/Blitz.app with MCP terminal
open .build/Blitz.app
# Agent connects via MCP and runs:
mcp.run('capture_screenshots', {locales:['en-US','vi-VN']})
mcp.run('attach_iaps', {ids: [12345, 12346]})
mcp.run('submit_build', {version: '1.0.35'})

The observation is simple: the manual path is human time and human error, the Blitz path is repeatable commands that an agent can run after you check credentials - but how reliable is that autopilot in the wild?

How to Use It

Top commands and their expected outcomes (from the repo docs)

• Clone and prepare:

  • Command:
    • git clone https://github.com/blitzdotdev/blitz-mac.git
    • git submodule update --init --recursive
  • Outcome: repository with required helper submodules pulled in (the README).

• Local debug build:

  • Command:
    • npm run build:app:debug
  • Outcome: launches a debug .build/Blitz.app with an MCP terminal and simulator controls for iterating locally (the README).

• Produce a signed release:

  • Command:
    • bash scripts/bundle.sh release
  • Outcome: a signed release artifact, verifiable with SHA256SUMS.txt and usable for distribution (the README).

• Agent-driven submission (high level):

  • Command (agent):
    • mcp.connect('claude')
    • mcp.run('upload', 'MyApp.ipa')
  • Outcome: an agent can upload builds and perform the sequence of screenshot, IAP attach, and submit operations through ~35 MCP tools exposed by Blitz (the README).

Placeholders and credentials

• Copy .env.example to .env and fill Apple credentials for signed builds. This is required for release signing and certain ASC operations (the README).

Markdy scene - what an agent-driven submission looks like (interactive visualization)

Configuration & Customization

• BLITZ_ASCD_PATH / BLITZ_ASCD_SOURCE_DIR: point to an alternate asc helper when you need a custom asc-cli binary. Use this when the bundled helper lacks an edge-case fix (the README).
• .env credentials: copy .env.example to .env for signing and fill Apple credentials. Use this when producing signed releases or uploads that require keys (the README).
• MCP binding: Blitz binds the MCP server to 127.0.0.1 by default for safety. Change only if you know the networking consequences and have proper auth layers (the README).
• Release verification: keep SHA256SUMS.txt checks as an explicit verification step in your pipeline when you consume release artifacts from GitHub releases (the README).

💡 Tip: If you need reproducible CI artifacts, standardize on the repo’s bundle.sh flow and verify SHA256SUMS.txt in your runner.

Where It Fits (And Where It Doesn’t)

• Fits when you have macOS + Xcode and want to move manual submission work to a repeatable, agent-driven flow (the README).
• Does not fit if you need cross-platform CI without macOS runners; Blitz is native macOS and requires an Xcode toolchain for many operations (the README).
• Works with asc-cli, App Store Connect API, simulator tooling, and Claude Code/Codex clients; it complements macOS runner-based CI rather than replacing general-purpose CI that runs on Linux (the README).

Visual aside: the repo is an autopilot and ground crew; autopilot reduces pilot workload, ground crew does the checklist. The tricky part is trusting the ground crew during a gust of policy changes.

The Rough Edges

• Platform lock-in: requires macOS 14+ and Xcode 16+ in practice. If your CI cannot provide macOS runners, Blitz is not an option (the README).
• Installer scripts and auto-update: release installers embed pkg-scripts and postinstall hooks that increase attack surface. The README recommends building from source and verifying checksums when security matters (the README).
• Telemetry and network calls: official builds may contact analytics and external APIs; the MCP server is localhost-only by default, which reduces exposure but does not eliminate it (the README).

⚠️ Warning: If you install binary releases, audit postinstall scripts and verify SHA256SUMS.txt before running on production machines.

Getting Started

1. Clone the repo and init submodules:
   • git clone https://github.com/blitzdotdev/blitz-mac.git
   • git submodule update --init --recursive
2. Build a debug app for iteration:

• npm run build:app:debug # opens .build/Blitz.app with MCP terminal (the README)

3. Copy credentials:
   • cp .env.example .env and fill Apple credentials for signed builds
4. For a signed release:
   • bash scripts/bundle.sh release then verify SHA256SUMS.txt before installing or distributing

Those are the shortest paths to the first working result. The rest is policy and patience.

How It Compares: Alternatives

• asc-cli is bundled and used for edge-case App Store operations. Blitz is not a replacement for asc-cli; it integrates and orchestrates it as part of a larger, agent-driven workflow (the README).

FAQ

Q: Can Blitz run on Linux or Windows?
A: No. Blitz is native macOS and requires macOS + Xcode toolchain; use macOS runners for CI (Where It Fits, the README).

Q: Can I use an AI agent like Claude Code to submit builds?
A: Yes. Blitz exposes an MCP server and roughly 35 tools so an agent can connect and drive uploads, screenshots, IAPs and submissions (How to Use It, the README).

Q: Are release artifacts auditable?
A: Yes. The docs recommend producing SHA256SUMS.txt and verifying checksums for release artifacts before installing (Configuration & Customization, the README).

Q: How are screenshots captured?
A: Use the simulator tooling plus Blitz MCP tools; recommended pattern is to boot the correct simulator and use xcrun simctl io <UDID> screenshot before uploading via Blitz (Real-World Use Cases, the README).

Q: Is it safe to run binary installers?
A: Exercise caution: audit postinstall pkg-scripts and verify checksums. If security matters, build from source and verify artifacts (The Rough Edges, the README).

Final Thoughts

The reviewer blinked red, then green. I did not press the buttons. The concrete result is this repository is active, well-documented for macOS workflows, and has 1,369 stars - a sign that the autopilot pattern is useful to a lot of people right now (the README). If you have macOS and Xcode, Blitz hands you a checklist you can trust to run in repeatable steps - the runway does not feel like a cliff anymore.

blitzdotdev/blitz-mac · Apache-2.0 · 1369 · docs