Quick answer
The lowest-friction way to share an unreleased app build with a non-developer stakeholder is a link that opens the app in a browser-hosted simulator. The alternatives ask more of the recipient: an installable internal build, TestFlight or Google Play internal testing (which need store accounts and device setup), or a preview update for reviewers who already have a development build installed.
Why is sharing a mobile build with stakeholders so hard?
"Can I see the new onboarding on my iPad before the board call?" The CEO's Slack message lands at 1:40, and she means today, between meetings. She does not have TestFlight installed, she does not know her device UDID, and she is not going to accept an invitation email that asks her to install a second app first.
Every mobile team hits this. The build works, the reviewer is willing, and the last mile is a set of Apple and Google gates designed for beta testers, not for a stakeholder who has ten minutes. The options below are ranked by what they ask of the recipient, because that is the variable you do not control.
What are the ways to share an unreleased app build?
From least to most asked of the person receiving the build:
- A browser link. The app runs in a hosted simulator. The recipient needs a browser and nothing else.
- An installable internal build. A URL that installs the app directly on a phone. On Android this is an APK link. On iOS it needs the device registered in advance.
- A store testing track. TestFlight on iOS, internal or closed testing on Google Play. The recipient installs the TestFlight app or joins a Play tester list, then installs through the store.
- A preview update. For reviewers who already have a development build installed, you publish new JavaScript and they open it from a QR code or a list inside the app. Zero friction the second time, but a build install the first time.
The right choice depends on who the recipient is and how often they will review. A one-off executive demo wants option 1. A QA contractor who reviews every week wants option 4 after a one-time setup with option 2 or 3.
Option 1: Send a shareable simulator link
A hosted simulator service runs an iOS Simulator or Android emulator on a server, installs your build, and streams the screen to a browser tab. The reviewer taps and scrolls in the tab. No install, no store account, no device registration.
A simulator link is good for layout, copy, navigation and the shape of a flow. It is no use for the camera, push notifications, biometrics or real touch latency. A simulator is not a phone.
Simulator links are the newest of the four options and the least standardized. Any CI service with macOS runners can produce the simulator build; fewer services can host and stream it. The Expo section below covers what Expo's version does and does not do today.
Option 2: Send an installable internal build
Skip the stores. Build a binary, host it at a URL, and let the reviewer install it directly.
Android. Build an APK (not an AAB, which only the Play Store can install). Anyone with the link can install it after accepting the system warning about apps from outside the store, as Expo's internal distribution guide describes.
iOS. Apple allows this through ad hoc provisioning: the build is signed with a profile that lists specific device UDIDs, and only those devices can install it. Apple sets the limits. You need a paid Apple Developer Program membership at $99 per year, you can register at most 100 iPhones per account per year, and you rebuild or re-sign each time you add a device, per the internal distribution docs.
Getting a non-developer's UDID is the awkward step; EAS handles it with a registration link the reviewer opens on their phone. Enterprise distribution removes the device limit but requires the Apple Developer Enterprise Program, which has extra eligibility requirements.
An internal build reaches the reviewer as soon as it finishes. Expo's guide to distributing apps for review puts it this way: "no need to fill out any forms or wait for approval/processing".
Option 3: Use TestFlight or a Google Play testing track
TestFlight and Play testing tracks are the store-native routes. Both need a store-signed release build, so the review overview notes they are only for release-style builds, not development builds.
TestFlight (iOS)
| Internal testing | External testing | |
|---|---|---|
| Who | Members of your App Store Connect team | Anyone; no App Store Connect account needed |
| Maximum testers | 100 | 10,000 per app |
| Beta App Review | Not required | Required on the first build of every app version |
| Invite | Email, CSV import, or a public link | |
| Time to reach testers | After Apple processing, usually 5 to 10 minutes | After Beta App Review approves |
| Build expiry | 90 days | 90 days |
Source: Expo TestFlight guide, Apple TestFlight overview.
For a stakeholder, the catch is internal testing: they must be added to your App Store Connect team, which means an Apple account and a role. External testing avoids that but adds Beta App Review to the first build. Either way the reviewer installs the TestFlight app first.
Google Play testing tracks (Android)
Google's internal testing track takes up to 100 testers per app and a build "becomes available to testers within minutes". Internal test builds "might not be subject to standard Play policy or security reviews". Closed testing scales to 200 lists of up to 2,000 users each, and open testing has no cap by default, but both are subject to Play's standard reviews, according to Google Play Help. The reviewer needs a Google account on the tester list, and installs from the Play Store.
Option 4: Publish a preview update for reviewers who already have the app
If the reviewer has installed a development build once, every later change can reach them without another install. You publish an update to the JavaScript bundle, and they open it from a QR code, a dashboard link, or a list inside the app. Native code does not change; the store binary is untouched. For iOS this stays inside the bounds of App Store Review Guideline 2.5.2, because only interpreted JavaScript is replaced and nothing bypasses review.
The first-time cost is the build install (option 2 or 3). After that, the review overview describes the turnaround as "seconds to share a new version of your app with your team". Preview updates suit repeat reviewers: a designer checking spacing every day, a QA contractor, an agency client who wants weekly check-ins.
Which sharing option fits which reviewer?
| Option | Recipient needs | You need | Time to recipient | Limits | Best for |
|---|---|---|---|---|---|
| Browser simulator link | A browser | A simulator build and a hosted simulator | Build time, then session start | Simulator only: no camera, push, biometrics | One-off demos; reviewers who install nothing |
| Internal build (Android APK) | To accept the "unknown source" warning | An APK build hosted at a URL | As soon as the build finishes | Android only | Fast, no store involvement |
| Internal build (iOS ad hoc) | To register their device once | Apple Developer account ($99 per year); UDID per device | Build time; 24 to 72 hours for new devices on new memberships | 100 iPhones per account per year; rebuild or re-sign per new device | Real device, no TestFlight |
| TestFlight internal | The TestFlight app; an App Store Connect team seat | Apple Developer account; store-signed build | Processing, usually 5 to 10 minutes | 100 testers; builds expire in 90 days | Teams already in App Store Connect |
| TestFlight external | The TestFlight app; an email or public link | Beta App Review on first build per version | After review | 10,000 testers per app | Wide beta groups |
| Play internal testing | A Google account on the tester list | A signed AAB in Play Console | Within minutes | 100 testers per app | Android beta with store install |
| Preview update | A development build already installed | EAS Update or equivalent configured | Seconds after publish | JavaScript changes only | Repeat reviewers |
Sources: Expo internal distribution, Expo TestFlight guide, Google Play Help, Expo review overview, Apple.
Where Expo fits
Expo has a product for each of the four options. All of them need a React Native app configured for EAS.
Browser link: Expo Simulators. Expo Simulators boots an iOS or Android simulator on Expo's infrastructure, installs a build, and streams it to a browser. The EAS CLI starts a session with eas sim:start --platform ios|android, takes an EAS Build with --build-id, and prints a web preview URL for iOS sessions.
Expo's eas-simulator skill documentation lists the builds a session can install: local release builds (.app for iOS, .apk for Android), EAS Build artifacts, and local development builds paired with a tunnel. Expo Simulators is in early access with a waitlist, and the CLI commands are marked experimental.
Installable build: internal distribution. Set "distribution": "internal" on a build profile in eas.json:
EAS Build produces an APK on Android and an ad hoc signed app on iOS, hosted at a URL identified by a 32-character UUID. By default anyone with the URL can install; the internal distribution guide shows how to require sign-in to an authorized Expo account in project settings. The eas device:create command gives you a link or QR code the reviewer opens on their iPhone to register the UDID.
Store tracks: EAS Submit. With EAS Submit, eas submit --platform ios uploads a store build to App Store Connect for TestFlight, and eas submit --platform android places an AAB on the Play track you choose. In EAS Workflows the testflight job from the pre-packaged jobs adds a build to internal and external groups, sets the "What to Test" notes, and can submit for Beta App Review.
Preview updates: EAS Update. Publish the current branch as a preview:
The CLI prints an EAS dashboard link. The reviewer opens it, clicks Preview, and scans a QR code to open the update in their installed development build. Inside the development build, the Extensions tab lists published updates by branch after the reviewer signs in, as the guide to previewing in development builds shows.
On a desktop, Expo Orbit for macOS, Windows and Linux launches an update on an Android emulator or iOS Simulator from the dashboard. The Orbit docs note that launching updates through Orbit is not supported on physical iOS devices.
To make this automatic, one workflow from the publish preview updates example publishes a preview on every commit to every branch:
Expo's own setup goes one step further and posts a comment on each pull request with links to compatible builds and a QR code for the update, so designers and product managers open the feature from the PR.
Limitations
Expo Simulators is early access with a waitlist and experimental CLI commands, and not every account has it. Sessions install the build types listed above. Public sharing of a simulator session link is not documented yet. Internal distribution on iOS inherits Apple's ad hoc limits.
Preview updates need a development build with expo-updates installed and only carry JavaScript changes; a native change needs a new build. Expo Go is not a review tool: the review overview calls it "a playground for students and learners" and "not useful for the review process of your app". On pricing, the EAS Free plan includes up to 15 Android and 15 iOS builds; EAS Update and simulator usage follow the pricing page.
Build sharing limits at a glance
| Fact | Value | Source |
|---|---|---|
| TestFlight internal testers | 100 | Expo TestFlight guide |
| TestFlight external testers | 10,000 per app | Apple |
| TestFlight build expiry | 90 days | Apple |
| Play internal testing | 100 testers; available within minutes | |
| Play closed testing | 200 lists of up to 2,000 users | |
| Ad hoc devices | 100 iPhones per account per year | Expo internal distribution |
| New device processing (new Apple memberships) | Up to 24 to 72 hours | Expo internal distribution |
| Apple Developer Program | $99 per year | Apple |
Next step
Decide whether your reviewer is one-off or repeat. For a one-off reviewer, produce a simulator build with ios.simulator: true and open it in a hosted simulator, or send a link from the internal distribution guide setup. For a repeat reviewer, install one development build, then run eas update --auto --environment preview for every change.
Verified on 12 September 2026.