This merely declares "class TestClass will be defined".
In this case (the one you pasted) this has no effect of whatsoever, so these are the same.
However, in case you're going to define a protocol that would use your class name (as type of parameters passed to delegate, for example), you will need to declare @class TestClass before the protocol definition, as your class is still not defined.
In general, if you need to mention your class name before the class definition is made, you will need to issue @class declaration first
As per Matt's answer there's absolutely no point to the @class declaration in your code. @class forward defines a class so that the compiler subsequently knows what general sort of unit you are referring to. Since Objective-C is pretty much typeless at runtime, that's often all that the compiler actually needs to know — just enough to distinguish the thing from an atomic C value.
I'm going to take a stab in the dark and say that because the instance variables are declared in the @interface you're looking at some old code. Because it's old code, the @class probably used to be somewhere else (eg, there was a delegate protocol declared in between) and has just ended up harmlessly stranded.
@class effectively tells the compiler that such a class exists somewhere and, thus, pointers declared to point to instances of said class are perfectly valid. However, you couldn't call a method on an instance reference whose type is only defined as an @class because there is no additional metadata available to the compiler (I can't remember if it reverts the call site to being evaluated as a call through id or not).
In your example, the @class is harmless, but entirely unnecessary.
@class is pretty handy when you need to define a protocol for an object that will usually interact with the object whose interface you are also defining. Using @class, you can keep the protocol definition in header of your class. This pattern of delegation is often used on Objective-C, and is often preferable to defining both "MyClass.h" and "MyClassDelegate.h". That can cause some confusing import problems
@class MyClass;
@protocol MyClassDelegate<NSObject>
- (void)myClassDidSomething:(MyClass *)myClass
- (void)myClass:(MyClass *)myClass didSomethingWithResponse:(NSObject *)reponse
- (BOOL)shouldMyClassDoSomething:(MyClass *)myClass;
- (BOOL)shouldMyClass:(MyClass *)myClass doSomethingWithInput:(NSObject *)input
@end
// MyClass hasn't been defined yet, but MyClassDelegate will still compile even tho
// params mention MyClass, because of the @class declaration.
// You're telling the compiler "it's coming. don't worry".
// You can't send MyClass any messages (you can't send messages in a protocol declaration anyway),
// but it's important to note that @class only lets you reference the yet-to-be-defined class. That's all.
// The compiler doesn't know anything about MyClass other than its definition is coming eventually.
@interface MyClass : NSObject
@property (nonatomic, assign) id<MyClassDelegate> delegate;
- (void)doSomething;
- (void)doSomethingWithInput:(NSObject *)input
@end
Then, when you are using the class, you can both create instances of the class as well as implement the protocol with a single import statement