XCode Build Settings

For the curious, here are the build settings I use and recommend, when using XCode for Mac and iOS applications.
Most of them activates the highest possible error reporting level.

At first sight, it may seem it's hard to code with those settings, but it really saves you a lot of time debugging your app.
Most of the problems usually encountered in application development, using Objective-C, comes from the Objective-C runtime. And sometimes, those problems are hard to debug, because of the dynamic nature of the Objective-C language.

Activating most of the compiler error flags will save you time, as the compilation will fail, with an error message, instead of leaving you with a app that crashed for apparently no reason.

About the "Unused Parameters" setting, if you really don't use a parameter, you can cast it to void, so the compiler won't complain:

void some_func( int some_param )
    ( void )some_param;
    /* ... */

When dealing with methods returning an id type, you may sometimes have to cast the object, to let the compiler knows about the type:

[ ( ClassName * )[ someObject getIdObject ] someMethod ];

So here are the settings, grouped as in the XCode build settings panel.


Dead Code Stripping


Activating this setting causes the -dead_strip flag to be passed to ld(1) via cc(1) to turn on dead code stripping.
If this option is selected, -gfull (not -gused) must be used to generate debugging symbols in order to have them correctly stripped.

[DEAD_CODE_STRIPPING, -dead_strip]

Link With Standard Libraries


If this setting activated, then the compiler driver will automatically pass its standard libraries to the linker to use during linking.
If desired, this flag can be used to disable linking with the standard libraries, and then individual libraries can be passed as Other Linker Flags.



Info.plist Output Encoding


Specifies the output encoding for the output Info.plist (by default, the output encoding will be unchanged from the input). The output endcodings can be 'binary' or 'XML'.


GCC 4.2 - Code Generation

Generate Debug Symbols


(Permitted for «Debug» configuration)
Enables or disables generation of debug symbols.
When debug symbols are enabled, the level of detail can be controlled by the build 'Level of Debug Symbols' setting.


Generate Position-Dependant Code


(No permitted for «Debug» configuration, or for shared libraries)
Faster function calls for applications. Not appropriate for shared libraries (which need to be position-independent).

[GCC_DYNAMIC_NO_PIC, -mdynamic-no-pic]

Inline Methods Hidden


When enabled, out-of-line copies of inline methods are declared private extern.

[GCC_INLINES_ARE_PRIVATE_EXTERN, -fvisibility-inlines-hidden]

Make Strings Read-Only


Reuse string literals.

[GCC_REUSE_STRINGS, -fwritable-strings]

Objective-C Garbage Collection

GCC_ENABLE_OBJC_GC = Unsupported

Compiles code to use Garbage Collector write-barrier assignment primitives within the Objective-C runtime.
Code is marked as being GC capable.
An application marked GC capable will be started by the runtime with Garbage Collection enabled.
All Objective-C code linked or loaded by this application must also be GC capable.
Code compiled as GC Required is presumed to not use traditional Cocoa retain/release methods and may not be loaded into an application that is not running with Garbage Collection enabled.
Code compiled as GC Supported is presumed to also contain traditional retain/release method logic and can be loaded into any application.
Garbage Collection is only supported on Mac OS X 10.5 and later.

[GCC_ENABLE_OBJC_GC, -fobjc-gc | -fobjc-gc-only]

Optimization Level

GCC_OPTIMIZATION_LEVEL = Fastest, Smallest [-Os]
  • None: Do not optimize. [-O0]

    With this setting, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results.
    Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.
  • Fast: Optimizing compilation takes somewhat more time, and a lot more memory for a large function. [-O, -O1]
With this setting, the compiler tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time. In Apple's compiler, strict aliasing, block reordering, and inter-block scheduling are disabled by default when optimizing.
  • Faster: The compiler performs nearly all supported optimizations that do not involve a space-speed tradeoff. [-O2]
With this setting, the compiler does not perform loop unrolling or function inlining, or register renaming.
    As compared to the 'Fast' setting, this setting increases both compilation time and the performance of the generated code.
  • Fastest: Turns on all optimizations specified by the 'Faster' setting and also turns on function inlining and register renaming options.
    This setting may result in a larger binary. [-O3]
  • Fastest, smallest: Optimize for size.
    This setting enables all 'Faster' optimizations that do not typically increase code size.
    It also performs further optimizations designed to reduce code size. [-Os]

GCC 4.2 - Language

C Language Dialect


(C99 permitted if absolutely necessary, especially on iOS)
Choose a standard or non-standard C language dialect.

  • ANSI C: Accept ISO C90 and ISO C++, turning off GNU extensions that are incompatible. [-ansi]
    Incompatible GNU extensions include the asm, inline, and typeof keywords
 (but not the equivalent __asm__, __inline__, and __typeof__ forms), and the '//' syntax for comments.

    This setting also enables trigraphs.
  • C89:
    Accept ISO C90, but not GNU extensions. [-std=c89]
  • GNU89:
    Accept ISO C90 and GNU extensions. [-std=gnu89]
  • C99:
    Accept ISO C99, but not GNU extensions. [-std=c99]
  • GNU99:
    Accept ISO C99 and GNU extensions. [-std=gnu99]
  • Compiler Default:
    Tells the compiler to use its default C language dialect. This is normally the best choice unless you have specific needs. (Currently equivalent to GNU89.)

Please see the full GCC manual for the full definition of all these settings on the C dialect:



GCC 4.2 - Warnings

Check Switch Statements


Warn whenever a switch statement has an index of enumeral type and lacks a case for one or more of the named codes of that enumeration.
The presence of a default label prevents this warning.
Case labels outside the enumeration range also provoke warnings when this option is used.


Effective C++ Violations


Warn about violations of the following style guidelines from Scott Meyers' Effective C++ book:

  • Item 11:
    Define a copy constructor and an assignment operator for classes with dynamically allocated memory.

  • Item 12:
    Prefer initialization to assignment in constructors.

  • Item 14:
    Make destructors virtual in base classes.

  • Item 15:
    Have operator= return a reference to *this.

  • Item 23:
    Don't try to return a reference when you must return an object.
and about violations of the following style guidelines from Scott Meyers' More Effective C++ book:
  • Item 6:
    Distinguish between prefix and postfix forms of increment and decrement operators.

  • Item 7:
    Never overload &&, ||, or, .

If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use grep -v to filter out those warnings.


Four Character Literals


Warn about four-char literals (e.g., MacOS-style OSTypes: 'APPL').


Global Construction or Destruction Required


Warn about namespace scope data that requires construction or destruction, or functions that use the constructor attribute or the destructor attribute.
Additionally warn if the Objective-C GNU runtime is used to initialize various metadata.


Hidden Local Variables


Warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in function is shadowed.


Implicit Conversion to 32 Bit Type


Warn if a value is implicitly converted from a 64 bit type to a 32 bit type.

[GCC_WARN_64_TO_32_BIT_CONVERSION, -Wshorten-64-to-32]

Incomplete Objective-C Protocols


Warn if methods required by a protocol are not implemented in the class adopting it.
Only applies to Objective-C and Objective-C++.


Inhibit All Warnings


Inhibit all warning messages.


Initializer Not Fully Bracketed


Warn if an aggregate or union initializer is not fully bracketed.
Example, Here initializer for a is not fully bracketed, but that for b is fully bracketed.

int a[ 2 ][ 2 ] = { 0, 1, 2, 3 };

int b[ 2 ][ 2 ] = { { 0, 1 }, { 2, 3 } };

Mismatched Return Type


Causes warnings to be emitted when a function with a defined return type (not void) contains a return statement without a return-value.
Also emits a warning when a function is defined without specifying a return type.


Missing Braces and Parentheses


Warn if parentheses are omitted in certain contexts, such as when there is an assignment in a context where a truth value is expected, or when operators are nested whose precedence people often get confused about.
Also warn about constructions where there may be confusion to which if statement an else branch belongs.
Here is an example of such a case:

    if( a )
        if( b )

In C, every else branch belongs to the innermost possible if statement, which in this example is if (b).
This is often not what the programmer expected, as illustrated in the above example by indentation the programmer chose.
When there is the potential for this confusion, GCC will issue a warning when this flag is specified.
To eliminate the warning, add explicit braces around the innermost if statement so there is no way the else could belong to the enclosing if.
The resulting code would look like this:

    if( a )
        if( b )

Missing Fields in Structure Initializers


Warn if a structure's initializer has some fields missing.
For example, the following code would cause such a warning, because "x.h" is implicitly zero:

struct s { int f, g, h; };
struct s x = { 3, 4 };

This option does not warn about designated initializers, so the following modification would not trigger a warning:

struct s { int f, g, h; };
struct s x = { .f = 3, .g = 4 };

Missing Function Prototypes


Causes warnings to be emitted about missing prototypes.


Missing Newline At End Of File


Warn when a source file does not end with a newline.


Multiple Definition Types for Selector


Warn if multiple methods of different types for the same selector are found during compilation.
The check is performed on the list of methods in the final stage of compilation.
Additionally, a check is performed for each selector appearing in a "@selector(...)" expression, and a corresponding method for that selector has been found during compilation.
Because these checks scan the method table only at the end of compilation, these warnings are not produced if the final stage of compilation is not reached, for example because an error is found during compilation, or because the -fsyntax-only option is being used.


Nonvirtual Destructor


Warn when a class declares an nonvirtual destructor that should probably be virtual, because it looks like the class will be used polymorphically.


This is only active for C++ or Objective-C++ sources.

Other Warning Flags

WARNING_CFLAGS = -Wall -Wextra -Werror -Wbad-function-cast -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wstrict-prototypes -Wdeclaration-after-statement

Space-separated list of additional warning flags to pass to the compiler. Use this setting if Xcode does not already provide UI for a particular compiler warning flag.


Overloaded Virtual Functions


Warn when a function declaration hides virtual functions from a base class.


For example, in:

struct A
    virtual void f();
struct B: public A
    void f( int );

the A class version of f() is hidden in B, and code like this:

B * b;

will fail to compile. This setting only applies to C++ and Objective-C++ sources.

Pedantic Warnings


Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++.
For ISO C, follows the version of the ISO C standard specified by any -std option used.

[GCC_WARN_PEDANTIC, -pedantic]

Pointer Sign Comparison


Warn when pointers passed via arguments or assigned to a variable differ in sign.


Prototype Conversion


Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype.
This includes conversions of fixed point to floating and vice versa, and conversions changing the width or signedness of a fixed point argument except when the same as the default promotion.
Also, warn if a negative integer constant expression is implicitly converted to an unsigned type.
For example, warn about the assignment "x = -1" if "x" is unsigned.
But do not warn about explicit casts like (unsigned) -1.


Sign Comparison


Warn when a comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned.
This warning is enabled by -W, and by -Wall in C++ only.

[GCC_WARN_SIGN_COMPARE, -Wsign-compare]

Strict Selector Matching


Warn if multiple methods with differing argument and/or return types are found for a given selector when attempting to send a message using this selector to a receiver of type "id" or "Class".
When this setting is disabled, the compiler will omit such warnings if any differences found are confined to types which share the same size and alignment.

[GCC_WARN_STRICT_SELECTOR_MATCH, -Wstrict-selector-match]

Treat Missing Function Prototypes as Errors


Causes warnings about missing function prototypes to be treated as errors.
Only applies to C and Objective-C.

[GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS, -Werror-implicit-function-declaration]

Treat Nonconformant Code Errors as Warnings


Enabling this option will downgrade messages about nonconformant code from errors to warnings.
By default, G++ effectively sets -pedantic-errors without -pedantic; this option reverses that.
This behavior and this option are superseded by -pedantic, which works as it does for GNU C.


Treat Warnings as Errors


Enabling this option causes all warnings to be treated as errors.


Typecheck Calls to printf/scanf


Check calls to printf and scanf, etc., to make sure that the arguments supplied have types appropriate to the format string specified, and that the conversions specified in the format string make sense.


Undeclared Selector


Warn if a "@selector(...)" expression referring to an undeclared selector is found.
A selector is considered undeclared if no method with that name has been declared before the "@selector(...)" expression, either explicitly in an @interface or @protocol declaration, or implicitly in an @implementation section.
This option always performs its checks as soon as a "@selector(...)" expression is found, while -Wselector only performs its checks in the final stage of compilation.
This also enforces the coding style convention that methods and selectors must be declared before being used.

[GCC_WARN_UNDECLARED_SELECTOR, -Wundeclared-selector]

Uninitialized Automatic Variables


Warn if a variable might be clobbered by a setjmp call or if an automatic variable is used without prior initialization.
Detection of uninitialized automatic variable requires data flow analsys that is only enabled during optimized compilation.
Note that GCC cannot detect all cases where an automatic variable is initialized or all usage patterns that may lead to use prior to initialization.


Unknown Pragma


Warn when a #pragma directive is encountered which is not understood by GCC.
If this command line option is used, warnings will even be issued for unknown pragmas in system header files.
This is not the case if the warnings were only enabled by the -Wall command line option.

[GCC_WARN_UNKNOWN_PRAGMAS, -Wunknown-pragmas]

Unused Functions


Warn whenever a static function is declared but not defined or a non-inline static function is unused.

[GCC_WARN_UNUSED_FUNCTION, -Wunused-function]

Unused Labels


Warn whenever a label is declared but not used.

[GCC_WARN_UNUSED_LABEL, -Wunused-label]

Unused Parameters


Warn whenever a function parameter is unused aside from its declaration.

[GCC_WARN_UNUSED_PARAMETER, -Wunused-parameter]

Unused Values


Warn whenever a statement computes a result that is explicitly not used.

[GCC_WARN_UNUSED_VALUE, -Wunused-value]

Unused Variables


Warn whenever a local variable or non-constant static variable is unused aside from its declaration.

[GCC_WARN_UNUSED_VARIABLE, -Wunused-variable]

Warn About Deprecated Functions


Warn about the use of deprecated functions, variables, and types (as indicated by the 'deprecated' attribute).

[GCC_WARN_ABOUT_DEPRECATED_FUNCTIONS, -Wno-deprecated-declarations]

Warn About Undefined Use of offsetof Macro


Unchecking this setting will suppress warnings from applying the offsetof macro to a non-POD type.According to the 1998 ISO C++ standard, applying offsetof to a non-POD type is undefined.
In existing C++ implementations, however, offsetof typically gives meaningful results even when applied to certain kinds of non-POD types. (Such as a simple struct that fails to be a POD type only by virtue of having a constructor.)
This flag is for users who are aware that they are writing non-portable code and who have deliberately chosen to ignore the warning about it.
The restrictions on offsetof may be relaxed in a future version of the C++ standard.



Surya prakash
10/10/2012 11:56

I want to set this option GCC_TREAT_WARNINGS_AS_ERRORS = YES from command line along with xcodebuild. Is there any possibilities ? Please advice.

Thanks in advance.

Regards, Surya
Surya prakash
10/11/2012 11:00
I got the resolution.

Regards, Surya.
OCTO talks ! » Code iOS : fini de jouer !
01/10/2013 12:53
[...] initialement utilisés par Xcode (par exemple "Hidden Local Variables"). Ce site peut aider à choisir les différents flags à [...]
01/30/2013 17:28
This was extremely detailed.. thank you !
01/30/2013 17:29
This was extremely detailed post and learnt a lot.. thank you !
07/04/2013 09:46
It was extremely valuable and useful post which was explained in a clear way. Thanks