Introduction

The message Print: Entry, "CFBundleIdentifier", Does Not Exist usually means a tool tried to read the CFBundleIdentifier key from an app's Info.plist, but the key was missing from the plist it actually opened. In practice, this is usually a build configuration problem: wrong plist path, wrong target, or missing bundle identifier expansion.

Core Sections

What CFBundleIdentifier Is

CFBundleIdentifier is the plist key that identifies an iOS or macOS app bundle. In many Xcode projects it is defined indirectly through the build setting PRODUCT_BUNDLE_IDENTIFIER.

A common plist entry looks like this:

<key>CFBundleIdentifier</key>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>

When the build runs correctly, Xcode resolves that placeholder and writes the final bundle id into the built app metadata.

Why the Error Happens

This error appears when a script or tool reads a plist that does not contain the expected key. Common reasons include:

• the target points to the wrong Info.plist
• the plist file exists but omits CFBundleIdentifier
• the script is reading the source plist while the build uses generated settings
• the wrong target or configuration is being inspected

For example, a custom build phase might run PlistBuddy against a stale file:

/usr/libexec/PlistBuddy -c "Print CFBundleIdentifier" "$INFOPLIST_FILE"

If $INFOPLIST_FILE does not resolve to the file you think it does, the command reports that the entry does not exist.

Check the Target Settings First

In Xcode, confirm the target's bundle identifier in the Signing and Capabilities tab or under Build Settings. The important values are:

• 'PRODUCT_BUNDLE_IDENTIFIER'
• 'INFOPLIST_FILE'
• whether the project uses generated Info.plist settings

You can also inspect resolved build settings from the command line:

xcodebuild -showBuildSettings -scheme MyApp | grep -E "PRODUCT_BUNDLE_IDENTIFIER|INFOPLIST_FILE"

That helps catch cases where the active scheme or build configuration points somewhere unexpected.

Verify the Actual Plist Contents

Once you know which plist file is being read, inspect it directly.

plutil -p /path/to/Info.plist

Or:

/usr/libexec/PlistBuddy -c "Print" /path/to/Info.plist

If CFBundleIdentifier is missing, add it or restore the standard Xcode-generated entry.

Example:

<key>CFBundleIdentifier</key>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>

Using the build setting placeholder is usually better than hardcoding the identifier in the plist, because it keeps target configuration centralized.

Watch for Generated Plist Behavior

Modern Xcode projects can generate parts of the plist from build settings. That means the source plist file may not contain everything you expect if the target is configured to generate or merge values during build time.

If a custom script reads the source plist too early, it may miss keys that only appear in the processed product plist inside the build directory. In those cases, inspect the built app's plist instead of the source file.

plutil -p build/Debug-iphoneos/MyApp.app/Info.plist

That helps distinguish "missing in source plist" from "missing in final built bundle."

Common Pitfalls

• Assuming every target in the project reads from the same Info.plist.
• Moving or renaming a plist file without updating INFOPLIST_FILE in the target settings.
• Reading the source plist in a script when the relevant key only appears in the processed build product.
• Treating build-folder cleaning as the fix instead of correcting the underlying target configuration.
• Forgetting that CFBundleIdentifier is often populated through $(PRODUCT_BUNDLE_IDENTIFIER) rather than a hard-coded literal value.

Summary

• The error means the inspected plist did not contain CFBundleIdentifier.
• Check PRODUCT_BUNDLE_IDENTIFIER and INFOPLIST_FILE for the active target and scheme.
• Verify whether your project uses a source plist, a generated plist, or both.
• Inspect the actual file being read, not just the file you expect Xcode to use.
• Custom scripts should read the correct plist at the correct phase of the build.