Edit this page
Learn how EAS Build provides shareable URLs for your builds with your team for internal distribution.
Uploading your app to TestFlight and Google Play beta can be time-consuming (for example, waiting for the build to run through static analysis before becoming available to testers) and limiting (for example, TestFlight can only have one active build at a time). Both Android and iOS provide alternative mechanisms to distribute apps directly to testers, so they can download and install them to physical devices directly from a web browser as soon as the builds are completed.
EAS Build can help you with this by providing shareable URLs for your builds with instructions on how to get them running, so you can share a single URL with a teammate that'll include all the information they need to test the app.
Installing an app on iOS is a bit trickier than on Android, but it's possible thanks to ad hoc and enterprise provisioning profiles. We'll talk more about this later in this doc.
Both Android and iOS offer ways to install a build of your app directly on a device. This gives you full control of putting specific builds on devices, allowing you to iterate quickly and have multiple builds of your app available for review at the same time.
This section provides an overview of mechanisms for internal distribution on both platforms.
To share your app to Android devices, you must build an APK (Android application package file) of your project. APKs can be installed directly to an Android device over USB, by downloading the file over the web or through an email or chat app, once the user accepts the security warning for installing an app that has not gone through Play Store review. AAB (Android app bundle) binaries of your app must be distributed through the Play Store.
Apple offers ad hoc provisioning profiles to distribute your app to test devices once they have been registered to your Apple Developer account. This method requires a paid Apple Developer account and that account will only be able to use this method to distribute to at most 100 iPhones per year.
You will need to know the UDID (Unique Device Identifier) of each device that will install your app, which may be challenging if you try to share with someone who is not a developer. Adding a new device will require a rebuild of your app.
Setting up Ad Hoc certificates correctly can be intimidating if you haven't done it before and tedious even if you have. If you're using EAS Build, which is optimized for Expo and React Native projects, we'll handle the time-consuming parts of setting up Ad Hoc credentials for you.
If your app is only intended for internal use by employees of a large organization and cannot be distributed through the App Store, you should use Enterprise distribution. Unlike with Ad Hoc Distribution, the number of devices that can install your app is unlimited, and you do not need to manage each device's UDID. Often these apps will be distributed to end users through a mobile device management (MDM) solution. Enterprise Distribution requires membership in the Apple Developer Enterprise Program. Organizations joining the Enterprise Program must meet additional requirements beyond what is required for App Store distribution.
Before a complete public release, Google Play beta is another option to distribute your app to testers. You can set up either an internal, closed, or open test track and control who has access to the app.
Each test track has its own requirements. For the internal track, you can only invite up to 100 testers. Both closed and open tracks support larger groups of testers. In closed tracks, you need to invite testers, while in open tracks, anyone can join your program.
To use Google Play beta, you need to upload your app as an AAB (Android App Bundle) to the Google Play Console, set up a test track, and invite users via email or a shareable link. Testers can install the app through the Play Store, and you can collect feedback and crash reports directly from the Google Play Console.
TestFlight is another option to distribute your app to iOS devices. TestFlight also requires a paid Apple Developer account. TestFlight's internal testing option allows you to create test groups that include up to 100 members of your Apple Developer account team, who then download the app through the TestFlight app. Some teams prefer TestFlight because it doesn't require a new build to add new testers, and apps stay updated automatically.
TestFlight also includes an external testing option that allows you to share your app with up to 10,000 users via an email or a public link.
Both internal and external test distribution in TestFlight require you to upload your app to App Store Connect and wait for the automated review before you can share a build. However, external test builds will need to go through a more formal App Store review (which is distinct from the review that your app must undergo before production release) before being distributed.
Setting up an internal distribution build only takes a few minutes with EAS Build and provides a streamlined way to share your app with your team and testers for feedback.
The setup requires setting "distribution": "internal" to the desired build profile in your eas.json file. This configuration automatically generates .apk files for Android and .ipa files for iOS so that they can be installed on devices directly and do not require a development server to run the app.
For Android, EAS Build will generate a new Android keystore for signing the APK, or it will use an existing one if the package name is the same as your development build. For iOS, EAS Build will generate an ad hoc provisioning profile that explicitly allows devices to run that app based on that device's UDID. This can be done using eas device:create when creating a new build.
See the tutorial on Internal distribution with EAS Build below for more information on how to configure, create, and install a build:
Complete step-by-step guide to setting up and sharing internal distribution builds with EAS Build.
It's possible to run internal distribution builds non-interactively in CI using the --non-interactive flag. However, if you are using ad hoc provisioning on iOS you will not be able to add new devices to your provisioning profile when using this flag. After registering a device through eas device:create, you need to run eas build interactively and authenticate with Apple in order for EAS to add the device to your provisioning profile. Learn more about triggering builds from CI.
You can see any devices registered via eas device:create by running:
# List devices registered for ad hoc provisioning- eas device:listDevices registered with Expo for ad hoc provisioning will appear on your Apple Developer Portal after they are used to generate a provisioning profile for a new internal build with EAS Build or to resign an existing build with eas build:resign.
If a device is no longer in use, it can be removed from this list by running:
# Delete devices from your Expo account, optionally disable them on the Apple Developer Portal- eas device:deleteThis command will also prompt you to disable the device on the Apple Developer Portal. Disabled devices still count against Apple's limit of 100 devices for ad hoc distribution per app.
Devices added via the website URL/QR code will default to displaying their UDID when selecting them for an EAS Build. You can assign friendly names to your devices with the following command:
# Rename devices on Expo and the Apple Developer Portal- eas device:rename