Shipping a mobile app is a dozen brittle steps across two consoles, a build service, and a payments dashboard — and half of them are gated on a human: Apple review, the Paid Apps agreement, screenshots, the first manual Play upload. Teams script this with Fastlane or a pile of CI YAML and still babysit it every release. amba ship is that pipeline as a single command in the Amba CLI: one amba.ship.json, then npx @layers/amba ship runs preflight, an optional monetization check, the production build for each platform, the store submit, the listing push, and the release promotion — recording per-app state so a re-run resumes exactly where it stopped. It is honest by design: a step no API can perform is detected and printed with the exact console URL, so the command stops cleanly, you clear the gate, and re-run — never wondering whether something was quietly faked as done.
What does amba ship automate, and what stays manual?
The automatable spine — building the production binary, uploading to TestFlight and your Play track, pushing the App Store listing, and promoting the Android build to production — runs end to end from one command, driving your existing Expo build toolchain. The rest is irreducibly human: only a person can create the store app records, accept the Apple Paid Apps agreement, capture screenshots, answer the privacy and data-safety questionnaires, publish the first Play upload, and press Submit for Review. amba ship does not pretend otherwise — it detects each gate and stops with the precise action and console URL, then resumes when you re-run.
Is amba ship an MCP tool or a CLI command?
It is the CLI — the human-developer entry point — because the build runs where your app source, signing keychain, and Expo project link live, which is your machine or CI, not a server. amba ship drives that local toolchain. Where it touches the Amba backend it composes the platform’s server-side surfaces: its monetization phase verifies your in-app purchase catalog through the monetization control plane (the same surface the amba_monetization_* tools wrap), and the privacy and support pages the stores require can be hosted with amba sites on a public URL. An agent working at the terminal can run the automatable phases and read the gate checklist; the human-gated steps still need a person.
How does it stay safe to re-run?
Every phase is idempotent and records its result under .amba/ship-state/. A re-run skips phases already done, reuses a recorded build for the same app version instead of triggering a duplicate billable build, and never re-submits a binary it already submitted. Bump app.version and the binary phases — build through release — re-run automatically while preflight and monetization stay. --dry-run prints the whole plan and makes no changes or network calls; --force re-runs a completed phase; --phase runs a single one. The loop is always: clear a gate, re-run, and the completed work is skipped.
Phase behavior verified against the shipped CLI (@layers/amba 4.1.0), June 2026.
How do I take an Expo app live with one command?
The real CLI sequence — scaffold, check, plan, ship
Commands run against the published CLI (@layers/amba 4.1.0). Your App Store and Play credentials stay in your build config, where the build runs — Amba never sees your signing keys.
What goes in the config?
amba.ship.json — non-secret ids and the NAME of your token env var
The config carries identifiers and the NAME of the env var holding your build token — never secret values. ios.ascAppId stays null until the store app record exists; ship treats a missing one as a gate. Bumping app.version re-runs the build → release phases.
Which MCP tools cover this surface?
When is this not the right call?
- It is a CLI workflow, not a one-click button
- amba ship automates the build → submit → release spine, but app-store launches are gate-dominated by design: Apple review, the Paid Apps agreement, screenshots, and the first manual Play upload are human steps no tool can perform. ship stops at each with the exact action; if you expected fully hands-off publishing, that is not what any honest tool can deliver.
- It drives your existing Expo build toolchain
- ship orchestrates the Expo production build and store submit — it does not replace your build profiles, project link, or signing credentials, which live in your app repo where the build runs. If you are not on Expo or React Native, ship is not your tool; it is purpose-built for that path.
- Fastlane is more configurable for bespoke release pipelines
- For teams needing deeply custom lanes — exotic code-signing matrices, non-Expo build systems, intricate multi-track rollouts — Fastlane’s plugin ecosystem goes further than amba ship’s opinionated six phases. ship trades that surface area for one config, one command, and honest gates; weigh which you need.
Can an AI agent set this up end to end?
Yes. Amba’s hosted MCP server at https://mcp.amba.dev/mcp (Streamable HTTP) exposes the whole backend as tool calls. amba_developer_signup mints a developer token and a provisioned project — client key and server key included — with no browser, and the project goes active in about ten seconds. amba ship is the command-line half of the story: a developer — or an agent working at the terminal — runs one command that drives the automatable build, submit, and release steps and surfaces the store gates a human must clear, so nothing is ever reported as done when it is not.
Ship — FAQ
What is amba ship?
A command in the Amba CLI that takes a code-complete Expo app from build to live on the App Store and Google Play. One amba.ship.json and one command run six idempotent phases — preflight, monetization, build, submit, store listing, release — recording per-app state so a re-run resumes where it stopped, and surfacing every manual store gate with its exact console action.
Does amba ship fully automate App Store and Play submission?
It automates everything an API can: the production build, the upload to TestFlight and your Play track, the App Store listing push, and the Android production promotion. The steps the stores require a human to do — creating the app records, the Apple Paid Apps agreement, screenshots, the first manual Play upload, and Submit for Review — are detected and surfaced with the exact action, never faked as done.
Do I have to give Amba my signing keys or store credentials?
No. The config holds non-secret identifiers and the name of the environment variable that carries your build token — never secret values. Your App Store and Play credentials live in your build config, where the build runs; Amba never sees your signing keys.
How does amba ship handle re-runs and new app versions?
Every phase is idempotent and records its result locally. A re-run skips done phases, reuses a recorded build for the same app version rather than triggering a duplicate, and never re-submits a binary already submitted. Bump app.version and the build-through-release phases re-run automatically. --dry-run prints the full plan and changes nothing.
Is amba ship an MCP tool an agent can call?
Not directly — it is the CLI, because the build runs where your app source and signing keychain live (your machine or CI), not on a server. An agent at the terminal can run the automatable phases and read the gate checklist. Where ship touches the backend it composes Amba’s server-side surfaces, like the monetization control plane for the in-app purchase catalog.
How does ship relate to in-app purchases?
If your app sells anything, set monetization.enabled and ship verifies your in-app purchase catalog against Amba’s monetization control plane before building, gating if it has drifted so you apply it first with amba monetization apply. Configure the catalog once; ship keeps the store in step with it.
Sources for this guide
- Amba ship guide as of 2026-06
- Expo EAS Submit docs as of 2026-06
- App Store Connect — submit for review (Apple) as of 2026-06