Use of extern in Objective C

You'll find that extern is used extensively in the Cocoa frameworks, and one would be hard-pressed to find a convincing argument that their OO is "spoiled". On the contrary, Cocoa is well-encapsulated and only exposes what it must, often via extern. Globally-defined constants are certainly the most common usage, but not necessarily the only valid use.

IMO, using extern doesn't necessarily "spoil" object orientation. Even in OO, it is frequent to use variables that are accessible from anywhere. Using extern is the most frequent workaround for the lack of "class variables" (like those declared with static in Java) in Objective-C. It allows you to expand the scope in which you can reference a symbol beyond the compilation unit where it is declared, essentially by promising that it will be defined somewhere by someone.

You can also combine extern with __attribute__((visibility("hidden"))) to create a symbol that can be used outside its compilation unit, but not outside its linkage unit, so to speak. I've used this for custom library and framework code to properly encapsulate higher-level internal details.

There are some use cases for the extern keyword in Objective-C.
Aaron Hillegass suggests to create global notification names extern. e.g.:

extern NSString* const XYYourNotification;

You then define the actual NSString* in your implementation

It depends on what do you use it for. It is perfectly valid to use it to access to globally defined constants.
If you have a global object, however, I'd suggest using Singleton instead.

Another example of a problem when not using extern:

Say you have a global variable in a header file:

NSString *globalVar = @"Wonderful";

And you use it in 3 places by importing that header file. You're code won't compile, the linker complaining that you have 3 duplicate symbols defined in your code. To solve it you have two ways out:

Use static, in which case each file that imports that header will have its separate reference defined (and changing one string won't affect the other strings imported in other files):

static NSString *globalVar = @"Wonderful";

Use extern in the .h file and define it in the .m file. This way there will only be one reference defined, and each file will use that same reference (changes being reflected in all files):

extern NSString *globalVar; // in .h

NSString *globalVar = @"Wonderful"; // in .m

Choose the approach that fits best.

Depends on your need, for example you have login page. After you logged in you are notifying to other pages in the applications.

#import <Foundation/Foundation.h>

extern NSString *const DidLoginNotification;

@interface LoginViewController : NSObject
- (void)login;
@end


// LoginViewController.m
#import "LoginViewController.h"

//define extern const in implementation file only once for the whole process
NSString *const DidLoginNotification =
    @"DidLoginNotificationNotified";

@implementation LoginViewController

- (void)login {
    // Perform notification
    [[NSNotificationCenter defaultCenter];
    sendNotificationName: DidLoginNotification
                    object:nil];
}

The notification receiving party does not need to know the value of the const.