MagicDeploy

One button between your project and TestFlight or Google Play.

Open a project, press Deploy. MagicDeploy works out what kind of project it is, finds the build it should ship, and uploads it. No Fastfile, no CI config, no browsing for an .ipa.

Getting started

1. Install the extension and open a folder containing an iOS or Android app.
2. Click the 🚀 MagicDeploy icon in the activity bar.
3. Your open workspace is added automatically if it holds a deployable project.
4. Press Deploy.

The first deploy asks for one credential per store. After that it never asks again.

What it recognises

Detection scores your folder and picks the best match — you don't tell it anything.

For iOS it resolves the workspace, the real app scheme, and the bundle identifier — reading schemes from your own project rather than the workspace, so CocoaPods dependencies don't flood the list. For Android it reads the applicationId, the app module, and whether release signing is actually configured.

Finding your build

iOS looks in your framework's output directory and in Xcode's Organizer archive library, matched on bundle id. An archive you made in Xcode's UI is picked up with no setup at all. Version, build number, team, and whether Apple already accepted that archive are read from the archive itself.

Android scans the Gradle output tree and skips two things that would otherwise cause confusing failures: work-in-progress bundles under intermediates/, and debug-signed artifacts that Google Play rejects. An .aab always outranks an .apk.

If nothing recent exists, it builds — flutter build, xcodebuild archive, ./gradlew bundleRelease, or dotnet publish, whichever your project needs.

Before every build, it checks the version

A build bakes the version in, and both stores reject a build number they have already seen — telling you only after the upload finishes. So MagicDeploy pauses first and shows what it is about to stamp in. Confirm it, bump it, or type your own.

Your project files are never modified. The version is passed to the build tool as arguments, so a deploy leaves no diff behind.

Flutter projects also get an Obfuscate toggle, which adds --obfuscate and writes Dart symbols to build/symbols/<platform>/<version> so later crash reports stay readable.

Release notes, written for you

Both stores take release notes, and the ✨ button drafts them from your recent commits using whichever AI CLI you already have — Claude Code, Gemini CLI, llm, or Ollama. It picks the commit range from your last tag, falling back to your last successful deploy, and skips chore and version-bump commits.

Everything runs locally. MagicDeploy sends nothing anywhere.

Every deploy is recorded

Runs are archived with their steps, timings, and full command log. Click any past deployment to read back exactly what happened, including runs from previous sessions. A deploy still in progress reattaches when you reopen the project, so switching tabs never loses the log.

Requirements

MagicDeploy drives the tools you already have; it does not bundle them.

• iOS — macOS with Xcode installed
• Android — a JDK and the Android SDK, or Flutter
• An Apple Developer account, a Google Play developer account, or both

Credentials

One per store, asked once and remembered.

Apple. Either an App Store Connect API key (recommended — MagicDeploy installs it where Xcode and altool both look), or an Apple ID with an app-specific password, which is kept in your login Keychain and handed to Apple's uploader without passing through MagicDeploy.

Xcode's Organizer uploads using the Apple ID session inside Xcode's own keychain. Apple provides no supported way for a command-line tool to reuse that session, which is why MagicDeploy needs its own credential.

Google. The Play Developer API accepts only a service account. Create a JSON key in Google Cloud Console, then invite that service account address in Play Console → Users and permissions with Release to testing tracks.

Your data stays on your machine

MagicDeploy runs entirely locally. Projects, deployment history, and credentials live in your home directory, never in the extension and never on a server. Nothing is uploaded anywhere except the build you asked to ship, sent directly to Apple or Google.

Good to know

• Archiving iOS apps requires Xcode, so that half is macOS-only. Android deploys run anywhere.
• TestFlight "What to Test" notes need the API key credential — an app-specific password can upload builds but cannot set notes. Google Play notes work with any setup.
• Your app must already exist in App Store Connect or Play Console. MagicDeploy ships builds; it doesn't create listings.
• Google Play needs at least one manual upload before the API will accept builds, and an app that has never been published accepts only draft releases.

Commands

Full documentation is built in — click Help in the app's top bar.

Licensed MIT.