Xcode Concepts
Xcode Target
A target is specifically used to build a product, a set of files contained in a project or workspace, and a target defines a product. It organizes the inputs to the build system — the source files and the instructions to process those source files — needed to build the product. Projects can contain one or more arGets, each of which produces a product.
The build instructions for the product come from Build Settings and Build Phases, which can be modified and edited in the Xcode Project editor. The build Settings of target are inherited from the build Settings of project, and can be overridden at the target level. The project uses the Target build option first, and can only run one target at a time. The Xcode Scheme configures the target to run
Target and the products built by target can be associated with another target. If a target needs the output of another target to build, the first target is said to depend on the second target. If both targets are under the same workspace, Xcode can discover the dependencies, in which case it builds products in the desired order. You can also specify explicit target dependencies in build Settings if there are implicit dependencies, and you can specify that the two Targets that Xcode might expect to have implicit dependencies are not actually dependent. For example, you can build both a library and an application linked to that library in the same workspace. Xcode can discover this relationship and automatically build the library first. However, if you do want to link to a library version other than the one built in workspace, you can create an explicit dependency in the build Settings, which overrides the implicit dependency.
Xcode Project
Xcode Project is a repository of all the files, resources, and information needed to build one or more software products. Project contains all the elements used to build products and maintain relationships between them. It contains one or more targets, which specify how to build the products. Project defines a default set of build Settings for all of its targets. (Each target can specify its own build Settings and override the project’s build Settings.)
An Xcode project contains the following information:
- A reference to the source file
- Source code, including header files and implementation files
- Libraries and Frameworks, internal and external
- Resource file
- Image files
- Interface Builder (NIB) file
- Groups for organizing source files in the structure navigator
- Project-level build configurations that specify multiple build configurations for a Project, such as build Settings for dubug and Release
- Targets, where each Target specifies:
- Project builds a reference to product
- The source file to reference to build the product
- Build configurations used to build the product, including dependencies on other targets and Settings, build Settings at project-level (parts that target does not need to override)
- An executable environment that can be used to debug or test a program. The execution environment specifies:
- An executable to launch when running or debugging from Xcode
- Command line arguments to pass to the executable, if any
- Environment variables to set when the program runs, if any
Projects can be standalone or included in a workspace.
You can use Xcode Schemes to specify build configurations and executable configurations for target to run.
Build Settings
Build Setting is a variable that contains information about how specific aspects of the Product build process should be performed. For example, the information in build Setting can specify options that Xcode passes to the compiler.
You can specify the Project level or target level build setting. The project-level build setting applies to all targets, where target has no separate build setting configured to override project.
A source file that a target organization needs to build a product. Build Configuration specifies the set of Build Settings used to build target’ product in a specific way. For example, there are typically separate build configurations for debug and release builds of products.
Build Settings in Xcode has two parts :setting title and The Definition. Build Setting Title Indicates that build Settings can be used in other Settings. Build Setting Definition is a constant or a formula that Xcode uses to determine the value of build Settings at build time. Build Setting may also have a display name for display in the Xcode user interface.
In addition to the default Build Settings provided by Xcode when creating a new project from the Project template, you can also create custom Build Settings for a project or a specific target. You can also specify a conditional build Settings. The value of the conditional Build Settings depends on whether one or more prerequisites are met. For example, this mechanism allows developers to specify SDKS for building products based on the target architecture.
Xcode Workspace
Workspace is an Xcode document that organizes projects and other documents so that they can be processed together. A workspace can contain as many Xcode projects as you want, as well as any other files you want.
Workspaces Extend the Scope of Your Workflow
Workspace extends the scope of the workflow
The project file contains Pointers to all the files in the project, as well as build Configurations and other project information. In Xcode 3 and earlier, the project file is always the root of groups and file structure hierarchies. Although a project can contain references to other projects, working with interrelated projects in Xcode 3 is complex and most workflows are limited to a single project. In Xcode 4 and later, you have the option of creating a Workspace to hold one or more projects, as well as any other files the developer wishes to include.
In addition to providing access to all files in each included Xcode project, Workspaces extends the scope of many important Xcode workflows. For example, because indexing is done in the entire Workspaces, code completion, jump to definition, and all other content-aware features work seamlessly in project entries in Workspaces. Because the refactoring operation works across everything in Workspaces, the API can be refactored in a Framework project and in multiple application projects that use the framework, all in one operation. When built, a project can use the products of other projects in Workspaces.
Workspace documents contain Pointers to the included projects and other files, but no additional data. A project can belong to more than one Workspace. The figure shows a Workspace with two Xcode Projects (Sketch and TextEdit) and a documentation project (Xcode4TransGuideDocPlan).
Projects in a Workspace Share a Build Directory
The Projects shared build directory in Workspace
By default, all Xcode projects in the Workspace are built in the same directory, called the Workspace Build Directory. Each workspace has its own build directory. Because all files in all projects in the workspace are in the same build directory, all of these files are visible to each project. Therefore, if two or more projects use the same library, there is no need to copy them separately into each project folder.
Xcode examines the files in the build directory to find implicit dependencies. For example, if a project contained in a workspace builds a library that is linked (referenced) to another project in the same workspace, Xcode automatically builds the library before building another project, Even if the Build Configuration does not specify this dependency. If necessary, such implicit dependencies can be overridden with explicit build Settings. For explicit dependencies, a project reference must be created.
Each project in the workspace continues to have its own independent identity. To process a project without affecting or being affected by other projects in the workspace, you can open the project without opening the workspace, or you can add the project to another workspace. Because a project can belong to multiple workspaces, projects can be processed in any number of combinations without having to reconfigure any projects or workspaces.
You can use the default build directory for workspace, or you can specify one. Note that if a project specifies a build directory, the original build directory will be overwritten.
You can use the workspace’s default build directory or you can specify one. Note that if a project specifies a build directory, that directory is overridden by the build directory of whatever workspace the project is in at the time you build the project.
Xcode Scheme
The Xcode Scheme defines the targets set to build, the configuration to use when building, and the set of tests to execute.
You can have any number of Schemes, but only one scheme can be activated at a time. You can specify whether Scheme should be stored in a project — in which case it is available in every workspace that contains the project — or in a workspace — in which case it is available only in that workspace. When you select a scheme, you also need to select a running target (that is, the architecture for which the hardware of products is built).
You can have as many schemes as you want, But only one can be active at a time. You can specify whether a scheme should be stored in a project — in which case it’s available in every workspace that includes that project, Or in the workspace — in which case it’s available only in that workspace. you also select a run destination (that is, the architecture of the hardware for which the products are built).
If there is a mistake, please indicate the source