Expo Go now needs a login: share your app with clients another way
· 7 min read
For years the quickest way to show an Expo app to someone was Expo Go: they installed it from the App Store, scanned your QR code and the project opened. That still works for developers. For clients, product owners and other people outside the team it got harder this autumn, and the better answer was always a real build of your app. This guide covers what changed, which sharing options are left, and how to send a client an installable build without asking them to make any account.
What changed in Expo Go
Two entries in the Expo changelog explain it (both read on November 4, 2026):
- Login on iOS. On September 3, 2026 Expo posted "Login now required for running projects in Expo Go" for iOS (Expo changelog). Your client now needs an Expo account and has to sign in inside Expo Go before your project opens.
- App Store timing. In May 2026 Expo wrote that "a version of Expo Go for SDK 55 is still waiting for approval on the Apple App Store" (Expo changelog). Expo Go is an app like any other, so a new SDK version reaches iPhones only after Apple approves it. If you upgrade your project early, your client's Expo Go may not run it yet.
Neither change is a problem for a developer who already has an Expo account. Both are a problem when the person on the other end just wants to tap a link and see the app.
Why Expo Go was never the right client preview
Even before the login, Expo Go showed your project inside someone else's app:
- The client has to install Expo Go first, and now sign in.
- Your app's own native code is not there. Expo Go only contains the native libraries it ships with, so anything custom does not run.
- The icon on the home screen is Expo Go, not your app. Splash screen, push notifications and deep links do not behave like the real thing.
- The project has to come from a running dev server or a published update, which means you are involved every time they open it.
A client signing off on a release should test the build you plan to ship, with your name and icon on it. That means a real build, installed from a link.
The options left, side by side
| Option | What the client needs | iPhone UDID needed | Good for |
|---|---|---|---|
| Expo Go | Expo Go app and an Expo login (iOS, since September 3, 2026) | No | Your own developers |
| Development build | The build plus your dev server or an update | Yes (ad hoc) | Developers only |
| EAS internal distribution link | Nothing, unless the project requires an Expo login | Yes (ad hoc) | Quick shares inside a small team |
| AppForShare install link | Nothing; an optional password | Yes (ad hoc) | Clients, stakeholders, outside testers |
| TestFlight | Apple ID and the TestFlight app | No | Larger iPhone tests close to release |
Expo's own advice page on sharing builds with stakeholders (published October 1, 2026) ranks the choices by "recipient burden", starting with a browser simulator link, then internal builds, store testing tracks and preview updates (Expo article). It is a fair list. Its browser simulator, Expo Simulators, is in limited beta as of November 4, 2026.
Send a client a real build, step by step
1. Add a preview profile
In eas.json, a profile with internal distribution makes an APK for Android and an ad hoc signed build for iOS (Expo internal distribution docs):
{
"build": {
"preview": {
"distribution": "internal",
"channel": "preview",
"android": { "buildType": "apk" }
}
}
}The channel line matters if you use EAS Update. It keeps the client on preview updates, not production ones. EAS Update channels and test builds explains why.
2. Get the client's iPhone into the profile
Ad hoc builds install only on iPhones whose UDID is in the provisioning profile. With EAS you run eas device:create and pick the website option, which makes a registration link for the phone. Expo's docs add one rule to remember: "Registering a device with Expo does not register it with Apple" until a build includes it, so a new phone always means a new build.
On AppForShare you can send the client an iPhone onboarding link instead (Pro and Team). They type their name and email, install a small profile, and the phone lands in your devices list. You register it with Apple using your App Store Connect API key, never an Apple ID sign in (iOS device registration). When a build that includes the phone is uploaded, the client gets one email with the install link. If you only need the UDID, the free UDID finder works on any plan.
3. Build on EAS
eas build --profile preview --platform allEAS keeps building your app. AppForShare does not build apps on its own machines and does not replace EAS Build.
4. Send the build to AppForShare
Pick one of three ways:
- Connect Expo (Pro and Team). Run the
eas webhook:createcommand shown on the project page once. Every finished internal build then lands in AppForShare by itself, with notes from the commit and the right channel (Connect Expo). - CLI (Pro and Team, upload token). On the machine where eas-cli is signed in:
Your Expo token never leaves that machine.npx appforshare upload --eas-latest --profile preview --platform ios --channel beta npx appforshare upload --eas-latest --profile preview --platform android --channel beta - Browser (Free). Download the file from the EAS build page and drop it on the upload page.
5. Send the client one link
With the Beta channel (Pro), the client gets one stable link and QR code that always opens the newest build, the iPhone build on an iPhone and the Android build on Android (Beta and Live channels). Add a password on any plan. The install page explains each step in 13 languages, and the client can send feedback with screenshots from the same page, no SDK in your app (tester feedback).
Two mistakes that look like a broken app
- Sending a development build. A build made with the development client waits for a dev server. On the client's phone it opens to a launcher screen or an error. The readiness check that runs on every build (every plan with an account) flags "development client build sent to testers".
- A test build on the production update channel. The client then sees whatever you publish for real users, not the change you asked them to check. The readiness check flags this too, and the build page shows the runtime version and update channel read from the build.
When Expo Go is still fine
For your own developers, Expo Go is still a quick way to check a screen while you work, as long as your project only uses the native libraries it includes. It is also fine for a teammate who already has an Expo account. For anyone who should judge the real product, send the real build. If the EAS link is enough for your team, keep using it; the full comparison is on AppForShare vs Expo EAS.
More for EAS teams: how EAS internal distribution links work and registering testers' iPhones with eas device:create.
Common questions
Does a client need an Expo account to install an EAS internal build?
Not by default. Expo's docs say internal distribution build URLs are "available to anybody with the URL". A project owner can turn off unauthenticated access, and then an Expo login is required.
Does AppForShare replace Expo Go?
No. Expo Go runs your JavaScript inside its own app. AppForShare shares whole installable builds of your app made by EAS or any other build tool.
Can an Android client install without any account?
Yes, on either service. The client allows installs from the browser once and installs the APK. If your profile makes an .aab, upload it and AppForShare turns it into an installable APK.
Where is the full setup?
The Use AppForShare with Expo EAS guide covers profiles, webhooks, Workflows and devices. For builds you make on your own Mac, see eas build --local: share the .ipa and .apk.
Your clients should test your app, not someone else's. Create a free account, upload your next preview build and send them one link.
