Xcode Build Settings

A string identifying the build system action being performed.

The locations of any sparse SDKs that should be layered on top of the one specified by Base SDK (SDKROOT). If more than one SDK is listed, the first one has highest precedence. Every SDK specified in this setting should be a “sparse” SDK, for example, not an SDK for an entire macOS release.

The group name or gid for the files listed under the Alternate Permissions Files (ALTERNATE_PERMISSIONS_FILES) setting.

Permissions used for the files listed under the Alternate Permissions Files (ALTERNATE_PERMISSIONS_FILES) setting.

The owner name or uid for the files listed under the Alternate Permissions Files (ALTERNATE_PERMISSIONS_FILES) setting.

List of files to which the alternate owner, group and permissions are applied.

This setting is deprecated as of Xcode 8.3 and may not be supported in future versions. It is recommended that you disable the setting.

If enabled, both #include <header.h>-style and #include "header.h"-style directives search the paths in User Header Search Paths (USER_HEADER_SEARCH_PATHS) before Header Search Paths (HEADER_SEARCH_PATHS). As a consequence, user headers, such as your own String.h header, have precedence over system headers when using #include <header.h>. This is done using the -iquote flag for the paths provided in User Header Search Paths (USER_HEADER_SEARCH_PATHS). If disabled and your compiler fully supports separate user paths, user headers are only accessible with #include "header.h"-style preprocessor directives.

For backwards compatibility reasons, this setting is enabled by default. Disabling it is strongly recommended.

When enabled, this causes the compiler and linker to disallow use of APIs that are not available to app extensions and to disallow linking to frameworks that have not been built with this setting enabled.

Enabling this setting will cause files in the target’s Copy Files build phases to be processed by build rules. For example, property list files (.plist) and strings files will be converted as specified by Property List Output Encoding (PLIST_FILE_OUTPUT_FORMAT) and Strings File Output Encoding (STRINGS_FILE_OUTPUT_ENCODING), respectively.

Enabling this setting will cause all Public and Private headers in the target’s Copy Headers build phase to be processed by build rules. This allows custom build rules to be defined to process these headers. Custom script rules can define their outputs relative to HEADER_OUTPUT_DIR, which will be provided to that script, taking the header visibility into account. The scripts are also passed SCRIPT_HEADER_VISIBILITY (“public” or “private”). Files that should not be processed by build rules may need to be moved to a Copy Files build phase when this setting is enabled.

A list of the architectures for which the product will be built. This is usually set to a predefined build setting provided by the platform. If more than one architecture is specified, a universal binary will be produced.

If set to anything other than the empty string, every URL in the AssetPackManifest.plist file will consist of this string with the name of the asset pack appended. If not set, the URLs in the AssetPackManifest.plist will be formed as appropriate for the build location of the asset packs. The prefix string is not escaped or quoted in any way, so any necessary escaping must be part of the URL string. This setting affects only URLs in the AssetPackManifest.plist file — it does not affect where asset packs are built in the local file system.

A list of components being built during this action.

Ensures that your libraries are built for distribution. For Swift, this enables support for library evolution and generation of a module interface file.

A list of the build variants of the linked binary that will be produced. By default, only the normal variant is produced. Other common values include debug and profile.

Identifies the directory under which all the product’s files can be found. This directory contains either product files or symbolic links to them. Run Script build phases can use the value of this build setting as a convenient way to refer to the product files built by one or more targets even when these files are scattered throughout a directory hierarchy (for example, when DEPLOYMENT_LOCATION is set to YES.

Specifies the executable that will load the bundle output file being linked. Undefined symbols from the bundle are checked against the specified executable as if it is one of the dynamic libraries the bundle was linked with.

The path to a file specifying code-signing entitlements.

The name, also known as the common name, of a valid code-signing certificate in a keychain within your keychain path. A missing or invalid certificate will cause a build error.

Automatically inject entitlements from the platform’s BaseEntitlements.plist into the code signatures of executables.

This setting specifies the method used to acquire and locate signing assets. Choose Automatic to let Xcode automatically create and update profiles, app IDs, and certificates. Choose Manual to create and update these yourself on the developer website.

Control whether the compiler should emit index data while building.

Identifies the build configuration, such as Debug or Release, that the target uses to generate the product.

The base path where build products will be placed during a build for a given configuration. By default, this is set to $(BUILD_DIR)/$(CONFIGURATION).

The base path where intermediates will be placed during a build for a given configuration. By default, this is set to $(PROJECT_TEMP_DIR)/$(CONFIGURATION).

Causes the copying of resources to preserve resource forks and Finder info.

If enabled, headers are run through the unifdef(1) tool when copied to the product.

Specifies the flags to pass to unifdef(1) when invoking that tool to copy headers. This setting has no effect unless Run unifdef on Product Headers (COPY_HEADERS_RUN_UNIFDEF) is enabled.

Specifies whether binary files that are copied during the build, such as in a Copy Bundle Resources or Copy Files build phase, should be stripped of debugging symbols. It does not cause the linked product of a target to be stripped—use Strip Linked Product (STRIP_INSTALLED_PRODUCT) for that.

Enabling this setting will create a section in the product’s linked binary containing the processed Info.plist file for the target. This setting only applies to command-line tool targets.

This setting defines the current version of the project. The value must be a integer or floating point number, such as 57 or 365.8.

Activating this setting causes the -dead_strip flag to be passed to ld(1) via cc(1) to turn on dead code stripping.

The type of debug information to produce.

• DWARF: Object files and linked products will use DWARF as the debug information format. dwarf

• DWARF with dSYM File: Object files and linked products will use DWARF as the debug information format, and Xcode will also produce a dSYM file containing the debug information from the individual object files (except that a dSYM file is not needed and will not be created for static library or object file products). dwarf-with-dsym

If enabled, the product will be treated as defining its own module. This enables automatic production of LLVM module map files when appropriate, and allows the product to be imported as a module.

If enabled, built products are placed in their installed locations in addition to the built products folder.

If enabled, indicates that binaries should be stripped and file mode, owner, and group information should be set to standard values.

Files and directories used only for development. Archive and install builds will exclude this content.

The team ID of a development team to use for signing certificates and provisioning profiles.

If enabled, don’t automatically generate an Info.plist file for wrapped products when the Info.plist File (INFOPLIST_FILE) build setting is empty.

The path at which all products will be rooted when performing an install build. For instance, to install your products on the system proper, set this path to /. Defaults to /tmp/$(PROJECT_NAME).dst to prevent a test install build from accidentally overwriting valid and needed data in the ultimate install path.

Typically this path is not set per target, but is provided as an option on the command line when performing an xcodebuild install. It may also be set in a build configuration in special circumstances.

Determines the compatibility version of the resulting library, bundle, or framework binary. See Dynamic Library Design Guidelines in Dynamic Library Programming Topics for details on assigning version numbers of dynamic libraries.

This setting defines the current version of any framework built by the project. As with Current Project Version (CURRENT_PROJECT_VERSION), the value must be an integer or floating point number, such as 57 or 365.8. By default, it is set to $(CURRENT_PROJECT_VERSION). See Dynamic Library Design Guidelines in Dynamic Library Programming Topics for details on assigning version numbers of dynamic libraries.

Sets the base value for the internal install path (LC_ID_DYLIB) in a dynamic library. This will be combined with the EXECUTABLE_PATH to form the full install path. Setting Dynamic Library Install Name (LD_DYLIB_INSTALL_NAME) directly will override this setting. This setting defaults to the target’s Installation Directory (INSTALL_PATH). It is ignored when building any product other than a dynamic library.

Embed all the built asset packs inside the product bundle. Since this negates the performance benefits of the On Demand Resources feature, it is only useful for testing purposes when it isn’t practical to use an asset pack server.

Activating this setting indicates that the target or project should generate bitcode during compilation for platforms and architectures that support it. For Archive builds, bitcode will be generated in the linked binary for submission to the App Store. For other builds, the compiler and linker will check whether the code complies with the requirements for bitcode generation, but will not generate actual bitcode.

Enable hardened runtime restrictions.

Specifies whether to automatically track dependencies on included header files.

If enabled, tagged assets—files and asset catalog entries—are built into asset packs based on their combination of tags. Untagged resources are treated normally.

If enabled, the product will be built with options appropriate for supporting previews.

When this setting is activated, the product will be built with options appropriate for running automated tests, such as making private interfaces accessible to the tests. This may result in tests running slower than they would without testability enabled.

Specifies whether the build system should add the search paths necessary for compiling and linking against XCTest. This setting is enabled by default if the target is a unit test target or if the target explicitly links to the XCTest framework.

This is a list of fnmatch()-style patterns of file or directory names to exclude when performing a recursive search. By default, this is set to *.nib *.lproj *.framework *.gch *.xcode (*) .DS_Store CVS .svn .git .hg. Normally, if you override this value you should include the default values via the $(inherited) macro.

A list of patterns (as defined by fnmatch(3)) specifying the names of source files to explicitly exclude when processing the files in the target’s build phases (see also Included Source File Names (INCLUDED_SOURCE_FILE_NAMES)). This setting can be used to define complex filters for which files from the phase should be built in response to other build settings; for example, a value of *.$(CURRENT_ARCH).c could serve to exclude particular files based on the architecture being built.

This is the extension used for the executable product generated by the target, which has a default value based on the product type.

The prefix used for the executable product generated by the target, which has a default value based on the product type.

This is a project-relative path to a file that lists the symbols to export. See ld -exported_symbols_list for details on exporting symbols.

This is a list of paths to folders containing frameworks to be searched by the compiler for both included or imported header files when compiling C, Objective-C, C++, or Objective-C++, and by the linker for frameworks used by the product. Paths are delimited by whitespace, so any paths with spaces in them must be properly quoted.

Framework bundles are versioned by having contents in subfolders of a version folder that has links to the current version and its contents.

The compiler to use for C, C++, and Objective-C.

Activating this setting will cause the object files built by a target to be prelinked using ld -r into a single object file, and that object file will then be linked into the final product. This is useful to force the linker to resolve symbols and link the object files into a single module before building a static library. Also, a separate set of link flags can be applied to the prelink allowing additional control over, for instance, exported symbols.

Forces the PkgInfo file to be written to wrapped products even if this file is not expected.

Activating this setting will cause the compiler and linker to generate profiling code. For example, GCC will generate code suitable for use with gprof(1).

Enables the generation of Text-Based stubs for dynamic libraries and frameworks.

Specifies whether the header map contains a name/path entry for every header in the target being built.

Specifies whether the header map contains a framework-name/path entry for every header in the target being built, including targets that do not build frameworks.

Specifies whether the header map contains a name/path entry for every header in the project, regardless of the headers’ target membership.

This is a list of paths to folders to be searched by the compiler for included or imported header files when compiling C, Objective-C, C++, or Objective-C++. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.

This is a list of fnmatch()-style patterns of file or directory names to include when performing a recursive search. By default, this is empty and is only customized when you want to provide exceptions to the list of filename patterns provided in Sub-Directories to Exclude in Recursive Searches (EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES).

A list of patterns (as defined by fnmatch(3)) specifying the names of source files to explicitly include when processing the files in the target’s build phases. This setting is only useful when combined with Excluded Source File Names (EXCLUDED_SOURCE_FILE_NAMES), and can be used to define complex filters for which files from the phase should be built in response to other build settings.

Expand build settings in the Info.plist file.

The project-relative path to the property list file that contains the Info.plist information used by bundles. For details on information property list files, see Information Property List Files in Runtime Configuration Guidelines.

Other flags to pass to the C preprocessor when preprocessing the Info.plist file.

Specifies the output encoding for the output Info.plist. The output encodings can be binary or XML. By default, the output encoding will be unchanged from the input.

Implicitly include the given file when preprocessing the Info.plist file. The path given should either be a project relative path or an absolute path.

Preprocess the Info.plist file using the C Preprocessor.

Space-separated list of preprocessor macros of the form foo or foo=bar. These macros are used when preprocessing the Info.plist file.

This is the name of the routine to use for initialization.

Enables private framework inlining for Text-Based Stubs.

Specifies whether the target’s Copy Files build phases are executed in installhdr builds.

Specifies whether the target’s Run Script build phases are executed in installhdr builds. See Active Build Action (ACTION) for details on installhdr builds.

Identifies the directory in the developer’s filesystem into which the installed product is placed.

The group name or gid for installed products.

Permissions used for installed product files.

The owner name or uid for installed products.

The directory in which to install the build products. This path is prepended by the Installation Build Products Location (DSTROOT).

Activating this setting will preserve private external symbols, rather than turning them into static symbols. This setting is also respected when performing a single-object prelink.

This setting defines the path to which the linker should emit information about what files it used as inputs and generated. Xcode uses this information for its dependency tracking. Setting the value of this setting to empty will disable passing this option to the linker.

This setting restricts the clients allowed to link a dylib by passing -allowable_client to the linker for each supplied value.

Sets an internal install path (LC_ID_DYLIB) in a dynamic library. Any clients linked against the library will record that path as the way dyld should locate this library. If this option is not specified, then the -o path will be used. This setting is ignored when building any product other than a dynamic library. See Dynamic Library Programming Topics.

Activating this setting will cause the linker to write a map file to disk, which details all symbols and their addresses in the output image. The path to the map file is defined by the Path to Link Map File (LD_MAP_FILE_PATH) setting.

This setting defines the path to the map file written by the linker when the Write Link Map File (LD_GENERATE_MAP_FILE) setting is activated. By default, a separate file will be written for each architecture and build variant, and these will be generated in the Intermediates directory for the target whose product is being linked.

Activating this setting will prevent Xcode from building a main executable that is position independent (PIE). When targeting macOS 10.7 or later, PIE is the default for main executables, so activating this setting will change that behavior. When targeting OS X 10.6 or earlier, or when building for i386, PIE is not the default, so activating this setting does nothing.

You cannot create a PIE from .o files compiled with -mdynamic-no-pic. Using PIE means the codegen is less optimal, but the address randomization adds some security.

This setting controls whether arguments to the linker should be quoted using -Xlinker. By default, Xcode invokes the linker by invoking the driver of the compiler used to build the source files in the target, and passing -Xlinker to quote arguments will cause the compiler driver to pass them through to the linker (rather than trying to evaluate them within the driver). By default, this setting is enabled. Disabling it will cause Xcode to not use -Xlinker to pass arguments to the linker. Disabling this setting is useful if the target has instructed Xcode to use an alternate linker (for example, by setting the LD setting to the path to another linker) and that alternate linker does not recognize -Xlinker.

This is a list of paths to be added to the runpath search path list for the image being created. At runtime, dyld uses the runpath when searching for dylibs whose load path begins with @rpath/. See Dynamic Library Programming Topics.

This is a list of paths to folders to be searched by the linker for libraries used by the product. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.

Activating this setting causes the linker to display mangled names for C++ symbols. Normally, this is not recommended, but turning it on can help to diagnose and solve C++ link errors.

When this setting is enabled, the compiler driver will automatically pass its standard libraries to the linker to use during linking. If desired, this flag can be used to disable linking with the standard libraries, and then individual libraries can be passed as Other Linker Flags (OTHER_LDFLAGS).

The base names for NSLocalizedString-like macros or functions used to produce localized strings in source code. The default base names of NSLocalizedString and CFCopyLocalizedString are always considered, even if this setting is empty.

When enabled, literal strings passed to the Text() initializer from Swift UI will be extracted during localization export.

This setting determines the format of the produced binary and how it can be linked when building other binaries. For information on binary types, see Building Mach-O Files in Mach-O Programming Topics.

• Executable: Executables and standalone binaries and cannot be linked. mh_execute

• Dynamic Library: Dynamic libraries are linked at build time and loaded automatically when needed. mh_dylib

• Bundle: Bundle libraries are loaded explicitly at run time. mh_bundle

• Static Library: Static libraries are linked at build time and loaded at execution time. staticlib

• Relocatable Object File: Object files are single-module files that are linked at build time. mh_object

This setting defines the user-visible version of the project. The value corresponds to the CFBundleShortVersionString key in your app’s Info.plist.

This is the project-relative path to the LLVM module map file that defines the module structure for the compiler. If empty, it will be automatically generated for appropriate products when Defines Module (DEFINES_MODULE) is enabled.

This is the project-relative path to the LLVM module map file that defines the module structure for private headers.

Absolute path of folder in which compiler stores its cached modules—this cache is a performance improvement.

This is the identifier of the kernel module listed in the generated stub. This is only used when building kernel extensions.

This defines the name of the kernel module start routine. This is only used when building kernel extensions.

This defines the name of the kernel module stop routine. This is only used when building kernel extensions.

This is the version of the kernel module listed in the generated stub. This is only used when building kernel extensions.

Identifies the architecture on which the build is being performed.

The path where intermediate files will be placed during a build. Intermediate files include generated sources, object files, etc. Shell script build phases can place and access files here, as well. Typically this path is not set per target, but is set per project or per user. By default, this is set to $(PROJECT_DIR)/build.

If enabled, only the active architecture is built. This setting will be ignored when building with a run destination which does not define a specific architecture, such as a ‘Generic Device’ run destination.

Defined a set of initial On Demand Resources tags to be downloaded and installed with your application.

Once your app is installed, this defined a set of On Demand Resources tags that should be downloaded. These tags are downloaded after the initial installation of your application, and will be downloaded in the order the tags provided in the list from first to last.

The path to a file that alters the order in which functions and data are laid out.

For each section in the output file, any symbol in that section that are specified in the order file is moved to the start of its section and laid out in the same order as in the order file. Order files are text files with one symbol name per line. Lines starting with a # are comments. A symbol name may be optionally preceded with its object file leafname and a colon (for example, foo.o:_foo). This is useful for static functions/data that occur in multiple files. A symbol name may also be optionally preceded with the architecture (for example, ppc:_foo or ppc:foo.o:_foo). This enables you to have one order file that works for multiple architectures. Literal C-strings may be ordered by quoting the string in the order file (for example, "Hello, world\n").

Generally you should not specify an order file in Debug or Development configurations, as this will make the linked binary less readable to the debugger. Use them only in Release or Deployment configurations.

Space-separated list of additional flags to pass to the compiler for C and Objective-C files. Be sure to backslash-escape any arguments that contain spaces or special characters, such as path names that may contain spaces. Use this setting if Xcode does not already provide UI for a particular C or Objective-C compiler flag.

A list of additional options to pass to codesign(1).

Space-separated list of additional flags to pass to the compiler for C++ and Objective-C++ files. Be sure to backslash-escape any arguments that contain spaces or special characters, such as path names that may contain spaces. Use this setting if Xcode does not already provide UI for a C++ or Objective-C++ compiler flag.

Options defined in this setting are passed to invocations of the linker.

Options defined in this setting are passed to all invocations of the archive librarian, which is used to generate static libraries.

Options defined in this setting are passed to invocations of the Text-Based InstallAPI tool.

Specifies the output encoding for property list files (.plist). The output encodings can be binary or XML. By default, the output encoding will be unchanged from the input.

This setting allows for better control of sharing precompiled prefix header files between projects. By default, Xcode assumes that the prefix header file may include header files from the build directory if the build directory is outside of the project directory. Xcode cannot determine this ahead of time since other projects may not have been built into the shared build directory at the time the information is needed.

If your prefix file never includes files from the build directory you may set this to NO to improve sharing of precompiled headers. If the prefix does use files from a build directory that is inside your project directory, you may set this to YES to avoid unintended sharing that may result in build failures.

Additional flags to pass when performing a single-object prelink.

Additional libraries to pass when performing a single-object prelink.

Activating this setting, in combination with the Dead Code Stripping (DEAD_CODE_STRIPPING) (-dead_strip) option, causes the -no_dead_strip_inits_and_terms flag to be passed to ld(1) via cc(1) to disable dead code stripping for initialization and termination routines. This option should not be used without the aforementioned Dead Code Stripping (DEAD_CODE_STRIPPING) option.

The location to copy the private headers to during building, relative to the built products folder.

A string that uniquely identifies the bundle. The string should be in reverse DNS format using only alphanumeric characters (A-Z, a-z, 0-9), the dot (.), and the hyphen (-). This value is used as the CFBundleIdentifier in the Info.plist of the built bundle.

The name to use for the source code module constructed for this target, and which will be used to import the module in implementation source files. Must be a valid identifier.

This is the basename of the product generated by the target.

The name of the current project.

Identifies the directory in which the project’s intermediate build files are placed. This directory is shared between all the targets defined by the project. Run Script build phases should generate intermediate build files in the directory identified by DERIVED_FILE_DIR, not the location this build setting specifies.

Must contain a profile name (or UUID). A missing or invalid profile will cause a build error. Use in conjunction with Development Team (DEVELOPMENT_TEAM) to fully specify provisioning profile.

The location to copy the public headers to during building, relative to the built products folder.

List of framework names that should have their symbols be reexported from the built library.

List of library names that should have their symbols be reexported from the built library.

List of library paths that should have their symbols be reexported from the built library.

Specifies whether to remove CVS directories from bundle resources when they are copied.

Specifies whether to remove .git directories from bundle resources when they are copied.

Specifies whether to remove .hg directories from bundle resources when they are copied.

Specifies whether to remove SVN directories from bundle resources when they are copied.

Overrides Targeted Device Family (TARGETED_DEVICE_FAMILY) when the resource copying needs to differ from the default targeted device.

This is a list of paths to search for files with resource manager resources. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.

Activating this setting will cause all source files to be scanned for includes (for example, of header files) when computing the dependency graph, in which case if an included file is changed then the including file will be rebuilt next time a target containing it is built. Normally only certain types of files, such as C-language source files, are scanned.

This setting is useful if your project contains files of unusual types, which are compiled using a custom build rule.

The name or path of the base SDK being used during the build. The product will be built against the headers and libraries located inside the indicated SDK. This path will be prepended to all search paths, and will be passed through the environment to the compiler and linker. Additional SDKs can be specified in the Additional SDKs (ADDITIONAL_SDKS) setting.

These flags are typically used to specify options for ordering symbols within segments, for example the -sectorder option to ld.

Generally you should not specify symbol ordering options in Debug or Development configurations, as this will make the linked binary less readable to the debugger. Use them only in Release or Deployment configurations.

Activating this setting when the linked product’s symbols are to be edited will cause editing to occur via a separate invocation of nmedit(1). Otherwise editing will occur during linking, if possible.

The path where precompiled prefix header files are placed during a build. Defaults to $(OBJROOT)/SharedPrecompiledHeaders. Using a common location allows precompiled headers to be shared between multiple projects.

If enabled, don’t install built products even if deployment locations are active.

Identifies the directory containing the target’s source files.

Specify the encoding to be used for Strings files (by default, the output encoding will be 16-bit Unicode). The value can be either an NSStringEncoding, such as one of the numeric values recognized by NSString, or it can be an IANA character set name as understood by CFString. The operation will fail if the file cannot be converted to the specified encoding.

Additional flags to be passed when stripping the linked product of the build.

If enabled, the linked product of the build will be stripped of symbols when performing deployment postprocessing.

The level of symbol stripping to be performed on the linked product of the build. The default value is defined by the target’s product type.

• All Symbols: Completely strips the binary, removing the symbol table and relocation information. all, -s

• Non-Global Symbols: Strips non-global symbols, but saves external symbols. non-global, -x

• Debugging Symbols: Strips debugging symbols, but saves local and global symbols. debugging, -S

Adjust the level of symbol stripping specified by the STRIP_STYLE setting so that when the linked product of the build is stripped, all Swift symbols will be removed.

The list of supported platforms from which a base SDK can be used. This setting is used if the product can be built for multiple platforms using different SDKs.

Enable to indicate that the target supports Text-Based InstallAPI, which will enable its generation during install builds.

The path at which all products will be placed when performing a build. Typically this path is not set per target, but is set per-project or per-user. By default, this is set to $(PROJECT_DIR)/build.

This is a list of paths to folders containing system frameworks to be searched by the compiler for both included or imported header files when compiling C, Objective-C, C++, or Objective-C++, and by the linker for frameworks used by the product. The order is from highest to lowest precedence. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted. This setting is very similar to “Framework Search Paths”, except that the search paths are passed to the compiler in a way that suppresses most warnings for headers found in system search paths. If the compiler doesn’t support the concept of system framework search paths, then the search paths are appended to any existing framework search paths defined in “Framework Search Paths”.

This is a list of paths to folders to be searched by the compiler for included or imported system header files when compiling C, Objective-C, C++, or Objective-C++. The order is from highest to lowest precedence. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted. This setting is very similar to “Header Search Paths”, except that headers are passed to the compiler in a way that suppresses most warnings for headers found in system search paths. If the compiler doesn’t support the concept of system header search paths, then the search paths are appended to any existing header search paths defined in “Header Search Paths”.

Selects the level of warnings and errors to report when building Text-Based InstallAPI.

Identifies the root of the directory hierarchy that contains the product’s files (no intermediate build files). Run Script build phases that operate on product files of the target that defines them should use the value of this build setting, but Run Script build phases that operate on product files of other targets should use BUILT_PRODUCTS_DIR instead.

The name of the current target.

Identifies the directory containing the target’s intermediate build files. Run Script build phases should place intermediate files at the location indicated by DERIVED_FILE_DIR, not the directory identified by this build setting.

Path to the executable into which a bundle of tests is injected. Only specify this setting if testing an application or other executable.

When running tests that measure performance via XCTestCase, report missing baselines as test failures.

A project-relative path to a file that lists the symbols not to export. See ld -exported_symbols_list for details on exporting symbols.

This is a list of paths to folders to be searched by the compiler for included or imported user header files (those headers listed in quotes) when compiling C, Objective-C, C++, or Objective-C++. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted. See Always Search User Paths (Deprecated) (ALWAYS_SEARCH_USER_PATHS) for more details on how this setting is used. If the compiler doesn’t support the concept of user headers, then the search paths are prepended to the any existing header search paths defined in Header Search Paths (HEADER_SEARCH_PATHS).

Enable the use of Header Maps, which provide the compiler with a mapping from textual header names to their locations, bypassing the normal compiler header search path mechanisms. This allows source code to include headers from various locations in the file system without needing to update the header search path build settings.

If enabled, perform validation checks on the workspace configuration as part of the build process.

List of framework names for which to suppress deprecation warnings and missing framework errors in the workspace validator.

A space-separated list of architectures for which the target should actually be built. For each target, this is intersected with the list specified in Architectures (ARCHS), and the resulting set is built. This allows individual targets to opt out of building for particular architectures. If the resulting set of architectures is empty, no executable will be produced.

Selects the process used for version-stamping generated files.

• None: Use no versioning system.

• Apple Generic: Use the current project version setting. apple-generic

This defines a reference to the user performing a build to be included in the generated Apple Generic Versioning stub. Defaults to the value of the USER environment variable.

This defines a prefix string for the version info symbol declaration in the generated Apple Generic Versioning stub. This can be used, for example, to add an optional export keyword to the version symbol declaration. This should rarely be changed.

Used to specify a name for the source file that will be generated by Apple Generic Versioning and compiled into your product. By default, this is set to $(PRODUCT_NAME)_vers.c.

Used as a prefix for the name of the version info symbol in the generated versioning source file. If you prefix your exported symbols you will probably want to set this to the same prefix.

Used as a suffix for the name of the version info symbol in the generated versioning source file. This is rarely used.

These flags are passed with linker invocations, and by default give the -no_arch_warnings flag to the linker to avoid many warnings being generated during multi-architecture builds.

The extension used for product wrappers, which has a default value based on the product type.

The locations of any sparse SDKs that should be layered on top of the one specified by Base SDK (SDKROOT). If more than one SDK is listed, the first one has highest precedence. Every SDK specified in this setting should be a “sparse” SDK, for example, not an SDK for an entire macOS release.

This setting is deprecated as of Xcode 8.3 and may not be supported in future versions. It is recommended that you disable the setting.

If enabled, both #include <header.h>-style and #include "header.h"-style directives search the paths in User Header Search Paths (USER_HEADER_SEARCH_PATHS) before Header Search Paths (HEADER_SEARCH_PATHS). As a consequence, user headers, such as your own String.h header, have precedence over system headers when using #include <header.h>. This is done using the -iquote flag for the paths provided in User Header Search Paths (USER_HEADER_SEARCH_PATHS). If disabled and your compiler fully supports separate user paths, user headers are only accessible with #include "header.h"-style preprocessor directives.

For backwards compatibility reasons, this setting is enabled by default. Disabling it is strongly recommended.

Enabling this setting will cause files in the target’s Copy Files build phases to be processed by build rules. For example, property list files (.plist) and strings files will be converted as specified by Property List Output Encoding (PLIST_FILE_OUTPUT_FORMAT) and Strings File Output Encoding (STRINGS_FILE_OUTPUT_ENCODING), respectively.

Specifies the directory inside the generated bundle that contains the product’s files.

Enabling this setting will create a section in the product’s linked binary containing the processed Info.plist file for the target. This setting only applies to command-line tool targets.

The name of the active architecture being processed.

This setting defines the current version of the project. The value must be a integer or floating point number, such as 57 or 365.8.

The name of the active variant being processed.

The type of debug information to produce.

• DWARF: Object files and linked products will use DWARF as the debug information format. dwarf

• DWARF with dSYM File: Object files and linked products will use DWARF as the debug information format, and Xcode will also produce a dSYM file containing the debug information from the individual object files (except that a dSYM file is not needed and will not be created for static library or object file products). dwarf-with-dsym

If enabled, built products are placed in their installed locations in addition to the built products folder.

Identifies the directory that contains the bundle’s documentation files.

If enabled, don’t automatically generate an Info.plist file for wrapped products when the Info.plist File (INFOPLIST_FILE) build setting is empty.

Determines the compatibility version of the resulting library, bundle, or framework binary. See Dynamic Library Design Guidelines in Dynamic Library Programming Topics for details on assigning version numbers of dynamic libraries.

This setting defines the current version of any framework built by the project. As with Current Project Version (CURRENT_PROJECT_VERSION), the value must be an integer or floating point number, such as 57 or 365.8. By default, it is set to $(CURRENT_PROJECT_VERSION). See Dynamic Library Design Guidelines in Dynamic Library Programming Topics for details on assigning version numbers of dynamic libraries.

This is a list of fnmatch()-style patterns of file or directory names to exclude when performing a recursive search. By default, this is set to *.nib *.lproj *.framework *.gch *.xcode (*) .DS_Store CVS .svn .git .hg. Normally, if you override this value you should include the default values via the $(inherited) macro.

Identifies the directory that contains additional binary files.

This is the extension used for the executable product generated by the target, which has a default value based on the product type.

Identifies the directory that contains the binary the target builds.

Specifies the name of the binary the target produces.

Specifies the path to the binary the target produces within its bundle.

The prefix used for the executable product generated by the target, which has a default value based on the product type.

Specifies the suffix of the binary filename, including the character that separates the extension from the rest of the bundle name.

Specifies the directory that contains the product’s embedded frameworks.

This is a list of paths to folders containing frameworks to be searched by the compiler for both included or imported header files when compiling C, Objective-C, C++, or Objective-C++, and by the linker for frameworks used by the product. Paths are delimited by whitespace, so any paths with spaces in them must be properly quoted.

Generates a precompiled header for the prefix header, which should reduce overall build times.

Precompiling the prefix header will be most effective if the contents of the prefix header or any file it includes change rarely. If the contents of the prefix header or any file it includes change frequently, there may be a negative impact to overall build time.

Implicitly include the named header. The path given should either be a project relative path or an absolute path.

Enabling this option causes all warnings to be treated as errors.

The compiler to use for C, C++, and Objective-C.

Forces the PkgInfo file to be written to wrapped products even if this file is not expected.

Activating this setting will cause the compiler and linker to generate profiling code. For example, GCC will generate code suitable for use with gprof(1).

This is a list of paths to folders to be searched by the compiler for included or imported header files when compiling C, Objective-C, C++, or Objective-C++. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.

This is a list of fnmatch()-style patterns of file or directory names to include when performing a recursive search. By default, this is empty and is only customized when you want to provide exceptions to the list of filename patterns provided in Sub-Directories to Exclude in Recursive Searches (EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES).

Expand build settings in the Info.plist file.

The project-relative path to the property list file that contains the Info.plist information used by bundles. For details on information property list files, see Information Property List Files in Runtime Configuration Guidelines.

Specifies the output encoding for the output Info.plist. The output encodings can be binary or XML. By default, the output encoding will be unchanged from the input.

Specifies the path to the bundle’s information property list file.

Specifies the file that contains the bundle’s localized strings file.

This is the name of the routine to use for initialization.

This setting restricts the clients allowed to link a dylib by passing -allowable_client to the linker for each supplied value.

Space-separated list of additional flags to pass to lex. Be sure to backslash-escape any arguments that contain spaces or special characters, such as path names that may contain spaces. Use this setting if Xcode does not already provide UI for a lex flag.

This is a list of paths to folders to be searched by the linker for libraries used by the product. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.

This setting defines the user-visible version of the project. The value corresponds to the CFBundleShortVersionString key in your app’s Info.plist.

Specifies the directory that contains the product’s Clang module maps and Swift module content.

The path to a file that alters the order in which functions and data are laid out.

For each section in the output file, any symbol in that section that are specified in the order file is moved to the start of its section and laid out in the same order as in the order file. Order files are text files with one symbol name per line. Lines starting with a # are comments. A symbol name may be optionally preceded with its object file leafname and a colon (for example, foo.o:_foo). This is useful for static functions/data that occur in multiple files. A symbol name may also be optionally preceded with the architecture (for example, ppc:_foo or ppc:foo.o:_foo). This enables you to have one order file that works for multiple architectures. Literal C-strings may be ordered by quoting the string in the order file (for example, "Hello, world\n").

Generally you should not specify an order file in Debug or Development configurations, as this will make the linked binary less readable to the debugger. Use them only in Release or Deployment configurations.

Options defined in this setting are passed to invocations of the linker.

Options defined in this setting are passed to all invocations of the archive librarian, which is used to generate static libraries.

Space-separated list of additional flags to pass to mig. Be sure to backslash-escape any arguments that contain spaces or special characters, such as path names that may contain spaces. Use this setting if Xcode does not already provide UI for a mig flag.

Space-separated list of additional flags to pass to the Rez compiler. Be sure to backslash-escape any arguments that contain spaces or special characters, such as path names that may contain spaces. Use this setting if Xcode does not already provide UI for a particular Rez flag.

Uniform type identifier. Identifies the type of the product the target builds. Some products may be made up of a single binary or archive. Others may comprise several files, which are grouped under a single directory. These container directories are known as bundles.

Specifies the output encoding for property list files (.plist). The output encodings can be binary or XML. By default, the output encoding will be unchanged from the input.

Specifies the directory that contains the product’s plugins.

This setting allows for better control of sharing precompiled prefix header files between projects. By default, Xcode assumes that the prefix header file may include header files from the build directory if the build directory is outside of the project directory. Xcode cannot determine this ahead of time since other projects may not have been built into the shared build directory at the time the information is needed.

If your prefix file never includes files from the build directory you may set this to NO to improve sharing of precompiled headers. If the prefix does use files from a build directory that is inside your project directory, you may set this to YES to avoid unintended sharing that may result in build failures.

The location to copy the private headers to during building, relative to the built products folder.

The location to copy the public headers to during building, relative to the built products folder.

Specifies whether to keep copies of unstripped binaries available.

Specifies the directory in which the collected Resource Manager resources generated by ResMerger are stored before they are added to the product.

Specifies the directory in which compiled Resource Manager resources generated by Rez are stored before they are collected using ResMerger.

This is a list of paths to search for files with resource manager resources. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.

Specifies the directory that contains the product’s scripts.

The name or path of the base SDK being used during the build. The product will be built against the headers and libraries located inside the indicated SDK. This path will be prepended to all search paths, and will be passed through the environment to the compiler and linker. Additional SDKs can be specified in the Additional SDKs (ADDITIONAL_SDKS) setting.

These flags are typically used to specify options for ordering symbols within segments, for example the -sectorder option to ld.

Generally you should not specify symbol ordering options in Debug or Development configurations, as this will make the linked binary less readable to the debugger. Use them only in Release or Deployment configurations.

Specifies the directory that contains the product’s shared frameworks.

The path where precompiled prefix header files are placed during a build. Defaults to $(OBJROOT)/SharedPrecompiledHeaders. Using a common location allows precompiled headers to be shared between multiple projects.

Specify the encoding to be used for Strings files (by default, the output encoding will be 16-bit Unicode). The value can be either an NSStringEncoding, such as one of the numeric values recognized by NSString, or it can be an IANA character set name as understood by CFString. The operation will fail if the file cannot be converted to the specified encoding.

Additional flags to be passed when stripping the linked product of the build.

If enabled, the linked product of the build will be stripped of symbols when performing deployment postprocessing.

The list of supported platforms from which a base SDK can be used. This setting is used if the product can be built for multiple platforms using different SDKs.

Specifies the directory that contains the product’s unlocalized resources.

This is a list of paths to folders to be searched by the compiler for included or imported user header files (those headers listed in quotes) when compiling C, Objective-C, C++, or Objective-C++. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted. See Always Search User Paths (Deprecated) (ALWAYS_SEARCH_USER_PATHS) for more details on how this setting is used. If the compiler doesn’t support the concept of user headers, then the search paths are prepended to the any existing header search paths defined in Header Search Paths (HEADER_SEARCH_PATHS).

Enable the use of Header Maps, which provide the compiler with a mapping from textual header names to their locations, bypassing the normal compiler header search path mechanisms. This allows source code to include headers from various locations in the file system without needing to update the header search path build settings.

If enabled, perform validation checks on the product as part of the build process.

Specifies whether the target’s Copy Files build phases generate additional information when copying files.

Selects the process used for version-stamping generated files.

• None: Use no versioning system.

• Apple Generic: Use the current project version setting. apple-generic

This defines a reference to the user performing a build to be included in the generated Apple Generic Versioning stub. Defaults to the value of the USER environment variable.

This defines a prefix string for the version info symbol declaration in the generated Apple Generic Versioning stub. This can be used, for example, to add an optional export keyword to the version symbol declaration. This should rarely be changed.

Used to specify a name for the source file that will be generated by Apple Generic Versioning and compiled into your product. By default, this is set to $(PRODUCT_NAME)_vers.c.

Used as a prefix for the name of the version info symbol in the generated versioning source file. If you prefix your exported symbols you will probably want to set this to the same prefix.

Used as a suffix for the name of the version info symbol in the generated versioning source file. This is rarely used.

These flags are passed with linker invocations, and by default give the -no_arch_warnings flag to the linker to avoid many warnings being generated during multi-architecture builds.

The extension used for product wrappers, which has a default value based on the product type.

Specifies the filename, including the appropriate extension, of the product bundle.

Specifies the suffix of the product bundle name, including the character that separates the extension from the rest of the bundle name.

Space-separated list of additional flags to pass to yacc. Be sure to backslash-escape any arguments that contain spaces or special characters, such as path names that may contain spaces. Use this setting if Xcode does not already provide UI for a yacc flag.

Specifies the executable that will load the bundle output file being linked. Undefined symbols from the bundle are checked against the specified executable as if it is one of the dynamic libraries the bundle was linked with.

Activating this setting causes the -dead_strip flag to be passed to ld(1) via cc(1) to turn on dead code stripping.

This is a project-relative path to a file that lists the symbols to export. See ld -exported_symbols_list for details on exporting symbols.

This is a list of paths to folders containing frameworks to be searched by the compiler for both included or imported header files when compiling C, Objective-C, C++, or Objective-C++, and by the linker for frameworks used by the product. Paths are delimited by whitespace, so any paths with spaces in them must be properly quoted.

Activating this setting will cause the compiler and linker to generate profiling code. For example, GCC will generate code suitable for use with gprof(1).

This is the name of the routine to use for initialization.

Activating this setting will preserve private external symbols, rather than turning them into static symbols. This setting is also respected when performing a single-object prelink.

This setting defines the path to which the linker should emit information about what files it used as inputs and generated. Xcode uses this information for its dependency tracking. Setting the value of this setting to empty will disable passing this option to the linker.

This setting restricts the clients allowed to link a dylib by passing -allowable_client to the linker for each supplied value.

Sets an internal install path (LC_ID_DYLIB) in a dynamic library. Any clients linked against the library will record that path as the way dyld should locate this library. If this option is not specified, then the -o path will be used. This setting is ignored when building any product other than a dynamic library. See Dynamic Library Programming Topics.

Activating this setting will cause the linker to write a map file to disk, which details all symbols and their addresses in the output image. The path to the map file is defined by the Path to Link Map File (LD_MAP_FILE_PATH) setting.

This setting defines the path to the map file written by the linker when the Write Link Map File (LD_GENERATE_MAP_FILE) setting is activated. By default, a separate file will be written for each architecture and build variant, and these will be generated in the Intermediates directory for the target whose product is being linked.

Activating this setting will prevent Xcode from building a main executable that is position independent (PIE). When targeting macOS 10.7 or later, PIE is the default for main executables, so activating this setting will change that behavior. When targeting OS X 10.6 or earlier, or when building for i386, PIE is not the default, so activating this setting does nothing.

You cannot create a PIE from .o files compiled with -mdynamic-no-pic. Using PIE means the codegen is less optimal, but the address randomization adds some security.

This setting controls whether arguments to the linker should be quoted using -Xlinker. By default, Xcode invokes the linker by invoking the driver of the compiler used to build the source files in the target, and passing -Xlinker to quote arguments will cause the compiler driver to pass them through to the linker (rather than trying to evaluate them within the driver). By default, this setting is enabled. Disabling it will cause Xcode to not use -Xlinker to pass arguments to the linker. Disabling this setting is useful if the target has instructed Xcode to use an alternate linker (for example, by setting the LD setting to the path to another linker) and that alternate linker does not recognize -Xlinker.

This is a list of paths to be added to the runpath search path list for the image being created. At runtime, dyld uses the runpath when searching for dylibs whose load path begins with @rpath/. See Dynamic Library Programming Topics.

This is a list of paths to folders to be searched by the linker for libraries used by the product. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.

Activating this setting causes the linker to display mangled names for C++ symbols. Normally, this is not recommended, but turning it on can help to diagnose and solve C++ link errors.

When this setting is enabled, the compiler driver will automatically pass its standard libraries to the linker to use during linking. If desired, this flag can be used to disable linking with the standard libraries, and then individual libraries can be passed as Other Linker Flags (OTHER_LDFLAGS).

This setting determines the format of the produced binary and how it can be linked when building other binaries. For information on binary types, see Building Mach-O Files in Mach-O Programming Topics.

• Executable: Executables and standalone binaries and cannot be linked. mh_execute

• Dynamic Library: Dynamic libraries are linked at build time and loaded automatically when needed. mh_dylib

• Bundle: Bundle libraries are loaded explicitly at run time. mh_bundle

• Static Library: Static libraries are linked at build time and loaded at execution time. staticlib

• Relocatable Object File: Object files are single-module files that are linked at build time. mh_object

The path to a file that alters the order in which functions and data are laid out.

For each section in the output file, any symbol in that section that are specified in the order file is moved to the start of its section and laid out in the same order as in the order file. Order files are text files with one symbol name per line. Lines starting with a # are comments. A symbol name may be optionally preceded with its object file leafname and a colon (for example, foo.o:_foo). This is useful for static functions/data that occur in multiple files. A symbol name may also be optionally preceded with the architecture (for example, ppc:_foo or ppc:foo.o:_foo). This enables you to have one order file that works for multiple architectures. Literal C-strings may be ordered by quoting the string in the order file (for example, "Hello, world\n").

Generally you should not specify an order file in Debug or Development configurations, as this will make the linked binary less readable to the debugger. Use them only in Release or Deployment configurations.

Activating this setting, in combination with the Dead Code Stripping (DEAD_CODE_STRIPPING) (-dead_strip) option, causes the -no_dead_strip_inits_and_terms flag to be passed to ld(1) via cc(1) to disable dead code stripping for initialization and termination routines. This option should not be used without the aforementioned Dead Code Stripping (DEAD_CODE_STRIPPING) option.

List of framework names that should have their symbols be reexported from the built library.

List of library names that should have their symbols be reexported from the built library.

List of library paths that should have their symbols be reexported from the built library.

The name or path of the base SDK being used during the build. The product will be built against the headers and libraries located inside the indicated SDK. This path will be prepended to all search paths, and will be passed through the environment to the compiler and linker. Additional SDKs can be specified in the Additional SDKs (ADDITIONAL_SDKS) setting.

This is a list of paths to folders containing system frameworks to be searched by the compiler for both included or imported header files when compiling C, Objective-C, C++, or Objective-C++, and by the linker for frameworks used by the product. The order is from highest to lowest precedence. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted. This setting is very similar to “Framework Search Paths”, except that the search paths are passed to the compiler in a way that suppresses most warnings for headers found in system search paths. If the compiler doesn’t support the concept of system framework search paths, then the search paths are appended to any existing framework search paths defined in “Framework Search Paths”.

A project-relative path to a file that lists the symbols not to export. See ld -exported_symbols_list for details on exporting symbols.

Additional flags to be passed when stripping the linked product of the build.

The level of symbol stripping to be performed on the linked product of the build. The default value is defined by the target’s product type.

• All Symbols: Completely strips the binary, removing the symbol table and relocation information. all, -s

• Non-Global Symbols: Strips non-global symbols, but saves external symbols. non-global, -x

• Debugging Symbols: Strips debugging symbols, but saves local and global symbols. debugging, -S

Adjust the level of symbol stripping specified by the STRIP_STYLE setting so that when the linked product of the build is stripped, all Swift symbols will be removed.

This is a project-relative path to a file that lists the symbols to export. See ld -exported_symbols_list for details on exporting symbols.

This is a list of paths to folders to be searched by the linker for libraries used by the product. Paths are delimited by whitespace, so any paths with spaces in them need to be properly quoted.