The Xcode setting that creates and updates certificates, App IDs, and provisioning profiles for you. Great on a laptop, the usual suspect when signing breaks on CI.
Automatically manage signing is the checkbox in a target's Signing and Capabilities tab that hands the whole signing setup to Xcode. Tick it, pick a team, and Xcode creates an Apple Development certificate if you lack one, registers your plugged-in device, creates or updates the App ID, and generates a provisioning profile on the fly. For one developer on one Mac it is genuinely magic.
What it does behind the scenes
Creates a Development certificate per developer, per machine, as needed.
Creates and maintains "managed" profiles named iOS Team Provisioning Profile: <bundle id>, invisible in the portal UI's normal flow.
Registers any device you plug in and hit Run on, consuming device slots.
Updates the App ID's capability list when you add capabilities in Xcode.
Where it breaks down
Automatic signing assumes an interactive, signed-in Xcode. Three situations violate that assumption:
CI machines
A build agent has no Apple ID session, so profile creation fails mid-build, typically with Xcode couldn't find any provisioning profiles matching. xcodebuild offers -allowProvisioningUpdates with App Store Connect API key flags as a workaround, but it gives every build machine write access to your developer account, which most teams do not want.
Teams
Every developer's Xcode mints its own certificates and managed profiles. Accounts accumulate dozens of near-duplicate profiles, and nobody can say which ones a release actually needs.
Distribution
Release signing needs an Apple Distribution certificate shared by the team, with the private key available wherever release builds run. Automatic signing manages this inside Xcode's Organizer flow, but that does not translate to unattended release pipelines.
Automatic vs manual at a glance
Automatic
Manual
Setup effort
None, Xcode handles it
You create certs and profiles
Solo development
Ideal
Unnecessary overhead
CI builds
Needs portal access per build
Deterministic, no portal access
Profile sprawl
One managed profile per dev/device combination
One curated profile per App ID
Who signs releases
The Xcode that archives
A known shared Distribution certificate
The pattern most teams land on: automatic signing for local debug builds, manual signing (a curated Distribution certificate plus explicit profiles) for anything a CI machine builds. The two coexist fine in one project, split by build configuration.
FAQ
Common questions about Automatic signing (Xcode)
Solo developer building on one Mac: automatic, no contest. A team with CI: automatic for local debug builds and manual for release and CI builds. The switch point is the first time a pipeline needs to sign a build unattended, because that is where automatic signing's need for portal access becomes a liability.
The build machine has no signed-in Apple ID, so Xcode cannot create or refresh profiles during the build. The error is usually a variant of "No profiles for <bundle id> were found". Fixes: switch CI builds to manual signing with pre-staged assets, or pass -allowProvisioningUpdates plus App Store Connect API key flags to xcodebuild and accept that runners get portal write access.
Managed profiles that automatic signing creates, one per bundle ID and team, updated as devices and certificates change. They are harmless but numerous, and they are why accounts that have used automatic signing for years show dozens of profiles nobody remembers creating.
Not by itself, but the target then needs a valid certificate and profile explicitly assigned per configuration. Create those first (a Distribution certificate the team shares, plus explicit profiles per App ID), select them in the target, and commit the project change. Do it configuration by configuration rather than all at once.
HexSign tracks every Apple certificate and provisioning profile and alerts you ahead of expiry. The Free plan covers tracking and alerts. Paid plans renew them for you.
