Diagnose and fix Bitrise Deploy to App Store Connect failures — API key permission problems, bundle ID and app record mismatches, and invalid binary rejections — with concrete checks in order of likelihood.
The Deploy to App Store Connect Step runs late in your pipeline, after a signed .ipa already exists, so a failure here is distinct from build or signing problems — the app compiled and signed, but Apple would not accept the upload. The log for this Step is the single most useful diagnostic, because Apple returns specific error text that names the reason: an authentication failure with the API key, a bundle identifier that matches no app record, an export compliance or encryption issue, or an "invalid binary" verdict with a detailed cause. Before changing configuration, read that log carefully and identify which category the failure falls into, since the fixes are quite different. It also helps to distinguish between an upload that never started, which points at authentication or connectivity, and one that uploaded but was then rejected during Apple's validation, which points at the binary itself. Because Apple performs some checks asynchronously after upload, watch for follow-up emails to your App Store Connect account describing a build that was accepted for processing but then invalidated, since those explain failures that do not appear in the Bitrise log at all.
The most common upload failure is an authentication or permission problem with the App Store Connect API key. The Step needs three correct values — Issuer ID, Key ID, and the .p8 private key — and if any is wrong, misconfigured, or references a revoked key, authentication fails before the upload begins. Confirm the Issuer ID matches the one shown at the top of the Keys area in App Store Connect, that the Key ID corresponds to an active, non-revoked key, and that the .p8 content stored in Bitrise is the exact file Apple issued, with no truncation or extra whitespace. Permissions matter as much as validity: the key's assigned role must be able to upload builds. A key with a limited role such as a read-only or customer-support role cannot deliver a build, whereas App Manager or Admin can. If the key was created with too narrow a role, generate a new key with an appropriate role, download its .p8 once, and update the Bitrise connection. Revoking and recreating a key is also the fix if you suspect the stored private key was corrupted or partially copied.
Bitrise uploads to an existing app record in App Store Connect; it does not create one. If no app record exists for your binary's bundle identifier, or if the bundle identifier in the build does not exactly match an existing record, the upload is rejected. Verify that an app with your exact bundle identifier — case-sensitive and including any suffix — has been created in App Store Connect under My Apps, and that the identifier is registered in the Certificates, Identifiers and Profiles section of the developer portal. A mismatch often appears when a build is signed for one identifier but the record was created for another, or when a target's bundle identifier was changed without updating App Store Connect. Also confirm the binary's identifier matches the provisioning profile used to sign it, since an App Store profile is tied to a specific App ID. If the app record genuinely does not exist yet, create it in App Store Connect with the correct name, primary language, and bundle identifier before re-running the deploy. This is a one-time setup that Bitrise cannot perform on your behalf.
An "invalid binary" rejection means the upload reached Apple but failed validation. There are many specific triggers, and the log or the follow-up email names the exact one, so read it precisely. Frequent causes include a duplicate version and build-number combination that already exists in App Store Connect, which Apple refuses; a missing or incorrect export-compliance declaration for encryption; an unsupported or missing app icon or asset catalog entry; an invalid Info.plist value; use of a private or deprecated API; or a build made with an Xcode or SDK version that Apple no longer accepts for submission. The fixes map directly to the cause: increment the build number so each upload is unique, ideally automatically from the Bitrise build number; set ITSAppUsesNonExemptEncryption correctly in your Info.plist to satisfy export compliance without a manual prompt; ensure required icons and assets are present and correctly named; and keep your build Xcode within the version range App Store Connect currently accepts. Because Apple periodically raises the minimum SDK it will accept, a binary that uploaded fine months ago can start being rejected purely for being built with an SDK that is now too old.
This cause is common enough to treat on its own. App Store Connect uniquely identifies each build by the combination of its marketing version, such as 1.4.0, and its build number, such as 12. If you upload a build whose version and build-number pair already exists, Apple rejects it, and the message can be confusing because the binary itself is otherwise valid. In an automated pipeline this happens easily when the build number is hardcoded or not incremented between runs. The reliable fix is to make the build number unique on every deploy, most commonly by setting it from the monotonically increasing Bitrise build number using a Step that updates the Info.plist or the project's CURRENT_PROJECT_VERSION before the archive Step. That way each Bitrise run produces a distinct build number automatically, and you never collide with a previously uploaded build. If you manage versioning manually, ensure your process bumps the build number before every release upload, and remember that even builds you deleted or expired in App Store Connect can still reserve their version-and-build combination, so reusing an old number is not safe.
Not every problem is a hard failure in the Bitrise log; some are delays or pauses on Apple's side that look like a failure to a team expecting an instant TestFlight build. After a successful upload, Apple processes the binary asynchronously, and processing can take minutes to considerably longer during peak periods. If a build seems missing, it may simply still be processing. A more actionable pause is export compliance: if your app does not declare its encryption status via ITSAppUsesNonExemptEncryption in the Info.plist, App Store Connect holds the build and asks a human to answer the encryption question, which stalls automated delivery. Setting that key correctly lets processing complete without intervention. Similarly, the first build sent to a new external tester group waits on Apple's Beta App Review, which is outside Bitrise's control and not a pipeline defect. When diagnosing, check the App Store Connect Activity or TestFlight tab and your account email for messages about compliance or invalidation. Distinguishing an Apple-side delay or manual gate from an actual upload failure prevents you from changing a correct Bitrise configuration in pursuit of a problem that lives on Apple's side.
Approach deploy failures in a consistent order. First, read the deploy Step log and any App Store Connect email to categorize the failure as authentication, record mismatch, or invalid binary. Second, if authentication, verify the API key's Issuer ID, Key ID, and .p8 content and confirm its role can upload builds, recreating the key if in doubt. Third, if the identifier is rejected, confirm an app record with the exact bundle identifier exists in App Store Connect and matches the signing profile. Fourth, if the binary is invalid, read the specific reason and fix it — most often a duplicate build number, missing export-compliance key, or an outdated SDK. Fifth, if nothing is actually failing, confirm whether the build is simply processing or paused on compliance or Beta App Review. Underlying all of this is an honest boundary worth restating: Bitrise hands a signed binary to Apple, but Apple's App Store Connect owns the app record, the validation rules, the processing, and the review. An active Apple Developer Program membership and correctly configured App Store Connect assets are prerequisites Bitrise cannot substitute for, and most deploy failures trace back to one of those Apple-side details rather than to the pipeline itself.
Authentication fails when the Issuer ID, Key ID, or .p8 private key is wrong, truncated, or references a revoked key, or when the key's role lacks upload permission. Confirm all three values match what App Store Connect shows, ensure the stored .p8 content is exact with no extra whitespace, and verify the key's role — such as App Manager or Admin — can deliver builds. Recreate the key if you suspect corruption.
Bitrise uploads to an existing app record and cannot create one. If no app in App Store Connect has your binary's exact, case-sensitive bundle identifier, or if the record uses a different identifier, the upload fails. Create the app record with the correct bundle identifier under My Apps, register the identifier in the developer portal, and ensure it matches the provisioning profile used to sign the build.
It means Apple received the upload but rejected it during validation. Read the specific reason in the log or the follow-up email — common causes are a duplicate version and build-number combination, a missing export-compliance declaration, missing required icons or assets, an invalid Info.plist value, use of a private API, or a build made with an SDK Apple no longer accepts. Fix the named cause directly.
App Store Connect rejects a build whose marketing version and build-number pair already exists, even for deleted builds. Make the build number unique on every deploy, typically by setting it from the incrementing Bitrise build number with a Step that updates the Info.plist or project version before archiving. That guarantees each run produces a distinct build number and avoids collisions with prior uploads.
After a successful upload, Apple processes the binary asynchronously, which can take a while. The build may still be processing. It can also be paused for missing export-compliance if you have not set ITSAppUsesNonExemptEncryption in the Info.plist, or, for external testers, waiting on Apple's Beta App Review. Check the TestFlight tab and your account email; these are Apple-side gates, not Bitrise failures.