UDIDs, certificates and profiles, explained once

iOS code signing has four parts. They are usually explained in the order Apple’s interface presents them, which is not the clearest order. Here they are in an order that makes sense.

The four parts

A certificate identifies who you are. Apple issues it to a developer or a team. It is stored in a keychain with a private key, and it expires, typically after a year. If you lose the private key, the certificate is unusable and you must issue a new one.

An App ID identifies which app. It is the bundle identifier plus the capabilities the app is allowed to use, such as push notifications, App Groups, HealthKit and associated domains.

A device is identified by its UDID, a unique identifier for one physical iPhone or iPad. The Apple Developer Program allows a limited number of registered devices per device type each year.

A provisioning profile ties the other three together: this certificate may sign this App ID and install it on these devices. It expires. It is embedded in the IPA at build time.

That last sentence is the one to remember.

Why editing the profile does nothing

The profile is built into the IPA. Adding a UDID to the profile in the developer portal does not change any existing IPA. The file on your disk still contains the old profile with the old device list.

So the sequence is always: add the UDID → regenerate the profile → rebuild → redistribute. Teams lose a lot of time to this, usually by adding a device, sending the same build again, and wondering why it still fails.

Where the UDID comes from

The UDID belongs to the device, not to an account. You need to read it from the physical device.

Do not copy it from an old spreadsheet. Many “why will this not install” tickets turn out to involve a UDID belonging to a device the team no longer has, typed from a list nobody had checked.

Profile types

Profile	Signs with	Installs on
Development	Development certificate	Registered devices only
Ad Hoc	Distribution certificate	Registered devices, up to 100 per type
Enterprise	Enterprise certificate	Any device, after the user trusts it
App Store	Distribution certificate	Nothing directly; store submission only

Two consequences to keep in mind:

• An App Store build cannot be sideloaded. This is not a bug, and there is no setting to change it.
• Enterprise distribution is only for your own organization. Using it to distribute to the public violates Apple’s terms and can lead to the certificate being revoked, which stops every app signed with it from launching.

Why builds suddenly stop working

Usually because something expired. Expiry happens on a date, not because of an action, so nothing warns you.

• Certificate expired. Every profile using it becomes invalid, and all builds stop installing at once.
• Profile expired. Builds for that app stop installing.
• Certificate revoked. The same effect as expiry, but immediate and usually deliberate, for example when someone cleans up the developer portal.

The typical pattern: it worked yesterday, nobody changed anything, and it failed on every device at the same time. If it failed on one device, it is a UDID problem instead.

The trust step

An installed development or enterprise build does not launch until the user trusts the certificate on the device: Settings → General → VPN & Device Management.

This is easy to miss because the installation succeeded. Nothing failed and the app is on the Home Screen, but it does not run. You need to trust each certificate once per device.

Preventing repeat problems

Three habits, each taking about five minutes:

1. Keep the device list accurate. Read UDIDs from the physical devices when they join the fleet, not from memory.
2. Record expiry dates. Put certificate and profile expiry dates in a calendar. This removes most sudden failures.
3. Review profiles when a device joins or leaves. Check which profiles are installed, and whether any were added by someone else.

None of this is interesting work, but all of it costs less than the lost afternoon it prevents.