No such provisioning profile was found for that UUID

Every provisioning profile has a UUID, and for a long time that UUID was how Xcode referenced a profile in build settings. The setting is called PROVISIONING_PROFILE and it holds a raw UUID string. This error means that string is present in your project and nothing installed on the build machine has that UUID.

The trap is that UUIDs are not stable. Regenerate a profile in the portal, after adding a device or renewing a certificate, and the replacement gets a brand new UUID even though the name is unchanged. Anything holding the old UUID breaks immediately, which is why this error tends to arrive the same afternoon someone renewed something.

Two settings, and you want the other one

PROVISIONING_PROFILE

The legacy setting. Holds a UUID. Xcode no longer writes it, but it persists in older project files and in anything copied from an old template. This is the setting producing your error.

PROVISIONING_PROFILE_SPECIFIER

The current setting. Holds the profile's name, such as "MyApp AppStore". A regenerated profile keeps its name, so the reference survives. This is what you want.

Both can be present at once, and when they are, the stale UUID still causes the failure even though the specifier is correct. That combination is what makes this error survive the obvious fix and feel unkillable.

Find the pinned UUID

It hides in the pbxproj, sometimes in only one of several build configurations, which is why it fails on Release and not on Debug. Grep for it rather than clicking through the build settings editor, because Xcode hides the legacy setting once it is no longer recognised.

grep -n "PROVISIONING_PROFILE" MyApp.xcodeproj/project.pbxproj

# Also check anything that generates or patches the project
grep -rn "PROVISIONING_PROFILE" \
  --include="*.yml" --include="*.yaml" --include="*.xcconfig" \
  --include="Podfile" --include="Fastfile" .

Check .xcconfig files in particular. A UUID set in a shared config file applies to every target that includes it, and nobody thinks to look there because the project navigator shows nothing.

Fix it

1. 1

   Remove every PROVISIONING_PROFILE entry

   From the pbxproj, from your xcconfig files, and from any project generator config. Leaving one behind in a single configuration is the usual reason the error comes back.

2. 2

   Set PROVISIONING_PROFILE_SPECIFIER to the name

   The exact name as shown in the portal, including spaces and capitalisation. Per target: the app, each extension, the watch app.

3. 3

   Install the profile on the build machine

   The specifier still needs a matching profile present. On CI that means copying the .mobileprovision into the profiles directory before the build, or passing -allowProvisioningUpdates with API key authentication.

4. 4

   Use the same names in ExportOptions.plist

   The export step reads its own map of bundle identifier to profile name. If the archive signs and the export fails, this file is the missing half.

xcodebuild archive \
  -scheme MyApp \
  -archivePath build/MyApp.xcarchive \
  CODE_SIGN_STYLE=Manual \
  DEVELOPMENT_TEAM=ABCDE12345 \
  PROVISIONING_PROFILE_SPECIFIER="MyApp AppStore" \
  PROVISIONING_PROFILE=""

Setting PROVISIONING_PROFILE to an empty string on the command line is a useful override while you are cleaning up the project file, because it beats whatever is committed without needing a merge conflict with three other branches. It is a workaround, not a resting place: get the setting out of the project.

If you need the UUID of an installed profile

PROFILES=~/Library/Developer/Xcode/UserData/Provisioning\ Profiles

for f in "$PROFILES"/*.mobileprovision; do
  security cms -D -i "$f" > /tmp/p.plist 2>/dev/null || continue
  UUID=$(/usr/libexec/PlistBuddy -c 'Print :UUID' /tmp/p.plist)
  NAME=$(/usr/libexec/PlistBuddy -c 'Print :Name' /tmp/p.plist)
  echo "$UUID  $NAME"
done

Xcode 16 and later read profiles from that path. Xcode 15 and earlier used ~/Library/MobileDevice/Provisioning Profiles. A CI script that installs .mobileprovision files into one directory while the local toolchain reads the other produces this error with a machine full of perfectly valid profiles. Writing to both costs nothing.

Related messages

• If the profile is found but covers the wrong identifier, see profile has app ID which does not match the bundle ID.
• If nothing is pinned and Xcode simply cannot find a profile, see No profiles for the bundle ID were found.
• If the profile exists but lacks your certificate, see profile doesn't include signing certificate.