Specify the location of the path (usually BUILD_DIR specified by xcodebuild) to read the Archive for exporting the IPA file.
Supports all macros and also environment and build variables from the Token Macro Plugin.
For example you can use the value :

${WORKSPACE}/build

Checking this option will prevent a build step from failing if xcodebuild exits with a non-zero return code.
This can be useful for build steps that run unit tests and also have a post-build task to publish unit test results: the test step will not fail the entire build for a failing unit test, but will instead mark the build unstable in the "publish test" phase.

The value to use for the BUILD_DIR setting. You only need to supply this value if you want the product of the Xcode build to be in a location other than the one specified in project settings and this job 'SYMROOT' parameter.
Supports all macros and also environment and build variables from the Token Macro Plugin.
For example you can use the value :

${WORKSPACE}/build

Checking this option will create a .ipa for each .app found in the build directory.
An .ipa is basically a zipped up .app.
This is quite handy for distributing ad-hoc builds to testers as they can just double-click the .ipa and it will import into iTunes.

The new bundle ID. Usually something like com.companyname.projectname.

The path to the info.plist file which contains the CFBundleIdentifier of your project.
Usually something like:

• ${WORKSPACE}/ProjectName/Project-Info.plist

This will set the CFBundleShortVersionString to the specified string.
Supports all macros and also environment and build variables from the Token Macro Plugin.

This will set the CFBundleVersion to the specified string.
Supports all macros and also environment and build variables from the Token Macro Plugin.
For example the value ${BUILD_NUMBER} will be replaced with the current build number.
We advice you to generate a unique value for each build if you want for example deploy it into a private store.
In that case, for example, you can use : ${JOB_NAME}-${BUILD_NUMBER}

Checking this option will replace the bundle identifier.
You will need to specify which bundle ID (CFBundleIdentifier) to use and where is the Info.plist file located.
This is handy for example when you want to use a different code signing identity in your development projects.

This will delete the build directories before invoking the build. This will force the rebuilding of ALL dependencies and can make large projects take a lot longer.

This will delete the ResultBundlePath before invoking the build.
If the directory already exists in the location specified by ResultBundlePath, xcodebuild will be an error and should be checked.

This is the name of the configuration as defined in the Xcode project.
By default there are Debug and Release configurations.

Checking this option will create an .xcarchive .app found in the build directory.
An .xcarchive is useful for submission to the app store or third party crash reporters.
You must specify a Scheme to perform an archive.

Build all entries listed under the "Targets:" section of the xcodebuild -list output that match the regexp.

The name of this configured keychain. Each job will specify a keychain configuration by the name.

The path of the keychain to use to retrieve certificates to sign the package (default : ${HOME}/Library/Keychains/login.keychain).

The password of the keychain to use to retrieve certificates to sign the package.

Specify the directory to output the log of xcodebuild.
If you leave it blank, it will be output to "project directory/builds/${BUILD_NUMBER}/log" with other logs.
If an output path is specified, it is output as a xcodebuild.log file in a relative directory under the "build output directory"

Specify the directory to output the output the test result.
If you leave it blank, it will not output a test result and will not analyze the test results.
If an output path is specified, it is output as a test result in a relative directory under the "ResultBundlePath".
The plug-in analyzes the test result here and outputs a JUnit compatible XML file under the ${WORKSPACE}/test-reports.

You only need to supply this value if you want to specify the SDK to build against. If empty, the SDK will be determined by Xcode. If you wish to run OCUnit tests, you will need to use the iPhone Simulator's SDK, for example:

/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.1.sdk/

You only need to supply this value if you want to specify the SYMROOT path to use.
If empty, the default SYMROOT path will be used (it could be different depending of your Xcode version).
Supports all macros and also environment and build variables from the Token Macro Plugin.
For example you can use the value :

${WORKSPACE}/symroot

The target to build. If left empty, this will build all targets in the project.
If you wish to build your binary and the unit test module, it is best to do this as two separate steps each with their own target.
This was, the iPhone Simulator SDK can be specified for the unit tests.

Instead of "New Builld System" which became available from Xcode 9, we build the application using the legacy build system.
There is a possibility that you can handle old projects that cause problems with the new build system.
Also, since new output formats of logs are changed in the new build system, it is also useful when you want to handle logs with legacy third party tools.

Extra xcodebuild parameters, added after the command that jenkins generates based on the rest of the config