How does iOS code signing work: certificates, App IDs, provisioning profiles, signing identities, export methods and signing on CI?

Four things work together. A signing certificate (Apple Development or Apple Distribution) proves who you are; its private key lives in a keychain on the machine that made the request, so a certificate without its key cannot sign, and losing the key means revoking and creating a new certificate. An App ID is your bundle identifier plus the capabilities enabled for it. A provisioning profile is a file signed by Apple that binds them: it lists the App ID, the certificates allowed to sign, the entitlements the app may claim and, for development and ad hoc profiles, the device identifiers allowed to run it. The code signature is a seal over the executable and every resource in the bundle; it records the signing identity and the embedded entitlements, and any change to the signed contents invalidates it (the check below signs a binary, then appends one byte and validation fails). The device verifies the chain to Apple’s root, checks the profile matches and the entitlements are a subset of what the profile grants, and only then launches the app. The profile types map to export methods: development (registered devices), ad hoc (registered devices, no debugger), App Store (what you upload) and enterprise (an organisation’s own distribution).

Xcode’s automatic signing creates and refreshes certificates, App IDs and profiles for you, which is right for local work. Manual signing (or automatic signing driven by an App Store Connect API key with -allowProvisioningUpdates) is what pipelines use, so builds are reproducible and do not depend on a person’s account. On CI never commit certificates or keys. Store them encrypted (a secrets manager, or fastlane match with an encrypted private repository), and in each job create a temporary keychain, unlock it, set a timeout, import the certificate and key, allow codesign to use it without a prompt, build, and delete the keychain at the end, as in the commands checked below. Expiry matters: certificates and profiles last a limited time (about a year), so track them, because an expired distribution certificate blocks new builds (apps already released are unaffected). Inspect a profile with security cms -D -i embedded.mobileprovision and a signature with codesign -dvv. When an error says “no matching provisioning profile”, check the bundle ID, the certificate, the device list and the entitlements, in that order.