Xcode what is a target

It is important to check how many users you are leaving behind. This is especially important if you offer a service users rely on or paid for. Before you consider raising the deployment target of a target, you need to decide whether it is appropriate to do so. What are the pros and cons?

It is usually obvious what you gain by raising the deployment target, but don't forget that it also has consequences for your application's userbase. Don't be too aggressive when it comes to raising the deployment target. I once read a story about a developer who lowered the deployment target because a significant number of users complained about no longer being able to receive updates.

Raising the deployment target requires careful planning. This isn't something you do in a bug fix release. I mentioned earlier that Xcode 12 no longer supports iOS 8. This can cause some issues with CocoaPods. This simply means that one or more dependencies pods you are using have a minimum deployment target set to 8. These phases are very generic definitions of actions. Then the target will then filter each file through the set of build rules to resolve the specific action to take based on the phase it is in.

Finally, the environment variables build settings are applied to the actions to invoke additional functionality. The intent of a target is to define an output build product for a set of conditions. Over time these conditions can become extremely complex, duplicating that complexity with minor changes across all targets can become a recipe for disaster. Fortunately Xcode provides a number of tools that allow us to consolidate the complexity into a single place where it is easier to manage.

Under the "Build Settings" panel of a target you can expand each setting to select a different option per configuration. Commonly they are used to change the signing identity and provisioning profile based on building "Debug" vs "Release". However they can be put to a lot more use for you. Accessing the settings for your project, settings that are configured here will be inherited by all the targets in your project.

Accessing the build configuration editor for this project file. When adding new build configurations, new entries will be added for each target in the project file. As mentioned in section about build configurations in " Managing Xcode ", each target can have a different xcconfig file assigned to it based on build configuration.

If you have multiple targets that differ in how the settings are configured rather than differing in code implementation, then using build configurations to abstract those changes can help prevent introducing the complexity of another target to your project file.

Note: Please take note of the dropdown menu underneath the list of build configurations. When running xcodebuild it will automatically pick a build configuration if there is none specified. You can show or hide detail for a capability by clicking the disclosure triangle to the left of the capability name.

For capabilities that are off, this area describes the capability and actions that occur when the capability is turned on. For capabilities that are on, use this area to view or update any associated configuration and to identify issues that need fixing. On-demand resources are app contents that you download only when needed. They are hosted on the App Store separately from the app bundle downloaded by the user.

You can use on-demand resources to enable smaller apps, faster downloads, and richer app content. You use tags to identify and manage the on-demand resources in a target. The Resource Tags pane shows the list of tags and the associated resources. You can use it to add and remove tags as well as to move resources between tags. For more information on adding and using on-demand resources, see On-Demand Resources Guide. The Info pane for a target shows properties associated with your app, file types that your app can create or open, and for OS X, services provided by your app.

It defines code files, resources Defines a specific set of build settings that generate:. Scheme can be shared which helps you in CI, Carthage [Example] Dependency - Targets can have dependencies. Dependency is a source link against.

These dependencies can be linked statically or dynamically [About] There are two types of them:. Schemes know how to respond to certain actions e. If you wanted to gain deeper knowledge then watch the entirety of the video. The video is simple to follow yet very foundational. My answer is mostly off of that. A scheme is how you specify what you want to run and it also contains information about how you want to run it.

For example, I could have a project with an iOS app and a Watch app, and in that case, I would have one scheme to run my iOS app and one scheme to run my Watch app. And finally, the Archive action will build my app for release and put it in the archive that I can then use to distribute to my testers or to the App Store or to save for future crash log de-symbolication, or symbolication. You have references to source code files and resource files on disc, targets which actually build those files into products like your app, Build settings which configure how your targets build their products, and schemes which configure how you perform actions, such as Run, with your targets.

Now, to access your project settings, you select your project in the navigator, you select the popover at the top of the editor, and select your project there.

You have references to source code files and resource files on disc, targets which actually build those files into products like your app, Build settings which configure how your targets build their products, and schemes which configure how you perform actions, such as Run [test, build], with your targets.

A target contains the instructions to build one thing like an app or a framework. The thing that your target produces is called its product. The set of steps that your target takes to build its product are called build phases. Now, one thing to note is that both projects and targets have Build settings, and targets inherit the value set at the project level but can override them with a target-specific value. A target's build phases do things like cause dependencies to build first, compile the source files in that target, and link the target against libraries and frameworks.

Like a single app can have an iOS target along with a watchOS target. Or just a single iOS Target. Or a single iOS target along with a test target, etc. To explicitly quote Apple docs :. A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace.

A target defines a single product; it organizes the inputs into the build system—the source files and instructions for processing those source files—required to build that product.

Projects can contain one or more targets, each of which produces one product. The instructions for building a product take the form of build settings and build phases, which you can examine and edit in the Xcode project editor.

A target inherits the project build settings, but you can override any of the project settings by specifying different settings at the target level. There can be only one active target at a time; the Xcode scheme specifies the active target. A target and the product it creates can be related to another target. If a target requires the output of another target in order to build, the first target is said to depend upon the second. If both targets are in the same workspace, Xcode can discover the dependency, in which case it builds the products in the required order.

Such a relationship is referred to as an implicit dependency. You can also specify explicit target dependencies in your build settings, and you can specify that two targets that Xcode might expect to have an implicit dependency are actually not dependent.

For example, you might build both a library and an application that links against that library in the same workspace. Xcode can discover this relationship and automatically build the library first. However, if you actually want to link against a version of the library other than the one built in the workspace, you can create an explicit dependency in your build settings, which overrides this implicit dependency.

You can have a scheme that has all the diagnostics enabled which makes debugging slow vs. Or a scheme that runs certain performance related tests vs. You can edit a scheme so that it performs such actions as:.