Xcode: project settings vs. target settings

Question

I\'m creating a static lib on Mac OS X for one of our customers, as well as a small cmd line app to test the static lib. The cmd line project has 2 extra library search paths, w

Answer 1

Preface: you ship targets. Your end products are targets. Not projects. Think of a project as the umbrella above multiple targets.

For a more realistic example assume both Uber and Lyft were being developed by the your (umbrella) company.

The company has the following three environments:

• Debug
• QA
• Release

The Debug and Release configs come out of the box with every new project you create. You can create as many additional configs as you want

This would require 3 configurations. To add a QA configuration follow the tutorial here

Did I apply this to the target or project?

I applied it to the project.

Ok so configs are only for projects and not for targets. Right?

Incorrect! It's confusing I know. You have to think of the project as a big container where you create your configs in there.

Then for each target (not project), for following tabs:

General, Resource Tags, Build Phases, Build rules, Info:

There is no difference between different configs

Signing and Capabilities tab:

You can switch between teams and sign it with a different team. This is useful if you want to sign your beta builds with your enterprise certificate but sign your Appstore build with app store certificate.

Build Settings tab:

For almost every variable in this section you can give a different value based on the config. Common Build Settings to customize are:

• Architectures - 'Build Active Architecture only'
• Build Options 'Debug Information Format'
• Packaging
  • Set the plist you want per configuration.
  • Change the bundle identifier (Packaging >> Product Bundle Identifier). If you switch values for a field then in the plist you'll see as:
• Signing
  • Code Signing identity
  • Code Signing Style (Manual or Automatic)
  • Development team
  • Provisioning Profile
• Apple Clang - Optimization Level

If the values are different then the row's value would be

<Multiple values>

and you basically have to expand that value to see what value is given for debug and what value is given for Release or QA config.

If all the values are the same then you'll just see the value that is given to all of them. By default the values are the same.

Long story short, this allows you to have 2 different apps (targets) with the same code (project), in 3 different environments (dev, QA, release). You create the different environments using configurations.

To learn more on this I highly recommend you to read more about this in depth and understand what configuration files (xcconfig) is. It's much more simpler than you think. It's mainly a key value pair:

• AppCoda - Using Xcode Configuration (.xcconfig) to Manage Different Build Settings
• NSHipster - Xcode Build Configuration Files

Answer 2

A project can contain multiple targets. For example, an app I write has four - the app itself, a Quick Look plugin, a framework and a bundle that contains Mac OS 10.6-specific functionality that can be dynamically loaded in.

Project settings apply to every single target in the project. Each target can then override individual settings if they need to - for instance, my project's Target SDK is set to 10.5, but the 10.6-specific bundle has it's Target SDK set to 10.6.

In some instances, some settings don't make sense to be in Project Settings - one of these, I guess, is search paths.

Answer 3

You often have multiple targets in a single project - for instance, you might have a framework project with a target for building as a dynamic .framework bundle, and a target for building a static lib. Or your app might have a target for building the app itself, and a target for building some helper command-line tool that it needs to install.

Wherever possible, I'd suggest changing settings at the highest level (in the project settings, and simultaneously changing debug & release configurations), and only customizing the target settings when necessary. Even better, move as many settings as possible into xcconfig files, which seem a much more explicit way of specifying your build setup.