Migrate from EAS Submit 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, and opens the simulator builds of the same project on live cloud devices.

This page is for Expo and React Native teams who submit with eas submit, or with the EAS Workflows submit and testflight jobs, and want to move that step. For the build step, see Build an Expo app without EAS. For a side-by-side of the two services, see EAS Build alternative: VibeView vs Expo EAS.

Who this is for

• Your eas.json has a submit profile and you run eas submit, or eas build --auto-submit^[5].
• You need more than internal groups. Plain eas submit adds a build to internal groups only^[1]. External groups, What to Test notes and Beta App Review go through the separate Workflows testflight job^[3]. In VibeView they are flags on the same command.
• You ship Google Play release notes, which EAS Submit doesn’t manage^[4], or an Apple TV, Android TV or Fire TV build of the same app.

Option mapping

vibeview.json below means platforms.ios.submit (also tvos) or platforms.android.submit (also androidtv). Flags are vibeview submit flags and always win over vibeview.json.

iOS and Apple TV

EAS names are from Expo’s eas.json reference^[1], its App Store submission guide^[5] and the Workflows testflight job^[3].

Apple’s export compliance question is answered once per app in VibeView. --uses-encryption or --no-uses-encryption saves the answer for later builds, and ITSAppUsesNonExemptEncryption in your Info.plist wins over it.

Android and Android TV

EAS names are from the Android options in Expo’s eas.json reference^[2]; the release-notes row is from its submission overview^[4].

See Google Play tracks, staged rollout and changes not sent for review for the Play terms.

What has no equivalent

• Submitting a binary built elsewhere. EAS Submit accepts any valid .ipa or .aab, including a local build passed with --path^[4]. VibeView submits its own cloud builds only.
• Distributing a build already in App Store Connect. The testflight job’s asc_build_id^[3] has no VibeView counterpart.
• Store metadata. EAS Metadata (metadataPath)^[1] has no counterpart. Listings, screenshots, App Store review and phased release stay in App Store Connect.
• Creating the App Store Connect app. EAS Submit can create the app record when ascAppId isn’t set^[1]. With VibeView you create it once by hand.
• Apple ID sign-in. VibeView works with an App Store Connect API key only.

Before and after

An EAS setup that submits Android to a staged beta and iOS to an internal group, plus the Workflows job that adds an external group and a note^[2][3]:

{
  "submit": {
    "production": {
      "ios": {
        "ascAppId": "1234567890",
        "ascApiKeyPath": "./keys/AuthKey_ABC123.p8",
        "ascApiKeyIssuerId": "00000000-0000-0000-0000-000000000000",
        "ascApiKeyId": "ABC123",
        "groups": ["QA team"]
      },
      "android": {
        "serviceAccountKeyPath": "./keys/play-service-account.json",
        "track": "beta",
        "releaseStatus": "inProgress",
        "rollout": 0.1
      }
    }
  }
}

# .eas/workflows/testflight.yml
jobs:
  build_ios:
    type: build
    params:
      platform: ios
      profile: production
  testflight:
    type: testflight
    needs: [build_ios]
    params:
      build_id: ${{ needs.build_ios.outputs.build_id }}
      internal_groups: ['QA team']
      external_groups: ['Public beta']
      changelog: 'Try the new checkout'

The same on VibeView. The keys are stored once with vibeview credentials, so vibeview.json names no key files:

{
  "platforms": {
    "ios": {
      "appId": "app_ios123",
      "build": { "...": "..." },
      "submit": { "ascKey": "team", "groups": ["QA team", "Public beta"] }
    },
    "android": {
      "appId": "app_android456",
      "build": { "...": "..." },
      "submit": { "track": "beta", "releaseStatus": "inProgress", "rollout": 0.1 }
    }
  }
}

vibeview build --cloud --production --platform all
vibeview submit --platform ios --latest --what-to-test "Try the new checkout" --wait-distribution
vibeview submit --platform android --latest --release-notes "Try the new checkout"

Switch step by step

One trap first. Apple and Google refuse a build number they have already seen. While EAS and VibeView both upload the same app, check VibeView’s counter with vibeview versions list before each VibeView build, and raise it with vibeview versions set if EAS uploaded a higher number since (step 4).

Where EAS is the better fit

• Any binary. EAS Submit uploads any valid .ipa or .aab, wherever it was built^[4]; VibeView submits its own builds.
• Store metadata. EAS Metadata manages App Store information and localized descriptions^[4]; VibeView leaves the listing to App Store Connect.
• App record creation and Apple ID sign-in^[1][5], for teams that don’t use API keys.
• Price. Expo’s Free plan includes submitting to the app stores^[7]. On VibeView, submitting needs a VibeView production build, which uses your plan’s build minutes.

What VibeView adds:

• External groups, What to Test and Beta App Review on the vibeview submit command.
• Google Play release notes in each language.
• One submission state that names what is missing and where to fix it, with Check again.
• A notification when testers have the build, and an email when it fails or Apple needs something from you, with matching Slack and webhook events. EAS reports a submission’s result through webhooks^[6].
• The export compliance answer saved once per app.
• Amazon Appstore submission for Android and Android TV.
• The same project on cloud iOS, Android, Apple TV and Android TV devices for testing.

Next: move the build with Build an Expo app without EAS, then the pipeline with GitHub Actions to TestFlight. Coming from fastlane instead? See Migrate from fastlane pilot.