Troubleshoot Codemagic uploads that fail to reach TestFlight or the App Store — API key problems, missing app records, wrong export options, and invalid binary rejections.
This failure is especially frustrating because the build compiled and signed successfully; only the final publishing step fails, so a green pipeline stops just short of delivering to testers. In the Codemagic log you see the upload phase error out with messages that vary by cause: authentication failures reaching App Store Connect, 'no suitable application record found', 'invalid binary', 'the bundle is invalid', 'missing compliance', or 'redundant binary upload' for a duplicate build number. Sometimes the upload appears to succeed in Codemagic but the build never shows in TestFlight, and you receive a rejection email from App Store Connect minutes later, because Apple performs additional validation server-side after the transfer completes. Because publishing is the last step, the fix almost always lives in your App Store Connect setup or export configuration rather than in your build or signing logic. As with all cloud CI issues, read the specific error before retrying, since each attempt consumes build minutes and, if the binary is genuinely invalid, will fail identically until you change something. Identify which of the common categories your error falls into first, because the remedies are quite different and time spent guessing is time and build minutes wasted.
Uploads to TestFlight and the App Store authenticate with your App Store Connect API key, so the first thing to check on an authentication failure is that key. Verify all three components stored in Codemagic are correct and current: the Key ID, the Issuer ID, and the .p8 private key file. A frequent mistake is a corrupted or re-formatted .p8, so re-upload the original file downloaded from App Store Connect. Confirm the key has not been revoked; if someone regenerated or deleted it, the stored credentials are dead and you must create a fresh key and update Codemagic. Also confirm the key's role provides enough access to manage builds — App Manager is commonly sufficient for uploading. A key with insufficient permissions may authenticate but then be refused when it tries to create or upload a build, producing a permissions error rather than an authentication one. If you rotated keys recently for security, make sure every workflow references the new integration and no stale variable still points at the old key. Getting authentication solid is a prerequisite for every other upload fix. If your Apple team enforces particular roles for compliance reasons, coordinate with whoever administers App Store Connect so the key carries exactly the access your pipeline needs and no more.
App Store Connect will only accept a build for an app that already exists in your account, matched by bundle identifier. If you have not created the app record, or the record's bundle identifier does not exactly match the identifier your build signed with, the upload fails with an error about no suitable application record being found. Fix this by logging in to App Store Connect, going to My Apps, and confirming an app exists whose bundle identifier is identical to your build's. If it does not exist, create it — you will register the bundle identifier, a name, the primary language, and an SKU. If the record exists but the identifier differs, the mismatch is the problem: either you are signing with the wrong identifier or the record was created for a different one. Reconcile them so the signed binary's bundle identifier and the App Store Connect record agree precisely. Remember that creating the App ID in the developer portal is separate from creating the app record in App Store Connect; you need both, and both must reference the same bundle identifier for the upload to find its target. If you maintain separate identifiers for staging and production, double-check that the workflow uploading to a given app record is signing with that record's exact identifier and not its sibling.
TestFlight and the App Store require a binary exported for App Store distribution. If your build exported with a development or ad hoc method, or with export options that do not match App Store requirements, the upload is rejected as an invalid binary or refused outright. In Codemagic, ensure your iOS signing distribution type is set to app_store, which drives the correct export options so the .ipa carries a distribution provisioning profile and is packaged for the store. Confirm you are archiving a release configuration rather than debug, since App Store distribution expects an optimized release build. Watch for architecture and packaging issues too; Apple's requirements about supported architectures and packaging evolve, and an outdated export configuration can produce a binary the store rejects. If you customized export options with a plist, review it against current App Store distribution requirements. The simplest reliable path is to let the app_store distribution type manage export options rather than hand-crafting them, which reduces the chance of a subtle mismatch that only reveals itself when Apple validates the uploaded binary after transfer. If you previously relied on bitcode, note that Apple has deprecated it, so an export configuration carried over from an older project may need updating to match current expectations.
Apple requires each uploaded build to have a unique build number within a given marketing version. If you upload a build number that already exists for that version, App Store Connect rejects it, often with a message about a redundant or duplicate binary. This bites CI pipelines because Xcode projects frequently carry a static build number, so every automated upload would collide with the previous one. The fix is to set the build number automatically during the build so each upload is unique and monotonically increasing. You can derive it from the Codemagic build index, from a timestamp, or by querying the latest build number already on App Store Connect and incrementing it; Codemagic's CLI tools can fetch that latest number for you. Add a script step early in the workflow that writes the computed value into your Info.plist, or use agvtool to set it, before archiving. Also make sure the marketing version string is what you intend, since build numbers only need to be unique within a version — a new marketing version resets the space of valid build numbers. Automating this eliminates a whole category of recurring upload rejections. A timestamp-based build number is simple and always increasing, but querying App Store Connect for the latest and adding one keeps the numbers compact and human-readable, which many teams prefer for changelogs.
An 'invalid binary' rejection covers a range of validation problems Apple checks after upload. Common triggers include a missing or improperly formatted app icon, an unsupported or missing required device capability, an Info.plist missing required keys, use of private APIs, or an absent export compliance declaration for encryption. The encryption compliance point catches many teams: Apple requires you to declare whether your app uses encryption, and without the ITSAppUsesNonExemptEncryption key in your Info.plist or an answer supplied to App Store Connect, processing can stall or the build can be held. Fix invalid binary errors by reading the specific validation message, which usually names the offending item, then correcting it in your project — add the missing icon asset, set the required Info.plist keys, or declare encryption compliance. Some of these errors only appear in a rejection email from App Store Connect after the transfer, not in the Codemagic log, so check the email associated with your Apple account. Address the named issue in your source or configuration and re-run; because the binary itself is at fault, retrying without changes will reproduce the identical rejection. A frequently missed detail is a complete app icon set: a single absent icon size in the asset catalog can trigger an invalid binary rejection even though the app runs fine in development.
When an upload fails, investigate in order of likelihood to minimize wasted build minutes. Begin by reading the exact error and, if the Codemagic log shows the upload succeeding, check your Apple account email for a post-transfer rejection. First rule out the API key: correct Key ID, Issuer ID, and .p8, not revoked, with App Manager access. Second, confirm the app record exists in App Store Connect with a bundle identifier that exactly matches your signed binary. Third, verify the export used the app_store distribution type and a release configuration. Fourth, ensure the build number is unique and incrementing within the marketing version. Fifth, for invalid binary errors, address the specific validation item — icon, Info.plist keys, or encryption compliance. Working this sequence resolves the overwhelming majority of Codemagic publishing failures. Once fixed, re-run and confirm the build appears in the TestFlight tab of App Store Connect, initially processing and then ready for testers. Because publishing sits at the end of the pipeline, a correct fix here rarely disturbs your earlier build and signing steps, so you can iterate on the upload configuration in isolation. Keeping a short internal runbook of the specific errors your project has hit and how each was resolved turns a future incident into a lookup rather than a fresh investigation.
Apple performs additional validation after the transfer completes. If that server-side check fails, the build is rejected even though Codemagic reported a successful upload. Check the email on your Apple account for a rejection notice describing the specific problem.
App Store Connect only accepts builds for an existing app matched by bundle identifier. Create the app under My Apps with a bundle identifier identical to your signed binary, or reconcile the mismatch if the record exists under a different identifier.
Each build number must be unique within a marketing version. A static build number in your Xcode project collides on every automated upload. Set the build number automatically from the build index, a timestamp, or the latest App Store Connect build number plus one.
A range of validation issues: missing or malformed app icon, missing required Info.plist keys, unsupported architecture, private API usage, or an absent encryption compliance declaration. Read the specific validation message, fix the named item in your project, and re-upload.
Apple requires you to declare whether your app uses non-exempt encryption. Without the ITSAppUsesNonExemptEncryption key in your Info.plist, or an answer in App Store Connect, processing can stall or hold the build. Add the key with the correct value for your app.
app_store. TestFlight and the App Store require a binary exported for App Store distribution with a distribution provisioning profile. Setting the Codemagic signing distribution type to app_store produces the correct export options automatically.