Which signing credentials does an EAS build need for Android and for iOS, and who holds them by default?
answer
- Android: one keystore, alias, two passwords
- iOS: certificate plus per-app profile
- certificate is account-wide
- credentialsSource defaults to remote
- EAS generates on first build
basics
~20 sAndroid builds are signed with a keystore (key alias and passwords); iOS builds need a distribution certificate plus an app-specific provisioning profile. By default credentialsSource is remote: EAS generates them on the first eas build and stores them encrypted on its servers.
solid answer
~50 sOn **Android**, EAS signs the APK or AAB with a **keystore**: a private key under a key alias, protected by a keystore password and a key password. With Play App Signing that key is the **upload key**, and Google re-signs the app with its own app signing key. On **iOS**, a device build needs a **distribution certificate**, which belongs to the Apple Developer account and can serve all its apps, and a **provisioning profile**, which is app-specific and binds the bundle identifier to that certificate (plus a device list for ad hoc). Push keys are managed alongside but do not sign builds. `credentialsSource` defaults to `"remote"`: on the first `eas build`, EAS CLI offers to generate what is missing (signing in to Apple for iOS), stores it encrypted on EAS servers, and reuses it for later builds and teammates. Simulator builds need none of this.
go deeper
Recall the pieces: a keystore on Android, a distribution certificate plus provisioning profile on iOS, and that EAS generates and stores them by default.
Explain scope and lifetime: the account-wide certificate, the app-specific profile that expires yearly, ad hoc device lists, and the upload key under Play App Signing.
Show you know which loss hurts: iOS certificates and profiles can be regenerated freely, while losing the Android key means a support-driven upload key reset at best and no more updates at worst.
Decide who in the organization owns the Apple team and the Play upload key, and whether EAS or an internal system is the custodian of record.
## Why builds are signed at all Both mobile platforms refuse to install or update an app that is not **code-signed**: the signature proves who produced the binary and that it was not altered. EAS Build can produce unsigned artifacts, for example iOS Simulator builds, but anything installed on a device or submitted to a store must be signed. EAS calls the files and secrets involved **credentials**. ## Android: the keystore An Android release is signed with a key stored in a **keystore** file. Four values describe it, the same four `credentials.json` uses: - `keystorePath`, the `.jks` or `.keystore` file; - `keystorePassword`, which unlocks the file; - `keyAlias`, which names the key inside it; - `keyPassword`, which unlocks that key. Google Play checks that every update is signed consistently with earlier releases. With **Play App Signing**, which is the default for new apps, the key EAS holds is the **upload key**: Google verifies the upload and re-signs the app with an app signing key it keeps itself. From EAS's point of view nothing changes: it signs with whatever keystore is associated with the application ID. ## iOS: certificate plus profile | Credential | Scope | Used for | Notes | |---|---|---|---| | Distribution certificate | the Apple Developer account, shared by all its apps | signing | a `.p12` with a password | | Provisioning profile | one bundle identifier | signing | ties the app ID to the certificate; ad hoc profiles also list device UDIDs; expires after 12 months | | Push notification key | the account | run time, not signing | managed from `eas credentials`, but a build does not need it to sign | A store build uses an App Store profile; an **internal** distribution build uses an ad hoc or enterprise profile, so only registered devices can install an ad hoc build. Each app extension target, such as a widget or share extension, has its own bundle identifier and so its own profile. ## Who holds them by default A build profile's `credentialsSource` decides where EAS Build gets credentials, and it defaults to **`"remote"`**: 1. On the first `eas build` for a platform, EAS CLI detects that nothing is configured and offers to set it up. 2. For Android it can generate a new keystore or accept one you provide. 3. For iOS it asks you to sign in with an Apple Developer Program account, then creates or reuses a distribution certificate and creates a provisioning profile. 4. The results are stored on EAS servers, encrypted at rest and with a key management service, and decrypted only in memory on the build workers. 5. Later builds reuse them, and teammates with the right project permissions can build iOS apps without access to the Apple team. The alternative, `credentialsSource: "local"`, reads everything from a git-ignored `credentials.json` for each build. ## What does not need credentials - A build profile with `ios.simulator: true` produces a Simulator build, which EAS does not sign. - `withoutCredentials: true` builds without signing, for example an Android debug build. - A development build installed on a physical device **does** need signing, typically ad hoc on iOS. ## Inspecting and managing them `eas credentials` (optionally `-p android` or `-p ios`) is the interactive manager: it shows what is configured, including keystore fingerprints, and lets you download, replace or delete credentials. Deleting there removes them from EAS only; Apple-side certificates and profiles must be revoked in the Apple Developer portal. ## A quick decision table | Build | Signing needed | What EAS uses | |---|---|---| | Android store build (AAB) | Yes | the upload keystore | | Android internal build (APK) | Yes | a keystore, reused if the application ID already has one | | iOS App Store build | Yes | distribution certificate plus App Store profile | | iOS internal build | Yes | distribution certificate plus ad hoc or enterprise profile | | iOS Simulator build | No | nothing | ## Common misconceptions - The iOS distribution certificate is not per app; a single certificate can sign every app of the team. - A provisioning profile expiring does not break the app already on the store; it only blocks new builds until a new profile is created. - Losing the Android upload key is recoverable through Google Play support when Play App Signing is on; without it, updates signed with a different key are rejected.
- Why can a teammate start an EAS iOS build without being a member of the Apple Developer team?With remote credentials, the distribution certificate and provisioning profile are already stored on EAS servers. A teammate with sufficient permissions on the Expo project can start a build that uses them; Apple access is only needed when credentials must be created or regenerated.
- Why does an EAS internal distribution build for iOS install only on some iPhones?Internal distribution on iOS uses ad hoc provisioning (or enterprise, with that program). An ad hoc profile lists the UDIDs of allowed devices, so only devices registered when the profile was generated can install it. Adding one means registering it and producing a new profile, by rebuilding or re-signing.
The iOS distribution certificate is your personal signature, valid on everything you sign; a provisioning profile is a per-app permit saying which signature may ship which app to which devices. The Android keystore is a wax seal pressed into every release: the store checks updates against it, so losing it means asking the store to register a new seal, or never updating the app again.
saying these in an interview costs you the question
- Each iOS app needs its own distribution certificate.
- An expired provisioning profile disables the app already on the App Store.
- The Apple push key is required to sign every iOS build.
- credentialsSource defaults to local, so a credentials.json is required.
- Simulator builds need a distribution certificate like device builds.