The problem of deciding the language of a header file already exists between C and C++, both of which use the .h extension.

The way CDT handles this is to rely on the index. The index stores information on the include relationship between files (used by the include browser). When parsing a header file in isolation the first step is to use the index to find a source file that includes the header. This file is called the "source context". The language of the source context is used to parse the header. If the source context cannot be computed then I believe it falls back on the project type, i.e. if its in a C project the header will be parsed as C etc. If there is more than one source file that includes the header then I believe the index returns the first one that was encountered during indexing. Take a look at TranslationUnit.getSourceContextTU().

So to get this to work properly for Objective C you need that information in the index, which I'm guessing is not available at the moment. Otherwise you may need an Objective C project type.

As a work around you can use the language mappings to force the language. Go to the project properties and choose C/C++ General > Language Mappings, then pick Objective C for the C header content type. Language mappings can also be set up programatically using the LanguageManager, for example the new UPC project wizard maps .c files to the UPC language.

Creating a new file.h within an objective c project results in Eclipse
defaulting to 'C header type' (as seen by right-clicking on the file
and going to properties). I don't know how to get it recognised as an
Objective-C header file instead, without which, the parser doesn't
seem to be kicked in.