The answer harkens back to the C roots of Objective-C. Objective-C was originally written as a compiler pre-processor for C. That is, Objective-C wasn’t compiled so much as it was transformed into straight C and then compiled.
Start with the definition of the type id. It is declared as:
typedef struct objc_object {
Class isa;
} *id;
That is, an id is a pointer to a structure whose first field is of type Class (which, itself, is a pointer to a structure that defines a class). Now, consider NSObject:
@interface NSObject <NSObject> {
Class isa;
}
Note that the layout of NSObject and the layout of the type pointed to by id are identical. That is because, in reality, an instance of an Objective-C object is really just a pointer to a structure whose first field — always a pointer — points to the class that contains the methods for that instance (along with some other metadata).
When you subclass NSObject and add some instance variables you are, for all intents and purposes, simply creating a new C structure that contains your instance variables as slots in that structure concatenated on the slots for the instance variables for all superclasses. (The modern runtime works slightly differently so that a superclass can have ivars appended without requiring all subclasses to be recompiled).
Now, consider the difference between these two variables:
NSRect foo;
NSRect *bar;
(NSRect being a simple C structure — no ObjC involved). foo is created with the storage on the stack. It will not survive once the stack frame is closed, but you also don’t have to free any memory. bar is a reference to an NSRect structure that was, most likely, created on the heap using malloc().
If you try to say:
NSArray foo;
NSArray *bar;
The compiler will complain about the first, saying something along the lines of stack based objects are not allowed in Objective-C. In other words, all Objective-C objects must be allocated from the heap (more or less– there are one or two exceptions, but they are comparatively esoteric to this discussion) and, as a result, you always refer to an object through the address of said object on the heap; you are always working with pointers to objects (and the id type really is just a pointer to any old object).
Getting back to the C preprocessor roots of the language, you can translate every method call to an equivalent line of C. For example, the following two lines of code are identical:
[myArray objectAtIndex: 42];
objc_msgSend(myArray, @selector(objectAtIndex:), 42);
Similarly, a method declared like this:
- (id) objectAtIndex: (NSUInteger) a;
Is equivalent to C function declared like this:
id object_at_index(id self, SEL _cmd, NSUInteger a);
And, looking at objc_msgSend(), the first argument is declared to be of type id:
OBJC_EXPORT id objc_msgSend(id self, SEL op, ...);
And that is exactly why you don’t use *foo as the target of a method call. Do the translation through the above forms — the call to [myArray objectAtIndex: 42] is translated to the above C function call which then must call something with the equivalent C function call declaration (all dressed up in method syntax).
The object reference is carried through because it gives the messenger — objc_msgSend() access to the class to then find the method implementation — as well as that reference then becoming the first parameter — the self — of the method that is eventually executed.
If you really want to go deep, start here. But don’t bother until you have fully grokked this.