Edit AllPages

Add your tips for General/XCode here:

Recent Tips (applicable to General/XCode 2.3)

* Enabling Warnings If you’d like to enable as many of gcc’s compiler warnings as possible, there are a few pitfalls to be aware of when doing so with Xcode. The following is my advice based on my experience.

First, go to your project or target settings and filter the build settings using the “Warnings” collection. Now uncheck all the warning options.

As suggested by Apple in this their “Static Analysis” document a good place to start is adding -Wall and -Wextra to the “Other Warning Flags”. gcc provides zillions of warnings, but a great many of the most useful ones are enabled by these two simple flags.

Next you need to add additional warnings one by one. There are a few ways to do this.

The best choice is to enable a warning using the checkboxes Xcode provides. Note though that many of these checkboxes are for warnings that are already included by -Wall and -Wextra.

The next best choice is to put the warning in the “Other Warning Flags” setting. However some warnings only apply to some languages and gcc will give a warning if a warning flag is passed when compiling a file of the wrong language! So if you have a project with multiple languages (.c, .m, .mm, .cp, etc.) you will get warnings about your warnings! :(

To work around this, C-only warnings need to be added to “Other C Flags” (make sure your “Other C++ Flags” do not include “Other C Flags”) and C++-only warnings need to be added to “Other C++ Flags”. There is no “Other Objective-C flags”, so Objective-C-only warnings will need to be specified per-file.

One reason to prefer the checkboxes Xcode provides (over adding flags) is that Xcode is then smart enough to only apply language-specific warnings to files of the corresponding language. For example, prefer the “Effective C++ violations” checkbox over -Weffc++ because the former is smart and is only applied to C++ files, the latter will generate annoying warnings for any .m or .c files in your project.

So now the question is: which warnings are available that are not included by -Wall and -Wextra, which are language-specific, and which do not already have a checkbox in the Xcode GUI? For that, you need to read through the gcc man page.

I have compiled a fairly comprehensive list, but I’m sure it’s not fully complete. I’ve organised them by language and included some comments, including the name of the built-in Xcode setting for the warning (ie the ones with corresponding checkboxes):

C only ——


-Wtraditional If you care about K&R C

-Wdeclaration-after-statement If you care about pre-C99







C++ only ——–









Objective-C only —————-

-Wselector gives very many warnings



All languages ————-

-Wsystem-headers Apple’s header give too many warnings





-Wlarger-than-len you have to pick len, for example: -Wlarger-than-10000


-Wcast-qual Useless for Cocoa, will warn for: General/NSString* str = @”hello”; <rdar://4625600>



-Wconversion Useless for Cocoa, will warn for: [button setEnabled:YES]; warning: passing argument 1 of ‘setEnabled:’ with different width due to prototype <rdar://4625881>: Behaves Correctly








-Wunreachable-code Will warn on every line where you use assert() from assert.h. <rdar://4625614>








For my projects, some of the above warnings are too obnoxious, here are the exact settings I use for my projects’ xcconfig files:

// C-only warnings GCC_WARN_ABOUT_MISSING_PROTOTYPES = YES OTHER_CFLAGS = -Wdiv-by-zero -Wbad-function-cast -Wstrict-prototypes -Wold-style-definition -Wnested-externs

// C++-only warnings GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS = YES GCC_WARN_ABOUT_INVALID_OFFSETOF_MACRO = YES OTHER_CPLUSPLUSFLAGS = -Wabi -Wctor-dtor-privacy -Wstrict-null-sentinel -Wsign-promo

// Objective-C-only warnings: must be set per file in multi-language projects, // try adding them to WARNING_CFLAGS and see if you get superfluous warnings // -Wstrict-selector-match -Wundeclared-selector

// For all languages GCC_WARN_FOUR_CHARACTER_CONSTANTS = YES GCC_WARN_ABOUT_MISSING_NEWLINE = YES GCC_WARN_ABOUT_DEPRECATED_FUNCTIONS = YES GCC_WARN_SHADOW = YES WARNING_CFLAGS = -Wall -Wextra -Wundef -Wendif-labels -Wlarger-than-10000 -Wpointer-arith -Wcast-align -Wwrite-strings -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Winline -Winvalid-pch -Wdisabled-optimization -Wshorten-64-to-32 -Wformat=2

– smcbride

Recent Tips (applicable to General/XCode 2.1?)

*By right-clicking in the breakpoints gutter (the thing on the left side of the editor window where you can click to set breakpoints), a contextual menu will appear with a bunch of useful options for debugging. You can “Continue to Here”, add breakpoints with actions such as “Log stack trace and auto-continue”, and a bunch of other nifty things.

Recent Tips (applicable to General/XCode 1.5)

Old Tips (not applicable to General/XCode 1.5)

– note that you’ll need to restart General/XCode to see the change

– this is apparently fixed in 1.2: * The Groups pane in the documentation window no longer disappears.* (Release Notes)

– this is fixed in 1.2 – General/CatfishMan

See also: General/ProjectBuilderTips

Watch out! Xcode HATES spaces! Don’t have your project or framework in a path that contains a space! From Apple’s release notes:

Any build setting that contains a path (or includes another build setting that resolves to a path) must be enclosed in double quotes if the path is likely to contain a space character. Xcode will handle the quoted value correctly, but will fail if an unquoted value resolves to a path that includes a space.