Do I need a CI pipeline?

No. The webhook is registered once with eas-cli, and EAS calls AppForShare after each build, also for builds you start from a laptop.

Is my Expo token sent to AppForShare?

No. Connect Expo needs no Expo token at all; EAS sends the build address in the webhook. The CLI way with --eas uses eas-cli on your own machine and keeps the token there.

How do you know the call comes from Expo?

Each call carries an expo-signature header made from the body with your secret. AppForShare checks it before it reads anything, and only downloads from Expo's artifact addresses.

Which plan do I need?

Pro or Team. The Expo facts and readiness lines on the build page are on every plan with an account.

AppForShare Create a free account

Every EAS build on your testers' phones, without a CI step

Pro and Team

Expo builds your app on its own machines and gives every internal build its own URL. Getting that build onto an AppForShare install page used to mean a CI job, eas-cli, curl and an upload step. Connect Expo removes all of it: you register one EAS build webhook, and when EAS finishes a build it tells AppForShare, which fetches the file and shares it.

You keep building on EAS exactly as before. AppForShare only adds what happens after the build: a link that always opens the newest build, passwords, iPhone onboarding, feedback, the readiness check and the store steps.

Start free See plans

Example

Connect Expo, Shop app

preview, iOS 1.4.0 (52)Shared to Beta, ready
preview, Android 1.4.0 (52)Shared to Beta, ready
production, iOSSkipped: store build, cannot install from a link
SignatureChecked on every call

Release notes from the commit message EAS sends, or the commit hash and app version.

Made for

Expo and React Native teams that build on EAS and share builds with clients or QA
Agencies with several Expo apps that want every build on one install page per app
Teams without a CI pipeline who run eas build from a laptop

What it ends

Copying a new EAS link into the team chat after every build
Writing a CI job only to download the EAS artifact and upload it again
Testers asking which of five EAS links is the newest one

How it works

Step 1
Turn it on for a project
In the project, open the Testing page and the Connect Expo card. AppForShare shows a webhook address for the project, a secret and the exact eas webhook:create command with both filled in.
Step 2
Run the command once
Run eas webhook:create --event BUILD with the address and secret in your Expo project folder. Nothing goes into your app, your eas.json or your CI.
Step 3
Map build profiles to channels
Pick which EAS build profile goes to which channel, for example preview to Beta. Builds of a profile you did not map still get their own link.
Step 4
Build as usual
When an internal build finishes on EAS, it appears in the project a few minutes later with its install link, release notes and readiness result, and testers are told the way the project is set up.

What happens on each build

EAS sends a BUILD event when a build finishes. AppForShare checks the expo-signature header against your secret before anything else, then downloads the build only from Expo's own artifact addresses, within your plan's file size limit. The same EAS build is never shared twice, even when EAS sends the event again.

Builds made with distribution: internal (ad hoc iOS builds and Android APKs) become builds in the project with their install link. Store builds are skipped with a clear line, because an App Store signed build cannot be installed from a link; send those with EAS Submit or with AppForShare's store upload. Errored builds can go to your build.failed webhook, and SUBMIT events show on the release page timeline.

Expo facts on the build page

Every build, from EAS or anywhere else, shows the Expo facts AppForShare reads from it: the Expo SDK, whether updates are on, the runtime version and the update channel. The readiness check adds Expo lines too: a development client build that needs a dev server sent to testers, a test build that reads the production update channel, or a runtime version that changed since the last build. These checks are on every plan.

Rather keep it in your pipeline?

Connect Expo is one of three ways. In Expo Workflows, a custom job can download the build with eas/download_build and run npx appforshare upload. From GitHub Actions or a laptop, appforshare upload --eas <build id> fetches the build through eas-cli on the same machine, so your Expo token never leaves it. The steps for each are in the guide.

Good to know

It does not build your app. EAS builds; AppForShare shares the result.
Store builds are skipped: App Store and Google Play builds cannot be installed from a link.
iPhones still need to be in the ad hoc profile. Register them with the onboarding link, then build again on EAS so the new profile is inside the build.
Your plan's file size limit applies: Pro takes builds up to 2 GB and Team up to 4 GB.
It does not touch EAS Update. Over the air updates keep working in the builds you share.

Questions

Do I need a CI pipeline?: No. The webhook is registered once with eas-cli, and EAS calls AppForShare after each build, also for builds you start from a laptop.
Is my Expo token sent to AppForShare?: No. Connect Expo needs no Expo token at all; EAS sends the build address in the webhook. The CLI way with --eas uses eas-cli on your own machine and keeps the token there.
How do you know the call comes from Expo?: Each call carries an expo-signature header made from the body with your secret. AppForShare checks it before it reads anything, and only downloads from Expo's artifact addresses.
Which plan do I need?: Pro or Team. The Expo facts and readiness lines on the build page are on every plan with an account.