Migrate from fastlane pilot to VibeView

VibeView builds iOS, Apple TV, Android and Android TV apps in the cloud, with no Mac. It submits them to TestFlight, Google Play and the Amazon Appstore from one CLI and one dashboard. The simulator builds of the same project open on live cloud devices.

This page is for teams whose release lane ends in upload_to_testflight (also called pilot or testflight). It maps each option you use to its VibeView equivalent and says which ones have none. Then it gives a switch plan that keeps fastlane running until you trust the new path.

Who this is for

• You run a lane :beta that calls build_app and upload_to_testflight^[4], on your own Mac or a hosted macOS runner. build_app drives xcodebuild^[5], so the lane needs a Mac with Xcode. pilot itself can upload from Linux with Apple’s Transporter^[3].
• You want build, signing and upload to run without a Mac you maintain.
• You also ship an Apple TV, Android or Android TV build of the same app and want one tool for all of them.

If your lane is mostly deliver (App Store review, metadata and screenshots), read What has no equivalent first: VibeView stops at TestFlight and the store tracks.

How the pieces map

vibeview submit sends a VibeView production cloud build, so the switch covers three fastlane actions^[4], not one:

Option mapping

Each row is an upload_to_testflight option or pilot command, as named in fastlane’s parameter reference^[1] and its pilot commands^[2]. Flags are vibeview submit flags unless the row names another command. vibeview.json means its platforms.ios.submit block.

The two testflight commands that replace the review and test-information options, set once per app:

vibeview testflight set-review-contact --first-name Ada --last-name Lovelace \
  --phone "+1 555 0100" --email review@example.com \
  --sign-in-required --sign-in-user demo@example.com --sign-in-password-file demo-password.txt
vibeview testflight set-info --locale en-US --description "What testers should try" \
  --feedback-email beta@example.com --privacy-url https://example.com/privacy

The sign-in password is read from a file or a pipe, never from the command line.

What has no equivalent

Said plainly, so nothing surprises you after the switch:

• App Store review and listings. deliver uploads metadata, screenshots and App Preview videos and submits for App Store review, with automatic_release and phased_release^[7]. VibeView does none of that. App Store review, phased release, the listing and screenshots stay in App Store Connect. Keep deliver for them if you use it.
• Removing and listing testers. pilot remove, pilot list, pilot find and pilot export^[2] have no VibeView command. Remove testers and see who installed a build in App Store Connect.
• Internal testers. VibeView adds testers to external groups only. Add someone to an internal group in App Store Connect.
• notify_external_testers, expire_previous_builds, reject_build_waiting_for_review^[1]. VibeView doesn’t change notification settings, never expires a build, and never removes a build from review. When another build of the version is in review, the submission says so and checks again on its own. Remove that build in App Store Connect if you want to.
• distribute_only (distribute a build already in App Store Connect). VibeView sends the builds it made; it doesn’t take an .ipa built elsewhere or a build someone uploaded by hand.
• app_clip_invocations: not available.

Before and after

A typical fastlane beta lane, with options from fastlane’s own docs^[4]:

# fastlane/Fastfile
lane :beta do
  sync_code_signing(type: "appstore")
  build_app(scheme: "MyApp")
  upload_to_testflight(
    api_key_path: "fastlane/api_key.json",
    groups: ["QA team", "Beta testers"],
    distribute_external: true,
    changelog: "Try the new checkout",
    uses_non_exempt_encryption: false
  )
end

The same release on VibeView. autoIncrement on the production profile gives every production build the next build number from a counter VibeView keeps per app, so the lane needs no build-number step. The groups and the key go in vibeview.json; the note and the encryption answer are flags:

{
  "platforms": {
    "ios": {
      "appId": "app_abc123",
      "build": {
        "profiles": {
          "production": { "command": "...", "artifact": "ios/build/*.ipa", "autoIncrement": true }
        }
      },
      "submit": { "ascKey": "team", "groups": ["QA team", "Beta testers"] }
    }
  }
}

vibeview build --cloud --production --platform ios
vibeview submit --platform ios --latest \
  --what-to-test "Try the new checkout" --no-uses-encryption --wait-distribution

The encryption flag is needed once: the answer is saved on the app.

Switch step by step

One trap first. Apple refuses a build number it has already seen. While fastlane and VibeView both upload the same app, check VibeView’s counter with vibeview versions list before each VibeView build. If fastlane uploaded a higher number since, raise it with vibeview versions set (step 4).

If you also use supply for Google Play

The Android side maps the same way. Option names are from fastlane’s upload_to_play_store reference^[8]; the VibeView keys go in platforms.android.submit.

See staged rollout and version code for the Play terms.

Where fastlane is the better fit

• It’s free and open source, under the MIT license, and it runs on your own computer or server^[6]. VibeView is a hosted service: builds use your plan’s build minutes, and your store keys are stored in VibeView.
• It covers App Store review and metadata. deliver submits for review and manages listings and screenshots^[7]; VibeView doesn’t.
• It manages testers both ways. pilot removes, lists and exports testers^[2]; VibeView only adds them to external groups.
• It uploads any .ipa. pilot uploads the file you point it at^[1]; vibeview submit sends VibeView cloud builds only.

What VibeView adds:

• Builds without a Mac or Xcode to maintain.
• A submission state that says what is missing and where to fix it, with Check again.
• The export compliance answer saved once per app.
• The same project on cloud iOS, Android, Apple TV and Android TV devices for testing before it ships.

Next: set up the one-time pieces in Upload to TestFlight without a Mac, then move the pipeline with GitHub Actions to TestFlight. Moving from EAS instead? See Migrate from EAS Submit.