Upload to TestFlight without a Mac

Getting a build into TestFlight has always meant a Mac at the end of the pipeline: Xcode’s Organizer or the Transporter app, both macOS-only. VibeView removes that last Mac too — cloud builds (beta) produce a signed .ipa on a managed toolchain, and vibeview submit uploads it to App Store Connect server-side, straight from the CLI on Windows, Linux, or macOS. Your machine never touches Xcode, Transporter, or altool.

The upload is the binary only — exactly as if you had dragged the file into Transporter yourself. Store listings, screenshots, release notes, and submitting for App Review stay in App Store Connect. And it isn’t iOS-only: the same command sends tvOS builds to TestFlight, and Android/Android TV builds to a Google Play track.

What you need

A VibeView account with the CLI installed (npm install -g vibeview && vibeview login)
An App Store Connect API key stored once with vibeview credentials asc-key add — the same key that powers signing credential generation
The app record created in App Store Connect (My Apps → ＋ → New App) with your bundle identifier — a one-time step; Apple only accepts uploads for apps that already exist there
A production build config in vibeview.json — the first --production run prompts for it

From source to TestFlight, step by step

Build a signed release.
```
vibeview build --cloud --production --platform ios
```
The build runs on VibeView’s fleet with your generated (or uploaded) distribution certificate and profile — see App Signing. The signed .ipa lands in your Builds page.
Submit it.
```
vibeview submit --platform ios --latest
```
--latest picks your newest succeeded production build; --build <id> submits a specific one. The CLI streams the submission log and exits when the upload is accepted. Eligible builds also carry a Submit to store button in the dashboard.
Watch it appear in TestFlight. Apple processes the upload on their side — expect the build in TestFlight roughly 10–15 minutes after the submission succeeds. From there it’s the normal Apple flow: pick testers, or attach the build to a version for App Review.

Build numbers, handled

Apple refuses an upload whose build number (CFBundleVersion) it has seen before. Set "autoIncrement": true under platforms.ios.build in vibeview.json and every production build gets the next number allocated server-side, injected as VIBEVIEW_BUILD_NUMBER — wire it into your build in one line (how). For an app already in TestFlight, the very first allocation checks your highest existing build number in App Store Connect and starts above it; you can also seed the counter yourself with vibeview versions set.

The same flow for Google Play

vibeview submit --platform android --track internal uploads an .aab to a Play track through a service-account key (vibeview credentials play-key add). Releases can go out completed, as a draft to roll out by hand, or as a staged rollout with --release-status inProgress --rollout 0.1. The Store Submission docs cover the one-time Play Console setup.

Cloud builds and store submission are in beta. A refused submission always says why in its log — a duplicate build number, a missing app record, or a key that lacks access — and a failed submission never blocks you from fixing the cause and submitting again.

When you’d use this

The obvious case is no Mac at all: a Windows or Linux team shipping a React Native app end to end. It’s just as useful when you have Macs but don’t want the pipeline — no CI runner to keep on the right Xcode, no fastlane lane to maintain, no signing certificates scattered across laptops. One vibeview.json in the repo, two commands, and any teammate (or CI job) can cut a TestFlight build.