Do I have to stop using EAS?

No. EAS keeps building, submitting and updating. AppForShare is the tester and store release layer after the build.

Which way should I pick?

Connect Expo if you want no pipeline at all. A Workflows job if your builds already run in Expo Workflows. The CLI with --eas if you build from GitHub Actions or a laptop.

Is my Expo token sent to AppForShare?

No. Connect Expo needs no Expo token, and the CLI uses eas-cli on your own machine.

Do my EAS links move over?

No. They stay on Expo. New builds get AppForShare links; send testers one channel link that keeps working for later builds.

Can testers install a store build?

No. App Store and Google Play builds cannot be installed from a link. Use an internal distribution profile for testers.

AppForShare Get started

Docs

Use AppForShare with Expo EAS

Keep EAS Build. This guide shows three ways to send EAS internal builds to AppForShare, how iPhones get into the next build, how EAS links map to AppForShare links, and where the store steps fit after EAS Submit.

Step 1, Every plan
Keep EAS Build
Nothing about how you build changes. Expo Build (EAS Build) keeps building on Expo's machines or with eas build --local, and EAS Update and EAS Submit keep working. AppForShare takes the finished internal build and adds a stable link, passwords, iPhone onboarding, feedback, the readiness check and the store steps.
Use a build profile with "distribution": "internal". On iOS that makes an ad hoc build for registered iPhones; on Android set "buildType": "apk", or keep the .aab and AppForShare turns it into one APK testers install.
```
{
  "build": {
    "preview": {
      "distribution": "internal",
      "channel": "preview",
      "android": { "buildType": "apk" }
    }
  }
}
```
Step 2, Pro and Team
Way 1: Connect Expo (no CI)
In the project, open Connect Expo. AppForShare shows a webhook address and a secret with the command filled in. Run it once in your Expo project folder. When an internal build finishes, EAS calls AppForShare, which checks the expo-signature header, downloads the build from Expo and shares it with release notes from the commit and the channel you mapped to the build profile.
Store builds are skipped with a note, because they cannot be installed from a link. The CLI prints the same command with appforshare eas connect --project <id> --profile preview=Beta.
```
eas webhook:create --event BUILD \
  --url https://appforshare.io/api/hooks/eas/<token> \
  --secret <secret from AppForShare>
```
Connect Expo

Step 3, Pro and Team

Way 2: an Expo Workflows job

Add APPFORSHARE_TOKEN as a secret environment variable in your Expo project, then add a custom job after the build job. eas/download_build gives the path of the downloaded file to the next step, which uploads it. The job runs on Expo's Workflows minutes, so it counts toward your Expo plan.

jobs:
  build_preview_ios:
    type: build
    params:
      platform: ios
      profile: preview
  share:
    needs: [build_preview_ios]
    steps:
      - uses: eas/download_build
        id: download_build
        with:
          build_id: ${{ needs.build_preview_ios.outputs.build_id }}
      - run: npx --yes appforshare upload "${{ steps.download_build.outputs.artifact_path }}" --channel beta

Step 4, Pro and Team
Way 3: GitHub Actions, any CI or your laptop
appforshare upload --eas <build id> asks eas-cli on the same machine for the build, downloads it and fills the release notes from the build. --eas-latest --profile preview --platform ios takes the newest finished build of a profile. Your EXPO_TOKEN stays on that machine and is never sent to AppForShare.
Built with eas build --local? The file is already on your disk: upload it directly. The CI guide has a full GitHub Actions job, and the GitHub Action can keep one comment on the pull request with the install links and QR codes (pr-comment: true).
```
npx appforshare upload --eas 4c2f0e1a-...
npx appforshare upload --eas-latest --profile preview --platform ios --channel beta
eas build --local --profile preview --platform android --output app.apk && npx appforshare upload app.apk
```
Upload from Expo EAS in CI
Step 5, Pro and Team
iPhones
Turn on the onboarding link of the iOS project and send it to testers. They install a profile, their iPhone lands in your devices, and an Admin registers it on Apple with your App Store Connect API key in one click, with no Apple ID sign in.
Then get the device into the next EAS build: run eas device:create and choose the Apple Developer Portal import, or let EAS refresh the ad hoc profile, and build again. Going the other way, appforshare devices import reads the output of eas device:list --json.
```
eas device:list --json > eas-devices.json
npx appforshare devices import eas-devices.json
```
iOS device registration
Step 6, Free, Pro and Team as noted
Moving off EAS internal distribution links
An EAS build URL is a build link here, on every plan. The newest build is a channel link (Pro and Team): one address that always opens the newest build, iOS or Android from the same link. Turning off unauthenticated access maps to a password per build (Free and up), extra links with their own stop date and install cap (Pro), or private projects and per tester access codes (Team). Stakeholders who sign off get the client portal.
Once testers use the new links, you can turn off unauthenticated access to internal builds in your Expo project so old links ask for an Expo login.
Beta and Live channels
Step 7, Every plan with an account
Updates and Expo checks
EAS Update keeps working in builds you share; AppForShare does not host updates. Channels on AppForShare hold whole builds. The build page shows the Expo SDK, the runtime version and the update channel a build reads, and the readiness check warns when a development client build goes to testers, when a test build reads your production update channel, or when the runtime version changed.
EAS Update channels and test builds
Step 8, Pro and Team, Play production and crash rates on Team
Store steps
Keep eas submit if it already uploads in your pipeline, or upload the App Store .ipa or the .aab to AppForShare and let an Admin send it to TestFlight or a Google Play testing track (Pro), or save a production draft (Team). Then use the listing editor (it imports and exports store.config.json), the App Store review card and the Google Play releases page, with crash and ANR rates per version on the release page (Team, read only).
Send store builds to TestFlight and Google Play
Step 9, Pro and Team
AI tools
Connect the Expo MCP server for builds and workflows and the AppForShare MCP server for links, testers, readiness and store status. Both use OAuth sign in and work side by side in Claude, Cursor or VS Code.
MCP server

Questions

Do I have to stop using EAS?: No. EAS keeps building, submitting and updating. AppForShare is the tester and store release layer after the build.
Which way should I pick?: Connect Expo if you want no pipeline at all. A Workflows job if your builds already run in Expo Workflows. The CLI with --eas if you build from GitHub Actions or a laptop.
Is my Expo token sent to AppForShare?: No. Connect Expo needs no Expo token, and the CLI uses eas-cli on your own machine.
Do my EAS links move over?: No. They stay on Expo. New builds get AppForShare links; send testers one channel link that keeps working for later builds.
Can testers install a store build?: No. App Store and Google Play builds cannot be installed from a link. Use an internal distribution profile for testers.

Weighing the two first? Read AppForShare vs Expo EAS. For the upload commands, see Upload from CI.

Use AppForShare with Expo EAS

Keep EAS Build

Way 1: Connect Expo (no CI)

Way 2: an Expo Workflows job

Way 3: GitHub Actions, any CI or your laptop

iPhones

Moving off EAS internal distribution links

Updates and Expo checks

Store steps

AI tools

Questions