There are several ways to distribute iOS apps to your team: for devices, you can use TestFlight, ad hoc provisioning, or enterprise provisioning, and for simulators you can share a direct link to the build that can be installed manually or through Orbit. EAS makes it easy to use all of these approaches, so you can do what works best for any particular build or process. When distributing to devices, most developers will use some combination of TestFlight and EAS internal distribution with ad hoc provisioning.
With ad hoc provisioning, only devices listed in the profile at build time can install the build. So you need to register your device with EAS (which handles registering it with Apple), regenerate the profile, and then rebuild the app. This process has been difficult to automate in the past because the only way to refresh the profile was for a developer to manually run eas build or eas credentials. In other words, there was no way to refresh an ad hoc profile with --non-interactive or in EAS Workflows, so automated internal builds could succeed, but they would not install on a newly enrolled device.
We've shipped three updates to close that gap in automation:
- Ad hoc provisioning profile refresh on the CLI:
--refresh-ad-hoc-provisioning-profileoneas buildupdates the ad hoc provisioning profile from Apple before a non-interactive build. - Ad hoc provisioning profile refresh in workflows:
refresh_ad_hoc_provisioning_profile: trueontype: buildjobs passes the same behavior through to the build worker. - Device registration in workflows: the
apple-device-registration-requestjob enrolls a physical device (QR code plus approval), then exposes its details to downstream jobs.
Together they support an automated loop: register and approve a device, refresh the profile so its UDID is included, then build an internal .ipa that installs on that device.
Refresh ad hoc provisioning profiles in CI
EAS CLI 19.1.0 added --refresh-ad-hoc-provisioning-profile. Use it with --non-interactive on an internal iOS build that uses EAS-managed credentials. Before gathering build credentials, EAS authenticates with your App Store Connect API key, reads devices registered on EAS for your Apple team, and creates or updates the ad hoc provisioning profile. The refreshed profile details are stored in EAS credentials and the build continues.
Learn more about automating internal distribution on CI.
Refresh profiles in EAS Workflows
Workflows type: build jobs accept refresh_ad_hoc_provisioning_profile: true in params, the workflow equivalent of the CLI flag. EAS validates the job (iOS platform, internal profile, remote credentials) and passes the setting through to the build worker, which refreshes the profile before the build starts.
Request device registration in a workflow
The apple-device-registration-request job pauses the workflow until a developer enrolls and approves their physical iOS device. This is useful for ensuring a device is registered before downstream jobs run.
When the job runs:
- The workflow run enters the "action required" state and shows a QR code in the dashboard.
- A team member scans the code or opens the link on their iPhone or iPad and installs the registration profile.
- A team member approves or rejects the enrollment on the workflow run page. (Enrollment alone does not advance the workflow; explicit approval is required for security.)
On approval, the job exposes outputs you can use downstream, including identifier (UDID), model, and software_version — useful in a downstream Slack job, for example. If your Expo account has multiple Apple teams, set apple_team_identifier in params; with exactly one team, it is optional.
End-to-end: register, approve, build
Together, device registration and profile refresh close the loop for internal iOS distribution in automation: enroll a device in the workflow, approve it, then build with profile refresh so the new UDID is on the provisioning profile.