A diagnostic guide to Bitrise iOS code signing failures — missing or expired certificates, mismatched provisioning profiles, and the wrong export method — with concrete checks and fixes in order of likelihood.
A code signing failure on Bitrise usually surfaces during the Xcode Archive & Export for iOS Step, and the build log will contain phrases like "Code signing is required for product type", "No signing certificate found", "No profiles for '<bundle id>' were found", or "No matching provisioning profiles found". Sometimes the failure appears earlier, in the Certificate and profile installer Step, if the assets themselves cannot be imported. The key insight for every one of these is that Bitrise builds on a fresh, ephemeral macOS machine that starts with none of your signing material, so anything that works on your own Mac purely because of what is already in your Keychain will fail in CI unless you supply it explicitly. Before changing anything, open the failing Step and read the full log around the error, because Xcode's signing messages are unusually specific: they name the bundle identifier it looked for, the profile type it needed, and often the certificate it could not find. That message tells you which of the causes below applies, so resist the urge to randomly re-upload files before you have read what Xcode actually reported.
The most fundamental cause is that the signing certificate Bitrise needs is either not present or no longer valid. If you use manually uploaded assets, confirm that your distribution certificate .p12 is uploaded in the Code Signing tab and that you entered the correct export password, because a wrong password prevents import and produces a "no signing certificate" style failure. Certificates also expire — Apple distribution certificates are valid for a multi-year period, but they do lapse — and a build that worked months ago can suddenly fail purely because the certificate expired. Check the certificate's validity in the Apple Developer portal under Certificates, and if it has expired or been revoked, generate a new distribution certificate, export a fresh .p12 with its private key, and re-upload it to Bitrise. Also ensure the .p12 actually contains the private key; exporting only the certificate without the key is a frequent mistake that makes signing impossible. If you use an App Store Connect API key with automatic signing, an expired or revoked certificate is usually regenerated for you, which is one reason that approach reduces this class of failure.
The second most common cause is a provisioning profile that does not match the build. A profile ties together a specific bundle identifier, a certificate, entitlements, and a distribution method, and if any of those disagree with your project, signing fails. Start with the bundle identifier: the profile's App ID must exactly match your target's bundle identifier, including case and any suffix, so a profile for com.example.App will not sign com.example.App.dev. Next check expiry, since provisioning profiles typically last one year and an expired profile causes an immediate failure even if the certificate is fine. Then confirm the profile's type matches what you are building — an App Store profile for TestFlight and release, an Ad Hoc profile for device test builds, a Development profile for debugging. Also verify the profile references the same certificate you uploaded, because a profile built against a different, now-absent certificate cannot be used. Regenerate the profile in the Apple Developer portal if any of these are wrong, download the fresh .mobileprovision, and re-upload it to Bitrise so the installer Step can place a valid, matching profile on the build machine.
A subtler but very common failure is a mismatch between the export method configured in the archive Step and the provisioning profile available. The Xcode Archive & Export for iOS Step has a distribution method input with values such as app-store, ad-hoc, development, and enterprise, and it must correspond to the profile you supplied. If the Step is set to app-store but only an Ad Hoc profile is uploaded, Xcode cannot find a matching App Store profile and fails, and the reverse is equally true. This mismatch is easy to introduce when you copy a workflow between apps or change your distribution target without updating the profile set. Open the archive Step, confirm the distribution method matches your intent — app-store for TestFlight and App Store — and confirm a profile of exactly that type, for exactly your bundle identifier, is present. If you are using automatic managed signing with an API key, ensure the Step is set to automatic and the API key connection is provided, since a Step left on manual with no matching uploaded profile will fail even though the key could have resolved one.
Xcode supports both automatic and manual signing, and a mismatch between how your project is configured and how the Bitrise Step is configured causes failures that are easy to misread. If your Xcode project uses manual signing with explicitly selected profiles, but the Bitrise archive Step is set to automatic without an API key that can resolve assets, signing fails because nothing selects the profile. Conversely, if the project expects automatic signing but you have only uploaded specific manual profiles, Xcode may try to resolve assets on its own and fail on the signing-key-free build machine. The cleanest fixes are to be deliberate and consistent: for manual signing, upload the exact certificate and profiles and use the installer Step, and set the archive Step to manual with the matching export method. For automatic signing, connect an App Store Connect API key and set the archive Step to automatic so Bitrise's tooling can create and download what it needs. Mixing the two paradigms halfway is the root of many confusing signing errors, so pick one model per workflow and configure both the project and the Step to agree with it.
Occasionally signing fails not because your current assets are wrong but because stale ones are interfering. If you recently rotated a certificate or profile, an old asset still uploaded in the Code Signing tab can be picked up instead of the new one, or a cached build environment can hold onto outdated data. When the more common causes check out but the failure persists, remove obsolete certificates and profiles from the Code Signing tab so only the current, valid ones remain, then run a clean build. If your workflow caches derived data or signing-related directories, clear that cache to force a fresh state, since a corrupt or outdated cache can reintroduce a problem you already fixed. It is also worth confirming that only one distribution certificate is active for your team where policy allows, because multiple certificates can lead Xcode to select an unexpected one. After cleaning up, re-run codesigndoc on your Mac to re-collect exactly the assets your scheme resolves today, and re-upload that clean set. Eliminating stale material removes a whole category of intermittent, hard-to-explain signing failures that survive otherwise-correct configuration.
When you hit a signing failure, work through the causes in order of likelihood rather than guessing. First, read the exact error to learn which bundle identifier and profile type Xcode wanted. Second, verify the certificate exists, is unexpired, unrevoked, and includes its private key. Third, verify a provisioning profile with the matching bundle identifier, matching type, current expiry, and the same certificate is uploaded. Fourth, confirm the archive Step's export method matches that profile type. Fifth, confirm the automatic-versus-manual model is consistent between your project and the Step. Sixth, clear stale assets and caches if the problem persists. For most teams, the durable fix is to migrate to an App Store Connect API key with automatic managed signing, because it regenerates certificates and profiles on demand and eliminates the recurring expiry-and-mismatch failures that manual uploads cause. Remember the honest constraint underneath all of this: Bitrise can only present valid Apple-issued assets to xcodebuild. It cannot manufacture signing authority, so an active Apple Developer Program membership with correctly issued certificates and profiles remains a hard requirement no amount of workflow tweaking can bypass.
Bitrise builds on fresh, ephemeral macOS machines with no signing assets in their Keychain, while your Mac already has certificates and profiles installed, often managed silently by Xcode. Anything that works locally only because of pre-existing Keychain contents must be supplied explicitly to Bitrise via the Code Signing tab or an App Store Connect API key, or the build machine will report a missing certificate or profile.
Sign in to the Apple Developer portal, open Certificates, and check the expiry date of your distribution certificate. Distribution certificates last a multi-year period but do eventually lapse, and an expired or revoked certificate causes immediate signing failures. If it has expired, generate a new one, export a fresh .p12 including its private key, and re-upload it to Bitrise, or use an API key so it is regenerated automatically.
It means Xcode looked for a provisioning profile matching your target's bundle identifier and distribution type and found none installed on the build machine. Confirm a profile with the exact matching bundle identifier and the right type — App Store, Ad Hoc, or Development — is uploaded in the Code Signing tab and not expired, and that the archive Step's export method matches that profile type.
Automatic managed signing via an App Store Connect API key avoids most recurring failures because Bitrise can create and download the certificates and profiles it needs and handle expiry for you. Manual signing gives explicit control but requires you to upload exact assets and renew them before expiry. The important thing is consistency: configure your Xcode project and the Bitrise archive Step to use the same model.
No. Bitrise only installs and uses Apple-issued signing assets and invokes Apple's signing tooling. The authority to sign for real devices and distribution comes exclusively from an active Apple Developer Program membership. If your membership has lapsed or your certificates and profiles were never validly issued, no workflow configuration can make signing succeed until those Apple-side assets are in order.