Vibeview
Pricing
Sign In

Store Submission

Upload a finished production build straight to TestFlight or a Google Play track — no Xcode, no Play Console upload page. From the CLI:

vibeview submit --platform ios
vibeview submit --platform android --track internal

Or from the dashboard: eligible builds on the Builds page carry a Submit to store action (with a Play track picker for Android builds).

vibeview submit takes a succeeded production build’s artifact (the signed .ipa, .aab, or .apk from App Signing & Production Builds) and delivers it to the store for you. It uploads the binary only — store listings, screenshots, release notes, and App Review submission stay in App Store Connect / Play Console, exactly as if you had uploaded the file by hand.

Submissions are available for ios, tvos, android, and androidtv.

What you need first

  • A succeeded production build whose artifact is still available. Builds come from vibeview build --cloud --production — see Cloud Builds. If you deleted the build’s artifact, submit refuses; rebuild first.
  • iOS / tvOS: an App Store Connect API key stored with vibeview credentials asc-key add — the same key that powers credential generation (see App Signing). If your organization stores more than one key, VibeView asks you to name the one to use.
  • Android / Android TV: a Google Play service account key stored with vibeview credentials play-key add --file service-account.json. Three one-time steps in Google’s consoles: create the service account in Google Cloud (IAM & Admin → Service Accounts) and download its JSON key; enable the Google Play Android Developer API for that same Cloud project (APIs & Services → Enable APIs) — without this every upload is refused; and invite the service account’s email in Play Console (Users and permissions) with permission to release to testing tracks. vibeview credentials play-key list and play-key rm <name> manage stored keys. Like all uploaded credentials, the key is write-only — it can be replaced or removed, never read back.
  • The admin or developer role — the same roles that can start cloud builds. Viewers can watch submissions but not create them.

One-time App Store Connect prerequisite

Apple only accepts uploads for an app that already exists in App Store Connect. Before your first submission of a new iOS or tvOS app, create the app record there (My Apps → ＋ → New App), choosing the platform and the bundle identifier your build is signed with. You only do this once per app — no build upload is needed, the record alone is enough.

One-time Play Console prerequisite

Google’s publishing API can update an existing app but cannot create one. Before your first submission of a new Android app, create the app in Play Console and upload one build to it manually. Every submission after that can go through vibeview submit.

Choosing what to submit

vibeview submit --platform ios [--build <id> | --latest]
  • --build <id> submits a specific build from the Builds page.
  • --latest picks your newest succeeded production build for that platform.

Each build can have one submission in flight at a time — starting a second one while the first is still queued or running is refused. Once a submission finishes (succeeded or failed), you can submit the same build again.

Where it goes

  • iOS / tvOS uploads land in TestFlight for the app matching the build’s bundle identifier. Apple then processes the build on their side — expect it to appear in TestFlight roughly 10–15 minutes after the upload finishes. Uploading the same build number twice is refused by Apple, not by VibeView — bump the build number and rebuild.

  • Android / Android TV uploads go to a Play track:

    vibeview submit --platform android --track internal

    --track accepts internal, alpha, beta, or production and defaults to internal. The release is created with the uploaded binary. The app is identified by the package name read from the uploaded binary itself; --package is only needed when that can’t be determined.

    By default the release is completed on the track immediately. Two alternatives:

    • --release-status draft uploads without rolling anything out — the release waits in Play Console for you to roll it out by hand.
    • --release-status inProgress --rollout 0.1 starts a staged rollout to that fraction of users (strictly between 0 and 1 — for everyone at once, use the default completed release); manage the ramp-up in Play Console afterwards.

Per-project submit defaults

Store your usual submission settings once in the project’s vibeview.json, next to the platform’s build config — flags always win over these defaults:

{
  "platforms": {
    "android": {
      "build": { "...": "..." },
      "submit": { "track": "internal", "releaseStatus": "draft" }
    },
    "ios": {
      "build": { "...": "..." },
      "submit": { "ascKey": "team" }
    }
  }
}

Android/Android TV accept track, releaseStatus, rollout, and changesNotSentForReview (set it if Google refuses your commit with a changes-cannot-be-sent-for-review error); iOS/tvOS accept ascKey (which stored App Store Connect key to use).

Watching a submission

The CLI streams the submission’s progress log and exits successfully only when the upload succeeded. Submissions also appear on the Builds page in the dashboard, on the build they belong to, with their status (queued → running → succeeded or failed) and log.

A submission that is interrupted partway (for example, the service restarts mid-upload) fails with an explanation in its log rather than hanging — though marking an interrupted submission as failed can take up to an hour. Because each build allows only one submission in flight, a re-submit of the same build during that window is refused; once the interrupted one is marked failed, submitting again works. A failed submission never blocks you — fix the cause and submit the build again.

Common refusals

  • “Apple doesn’t know this app yet” — the app doesn’t exist in App Store Connect, or its bundle identifier doesn’t match the build’s. See the one-time App Store Connect prerequisite above.
  • “create the app in Play Console and upload one build to it manually first” — the one-time prerequisite above hasn’t been done for this app.
  • “the service account isn’t invited to this Play Console account or lacks release permission” — invite the service account’s email address in Play Console under Users and permissions and grant it release access.
  • “No App Store Connect key is stored” / “No Google Play service account key is stored” — add one with vibeview credentials asc-key add or vibeview credentials play-key add.
  • “This build isn’t linked to an app — pass —package ” — the package couldn’t be read from the binary and the build has no linked app; supply it explicitly.
  • “The build’s artifact is built as X — you passed —package Y” — the binary’s own package identifier disagrees with your --package flag; drop the flag or pass the matching one.