Coming from an object oriented programming such as actionscript or java this feature may seem a little different. At least it felt different to me. It took sometime for me to get the understanding. It was un-believable for me, at first, and all magical.
In ObjectiveC there is a feature called Category. Its another way to extend a class. If we compare with inheritance, well it can not be compared to that. As one might be knowing that, ObjectiveC itself, provides option for inheritance.
Category adds functionality to the class itself.
What?!! Yes, its that powerful. I must say it again. It adds functionality to the class itself. Its not inheritance. As with inheritance one must use the child class, to get the added functionality. But with “Category” the added functionality is available to the class itself. Wherever one might have used the class, if a new Category is added, that class just gets the functionality. Thats magic!! Yes, kind of. But then its fun and powerful, when you know the real power of it. “I can do that by adding functionality to my class file itself”, there you said it. Lets talk about situations.

Just imagine, you have a class and used it everywhere, and later you wanted to add some functionality to the class itself without ever touching the class file. The situation may arise, that one is using an external library of some kind. That library is maintained by someone else. So, you never worry about it and just use it. What if, you want to add some functionality to some class of that library. Ohh well, “I will change the class”. What if the licensing policy do not allow you to do it? Or better, lets say, if you change it and the library is updated! You have to change the updated class again! And chances are that, the functionality is now written with some other logic in the library, which makes your implementation of the class unusable. You have to re-write it in the class. And thats a lot of work, if you think the library is getting updated regularly.

Lets take a situation, where one subclasses a class and used it. Well, the same thing may happen, that the root lib is updated and used a different approach this time. All the subclass logic need to be updated!

In another scenario, one may need some more functionality to the class. Well, we subclass it again. Nice and fine as long as you have used it in some places you remember. There may be cases one need to remove the first subclass and add the subclass of the first subclass. And thats a lot of work too.

Lastly, what if one needs to add functionality to the base SDK or the parent library. Subclass it and use it, simple. But we have already seen problems with subclassing. One has already used the base class through out the project, but later on it is required to add some functionality to the class. Either some how one has to add the functionality to the base class or subclass it and use the subclass everywhere, the base class was used previously.

Ok, coming back to Category. It allows a user to add functionality to the base class itself. One need not touch the class itself. It can be done even to the original ObjectiveC classes shipped with Apple SDK. That means, if we have used a class and later decide we need to add some more functionality to it, we are safe on with Category. As soon as it is declared, the functionality is available to all the places, where the base class is used.

Lets see how we can do it, some syntaxes and naming conventions.

Defining a Category, is kind of same a defining an ObjectiveC class. One needs 2 files for it. An interface file and an implementation file. The file naming conventions are generally as “ClassName+CategoryName.h” and “ClassName+CategoryName.m”. Where “ClassName” is the name of the class one needs to extend or add functionality to and “CategoryName” is the name of the Category one is defining now.
Each Category in a project must have a different name.
Categories can not define or add instance variables to a class.
Categories can override methods of the parent class.
Lets define a category :

//file name GameAddition+ShadowText.h
#import 
@interface GameAddition (ShadowText) 
-(SPSprite *)makeText:(NSString *)text 
			withColor:(int)colorValue 
			  andSize:(int)size 
	  withShadowColor:(int)shadowColor;
@end

And the implementation file will look as

//file name GameAddition+ShadowText.m
#import "GameAddition+ShadowText.h"
@implementation GameAddition(ShadowText)
-(SPSprite *)makeText:(NSString *)text 
                    withColor:(int)colorValue 
                       andSize:(int)size 
        withShadowColor:(int)shadowColor
{
	//custom code goes here
}
@end

the difference here is both in interface and implementation file the declaration is changed to

@interface ClassName (CategoryName)

instead of just

@interface ClassName 

And same happens with implementation file too, instead of

@implementation ClassName 

the category implementation file will declare it as

@implementation ClassName (CategoryName) 

. The category name will be on parenthesis.

Now thats all to it. Wherever we would have used the class “GameAddition”, a new method is available to it. But then we need some work there too. Just to make the application know we are using the category, wherever we have imported “GameAddition.h”, we have to import “GameAddition+ShadowText.h” instead. And there we go.

Hope that helps someone out there.

References :
1. http://cocoadevcentral.com
2. http://macdevelopertips.com