What is the difference



 Employee *person = [[Employee alloc] init];
        id person = [[Employee alloc] init];

could someone please let me know. and why its not id *person?



Good question.

There may well be other reasons, but three that I can think of:

[li]By using the real object type for the variable, the compiler can provide warnings when you’re trying to do something that doesn’t work with Employee instances[/li]
[li]Xcode can provide useful code completions, which is a big deal, given how verbose Objective-C is[/li]
[li]Future maintenance is easier when you know what’s what. It’s not such a big deal when a variable is declared and used back to back, but when code stretches out and objects are passed around between different pieces of your system, it gets more challenging[/li][/ul]

Some programmers really appreciate the freedom of non-typed variables, I imagine, but in a large program, I want the compiler to be able to tell me if I’m clearly doing something wrong. Much better than the user discovering something after I’ve shipped my software. (There’ll be enough of those bugs as is.)


The id type is defined as just a pointer to an Objective-C object (it’s not actually a class), and the asterisk is even included in its definition. Therefore,

id myObject; // a pointer to an object, called myObject
id *myObject; // a pointer to a pointer to an object

id is completely generic, and is a type that declares a pointer that can point to any object of any type. If you really wanted to, you could write your entire application using only ids, since the actual type of an object isn’t determined until it’s allocated:

id myString = [NSString stringWithString:@"Hello, world!"];
id myArray = [NSArray arrayWithObject];
// etc.

This, however, is extremely unwise, as you would (a) be hated by your future self for having written code that is difficult to read, and (b) lose the benefit of useful compiler warnings that can help you find out when you accidentally pass an object of the wrong type as an argument to a method.

id is extremely handy, however, when you honestly don’t know until your code is actually running what kind of object you have:

for (id someObject in someArray) {
    NSLog(@"Fancy that, I found an object of type %@ in the array.", NSStringFromClass([someObject class]));

In contrast, Person is a concrete class, and, like any other actual Objective-C class, you create a pointer to an instance of the Person class in the normal way:

Person *p = [[Person alloc] init];

I hope that helps - let us know if there’s any further confusion.


Thanks so much guys


I found this confusing as well at first.

You’ll find that we use id a lot more when dealing with Interface Builder and writing Cocoa and UIKit apps.

The biggest gain I see in Xcode is that you pick up code sense, autocomplete, and error checking when you are writing.


id is always a pointer, one that is not static in the type which it points to.
Using the type id really shines when you don’t know what type the object is going to be at a particular time it’s used. The power of this dynamic typing will become much more clear when you move ahead to dynamic binding and polymorphism.