Use automatic signing for development on laptops and explicit, manual signing for release builds on CI. Automatic signing picks a profile for you, which is convenient but can choose the wrong one. A release build should say exactly which certificate and profile it uses, so the result is predictable and reviewable.
The problem with automatic on a build server
The fastlane codesigning guide notes that the Automatic setting for the provisioning profile does not always work reliably, because it selects the most recently updated profile whether or not the matching certificate is installed. The recommendation is to specify a particular provisioning profile instead.
For a release, "whichever profile was newest" is not a good answer to "what did we sign this with?"
The mixed approach
The guide describes a pattern many teams use. Configure the project for automatic signing for development, and set the release configuration to use explicit values supplied by the signing tool. In the Fastfile, a release lane syncs the signing identity, turns automatic code signing off for the project, builds, then turns it back on. The effect is that developers keep a low-friction setup while release builds stay controlled.
Match's own documentation describes the same trade-off as a benefit: more predictable builds by setting profiles explicitly instead of using the Automatic setting, and the Xcode behavior it mentions of sometimes revoking certificates, which breaks a setup and fails builds.
Compare the two
| Aspect | Automatic | Manual or explicit |
|---|---|---|
| Setup effort | Low | Higher |
| Chooses profile | The tool, by recency | You, by name |
| Revocation surprises | Possible | Rare, if CI is read-only |
| Reviewability | Weak | Strong, in the config |
| Where it fits | Developer machines | Release builds on CI |
Steps to move a release lane to explicit signing
- Decide where certificates and profiles live and who may read them. Our post on git-stored certificates covers that.
- In the release configuration, reference the profile by name through a variable, not a hard-coded value.
- In the release lane, fetch the profile read-only, disable automatic signing for the build, and re-enable it afterwards.
- Build, export and upload.
- Log which certificate and profile were used, without logging secrets, so the build record can answer the question later.
- Test the lane on a clean machine, since local state hides problems.
Common mistakes
- Letting CI run in a mode where it can create and revoke certificates. A single failed run can then break other people's builds.
- Forgetting to re-enable automatic signing, which confuses developers.
- Sharing a profile between app targets that need different entitlements.
- Treating the profile as a secret and the certificate as harmless. The private key is the secret.
What about Xcode's managed option
Xcode's cloud-managed signing is a legitimate choice for small teams, and the fastlane guide links Apple's session on it. It trades some control for convenience. If you pick it, still limit who can release and keep store credentials out of general CI jobs.
Where Safeguard fits
Safeguard does not sign builds. It checks dependencies, produces SBOMs and applies policy gates so an unexpected component does not reach a release. Try a free scan.
Quick check
Is manual signing less secure than automatic?
Not inherently. The security gain is predictability and reviewability. Key handling matters more than the mode.
Can I switch back and forth in one project?
Yes. The documented pattern disables automatic signing in the release lane and re-enables it afterwards.
Sources
Last reviewed: 19 October 2026.
