---
title: Customizing the build schemes for a project
framework: xcode
role: article
role_heading: Article
path: xcode/customizing-the-build-schemes-for-a-project
---

# Customizing the build schemes for a project

Specify which targets to build, and customize the settings Xcode uses to build, run, test, and profile those targets.

## Overview

Overview When you build, run, test, profile, or archive part of your project, Xcode uses the selected build scheme to determine what to do. A build scheme contains a list of targets to build, and any configuration and environment details that affect the selected action. For example, when you build and run an app, the scheme tells Xcode what launch arguments to pass to the app. Xcode provides default schemes for most targets, and you can customize those schemes or create new ones as needed. To view your project’s current schemes, click the scheme name in the toolbar of your project window. Xcode displays a pop-up menu with a list of current schemes at the top, and commands to edit, create, and manage schemes at the bottom.

To view and modify your project’s current schemes, select Manage Schemes. For example, disable automatic creation of schemes for new targets, and change scheme attributes such as which project contains the scheme. By default, Xcode shares schemes with other team members.

Specify the build options for a scheme’s targets When you tell Xcode to build a scheme, Xcode analyzes your project and generates the list of tasks required to build the targets of that scheme. To speed up builds, Xcode executes as many tasks as possible in parallel, taking advantage of whatever resources are available. To ensure that products build correctly, Xcode serializes tasks when dependencies exist between them. For example, Xcode builds a private framework before it builds the app that links against that framework. To see a scheme’s current list of targets, edit the scheme and select the Build page. Use this page to add or remove targets and to configure additional build options.

The following table lists the build options you can configure for your schemes.  |   |   |   |  Specify launch arguments and environment variables If your product configures itself using command-line arguments or environment variables, specify that information on the Arguments tab of the Run, Test, or Profile build scheme action. Xcode configures and exports environment variables before it runs the process. Xcode passes command-line arguments directly to the launched process. Configure the runtime environment for built products In the Run, Test, and Profile build scheme actions, the Info tab contains high-level information about how to launch and run your product. Some options are available for all build actions, but some options are specific to the current build action. The following table lists the available options.  |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |  Xcode uses information in the Options tab to configure the runtime environment for a product. Use these options to override language settings or specify simulated device data such as the current location. The following table lists the available options.  |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |  Run diagnostics on your target Xcode includes tools to validate the stability of your code and eliminate potential bugs. These tools annotate your code with runtime checks that examine specific types of operations. For example, one tool detects potential race conditions between your app’s threads. Enable these checks from the Diagnostics tab of your build scheme. The following table lists the supported diagnostics.  |  |   |  |   |  |   |  |   |  |  To detect memory-related issues, Xcode supports the following diagnostics: Malloc Scribble writes the value 0x55 to every byte of a released memory block. This action helps you detect code that accesses the released block. Malloc Guard Edges adds guard pages before and after large allocations. These pages detect code writes beyond the boundaries of an allocated memory block. Guard Malloc uses several techniques to crash your app at the point where a memory error occurs. Zombie Objects detects code that tries to access an already released object. Malloc Stack Logging captures function call stack information at the time of each memory allocation. Memory Graph on Resource Exception captures information about your memory graph. You can view the information in the debugger. Run tasks before or after scheme actions For each action in your scheme, you can run scripts or send emails before or after Xcode performs that action using pre-actions and post-actions. For example, you might use a post-action to log test results to a custom server each time you run your code. Unlike build phases, Xcode executes your actions only when you select the appropriate command from the Product menu. To add a pre-action or post-action: Click the disclosure triangle for the action. Select Pre-actions or Post-actions Click the Add button (+) and select the type of action to add. Configure the details of the action.

For script actions, Xcode exposes the build settings for one of the scheme’s selected targets. Use environment variables to access the values of those variables. For a list of available build settings, see Build settings reference.

## See Also

### Build customization

- [Customizing the build phases of a target](xcode/customizing-the-build-phases-of-a-target.md)
- [Creating build rules for custom file types](xcode/creating-build-rules-for-custom-file-types.md)
- [Running custom scripts during a build](xcode/running-custom-scripts-during-a-build.md)
- [Running code on a specific platform or OS version](xcode/running-code-on-a-specific-version.md)
