Learn how EAS manages iOS distribution certificates and provisioning profiles automatically, and how to configure or supply your own credentials for reliable signed builds.
Code signing is one of the most confusing parts of native iOS development. Apple requires every app to be signed with a valid distribution certificate and a matching provisioning profile.
Historically you managed these in Xcode and the Apple Developer portal, and mismatches produced cryptic errors.
Expo's biggest quality-of-life win here is that EAS can manage all of this for you. It generates, stores, and applies the right credentials automatically.
This guide explains both the automatic path, which most people should use, and the manual path for teams with existing credentials or stricter policies.
For an iOS build you fundamentally need two things. The first is a distribution certificate, which proves your identity as the publisher.
The second is a provisioning profile, which ties your certificate, your app's bundle identifier, and allowed devices together.
For App Store distribution the profile is an App Store type profile. For internal testing you may use ad hoc or development profiles instead.
EAS understands these distinctions. When you choose a build profile, EAS knows which type of credential it needs and can produce the right one.
The simplest approach is to let EAS handle everything. When you run eas build --platform ios for the first time, EAS detects that credentials are missing.
It then prompts you to sign in with your Apple ID. With your permission, EAS creates a distribution certificate and provisioning profile in your Apple Developer account.
These generated credentials are stored securely by Expo and reused for future builds. You do not have to touch Xcode at all.
For most developers, especially those without a Mac, this is the recommended path. It eliminates the most error-prone part of iOS release engineering.
You can review what EAS is holding by running eas credentials. This opens an interactive menu.
Select the iOS platform and you will see the distribution certificate and provisioning profile currently associated with your project.
This is useful for confirming that the right credentials exist before an important release. It also shows expiration information.
Certificates expire. Knowing where to look means you can renew or regenerate before an expired certificate blocks a build at an inconvenient time.
Some teams must use existing credentials, perhaps due to company policy or an established Apple account setup. EAS supports this too.
Through the eas credentials menu, you can upload your own distribution certificate and provisioning profile instead of letting EAS generate them.
You can also configure credentials via a credentials.json file for more explicit, version-controllable setups. This is common in CI-heavy workflows.
Choose this path only if you have a real need. For most projects the automatic route is simpler and less prone to human error.
If your app uses push notifications, you need an additional credential: an Apple Push Notifications key or certificate.
EAS can manage this as well. When your project requires push, EAS prompts to create and store the necessary key.
Keep push credentials in mind early if notifications are core to your app. Adding them later is fine, but it is one more Apple credential to track.
As with signing credentials, letting EAS manage the push key is usually the least painful option.
When EAS generates credentials for you, two things happen. The certificate and provisioning profile are registered in your Apple Developer account, and Expo keeps a synchronized copy on its servers so builds can use them.
This dual storage is why you do not have to re-supply credentials on every build. EAS retrieves what it needs from its secure store automatically.
It also means your Apple Developer account remains the source of truth. If you revoke a certificate in Apple's portal, EAS will need to generate or fetch a valid one again.
Knowing this helps when something looks out of sync. If a build uses an unexpected credential, comparing what EAS holds against what exists in your Apple account usually explains the discrepancy.
For most developers this stays invisible. But when you troubleshoot, understanding the two locations makes the behavior predictable rather than mysterious.
Credentials get more nuanced once more than one person builds the same app. If several developers each let EAS generate their own certificate, you can end up with multiple certificates, which Apple limits in number.
The cleaner approach for teams is to centralize credentials. Store them in Expo's shared project credentials so everyone builds against the same certificate and profile.
For continuous integration, a credentials.json file combined with an App Store Connect API key gives you a repeatable, non-interactive setup. CI machines cannot answer interactive prompts, so this matters.
Decide on a credential strategy early if you expect a team. Retrofitting one after certificates have proliferated is more work than setting it up cleanly from the start.
Expo's shared access model is designed for exactly this. Team members with the right role can build without each generating conflicting credentials.
Apple certificates do not last forever, so plan for renewal. A distribution certificate has a limited validity period, after which builds that rely on it will fail.
The good news is that renewal through EAS is straightforward. Running eas credentials lets you inspect expiration and regenerate a certificate when the time comes.
Rotating credentials is also sometimes necessary for security reasons, such as when someone leaves a team or a key may have been exposed. EAS lets you replace the affected credential and rebuild.
Provisioning profiles are tied to your certificate and app, so regenerating a certificate often means refreshing the profile too. EAS handles this coordination for you in the automatic flow.
Build renewal into your release calendar rather than discovering an expired certificate mid-launch. A few minutes of proactive checking avoids a stressful, deadline-day failure.
If a build fails on credentials, the most common cause is an expired certificate or a bundle identifier mismatch. Run eas credentials to inspect and regenerate.
Another frequent issue is Apple two-factor authentication interrupting automated flows. Using an App Store Connect API key smooths this out for CI.
Remember the broader context. EAS is managing native Apple credentials for a React Native app, not a native Swift project, but the signing requirements are identical to any iOS app.
Finally, you still need an active Apple Developer Program membership. No amount of tooling removes that requirement, because Apple itself issues the certificates.
No. EAS can automatically generate, store, and reuse your distribution certificate and provisioning profile. This is the recommended approach for most developers, especially those without a Mac.
Run eas credentials in your project, select the iOS platform, and you will see the certificate and provisioning profile associated with your project, including expiration information.
Yes. Through the eas credentials menu or a credentials.json file you can supply your own distribution certificate and provisioning profile instead of letting EAS generate them.
An expired certificate will block new builds. Use eas credentials to inspect expiration and regenerate or renew the certificate before it lapses.
Yes. Apple issues the certificates, so an active Apple Developer Program membership is required regardless of whether EAS manages the credentials for you.