fastlane deliver Upload to App Store: API Key or Apple ID? 2026

deliver handles App Store submission tasks, but your release lane may also call other fastlane actions. Those actions can have different authentication support. Confirm the exact action and the fastlane version used by your lane against the fastlane App Store Connect API support documentation and the deliver action reference.

Can fastlane deliver use an App Store Connect API Key? Yes, fastlane documents API Key authentication for supported App Store Connect work. That does not mean every action in your lane supports it. For example, privacy-related work has its own action and requirements; check the fastlane privacy-details documentation rather than inferring its behavior from a successful deliver run.

Treat your lane as a list of operations, not as one “upload” command. A lane can authenticate successfully, update metadata, then fail at a later step that uses a different action. Record which action performs each operation and which credential it receives. If a fastlane release lane changes, review the support documentation again before removing an existing Apple ID fallback.

Separate upload, processing, and review

A completed authentication step proves that a credential was accepted. It does not prove that the binary transferred successfully, that App Store Connect finished processing it, or that Apple approved the app.

Keep these states separate in logs and release checks:

• Authentication: fastlane obtained authorization for the action.
• Transfer: the upload tool finished sending the binary.
• Processing: the uploaded build appears in App Store Connect and reaches a usable state.
• Distribution or review: the build is available to the intended TestFlight group or the app has entered the relevant review process.

Apple documents build-upload requirements separately from API authorization. Check the Apple build-upload guide for role requirements and upload details. Transporter or another upload path is part of the transfer stage; it is not a substitute for checking the build record afterward.

Which fastlane upload steps may still need Apple ID? There is no safe blanket answer for every lane. Inspect the action that runs the step, its current authentication options, and any configured upload tool. If the action does not support API Key authentication for the operation you need, keep Apple ID credentials scoped to that step rather than treating the whole release pipeline as Apple ID-only.

An API Key is not a shortcut around App Store Connect roles. Its access depends on its key type and the permissions associated with it. Apple distinguishes Team Keys from Individual Keys and documents their creation and access rules in its API Key guide.

The key type does not guarantee that a particular fastlane action will work. You need both authorization and action support. A valid key can still lack a required role, and a sufficient role cannot make an unsupported API operation available.

For binary uploads, check the role required by Apple’s current upload guidance. Do not grant a broad role simply because it avoids investigating a permission error. First identify the failing action and the resource it needs to access. Then compare that requirement with the key’s assigned role and app scope.

What should you check when an API Key lacks permission? Confirm whether it is a Team Key or Individual Key; inspect its assigned role; verify that the relevant app is in scope; and check whether the action is supported with API authentication. Keep these checks distinct. A permission denial, an unsupported action, and an invalid credential can produce different failures.

An API Key workflow uses a private .p8 key together with its Key ID and, where required, the Issuer ID. The private key signs JWTs; the identifiers tell the client which key and issuer to use. Apple’s API Key creation guidance explains key creation and handling. Treat the .p8 file as a secret, not as ordinary project configuration.

Apple ID authentication has a different set of responsibilities. It can involve account credentials, interactive two-factor authentication, and—in certain supported upload workflows—an app-specific password. Those are not interchangeable credentials. fastlane’s authentication guide describes its authentication options and the app-specific password boundary. Do not assume an app-specific password replaces API authentication for metadata management or every other App Store Connect operation.

Use these controls whichever method you select:

• Keep .p8 files, passwords, and tokens out of source control.
• Store secrets in the CI secret store or an equivalently controlled credential location.
• Do not print private key material, passwords, JWTs, or full environment dumps in build logs.
• Limit which jobs and maintainers can access release secrets.
• Document who owns each credential and how access is removed when responsibilities change.
• Rotate or revoke credentials through the appropriate account controls when exposure is suspected.

A Team Key can simplify automation for a team, but its scope makes storage and access controls more important. An Individual Key may better reflect a user’s access boundary, but it also ties the automation to that user’s role and continued access. Choose based on the actual ownership and permission model—not on the assumption that one key type is automatically safer.

Automation works best when the job can authenticate without waiting for a person to approve a prompt. That makes API Key authentication a strong default for supported App Store Connect actions. Apple’s JWT model lets the client create a short-lived token from the private key; Apple sets a 20-minute maximum for the token lifetime (JWT request-token rules). Protect the signing key even though the token expires.

Apple ID workflows can be more dependent on session state or interactive verification. fastlane documents Apple ID authentication and app-specific passwords, but an app-specific password should not be treated as a universal replacement for an API Key. Check the action’s own requirements and test the exact non-interactive workflow you intend to run.

Before migrating credentials, use a staging or low-risk release lane. Run the same action with the candidate method and capture only non-secret diagnostics: action name, exit status, and the resulting App Store Connect state. If the lane prompts for authentication, determine whether the prompt comes from the action, the account session, or the upload tool. Do not silence the prompt by placing an Apple ID password in a script.

Use this checklist before changing a production release lane:

• [ ] List every action in the lane: build upload, metadata update, TestFlight distribution, and any privacy or submission tasks.
• [ ] Check the current fastlane support documentation for API Key support for each action, not just for deliver.
• [ ] Confirm whether each key is a Team Key or Individual Key, then verify its role and app access in App Store Connect.
• [ ] Store the .p8 file and identifiers in controlled secret storage; confirm they do not appear in the repository or job logs.
• [ ] Run a non-production or otherwise low-risk test that uses the same actions and authentication path as the intended release.
• [ ] Verify authentication, binary transfer, App Store Connect processing, and TestFlight or review status as separate outcomes.
• [ ] Record the credential owner, the lane that uses it, and the procedure for revoking access.

Which authentication method fits a remote Mac release workflow? Prefer an API Key for every supported action when you can store and expose the private key safely. Keep Apple ID authentication only for the specific operation that requires it. A remote host changes where you manage secrets and inspect logs; it does not change the action’s API support or the key’s permissions.

For remote Mac acceptance, test the workflow in the environment that will run the release. Confirm that the job can read its intended secret, invoke the exact fastlane action, and leave a build record you can inspect in App Store Connect. Do not count a green shell command as a complete release handoff. Check the binary and downstream status separately, and remove temporary credentials after the test if they were added only for validation.

If your current workflow relies on a developer’s interactive session, mixes credentials in a shared script, or gives every job broad access, fix those boundaries before increasing release frequency. A local Mac may be the simpler choice when you need a dedicated physical machine or predictable long-term use. If you need a remotely accessible macOS environment for release work, compare the workflow requirements with CALMVPS pricing and rental options and review the available Mac rental arrangements. Keep the decision tied to your lane: the host can provide a place to run fastlane, but it cannot make an unsupported action accept an API Key.