Why use id when we can just use NSObject?

id erases the type and it is equivalent to saying "this object responds to any selector visible to the translation". Of course, it is your responsibility to make sure your program is correct when you erase types (and also when you typecast them).

If the type were NSObject, then the compiler would say "NSObject may not respond to selector" if the selector was not declared in NSObject's interface or the protocols it adopts. In that event, you could also add a typecast to cast it to the type you expect.

With strict/correct types, the compiler can kick in and help you out, which is great because ObjC is a very dynamic language.

id is particularly useful when using (or building) collections types. Adding an object would not be a problem unless you defined a new root type (does not inherit from NSObject). Getting a value from the collection would require a typecast if we were to use it as something other than our base class (NSObject).

Objective-C does not support generics - you cannot, for example, declare an NSArray of NSStrings. You can populate an NSArray with NSStrings and pass this through id for a more natural written style when type safety is not preserved (a la generics).

So, let's expand on this with some real code.

Example A

NSString * string = [array objectAtIndex:0]; // << trust me (via id)return [string length];-or-return [[array objectAtIndex:0] length]; // << trust me (via id)

Example B

And now let's say id is not available and we fix all our compiler warnings because it's the right thing to do:

NSString * string  = (NSString*)[array objectAtIndex:0]; // << typecast == trust mereturn [string length];-or-return [(NSString*)[array objectAtIndex:0] length]; // << typecast == trust me

id doesn't decide its value at runtime, nor does any NSObject. ObjC objects don't perform implicit promotions, they just cast the pointer through without formal promotion.

Related to your example, I actually declare my delegates and parameters as NSObjects with protocols:

NSObject<MONShapeDelegate>* delegate;

every object is a subclass of NSObject

That is an incorrect statement. You can create objects that do not inherit from NSObject. it's not really recommended, but it is possible.

NSProxy is an example - it does not inherit from NSObject.

typedef struct objc_object {    Class isa;} *id;

Above is the actual definition of the id in Objective-C language. Objective-C runtime system is built around id and Class. Nothing have to do with NSObject or common super class.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-SW3

The NSObject Class

NSObject is a root class, and so doesn’t have a superclass. It defines the basic framework for Objective-C objects and object interactions. It imparts to the classes and instances of classes that inherit from it the ability to behave as objects and cooperate with the runtime system.

A class that doesn’t need to inherit any special behavior from another class should nevertheless be made a subclass of the NSObject class. Instances of the class must at least have the ability to behave like Objective-C objects at runtime. Inheriting this ability from the NSObject class is much simpler and much more reliable than reinventing it in a new class definition.

I think, this is because it is originally C not C++ (or other more strict typing languages).