Introduction

EXECUTABLE_NAME and PRODUCT_NAME are Xcode build settings, not magic values baked into your source code. PRODUCT_NAME is typically configured directly on the target, while EXECUTABLE_NAME is usually derived from it by the build system.

Where PRODUCT_NAME Comes From

In Xcode, PRODUCT_NAME is a target build setting under Product Information. By default, it is usually set to the target name that existed when the target was created, though you can override it later.

You can see it in several places:

• Xcode target settings under Build Settings
• an .xcconfig file if the project uses one
• the project.pbxproj file inside the .xcodeproj bundle

A simple .xcconfig override looks like this.

PRODUCT_NAME = MyApp

If you do not override it, Xcode computes a default value based on the target configuration.

Where EXECUTABLE_NAME Comes From

EXECUTABLE_NAME is usually not something you type in manually. Apple documents it as a derived build setting whose default value is built from:

• 'EXECUTABLE_PREFIX'
• 'PRODUCT_NAME'
• 'EXECUTABLE_SUFFIX'

In normal app targets, the effective executable name is often just the product name with whatever suffix rules apply to that product type.

That is why Info.plist entries often use $(EXECUTABLE_NAME) instead of a hard-coded string.

How to Inspect the Resolved Values

The most reliable way to answer "what is this value for my current build?" is to ask Xcode.

xcodebuild -project MyApp.xcodeproj \
  -scheme MyApp \
  -showBuildSettings | grep -E 'PRODUCT_NAME|EXECUTABLE_NAME'

That command prints the resolved values after Xcode applies defaults, inherited settings, configuration files, and target-specific overrides.

This matters because the value you see in the UI may still contain variable references such as $(TARGET_NAME), while the build output uses the fully expanded value.

How These Settings Relate to Info.plist

A common pattern is:

<key>CFBundleExecutable</key>
<string>$(EXECUTABLE_NAME)</string>

That tells Xcode to write the actual built executable name into the app bundle metadata. If CFBundleExecutable and the real binary name disagree, launch and signing issues can follow.

Apple's guidance has long been to keep the executable file entry aligned with $(EXECUTABLE_NAME).

Project File and Configuration Sources

When people ask where these values are "defined," the answer depends on what level they mean.

If they mean default definition, Xcode defines these settings as part of its build system.

If they mean project-specific override, the value may come from:

• target Build Settings
• project Build Settings
• imported .xcconfig files
• inherited settings from a parent configuration

You can inspect raw project configuration with:

grep -n "PRODUCT_NAME\|EXECUTABLE_NAME" MyApp.xcodeproj/project.pbxproj

That shows explicit overrides, but not every derived value. xcodebuild -showBuildSettings is still the better final answer.

When You Would Override Them

You might override PRODUCT_NAME when the app bundle name should differ from the target name, or when multiple build variants should produce differently named products.

You might override EXECUTABLE_NAME less often, usually in unusual packaging cases such as frameworks, bundles, or custom binary naming rules.

In most app targets, overriding PRODUCT_NAME is enough because EXECUTABLE_NAME follows from it automatically.

Common Pitfalls

The most common mistake is searching only the source tree and missing that these are build settings owned by Xcode, not variables defined in Swift or Objective-C code.

Another mistake is editing Info.plist to a hard-coded executable name while the build setting still changes across configurations.

A third issue is checking only the project-level settings. Target-level overrides win frequently, and .xcconfig files may override both.

Finally, do not assume the visible string in Xcode is the final value. Inherited and derived settings are expanded at build time.

Summary

• 'PRODUCT_NAME is a target build setting, usually visible in Xcode Build Settings.'
• 'EXECUTABLE_NAME is usually derived from PRODUCT_NAME plus prefix and suffix settings.'
• Project-specific values may live in target settings, project settings, or .xcconfig files.
• 'xcodebuild -showBuildSettings is the most reliable way to inspect resolved values.'
• 'CFBundleExecutable should usually reference $(EXECUTABLE_NAME).'
• In most cases, changing PRODUCT_NAME is enough and EXECUTABLE_NAME follows automatically.